障害対応の後に待っている、地味に一番しんどい作業
夜中にPagerDutyの通知で叩き起こされる。原因を特定して、復旧して、朝までに一段落——ここまでは「対応」だから、まだ気力で乗り切れる。
本当にきついのは、そのあとに待っている「インシデントレポート」を書く作業だ。何が起きたか、いつ気づいたか、なぜ気づくのが遅れたか、再発防止策は何か。クライアントに出す報告書と、社内向けのポストモーテムの両方を、寝不足の頭で組み立てないといけない。
私が働いている受託の小さなWeb制作会社では、対応そのものより報告書作成に時間を取られることが珍しくない。「文章を整える作業」ならAIに任せられるはずだと思い、直近で起きた本番障害の報告書をChatGPTに下書きさせてみた。
TOI
障害対応そのものよりも「言語化」に体力を持っていかれる説、あると思う。
何が起きたか(伏せられる範囲で)
対象は、クライアントのコーポレートサイトに組み込んでいたお問い合わせフォームのバックエンド処理。デプロイ後にサーバーのメモリ使用量がじわじわ上昇し、深夜にプロセスが落ちてフォーム送信がエラーになった。復旧自体はプロセス再起動とロールバックで20分ほどで終わっている。実際の案件の詳細はぼかすが、「よくある本番障害」のパターンとして書いていく。
ChatGPTにインシデントレポートを下書きさせてみた
使った手順
- Slackの障害対応スレッド(時系列のやり取り)をコピーしてChatGPTに貼り付け
- 「このやり取りから、時系列・影響範囲・原因・復旧対応・再発防止策の5項目でインシデントレポートの下書きを作って」と指示
- 出てきた項目ごとに「この部分、事実と違う」「ここは推測が混ざっている」を指摘して直させる
- 最終的にクライアント向けと社内向け(ポストモーテム)の2バージョンに分けて整形させる
プロンプトはこんな形にした。
以下はSlackの障害対応スレッドのログです。
このログをもとに、次の5項目でインシデントレポートの下書きを作成してください。
1. 発生日時と検知経路
2. 影響範囲(誰に何の被害が出たか)
3. 発生原因
4. 復旧対応の内容と所要時間
5. 再発防止策
【制約】
・ログに書かれていない事実は絶対に補完しない
・推測が入る場合は「推測」と明記する
・専門用語はクライアント向けには言い換える
【ログ】
(Slackのやり取りを貼り付け)出てきたのは「体裁は立派だけど中身の薄い」報告書だった
時系列と影響範囲は、ログに書いてある事実をそのまま整理してくれるので、ほぼそのまま使えるレベルだった。ここは素直に速い。「発生原因」と「再発防止策」の2項目は、正直そのままでは出せない内容だった。
原因の項目は「メモリリークが発生したため」という、Slackのログに書かれていた仮説をそのまま清書しただけで終わっていた。再発防止策も「監視を強化する」「メモリ使用量にアラートを設定する」といった、どの障害報告書にも当てはまりそうな一般論しか出てこない。
TOI
「監視を強化します」って、具体的に何をどう強化するのか書いてないと、次も同じことが起きるやつだ…
「本当の原因」を深掘りさせようとしてみた結果
なぜ表面的な内容しか出てこないのか気になって、「なぜメモリリークが起きたのか、根本原因まで掘り下げて」と何度か聞き直してみた。
- 1回目: 「特定のAPIエンドポイントで、リクエストごとに生成したオブジェクトが解放されていなかった可能性があります」
- 2回目「なぜ解放されなかった原因は?」: 「イベントリスナーの登録処理で、解除処理が対になっていない実装になっていた可能性があります」
- 3回目「そのコードのどこが原因か特定して」: ここで初めて「該当コードを共有いただければ、より具体的に分析できます」という返事になった
つまり、Slackのログという伝聞情報だけからは、ChatGPTも「もっともらしい仮説」を積み上げることしかできない。実際にコードを読んで「このイベントリスナーの解除漏れが犯人だ」と特定したのは、結局自分で該当コミットのdiffを追ってからだった。ChatGPTに聞き直した3往復は、正直「自分の仮説を裏付けるための壁打ち」以上の役には立っていなかった。
再発防止策も同様で、「コードレビューでイベントリスナーの解除処理を必須チェック項目に追加する」「Nodeプロセスのメモリ使用量を◯◯MBでアラートする」という、実装まで踏み込んだ内容に書き直せたのは、自分でコードの原因箇所を特定したあとだった。
クライアント向け報告書は、むしろChatGPTのほうが向いていた
一方で意外だったのが、社内向けポストモーテムより、クライアントに出す報告書のほうがChatGPTとの相性が良かったことだ。原因を専門用語のまま書くとクライアントには伝わらないので、「イベントリスナーの解除漏れによるメモリリーク」を「一部の処理でシステム内部のデータが解放されずに蓄積し、メモリ不足に至った」のように言い換える作業は、精度も速さも申し分なかった。
以前、脆弱性診断ツールWPScanの結果をAIに解説させたときも同じ構造だった。「見つける・整理する」はAIが速く、「本当に危険かの最終判断」は人間の仕事として残った。今回のインシデントレポートも、根本原因の特定という一番重い部分は変わらず自分の仕事だった。
結局どう使うのが正解だったか
今回の障害対応を通じて見えた、任せていい部分とダメな部分の境界線はこうだ。
ChatGPTに任せて良かった部分
- Slackログからの時系列・影響範囲の整理(事実の要約)
- クライアント向けの専門用語の言い換え
- 報告書のフォーマット・体裁の統一
自分でやるしかなかった部分
- 根本原因の特定(実際のコードを読んで検証する作業)
- 再発防止策を「実装レベル」まで具体化すること
- 「推測」と「確定した事実」の切り分けの最終判断
いちばんの学びは、ChatGPTに投げる前に「原因は自分で特定してから、文章化だけを任せる」という順番にすべきだったということ。原因究明そのものをChatGPTに丸投げすると、Slackログという伝聞情報の範囲内で「もっともらしい仮説」を生成してしまい、それを鵜呑みにして報告書を書くと、再発防止策が的外れになるリスクがある。
まとめ
- インシデントレポートの「時系列整理」「体裁統一」「クライアント向けの言い換え」はChatGPTに任せて速く済ませる
- 「根本原因の特定」は伝聞ログだけでは限界があるので、必ず実際のコード・ログを自分で確認してから書く
- ChatGPTへの深掘り依頼は「壁打ち」程度に考え、答えを鵜呑みにしない
- 再発防止策は「監視を強化する」のような一般論で終わらせず、実装レベルまで自分で具体化する
- 次に障害が起きたら、まず自分で原因を特定してから、ChatGPTには文章化だけを依頼する順番にする
コメント