インシデント対応とポストモーテム
運用フェーズの監視・インシデント対応(operate-monitor)の実施手順です。ピットイン方式の原則どおり、一次分析は AI・対処の判断は人という分担で回します。
graph LR A["検知<br>(監視アラート/報告)"] --> B["AI 一次分析<br>(影響範囲・原因候補)"] B --> C["重大度判定(人)"] C --> D["対処<br>(コア機能は理解保持者)"] D --> E["復旧確認"] E --> F["ポストモーテム<br>(重大度1・2は必須)"] F --> G["恒久層への書き戻し"]
重大度の判定基準
Section titled “重大度の判定基準”判定は当番の担当者が単独で即断します(重大度を合議にかけない。迷ったら高いほうに倒す)。
| 重大度 | 基準 | 初動期限 | エスカレーション先 |
|---|---|---|---|
| Sev1 | サービス全停止、データ破損・漏えいの疑い | 15分 | 価値責任者+技術判断者へ即時。顧客影響があれば事業決裁者へ |
| Sev2 | 主要機能の停止・著しい劣化(回避策なし) | 1時間 | 技術判断者 |
| Sev3 | 一部機能の劣化(回避策あり) | 営業日内 | 不要(記録のみ) |
| Sev4 | 影響のない異常(ログ・軽微なアラート) | 週次で棚卸し | 不要 |
AI と人の分担
Section titled “AI と人の分担”| 工程 | AI がやること | 人がやること |
|---|---|---|
| 検知・一次分析 | ログ・メトリクスの横断検索、影響範囲の推定、過去の類似インシデント・変更履歴の照合 | 分析結果の妥当性確認、重大度判定 |
| 対処 | 対処案の提示、ロールバック手順の生成 | 対処の決定と実行(本番への変更は必ず人が承認する) |
| 記録 | タイムラインの自動整形、記録の下書き | 事実確認、再発防止策の決定 |
- コア機能の障害は、理解を維持している担当者(コア理解維持タスク deep-read の記録者)が対応する。AI の推測だけで本番を触らない
- 復旧を急ぐ場合も、変更は hotfix ブランチ+PR で行い、CI と事後レビューを省略しない
生成の条件から影響範囲を絞る
Section titled “生成の条件から影響範囲を絞る”原因の変更が AI の生成によるもので、同じ誤りが他の変更にも入っている疑いがある場合は、変更ごとの生成の条件の記録(第5章 5.8.2)から、点検する範囲を絞ります。出荷済みの全成果物の一律の遡及点検は課しません。
| 手順 | 行うこと | 担い手 |
|---|---|---|
| 1 | 原因の変更の生成の条件(モデルの版、指示資産の版、担い手の識別、変更種別)を、記録から特定する。特定できない場合は、その事実をポストモーテムに書き、手順2 の範囲を出荷済みの全変更とする | AI が記録を引き、人が確かめる |
| 2 | 出荷済みのリリースから、同じ生成の条件を持つ変更を一覧にする。一覧は記録の機械的な抽出とし、AI の推定で絞らない | 機械 |
| 3 | 一覧を、リスク区分と、参照する壊してはならない品質条件(QC-NN)で並べる。R1 と、層1 の受容しない条件に関わる変更を先に置く | 機械 |
| 4 | 点検する範囲と順序を決め、点検しない範囲とその理由を書く | 技術判断者。Sev1 では D-0 表4 の有事の決定者が停止・切替・顧客説明を決める |
| 5 | 範囲・点検の結果・点検しなかった範囲をポストモーテムの「影響範囲の絞り込み」へ書く | 対応者 |
- 手順2 の一覧の作成を、AI の要約に置き換えない。生成の条件が同じ変更を漏れなく挙げることが目的であり、関連の推定は目的でない
- 点検しなかった範囲は、次の出荷の保証の開示の項目5 に、残存リスクとして載せる
- 生成の条件で範囲を絞り込めることは、実績で確かめていない(下記)
ポストモーテム(Sev1・Sev2 は必須)
Section titled “ポストモーテム(Sev1・Sev2 は必須)”復旧後3営業日以内に、個人を責めない(blameless)前提で書きます。目的は犯人捜しではなく、プロセスとシステムの欠陥の特定です。
# ポストモーテム: <インシデント名> / Sev<N>
- 発生日時〜復旧日時: (停止時間: N分)- 影響: <誰に・何が・どれだけ>- 対応者: <当番・エスカレーション先>
## タイムライン| 時刻 | 出来事(検知・判断・操作) || --- | --- |
## 根本原因<技術的原因と、それを見逃したプロセス上の原因の両方>
## 影響範囲の絞り込み(原因が AI の生成による場合)- 原因の変更の生成の条件: <モデルの版、指示資産の版、担い手の識別、変更種別。特定できなければ「特定できない」>- 同じ生成の条件を持つ出荷済みの変更: N件(一覧へのリンク)- 点検した範囲と結果: ...- 点検しなかった範囲と理由: <次の出荷の保証の開示の項目5 へ載せる>
## うまくいったこと / いかなかったこと- 良: <検知が速かった等>- 悪: <手順書が古かった等>
## 再発防止アクション| アクション | 種別(検知強化/修正/手順改善) | 担当 | 期限 || --- | --- | --- | --- |<!-- 「注意する」「周知する」は再発防止策として不可。仕組み(監視・CI・手順)の変更にする -->
## 書き戻し- 恒久層コンテキストへ反映した学び: <ファイルと PR>- 負債台帳へ移した項目: D-NNN- 再発防止アクションのうち自動化できるもの(監視の追加・CI チェックの追加)を優先する。「人が気をつける」型の対策は数週間で消える
- ポストモーテムの学びはコンテキスト基盤への書き戻しで恒久層へ反映する。これを怠ると AI の一次分析が同じ見逃しを繰り返す