パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生。ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず
パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生。ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず CDNプロバイダのCloudflareは、世界協定時4月15日の午後3時31分から午後7時52分（日本時間4月午前0時31分から午前4時52分）まで、ダッシュボードおよびAPIが使えなくなるという障害を発生していました。 Cloudflare Dashboard and API Outage on April 15, 2020https://t.co/zJctsOomVf — Cloudflare | #BuiltForThis (@Cloudflare) April 16, 2020 同社のブログ「Cloudflare Dashboard and API Outage on April 15, 2020」によると、同社の2つのコアデータセンターのうちの1
ファーストサーバの手順の問題点 - きしだのHatena
えらいことなってますが。 正規手順と今回の現象の説明などを含めた中間報告が出されています。 http://support.fsv.jp/info/nw20120625_01.html ここで、正規手順で、途中でオペレーションミスがあったときに復旧できない状態になってしまう可能性があることがわかります。 具体的には「原因3：メンテナンス仕様」のこの部分。 脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用する この時点でこの更新プログラムに不具合があった場合には、リストアできなくなることになるわけです。そして今回はそれがおきたようです。 より安全な手順であれば、バックアップ側にパッチをあてている間は正常系がバックアップのバックアップということになるはず*1ですが、どこにもバックアップがない状態になってしまったわけです。 手順１
ファーストサーバの事故から考えること
つい先日、ファーストサーバというホスティング企業が多数の顧客の全データを喪失するという前代未聞の事故が起こりました。 twitterやfacebookでは技術者や弁護士など、様々な方々が色んな観点からの議論を始めています。 私としても、今回の事故から得られた教訓と、弊社でのデータ保全の取り組みについてお話ししたいと思います。 大規模障害の概要と原因について（中間報告） ファーストサーバ サポートWEB こちらに中間報告があがっていますが、オペレーションミスによりサーバの削除タスクをバックアップ環境を含めた全サーバに対して適応してしまったという前代未聞の事故です。 動的にサーバのプロビジョニング(構成管理)を行う場合には、バグやオペミスによりデータを誤って消してしまうということは考えられますので、その点では作業手順やプログラムの安全品質については厳重な管理が必要と考えられます。 本質的な原因
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
