利益:
- インシデントのライフサイクル (検出、トリアージ、軽減、解決、事後分析)、MTTD/MTTR メトリクス、および「最初に軽減し、後で調査する」の原則を理解する能力
- AI を使用してインシデント発生時の仮説を絞り込み、責任のない事後スケッチを作成し、各根本原因をデータで検証する能力
- 事後分析を非難しない言語で記述し、イベントデータをマスクして共有するという規律を適用する能力。
どのシステムもいつかは壊れます。違いは、優れたチームがこの避けられない出来事に対してどのように準備し、どのように学習するかです。インシデントとは、サービスのクラッシュ、応答時間の急上昇、データの損失など、サービスを中断する、または中断する恐れのある予期しないイベントです。インシデント管理とは、インシデントをできるだけ早く検出、軽減、解決し、そこから学ぶことを意味します。これは、DevOps および SRE (サイト信頼性エンジニアリング) のプロフェッショナルを昼夜を問わず駆り立てる規律です。
イベントの品質を測定する 2 つの重要な指標、MTTD (平均検出時間) と MTTR (平均回復時間) です。目標は両方を縮小することです。ここで AI は 2 つの大きな価値を追加します。それは、イベント発生時のログとメトリクスを迅速に要約して考えられる根本原因を絞り込むことと、イベント後にポストモーテム (イベント後調査レポート) を迅速に作成することです。ただし、どのサービスをオフにするか、ロールバックするか、顧客に何を言うかなど、事態の推移に関する決定はあなたが行います。
イベントのライフサイクル
- 検知：アラームが鳴ったり、顧客からのクレームが入ったりします。早ければ早いほど良いです。
- トリアージ: どれくらい深刻ですか?ドメインとは何ですか?重大度レベルは、通常は SEV1 (最も重大、システム全体) から SEV4 (軽度) まで割り当てられます。
- 対応チームを編成します。重大なインシデントでは、インシデント指揮官が調整を引き受けます。
- 軽減: 最初に出血を止めます。多くの場合、ロールバックまたはフラグをカバーします。根本的な原因は後でわかります。
- 解決策: 永続的な修正を適用します。
- 学ぶ（事後）：何が起こったのか、なぜ起こったのか、どうすれば再発を防ぐことができるのか？
ヒント: インシデント発生時に最も高くつく間違いの 1 つは、「まず正確な根本原因を突き止めよう」という理由で止血を遅らせたことです。ルール: 最初にデクリメント (復元/復元サービス)、次に問い合わせます。多くの場合、正常であることがわかっているバージョンにロールバックすることが最も迅速な軽減策です。
罪悪感のない死後文化
健全なチームの根幹は、責任を問わない事後分析の文化です。目標は「誰がやったのか」ではなく、「どのシステムとプロセスがこのミスを許したのか」です。という質問です。人は罰せられると分かっていれば間違いを隠します。隠れたエラーが繰り返されます。事後分析は告発報告書ではなく、学習文書です。
優れた事後分析には、概要、影響 (ユーザー数、期間、金額)、タイムライン、根本原因、うまくいったこと/悪かったこと、およびアクション項目 (それぞれに所有者と日付が記載された具体的な対策) が含まれます。
注意: AI を使用して事後分析を作成するときは、非難的な言葉 (つまり、「X 人は間違いを犯した」など) を必ず排除してください。また、イベント データを AI にフィードするときに、クライアント ID、内部 IP、シークレットをマスクします。事後検証は広く共有されることがよくあります。
根本原因分析: 5 つのなぜと AI
古典的なテクニックは「5 Whys」です。「なぜ?」と尋ねます。問題に。何度も問いかけることで、表面的な症状から本当の根本にたどり着きます。 「サービスがクラッシュしました。なぜですか? メモリ不足です。なぜですか? リークがありました。なぜですか? ライブラリの更新です...」 AI はこのチェーンを素早く構築し、考えられる分岐を提案します。ただし、それぞれの「理由」をデータで検証する必要があります。 AI は、合理的だが間違ったチェーンを構築することもできます。
重大度テーブル
レベル
影響
例
介入
SEV1
システム全体/重大なビジネス損失
支払いは完全に中止されました
即座にチーム全員、指揮官
SEV2
重大な機能障害
ログインに失敗しました
迅速なオンコール + サポート
SEV3
部分的/限定的な効果
報告が遅れています
勤務時間中
SEV4
小型/化粧品
タイプミス
通常の作業キュー
ミニケース3個
ケース 1 — MTTR が 45 分から 8 分に。決済サービスがクラッシュしました。当直のエンジニアは、マスクされたログと最後の導入情報を AI に渡し、「過去 20 分間で最も可能性の高いトリガーは何ですか?」と尋ねました。彼は尋ねた。 AIは、最後の展開と同じ瞬間に崩壊が始まったことを示しました。エンジニアはすぐにそのバージョンをロールバックしました。サービスは 8 分後に戻りました。その後、根本原因 (新しいバージョンの接続プールのバグ) が都合良く調査されました。
ケース 2 — 20 分で死後スケッチ。 SEV2 の後、チームは疲れていて、レポートを書く気力がありませんでした。報告が何週間も遅れることもよくありました。今回は、タイムラインと事件のメモを AI に渡し、犯罪のない死後スケッチを作成しました。 AI は、インパクト、タイムライン、アクションアイテムのためのきちんとしたフレームワークを作成しました。チームはそれに事実を詰め込み、20 分で公開しました。教訓は失われていませんでした。
ケース 3 — 間違った根本原因が見つかった。あるケースでは、AI が「根本原因はデータベースの過負荷」であると言いましたが、それは合理的であるように思えました。しかし、エンジニアは指標を確認しました。インシデント発生時にはデータベースの負荷は正常でした。本当の原因は外部 DNS の問題でした。 AI に関する最初の仮説は流動的でしたが、間違っていました。データによる検証により、誤った結論を伴うレポートの発行が防止されました。
コピー可能な 4 つのテンプレート
1) インシデント発生時の迅速なトリアージ:
制作イベントを体験中です。マスクされた症状: [SYMPTOM]。最後の変更: [LAST DEPLOY/CHANGE]。教えてください:(1) 最も可能性の高い 3 つの根本原因仮説 (確率の順)、(2) それぞれを 1 分で検証するコマンド/メトリック、(3) 最速の SAFE 緩和ステップ (ロールバックなど)。厳密に言うと、それぞれの仮説を検証する必要があると述べます。
2) 無実の死後スケッチ:
以下の事件メモから、非難の余地のない死後スケッチを書きます。セクション: 概要、影響 (ユーザー/期間/コスト)、タイムライン、根本原因、うまくいったこと、うまくいかなかったこと、アクション アイテム (それぞれ所有者 + 日付フィールド付き)。ネーミング、プロセス、システムに焦点を当てます。注: [マスク済み]
3) 5 なぜなぜ分析:
次の症状から始まる「5 つのなぜ」チェーンを構築します: [症状]。各ステップで複数の分岐が考えられるかどうかを示します。それぞれの「なぜ」の隣に、それを検証するために調べる証拠 (ログ/メトリクス) を書きます。最後に、まだ検証されていないステップをマークします。
4) 実行可能な項目の作成:
この根本原因に応じて、同じイベントの再発を防ぐための実行可能な項目を提案します。各項目を、(a) 予防、検出または削減、(b) 推定される労力、(c) 影響によって分類します。影響/労力比が最も高い順に並べ替えます。根本原因: [X]
弱いプロンプト / 強いプロンプト
弱者: 「サービスがクラッシュしました。どうすればよいですか?」
結果: コンテキストなし。 AI は、お客様のケースに当てはまらない一般的な推奨事項を作成したり、決定的な根本原因を見つけ出すこともできます。
Strong: 「本番決済サービスは 5 分間 5xx を与え続けています。最後のデプロイは 6 分前です。最も可能性の高い 3 つの根本原因仮説を確率の高い順に与え、それぞれを検証するコマンドに指示し、最も速い安全な軽減策を提案します。具体的には言わず、検証する必要があると述べてください。」
違い: 2 番目のプロンプトでは、症状、タイミング、最後の変更が示されます。仮説 + 検証 + 削減が要求され、AI は不正確なままになります。
よくある間違い
- 軽減する前に正確な根本原因を探します。止血が遅れ、MTTRが増加します。
- AIの最初の仮説を検証せずに発表する。流動的ではありますが、誤ったルートがレポートへの漏洩の原因となります。
- 非難的な言葉遣い。匿名で書かれた事後調査は隠蔽を助長し、間違いを繰り返すことになります。
- 箇条書きのないアクション指向のレポート。所有者と日付のない提案は決して実現されません。
- イベントデータをマスクせずに共有します。事後分析は幅広い聴衆に伝わります。機密/個人情報が漏洩する。
- 事前にロールバック パスを準備していない。逆転が現実的でない場合、減少は遅くなります。
要約すれば
インシデント管理とは、避けられないイベントを迅速に検出、軽減、解決し、そこから学ぶことです。 MTTD と MTTR は重要な指標です。黄金律は「最初に軽減し、後で調査する」であり、既知の正常なバージョンに戻すことが最も早い軽減策であることがよくあります。 AI は、イベント発生時のログを要約し、仮説を絞り込み、イベント後に責任のない事後スケッチを作成する際に非常に貴重です。ただし、各根本原因仮説をデータで検証し、責任の言語を排除し、イベント データをマスクするのはユーザーの責任です。
アプリケーションタスク
過去の（または架空の）出来事を考えてみましょう。 （1）「現場迅速トリアージ」テンプレートを用いてAIに仮説と検証ステップを生成させる。どの仮説がデータによって確認できるかに注目してください。 (2) 「無罪事後概要」テンプレートを使用して報告書の概要を作成し、事実を記入します。 (3) 少なくとも 2 つの実行可能な項目を特定し、それぞれに所有者と日付を割り当てます。
チェックリスト
- [ ] インシデント発生時、私はまず軽減 (ロールバック/シャットダウン) を考え、根本原因を後回しにしました。
- [ ] AI のあらゆる根本原因仮説をログ/メトリクスで検証しました。
- [ ] プロセスとシステムに焦点を当て、事後分析を非難しない言語で書きました。
- [ ] 実行可能な各アイテムに所有者と日付を割り当てました。
- [ ] AIに与えたイベントデータから秘密や個人情報をマスキングしました。
- [ ] 影響に応じて重大度レベルを正しく割り当てました。