もし間違ってDROP DATABASEしてしまったら – area[nothing] : diary
2007/ 01 02 03 04 05 06 07 08 09 10 2006/ 01 02 03 04 05 06 07 08 09 10 11 12 2005/ 01 02 03 04 05 06 07 08 09 10 11 12 2004/ 01 02 03 04 05 06 07 08 09 10 11 12 2003/ 01 02 03 04 05 06 07 08 09 10 11 12 2002/ 01 02 03 04 05 06 07 08 09 10 11 12 2001/ 01 02 03 04 05 06 07 08 09 10 11 12 2000/ 01 02 03 04 05 06 07 08 09 10 11 12 1999/ 01 02 03 04 05 06 07 08 09 10 11 12 1998/ 01 02 03 04 05 06 07 0
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告 3月13日の11時53分から15時13分（いずれも日本時間）までの3時間20分のあいだ、GmailやGoogle Drive、Google Photos、Google Storage、App EngineのBlobstore APIなどGoogleの広範囲なサービスで一部の機能が利用できなくなる、あるいは遅延が発生するなどの障害が発生しました。 その原因と対策について、Googleが「Google Cloud Status Dashboardのインシデント#19002」として報告しています。 報告では障害の原因が、ストレージ内のリソースを削減しようとしたSRE（Site Reliability Engineer）による構成変更にあったと説明。 SRE（Site Reliabili
ING銀行の基幹データセンター、消防訓練で消火ガス噴射の衝撃音が大量のハードディスクとサーバを破壊。ATMや決済サービスが停止に
ING銀行の基幹データセンター、消防訓練で消火ガス噴射の衝撃音が大量のハードディスクとサーバを破壊。ATMや決済サービスが停止に オランダに本社を置く大手金融機関INGの基幹データセンターで、消防訓練のため消火ガスの噴射をしたところ予想以上に大規模な衝撃音が発生。大量のハードディスクやサーバが故障したと報道されています。 Fire drill knocks ING bank's data centre offline - BBC News ING Bank pays back fees to clients affected by system crash in Romania A Loud Sound Just Shut Down a Bank's Data Center for 10 Hours | Motherboard これにより9月10日土曜日の朝から夜まで、同社のATMやカード
ウィルス感染でWebサービスが20日間ダウン。本当にごめんなさい - Qiita
障害が起きたWebサービスは個人で運営しているサービスです。 2016年2月、障害から20日後にサービス再開しましたがアクティブユーザは以前の18%です。未だ回復の目処は立っていません。冗長化していないサーバがウイルス感染し、その後の対応も後手後手に回ってしまいました。 2016年1月末に起こるべくして起こった障害について記事にしてみました。ご迷惑をお掛けしてしまい本当に申し訳ありません。 ■ ユーザは、もう戻ってこない どんなウイルスに感染したのか SYNフラッド攻撃（SYN Flood Attack）を他のWebサイトに行うウイルスに感染して、確認していませんが他のサービスをSYNフラッド攻撃していたと思います。またウイルス感染時にサーバのsshdを書き換えられsshで接続できなくなりました。感染後にコンソールログインして書き換えられた醜い authorized_keys を見た時ゾッ
大規模障害から1年余り、あの企業が「その後」を語った
「この度は取材をお受けしましたが、どう対応したらよいか。今でも迷いがあります」。担当者は取材の冒頭で、心境をこう吐露した。 記者は取材のためレンタルサーバー事業を手掛けるファーストサーバ（本社：大阪市）を訪れた。1年半ほど前に、顧客企業が利用していたサーバー約5700台のデータをほぼ消失させる大規模障害を起こした事業者だ。 今回の取材は、過去に失敗を経験した複数の企業や公的団体に申し込んだ。目的は、「IT運用の失敗から技術者がどう学び、再発防止に取り組むべきか」をまとめる企画記事を執筆するためだ。 中でもファーストサーバは、運用のプロであるべきITベンダーが、一部とはいえ現場担当者のずさんな運用作業を見逃していた実態が明るみになり、個人としても大きな衝撃を受けた。失敗を経てどう体制を立て直したのか、大いに興味があった。 「非技術者」にも分かる再発防止策を：ファーストサーバ 簡単に、ファース
エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生
Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート
Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート 「2011年1月にHigh Replication Datastoreを立ち上げて以来、App Engineでこれだけ大規模なシステム障害を経験したことはなかった」。グーグルのGoogle App Engine Blogは10月26日付けのエントリ「About today's App Engine outage」でこう書き、同日発生したApp Engineの障害について報告しました。 この障害は10月26日のおおよそ午前7時半から11時30分までの約4時間、 App Engineのリクエストの約半分が失敗するという大規模なものでした。同社は以下のように経緯を説明しています。 ルータへの負荷が全データセンターへ拡大 4:00 am - Load begins increasing o
株式会社IDCフロンティア
IDCフロンティアのクラウドサービスが政府情報システムのためのセキュリティ評価制度（ISMAP... データセンター 2024年01月10日 【接続先追加】「バーチャルブリッジ」に主要IX事業者などの他事業者接続が追加 データセンター 2024年01月10日 令和6年能登半島地震の影響により、被災された地域のお客さまがご利用中のサービスについて支援措置を実施します。 サービス 2024年01月05日 新年のご挨拶 代表取締役社長 鈴木 勝久 その他 2024年01月04日 1月17日～19日に福岡で開催される「JANOG53 in Hakata」にブース出展します その他 2023年12月20日 ZDNET Japan Business＆IT ClassWork supported by ... その他 2023年12月15日 IDCフロンティア、「AIサービスのためのデジタルインフラ」を
Gmailの障害、原因はストレージソフトのバグ
ユーザーはGmailアカウントが空になったと報告しているが、Googleはメールは失われていないとしている。 米Googleは一部Gmailユーザーのメールが消えた問題について、ソフトウェアのバグが原因だと明らかにした。ユーザーのメールはなくなってはいないとも説明している。 この問題は2月27日（米国時間）から起きており、一部のユーザーがGmailアカウントが空になったと報告している。Googleは、メールはなくなってはおらず、既に影響を受けたユーザーの多くがメールにアクセスできるようになったとしている。近いうちにすべてのユーザーが通常の状態に戻るはずという。 このような問題が起きた原因は、ストレージソフトウェアのアップデートで予期しないバグが発生したためと同社は述べている。同社は問題に気づいてすぐに、ソフトウェアのバージョンを古いものに戻した。 Googleはユーザーのデータのコピーを複
2月5日に発生した障害について‐ニコニコインフォ
2月5日に発生した障害について 2011年02月06日Tweet 昨日のニコニコ動画サーバ障害ではプレミアム会員、一般会員問わず多くの方に たいへんご迷惑をおかけしてしまい申し訳ありませんでした。 原因は主にプレミアム会員向けハードウェアの故障ですが、 そのほかに ・ハードウェア障害検知の初動が遅れた ・ユーザーへの障害報告の遅れ・情報量不足 の２点、合計３点の大きな問題があったと認識しています。 復旧に時間がかかったのはインフラ構造上の理由で、根本的には 莫大なお金をかけることでしか解決できません。 プレミアム会員が堅調に伸びていけば1-2年単位で少しずつ改善していける見込みです。 インフラ費用については、 大会議などのイベントをやめると解決するというレベルではなく、 現状では動画配信設備の改善を生放送で増えている プレミアム会員の売上から捻出するという状態です。 但
SAKURA Internet // 2008年12月21日 「西新宿データセンター」における電源障害に関する質問および回答
2008年12月21日 お客様各位 さくらインターネット株式会社 平素よりさくらインターネットをご利用いただき、誠にありがとうございます。 12月19日に発生いたしました、弊社西新宿データセンター（所在地：東京都 新宿区西新宿）における電源設備からの発煙および電源供給障害につきまして、 皆様からお問い合わせの多い項目の回答を以下にまとめさせていただきました ので、お知らせさせていただきます。 ・火災について ・電源について ・サービスについて ・その他 ■火災について Q.火災は発生したのか？ A.現在のところ弊社および消防隊は、発煙のみを確認しており発火については 確認されておりません。 Q.消火設備はあるのか？作動したのか？ A.ハロン消火設備が設置されておりますが、発火の事実について確認されてお らず、消火設備は作動しておりません。 Q.発煙による人的被害はあったのか？ A.ございま
お客様を怒らせないシステム障害考 - （旧姓）タケルンバ卿日記避難所
Twitterも調子悪けりゃ、はてなも調子悪そうですねえ。Twitterはやっと過去ログ見れるようになったと思いきや、突然気絶するし、はてなもスターとブックマークとハイクが日替わりランチ状態で不調。ま、なんとか正常に戻ったようですけどねえ。関係者の皆様、お疲れ様です。 ただ、このあたりのトラブル対応を見るに、正直言ってもったいないなあと思うところがあります。ワタクシは外食や宿泊などのサービス・接客業勤めが長く、「申し訳ございません」（＠高嶋政伸）奉行だったせいもあって、このあたりのトラブル対応にもったいなさを感じるのですよ。クレーム対応のイロハみたいな大げさな話じゃなくて、その手前の「お客様を怒らせないコツ」というのかな。 そこで今回は「ユーザーを怒らせない障害解決方法」について書いてみたいと思います。僭越ながら、特にはてなさん向けに。いつも利用してるわけなんで、是非お役立ていただけたら幸
OSS Message Pedia
さあ、始めよう オープンソースプロダクトのメッセージを検索できます。あなたが使用しているソフトウェアのエラーメッセージの対処方法が分かります。 調査して欲しいメッセージ 153(ja) [4] Debug: sleeping function called from invalid context at : [1 month ago] 84(ja) [3] request_module: runaway loop modprobe [18 days ago] 5356(ja) [3] : VFS is out of sync with lock manager! [1 month ago] 22473(ja) [3] : dma_timer_expiry: dma status == 0x [3 months ago] 13057(ja) [3] tty_check_change: tty
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
再発防止策を考える技術 / #phpconsen
Downdetector
メンテナンス・障害情報 – さくらのサポート情報
弊社データセンターにおける通信障害について｜プレスルーム｜日鉄ソリューションズ
IDEA * IDEA