Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く

AWSの米国東部リージョン（US-EAST-1、バージニア北部）において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。 Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。 この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。 コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。 2月28日

[ip6ser]

コマンドのミスって絶対に起きるからね。こういうことが起きてよりクラウドは強化されるから、当たらなかった人はラッキーだ

[peperon_brain]

改善策のところが具体的だし「もうやった」なのがすごい。「管理を徹底し再発防止に努める」みたいなふわっとしたこと言わないもんな。

[luccafort]

ヒューマンエラーはいつまでたってもなくならないし、完全に防ぐことが難しいのだなあ。

[ymkjp]

彼がS3を止めた最初で最後の人類になることはまだ知る由もなかったー

[metamix]

ちょっと前にシステム復旧作業を公開配信してたシステム会社も、原因は同じくadmin権限者のコマンド打ち間違えだったな… あの会社もAmazonもミスを隠さずユーザーに共有していく姿勢が素晴らしい

[miyatakesan]

この規模でこの復旧対応は早いわぁ

[hidehara]

なるほどなぁ。成長し続けるシステムほど、自動化した作業の影響範囲を適切に維持し続けるのは難しいと感じた。適切なマージンを自動化の仕組み内部にも保持し続ける必要があるのだろうなぁ。

[kana0355]

“ツールがサーバを削除する速度を遅くすると同時に、システムの稼働維持に最低限必要な台数を超えたサーバを削除しないようにセーフティガードを追加した。ほかのツールにも同様のセーフティガードを導入した”

[nekoruri]

“今年後半に予定されていたさらなるセル分割作業の優先順位を高め、すぐさま取りかかるようにした” あーあーあー

[nilab]

Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く － Publickey

[richard_raw]

分かりやすい解説。「再起動とセーフティチェックのための整合性の検証にかかる時間が予想よりも長くかかってしまいました。」まあ頻繁にチェックするような項目じゃないですよね。

[uzuki-first]

内容と改善策が具体的

[onotomo_net]

S3ですら、障害が起きうるんですよと。

[raimon49]

敢えて「ツールがサーバを削除する速度を遅くする」っていうのも何だか凄い話だな…。

[akikan2]

後のRM-R事件である

[sucelie]

でも3時間で復帰できるのか。すげーな。

[snobsnog]

AWSでもあるんだよね……ヒューマンエラーはさ

[lwix]

単純なミスほど撲滅するのが難しい

[kei_0000]

あれ人的ミスだったのか。AWS位になれば、クリティカルな作業はせめて半自動化位にはなってると思ったけど。あのほぼ100%のデータ保全保証は大丈夫かな。

[katzchang]

「時間がかかった」というところ以外は想定通り復帰してるってことなのかな

[kuroaka1871]

"コマンドのミス"

[jt_noSke]

そうなんだ、うーん

[Mint0A0yama]

また一つ障害要因と対策の理解が深まった。解説に感謝🙏

[synbizmix]

詳しい解説。/Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く － Publickey

[sora_h]

まともな日本語記事だ。