注意
本記事の大部分は AI が書いています。
レビューはしていますが、内容の信ぴょう性については慎重に確認をしてください。
まえがき
私は LT などで発表することは比較的得意だと自覚しているのですが、記事の執筆には苦手意識があります。長い文章を書くのはスライドを作成することに比べて労力が大きいですし、面白い内容にするのはさらに努力が必要です。
一方で、最近は LLM の性能が非常に高く、構成さえ決めれば並の人間より質の高い文章を書けるようになっていると思います。
本記事は、社内エンジニア勉強会で発表予定の「障害対応のコツ」の構成をもとに、Claude 3.5 Sonnet に書いてもらった記事です。
Claude が書いた記事
怖くない！若手エンジニアのための実践的障害対応入門
〜深夜の障害対応で慌てないための心得と技〜
「え、マジで！？ヤバい、どうしよう...」
新人エンジニアの私は、初めての深夜アラートに固まってしまいました。
Subject: 【緊急】本番環境で障害発生
Time: 23:47
Priority: High
スマートフォンの画面を見つめる手が、小刻みに震えています。
そんな経験、あなたにもありませんか？あるいは、これから経験するかもしれない瞬間に、今から怯えていませんか？
大丈夫です。この記事を読めば、あなたも障害対応を乗り切れるようになります。なぜなら、障害対応は特別なスキルではなく、正しいアプローチと心構えがあれば、誰でも取り組めるものだからです。
なぜベテランは慌てないのか
同じ障害に直面しても、ベテランエンジニアはなぜか慌てません。その秘密は、実はシンプルです。
「ちょっと深呼吸してみよう」
私の隣に座ったベテラン山田さんは、まず私にそう声をかけました。そして、こう続けます。
「障害対応で最も大切なのは、冷静さを保つことなんだ。なぜかわかる？」
私が首を傾げると、山田さんはにっこりと笑って説明してくれました。
「だって、今起きている現象は、自然科学の実験と同じようなものだからさ。慌てて適当な対応をするより、まずは現象をよく観察することが大切なんだ」
サイエンティストになりきろう
そう言えば、高校の物理実験でも、最初に現象をよく観察していましたよね。
山田さんの言葉で、私の中で何かが腑に落ちました。そうか、障害対応は怖いものではない。ただの「観察と実験」なんだ。
「じゃあ、今からサイエンティストになりきって、この現象を調査してみようか」
実践！障害対応の具体的な手順
Step 1: 冷静になるためのテクニック
まず、深呼吸をします。そして、次の3つの質問に答えていきます：
- 「何が」起きているのか？
- 「いつから」起きているのか？
- 「誰が」影響を受けているのか？
これらの質問に答えることで、パニック状態から抜け出し、問題を客観的に見られる状態になります。
Step 2: データ収集のテクニック
「よし、まずはメトリクスを見てみよう」
山田さんと一緒に、モニタリングダッシュボードを開きました。
CPU Usage: 82% (↑40%)
Memory: 95% (↑30%)
Response Time: 2300ms (↑500%)
Error Rate: 15% (↑1400%)
「おや？面白いデータが取れたね」
山田さんが画面を指さします。
「このグラフの形、何か気付くことはある？」
私は、急激な上昇を示すグラフをしばらく見つめました。そして...
「あ！エラー率の上昇が始まる30分前から、メモリ使用率が徐々に上がっていってる！」
「その通り！いい観察眼だ」
山田さんが満足げに頷きます。
Step 3: ログ解析のテクニック
「次は、ログを見てみよう。でも、最新のエラーログだけじゃなくて、その前後も含めて見るのがコツだよ」
23:15:01 [INFO] Batch process started
23:15:05 [DEBUG] Processing items: 152,890
23:15:10 [WARN] Memory usage above 80%
23:45:01 [ERROR] OutOfMemoryError: Java heap space
23:45:02 [ERROR] Failed to process request
23:45:03 [ERROR] Connection pool exhausted
「あれ？深夜のバッチ処理の後からメモリ使用率が...」
「そう、見えてきたね。仮説を立ててみよう」
Step 4: 仮説を立てる技術
山田さんは、ホワイトボードに図を描き始めました：
バッチ処理開始 → 大量データ処理 → メモリ消費増加 → OOMエラー → システムダウン
「どう思う？このストーリーで説明がつく？」
「はい！バッチ処理が普段より多くのメモリを消費して、最終的にメモリ不足になった...というストーリーですよね？」
「その通り！じゃあ、検証してみよう」
Step 5: 仮説検証のテクニック
仮説を検証するため、私たちは次の3つのことを確認しました：
-
バッチ処理の対象データ量
SELECT COUNT(*) FROM batch_items WHERE date = CURRENT_DATE; -- Result: 152,890 (通常の3倍！) -
Javaヒープダンプの分析
jmap -dump:format=b,file=heap.bin <pid> -
前回のバッチ実行時のメトリクス
「なるほど、データ量が急増したことが原因だったんだ！」
実践的な対応策
緊急対応（今夜を乗り切る）
- バッチ処理の一時停止
- ヒープメモリの増加
java -Xmx4g -jar application.jar - 監視の強化
恒久対応（次の障害を防ぐ）
- バッチ処理の改善
- データの分割処理
- メモリ使用量の最適化
- 監視の強化
- メモリ使用率のアラートしきい値見直し
- バッチ処理の進捗モニタリング
若手エンジニアに伝えたい、障害対応の極意
その1: 恐れずに立ち向かう
「障害は、私たちの成長のチャンス」と山田さんは言います。
確かに、この一件で私は多くのことを学びました：
- メトリクスの読み方
- ログ解析の手法
- システムの挙動の理解
- 冷静に考えることの大切さ
その2: チームで戦う
一人で抱え込まない！これが重要です。
Bad:
「すみません、まだ原因調査中です...」
Good:
「現在、メモリ使用率の急上昇が見られます。バッチ処理との
関連性を調査中で、山田さんと一緒に解析を進めています」
その3: 記録と共有を忘れずに
障害対応が終わったら、必ず記録を残しましょう：
- 何が起きたのか
- どうやって対応したのか
- 何を学んだのか
これは、未来の自分や他のエンジニアへの贈り物となります。
まとめ：あなたにもできる！
この記事を読んでいるあなた。次の深夜アラートが来た時、もう怖くないはずです。なぜなら：
- 障害対応は、単なる「観察と実験」
- 正しいアプローチを知っている
- 具体的な手順を把握している
- チームで戦えることを知っている
そう、あなたは一人じゃない。しっかりとしたアプローチと、心強い仲間たちがいれば、どんな障害だって乗り越えられます。
さあ、次の障害対応、楽しみながらチャレンジしてみませんか？
「えっ、障害対応が楽しみ！？」って思いましたか？
でも、本当なんです。なぜなら、それは私たちエンジニアが成長できる最高の機会なのですから！
執筆方法
ここからは人間が書いた文章です。
最初に、LLM に書いて欲しい記事のアウトラインを箇条書きで作成しました。今回のアウトラインは以下の内容です。
記事執筆の前に用意したアウトライン
# 障害調査・対応の実践的アプローチ
## 1. 調査時のマインドセット
### サイエンスとエンジニアリングの違い
- サイエンティストの思考（観察と仮説検証）
- データに基づく客観的な観察
- 仮説の構築と検証
- 「なぜ」を追求する姿勢
- エンジニアの思考（問題解決と創造）
- 要件に基づく設計と実装
- 効率的な解決策の提供
- 「どうやって」を追求する姿勢
### なぜ調査にはサイエンティストの帽子が必要か
- 思い込みからの解放
- 現象の本質的な理解
- 体系的な原因特定
### 冷静さの重要性
- パニックは連鎖する
- 焦りは誤判断を招く
- チーム全体の士気への影響
## 2. 障害調査の基本的な流れ
### 事象把握のフェーズ
- 何が起きているのかを正確に理解する
- 影響範囲を特定する
- 事象の再現性を確認する
### 原因特定のフェーズ
- 仮説を立てる
- 検証を行う
- 根本原因にたどり着く
### 対応方針の決定フェーズ
- 暫定対応と恒久対応の判断
- リスクの評価
- 実施手順の検討
## 3. 事象把握の具体的手法
- 「コードを読まない」ことの重要性
- メトリクスの読み方
- 通常時との比較
- 相関関係の発見
- トレンドの把握
- ログの読み方
- エラーログの文脈理解
- 時系列での追跡
- パターンマッチング
## 4. 原因特定の具体的手法
- 仮説の立て方
- データからの仮説構築
- 可能性の列挙
- 仮説の検証方法
- ログやメトリクスによる検証
- 追加の調査項目の決定
- 根本原因の特定
- 表層的な症状と根本原因の区別
- 因果関係の整理
## 5. 対応方針の決定手法
- 暫定対応の検討
- 即時対応の必要性の判断
- リスクの評価
- 恒久対応の検討
- 根本的な解決策の設計
- 実装方針の決定
このアウトラインの作成にも LLM は活用していますが、この段階では人間が書いてそれを LLM にレビューしてもらい、フィードバックを修正して再度レビューしてもらう、というループで改善をしながら作成しています。
そして、このアウトラインをもとに記事を作成してもらったのですが、最初に生成された記事はアウトラインに引っ張られ過ぎて非常につまらない、内容も薄い記事となっていました。
そこで、
- 想定読者を指定する
- この記事によって、何を実現したいのかを明確にする
の2点を意識して、プロンプトに
対象読者は若手のエンジニアです。障害対応に対する苦手意識を、この記事を読むことによって克服するきっかけになることを目指します。
面白く読めること、有用な TIPS を得ること、次に障害対応をする際に勇気を得ることが重要です。
の2文を付け加えたところ、上記のような記事を得ることができました。
（細かくは幾度かフィードバックしていますが、最終稿を得るのに有効だったのはこの２文だと考えています。）
あとがき
数回修正は依頼しましたが、想像以上に面白い記事を書いてくれたと思います。
同様の手順で Gemini にも記事を書いてもらいましたが、こちらも少し毛色は違いますがなかなか面白いです。より有用な記事を書いてくれたのは Claude だったかなと思い、こちらを採用しました。
苦手意識がある記事執筆も LLM の手を借りることで効率を上げられる可能性があります。
自分の文章を守りつつ、生産性を向上するための工夫を考えてみようと思いました。
参考：Gemini 2.0 Experimental Advanced が書いた記事
# 障害対応、怖くない！〜 新米エンジニアよ、サイエンティストの帽子でバグに立ち向かえ 〜
「ピピピピピ…」
深夜2時、無機質なアラート音が静寂を切り裂く。鳴り響くスマートフォン。そこに表示された無情なメッセージ：**「ERROR: 500 Internal Server Error」**
新人エンジニアの佐藤は、飛び起きた。心臓がバクバクと早鐘を打つ。
「やばい、障害だ…」
初めての本格的な障害対応。佐藤は、不安と恐怖で手が震えはじめた。
しかし、ちょっと待ってほしい。深呼吸をして、この記事を思い出してほしい。そう、**障害対応は怖いものではない。**むしろ、エンジニアとして大きく成長できる、最高のチャンスなのだから！
## 1. 調査時のマインドセット：エンジニアの帽子を脱ぎ捨て、サイエンティストであれ
### 慌てるな！君はエンジニアである前に、科学者だ
障害発生！しかし、ここで慌ててはいけない。経験豊富なベテランエンジニアほど、こういう時こそ冷静だ。なぜか？彼らは、エンジニアである前に、**「サイエンティスト」** のマインドで問題に立ち向かう術を知っているからだ。
### サイエンスとエンジニアリング、その違いは？
* **サイエンティスト:** 「なぜ？」を追求し、観察と実験、仮説検証を通じて、真理を探求する。そう、シャーロック・ホームズのように。
* **エンジニア:** 「どうやって？」を追求し、要件に基づいて、効率的に問題を解決する。そう、ドラえもんのように。
障害調査の初期段階では、エンジニアの「どうやって直すか？」という思考は、ちょっと脇に置いておこう。まずは、サイエンティストの「なぜ起きたのか？」という思考で、現象を正確に理解することが先決だ。
### なぜ「コードを読まない」ことが重要なのか？
ここで、佐藤は、慌ててエラー箇所のコードを読み始めた。しかし、ベテランエンジニアの鈴木は、それを制止する。
「ちょっと待った！コードを読むのはまだ早い。まずは、データを見よう。」
なぜ、鈴木はコードを読むことを止めたのか？それは、コードを読むことで、**「思い込み」という名のバイアス**が発生してしまうリスクがあるからだ。
「この機能が怪しいはずだ」「このエラーは以前見たことがある」
こうした思い込みは、真実から目を逸らさせ、問題の本質を見えにくくしてしまう。まずは、先入観を捨て、**「データ」** という客観的な事実と向き合うことが大切なのだ。
### 冷静さが全てを制す
パニックは百害あって一利なし。焦りはミスを誘発し、状況をさらに悪化させる。
「落ち着いて、佐藤くん。深呼吸をしよう。我々は一人じゃない。チームで協力して解決するんだ」
鈴木の落ち着いた声に、佐藤は少しずつ冷静さを取り戻していった。
## 2. 障害調査の基本的な流れ：事象把握、原因特定、そして解決へ
障害調査は、大きく分けて3つのフェーズで進む。
**第1フェーズ：事象把握 - 何が起きているかを正確につかめ！**
1. **何が起きているのか？:** エラーメッセージ、ユーザーからの報告、システムのアラートなどから、発生している事象を正確に把握する。
2. **影響範囲は？:** どのサービス、どの機能、どのユーザーに影響が出ているのかを特定する。
3. **再現性は？:** 同じ操作や条件で、事象が再現するかどうかを確認する。
**第2フェーズ：原因特定 - なぜ起きたのか？真犯人を突き止めろ！**
1. **仮説を立てる:** 収集した情報をもとに、原因と考えられる仮説を複数立てる。名探偵のように、あらゆる可能性をリストアップしよう！
2. **検証する:** ログの確認、メトリクスの分析、テスト環境での再現など、様々な手法で仮説を検証する。
3. **根本原因にたどり着く:** 検証結果から、仮説を絞り込み、真犯人（根本原因）を特定する。
**第3フェーズ：対応方針の決定 - どう解決する？最善の一手を打て！**
1. **暫定対応と恒久対応の判断:** 緊急度と影響範囲に応じて、迅速な暫定対応と、再発防止のための恒久対応を検討する。
2. **リスクの評価:** それぞれの対応策のリスクを評価し、最も適切な方法を選択する。
3. **実施手順の検討:** 対応策を実行するための具体的な手順を策定し、チームで共有する。
## 3. 事象把握の具体的手法：データは語る、真実の物語を
「さあ、佐藤くん。データと対話する時間だ。」
鈴木は、佐藤をディスプレイの前に座らせた。
### メトリクスは語る：システムからのSOSを見逃すな！
メトリクスは、システムの健康状態を示す重要な指標だ。普段はおとなしいグラフたちが、障害発生時には、ここぞとばかりに異常値を叩き出し、何かを訴えかけてくる。
* **普段との違いは？:** CPU使用率、メモリ使用量、ネットワークトラフィックなど、通常時と比べて異常な値を示しているメトリクスはないか？
* **変化のタイミングは？:** メトリクスの値が急変したタイミングはいつか？それは、エラー発生時刻と一致しているか？
* **相関関係は？:** 複数のメトリクスを組み合わせて分析することで、事象の関連性が見えてくることがある。例えば、データベースの応答速度の悪化と、特定のエラー数の増加が同時に発生している場合、データベースがボトルネックになっている可能性がある。
### ログは語る：システム内部で起きている「事件」の痕跡
ログは、システム内部で起きている「事件」の痕跡を記録した、重要な証拠だ。
* **エラーログだけじゃない！:** エラーログだけでなく、アクセスログ、アプリケーションログなど、あらゆるログが重要な情報源となる。
* **時系列で追え！:** 複数のログを時系列で追跡することで、エラーの伝播経路や、関連する処理を特定できる。
* **パターンを見つけろ！:** 同じエラーが繰り返し発生していないか？特定のパターンが見られないか？
「このエラーログ、直前にデータベースへの接続エラーが出てるな。しかも、同時刻にDBサーバーのCPU使用率が跳ね上がってるぞ…これは怪しい！」
佐藤は、データの中に隠された真実の断片を見つけ出した。
## 4. 原因特定、そして解決へ：仮説検証の鬼となり、真犯人を追い詰めろ！
事象を把握したら、次は原因の特定だ。ここでは、立てた仮説を検証し、真犯人（根本原因）を突き止めるプロセスを解説する。
### 仮説検証は、実験だ！
データから得られた情報をもとに、原因と考えられる仮説を複数立てる。
「データベースサーバーの過負荷が原因かもしれない」
「新しくデプロイした機能にバグがあるかもしれない」
「ネットワーク機器の障害かもしれない」
そして、それぞれの仮説を検証するために、さらなる調査やテストを行う。
* **追加のログ調査:** 特定の処理に関するログをさらに詳しく調べる。
* **テスト環境での再現:** テスト環境で同様の事象を再現させ、原因を絞り込む。
* **パフォーマンス計測:** 特定の処理にかかる時間を計測し、ボトルネックを特定する。
「テスト環境で再現したぞ！どうやら、特定の条件下で、新しい機能がデータベースに過剰な負荷をかけているようだ！」
佐藤は、仮説を検証し、原因を特定することに成功した。
### 暫定対応、そして恒久対応へ
原因が特定できたら、いよいよ対応だ。
* **暫定対応:** まずは、迅速にサービスを復旧させることが最優先だ。例えば、問題のある機能を一時的に停止したり、サーバーを再起動したりするなどの対応が考えられる。
* **恒久対応:** 暫定対応で急場をしのいだら、根本的な原因を解決し、再発を防止するための対策を実施する。例えば、バグの修正、パフォーマンスチューニング、システムの構成変更などだ。
「佐藤くん、よくやった！これでシステムは復旧するはずだ。しかし、油断は禁物だ。恒久対応をしっかり行い、再発防止に努めよう。」
鈴木は、佐藤の肩をポンと叩いた。
## 5. 障害対応は怖くない！最高の成長のチャンスだ！
深夜の障害対応を終え、佐藤は疲労困憊だった。しかし、その顔には、達成感と自信が満ち溢れていた。
「鈴木さん、ありがとうございました！初めての障害対応で不安でしたが、なんとか乗り切ることができました！」
「佐藤くん、君はよくやった。今回の経験は、君を大きく成長させてくれたはずだ。障害対応は確かに大変だ。しかし、それは同時に、エンジニアとして大きく成長できる最高のチャンスでもあるんだ。」
鈴木は、朝日を浴びながら、佐藤に語りかけた。
### 障害対応で得られるもの
* **技術力の向上:** 普段は触れないようなシステムの深層部に触れることで、技術的な知識と経験が深まる。
* **問題解決能力の向上:** 困難な状況で、冷静に、論理的に問題を解決する力が身につく。
* **チームワークの強化:** チームメンバーと協力して問題を解決することで、絆が深まる。
* **自信:** 困難な障害対応を乗り越えた経験は、大きな自信となる。
そう、**障害対応は、エンジニアにとって最高の「実戦トレーニング」なのだ！**
この記事を読んだあなたが、次に障害対応に直面した時、少しでも前向きな気持ちで、そしてちょっぴりワクワクしながら、問題解決に取り組んでいただければ幸いだ。
さあ、あなたも一緒に、データと対話し、仮説を検証し、真犯人を突き止め、そして、最高のエンジニアへと成長しよう！
**障害対応は、怖くない！**