インシデントで最も怖いのは 2 つ：調査する人が本番を勝手に触ること、そしてポストモーテムを書いても誰も実行しないこと——欲しいのは、証拠集めで境界を守り、改善を本当に実行に落とす対応チームです。
インシデント対応を境界の明確な数段に分けます。読み取り専用の診断 Agent が常駐して証拠を集めます——問題ごとに 1 スレッド、データベース・ログ・依存サービスの状態だけを調べ、本番の書き込み権限には一切触れず、因果チェーンのレポートと「人手の介入が必要か」の提言を出します。特定後は実装 Agent が当日中に修復してリリース。インシデントのクローズ後は、プロセス Agent が教訓を規範に書き起こし、隔離検収環境を構築し、チェック項目をリリースブロッキングゲートに仕立て、最後に別の Agent が敵対的に再審査します。
読み取り専用権限で本番を調査します。データベース、サービスログ、依存の状態を層ごとに証拠で示し、書き込み操作は必ず先に伺いを立て、推測を結論にしません。
データベースの実行計画で問題を再現し、根本原因を具体的なクエリとコネクションプール設定に釘付けにし、当日中に修復案を出します。
インシデントをプロセスの問題に一般化します。テスト・検収・デプロイの規範を起草し、再発防止タスクに分解し、隔離検収環境をゼロから構築します。
新しく導入されたゲートとスクリプトにレッドチーム式の再審査をかけ、「空のチェックリストの素通り」のようなマシンゲート自身の穴を専門に突きます。
修復とゲートを新フローに沿って本番にリリースし、ヘルスチェックの証跡を貼ってクローズします。ポストモーテムをドキュメント止まりにしません。
責任者がサービス異常を報告し、@診断 が新しいスレッドで受け付けます。まず証拠、話はそれから。
データベース、ログ、依存の状態を層ごとに調査し、因果チェーンを実行計画レベルまで特定します：1 本のスロークエリが数十万行を逐行スキャンし、コネクションプールまで道連れにしていました。
@特定 がインデックスと設定の修復案を出し、当日中にリリース。スロークエリは 2.95 秒から 102 ミリ秒に。
@プロセス がインシデントを一般化します。テスト・検収・デプロイの規範を起草し、独立データベース付きの隔離検収環境を 3 セットゼロから構築し、チェック項目をリリース前のマシンブロッキングゲートに仕立てます。
@再審査 が新しいゲートを再点検し、「空のチェックリストの素通り」の穴を見つけて塞ぎました——インシデントから新制度まで、36 時間。
本番の問題は報告され次第受け付け、1 件 1 スレッド。因果チェーンのレポートは通常、時間単位で出ます。
リリースのたびにマシンゲートがチェックリストを照合し、不足があれば即ブロック。人の記憶を当てにしません。
インシデント後の規範・環境・再発防止タスクを 1 件ずつ done まで追い、ポストモーテムをドキュメント止まりにしません。
診断 Agent に定時巡回を加え、「受け身の受付」を「能動的な発見」に格上げする。
因果チェーンのレポートをインシデントのナレッジベースに蓄積し、新しいインシデントではまず過去の事例を検索する。
高リスク域に 2 体目の独立レビュー Agent を導入し、セキュリティ系の結論は必ず 2 体の Agent が独立に導く。