【AWS re:Invent 2024】インシデントの火消し、その次は？ [ARC207]

こんにちは、MSPの田所です。

AWS re:Invent 2024 のレポートです。
現場のイベント模様をお届けします。

セッション情報

The incident is over: Now what?

インシデントの火消し、その次は？

Good architecture helps minimize or avoid the impact of failures. Operational practice defines how to handle inevitable incidents and recover quickly. But what about the aftermath? How do you ensure that the true root cause has been tracked down and that effective preventive actions have been planned for implementation? How can you turn every incident into a learning opportunity? How do the shared responsibility model and third-party software vendors come into play? This session will share mental models and experiences around root cause analysis and correction of error (COE), so you can drive an effective practice in your own organization.

AWS がどのようにインシデント対応に取り組んでいるか紹介します！

Session types: Breakout session

1時間の Breakout セッション

今回のまとめ

• 心理的安全性を確保する
• なぜなぜ分析は質問を広げながら
• 対策は時間軸ごとに考える

セッションの詳細

1. インシデントの検知と対応

インシデントを検知した時、まずは誰を巻き込むかを決めます。
影響範囲の大きさによって変わるでしょうし、インシデントの発見が内部か外部かによっても変わるかもしれません。

そこから、原因調査と根本解決を行うチームと、顧客の復旧を支援するチームの二手に分かれて対応を行います。

そしてコミュニケーションの際は、情報の正確性と深さと速さのバランスが重要になると言います。
これは分かりみの深い領域です。
そしてバランスに答えがないのも一つの特徴です。

復旧対応としては、主に以下の選択肢が考えられます。

• 問題の箇所を切り離す
• 変更を戻す
• サービスを再起動する
• スケールアップする
• 変更を加える

問題を修正するのではなく、回避する方に重きを置いていますね。

そして短期の対処を完了させます。
すぐに再発しないよう対応した後は、根本対策に焦点を当てます。
担当者を割り当てて、COE (correction of error) と呼ばれる事後分析を開始します。

• correction of error (COE) を開発すべき理由

 

2. 振り返りと対策

復旧対応が完了したら、振り返りを行います。
聞き取り調査を行う場合は、何よりも心理的安全を確保することが大切であると言います。

そして以下をまとめていきます。

• 影響範囲
• 根本原因（なぜなぜ分析）
• 状況整理
• 学び
• 今後に向けたアクション

原因分析の 5 Whys について見ていきます。
5 Whys は一つの質問を掘り下げるのではなく、事象から浮かぶ複数の Why をそれぞれに掘り下げていきます。
実際の木や根の形を想像すると分かりやすいかもしれません。

顧客視点の原因分析も大切です。
顧客が知りたい情報を伝わる形で掘り下げていきます。
ここがしっかりしていれば、信頼を取り戻すチャンスになります。

今後のアクションについてです。
以下に分けて考えます。

• 短期：すぐに再発させない対策
• 中期：プロセス改善など継続性のある対策
• 長期：ツール利用や自動化などシステム的な対策

そして長期の対策は常にトレードオフを考える必要があります。
インシデントを再発させないための完璧なシステムを 1 から開発すれば、問題は解決するかもしれません。
ただしそこに投入する労力、時間、コストは見合っているか、冷静な判断が必要です。

 

3. 学びの共有

そしてプロセスの変更点や得られた学びは、個人で閉じずに横展開、共有します。
これにより他のチームで同じような問題が起こるのを防ぎます。

これまでのまとめです。

• 早めに巻き込む
• まずは復旧対応
• 原因分析は心理的安全を守りながら
• 改善や学びは横展開する

MSPとして

1. なぜなぜ分析の広げ方

MSPとしてインシデント対応は必須の業務ですが、取り入れられる部分があると感じました。
まず原因分析について、事象に対してなぜを広げていくことは、根本対策を考える上で非常に重要であると思いました。
一本の線で分析を行なってしまうと、間違ってはいないが効果的でもない対策に辿り着いてしまうこともあり、共通認識として持っておくべき分析の仕方であると思います。

2. 対策を時間軸で分ける

対策を短期、中期、長期に分けて取り組むことも重要であると感じました。
まずは復旧、そこから再発させないプロセス、そして自動化などシステム的な対策。
そのいずれも大切で、特に長期の対策が今後の負荷を圧縮することにも繋がります。
急ぎではない重要な事項として確実に進めていきたい領域です。

おわりに

運用チームとして、AWS のインシデント対応に学ぶべき点がたくさんありました。
AWS だったらどうやって対応するか思考を巡らせながら、会社としてより良いコミュニケーション、分析、対策をしていけるよう進めてまいります。

おしまい