壊れたとき、最初の10分で何をするか：運用と障害対応の設計【第8回・完結】

本番で障害が起きたとき、最初の10分で何をしますか。原因を調べ始めますか。この記事を読み終えると、止血を優先する初動を説明でき、壊れたことに早く気づく仕組みを設計し、同じ障害を繰り返さない振り返りができるようになります。ジュニアエンジニア向け開発フロー入門シリーズ（全8回）の最終回です。

🎯 テーマの主役：「運用と障害対応」——壊れる前提で設計する

今回の主役は運用と障害対応です。一言で言えば、運用とは「壊れることを前提に、早く気づき、早く戻し、同じ壊れ方を繰り返さない仕組み」です。

日常の例えで言うなら、救急外来のトリアージです。救急外来には、同時に複数の患者が運ばれてきます。医師は全員を順番に診ることはしません。まず命に関わる状態かどうかを短時間で判断し、優先順位を付けます（この判断をトリアージと呼びます）。そして最初にやるのは原因の特定ではなく、止血と呼吸の確保です。「なぜこの怪我をしたのか」を詳しく聞くのは、命が安定してからです。

障害対応も同じです。障害が起きたとき、最初にすべきは原因の究明ではありません。影響を止めること（止血）です。そして、状況を正確に共有し、落ち着いて戻す。原因の究明は、止血が終わってからでも遅くありません。第7回で「戻し方を先に決めておく」と書いたのは、まさにこの瞬間のためです。

第1回から第7回までで、変更は課題からリリースまで運ばれてきました。今回の第8回は、関門8の「運用」です。第1回の出口条件は「異常に気づく手段と、連絡先がある」でした。この記事では、その気づく手段（監視）と、壊れたときの動き方（障害対応）、繰り返さない仕組み（振り返り）を扱います。

この関門を通せるようになると、次の4つができるようになります。第一に、「壊れても早く戻せる」を目標として設定できること（100%を目指さない）。第二に、気づくための観測を設計できること。第三に、障害の初動10分を手順として持てること。第四に、振り返りを、学習に変えられることです。

動機：運用が「特別な日の作業」になっていないか

運用について、次のような状態に心当たりはないでしょうか。ふだんはシステムのことをほぼ考えない。障害が起きたときだけ、関係者が集まって慌てて対応する。監視のアラートは1日に何十件も鳴っていて、ほとんど無視している。障害が収束した後は「疲れたね」で終わり、次に同じような障害が起きて「またか」となる。

この状態の問題は、運用が「特別な日の作業」になっていることです。ふだん見ていないものは、変化に気づけません。アラートが常時鳴っている状態は、鳴っていないのと同じです（誰も見ないから）。そして振り返りがないので、同じ障害が繰り返されます。

第7回までで、私たちは変更を安全に届ける仕組みを作ってきました。しかしどんなに丁寧に作っても、壊れるときは壊れます。環境は変わり、データは増え、依存ライブラリは更新され、想定外の使われ方をします。「壊れないようにする」は目標になりません。目標になるのは「壊れたときに、早く気づいて、早く戻る」です。

この記事の仮説はこうです。運用の質は「障害が起きないこと」ではなく「障害の影響時間を短くできること」で測る。もしこれが正しければ、運用の設計は検知（気づく）・止血（止める）・学習（繰り返さない）の3つに投資する形になります。

🔍 検証①：目標は「100%動くこと」ではなく「許容できる壊れ方」

まず、運用の目標設定から始めます。よくある誤りは「可用性100%」を目標にすることです。100%は達成できません。そして、達成できない目標は誰も本気で目指さず、判断の基準にもなりません。

代わりに使われるのがSLO（Service Level Objective：サービスレベル目標）です。「このサービスは、月間で99.9%のリクエストを成功させる」という形で目標を決めます。99.9%という数字は、月あたり約43分の失敗が許容されることを意味します（30日を43,200分として計算）。99.99%なら約4分です。つまりSLOは、「どれくらい壊れてよいか」を先に決めるという考え方です。

この発想から生まれたのがエラーバジェット（誤り予算）です。「許容される失敗の総量」を予算として捉え、使い切ったら新機能の開発より安定化を優先するという判断に使います。逆に、予算が余っているなら、新しい変更を積極的に出してよいという判断もできます。エラーバジェットは、開発と運用の対立を、数字で解く道具です。

重要なのは、数字の高さより「合意があること」です。「このサービスは99.9%を目標にする。だから月43分までは止まってよい。ただしそれを超えたら、新機能より安定化を優先する」——この合意があれば、障害対応でも「どこまで頑張るか」の判断がぶれません。目標がない状態では、障害のたびに「どこまでやるか」を議論することになります。

🔍 検証②：観測の3本柱——ログ・メトリクス・トレース

「早く気づく」ためには、観測できる状態を作る必要があります。観測の手段は、次の3つに整理できます。

この3つは役割が違うので、置き換え関係にありません。メトリクスで異常に気づき、ログで詳細を確認し、トレースで経路をたどる——この流れが基本です。特に重要なのはメトリクスです。数値の時系列があれば、「ふだんと違う」に機械的に気づけます。ログだけでは、正常と異常の区別をいちいち人が読むことになります。

そして、設計時に決めておくべきことがあります。何を記録するかです。後から「あのときのログがない」と気づいても、その障害は再現できません。最低限、次の3つを決めます。①重要な処理の成功・失敗（利用者に影響する処理）、②所要時間（遅さは故障の前兆）、③追跡できるID（1つのリクエストを複数のログで追えるようにする）。特に③は、障害調査の速度を桁で変えます。「このIDの処理を全部見せて」と言えるかどうかが、調査時間を分単位か時間単位かに分けます。

🔍 検証③：アラートは「鳴らす」より「鳴らさない」設計が難しい

監視で最も難しいのは、アラート（警告）の設計です。比喩は火災報知器です。火災報知器は、鳴るべきときに鳴らなければ意味がありません。しかし同時に、誤報が多すぎると誰も見なくなります。料理の湯気で毎日鳴る報知器は、1週間で電池を外されます。監視も同じで、誤報の多いアラートは、存在しないのと同じです（そして、本当の火災のときに見逃されます）。

良いアラートの条件は、次の3つです。①人間の行動が必要であること（見て何もしないなら、それはアラートではなく記録）、②対応手順があること（何をすればよいか分かる）、③誤報が少ないこと（鳴ったら本当だと信じられる）。GoogleのSREの実践でも、「アラートは、人間が今すぐ行動すべきものだけにする」という原則が示されています。

もう1つ重要な分類が、症状ベースと原因ベースです。症状ベースは「利用者が困っている」を検知します（エラー率の上昇、応答時間の悪化、処理の滞留）。原因ベースは「特定の原因の兆候」を検知します（CPU使用率、ディスク残量、特定のサーバーの応答）。症状ベースを優先するのが原則です。理由は、原因は予想外のことが多いからです。CPUが原因だと思っていたら、実はネットワークだった——原因ベースのアラートだけを張っていると、想定外の壊れ方に気づけません。

🔍 検証④：障害対応の初動——最初の10分

障害が起きたときの初動を手順化します。原則は「止血が先、原因は後」です。

初動で最も重要なのは、「原因が分からなくても止血できる」という理解です。第7回で用意した戻し方（前のバージョンに戻す、機能を切る、打ち消しを出す）は、原因を特定していなくても実行できます。「怪しい変更を戻したら直った」という経験は、エンジニアなら誰でもあります。原因の特定は、止血が終わってからでも間に合います。むしろ、止血が終わって影響が止まっていれば、落ち着いて調査できます。

また、記録が重要です。「何時に、誰が、何をしたか」をタイムラインとして残します。これは振り返り（検証⑤）の材料になり、二次障害を防ぐ情報にもなります（「さっきこの設定を変えた」という情報が共有されていないと、別の人が同じ設定を触って混乱します）。記録は障害中に書くのは大変ですが、チャットに書き残すだけでも十分機能します。

🔍 検証⑤：振り返り——人を責めると、情報が消える

障害が収束した後の振り返り（ポストモーテム）が、運用の質を決めます。ここで最も重要な原則は、人を責めない（Blameless）ことです。

なぜ人を責めてはいけないのか。理由は合理的です。人を責める振り返りをすると、次の障害で情報が隠されます。「これは自分のせいかもしれない」と思った人は、自分の関与を報告しなくなります。すると、原因の全体像が見えなくなり、同じ障害が繰り返されます。第5回で見た心理的安全性と同じ構造です。責任を追及する場にすると、学習が止まります。

振り返りで書く内容は、次のとおりです。①タイムライン（何時に何が起き、何をしたか）、②影響（誰がどれくらい困ったか）、③原因（なぜ起きたか。複数の要因があることが多い）、④うまくいったこと（次も活かすこと）、⑤改善項目（誰が・いつまでに・何をするか）。特に④と⑤が重要です。振り返りが「反省文」で終わると、改善が起きません。

🔍 検証⑥：再発防止は「予防」だけを目指さない

振り返りから出る対策には、3つの層があります。①予防（起きなくする）、②緩和（起きても影響を小さくする）、③検知（早く気づく）。よくある誤りは、①予防だけを対策にすることです。「二度と起きないようにする」は目標として正しいのですが、原因が多様すぎて、予防だけでは尽きません。1つの原因を潰しても、別の原因で同じ症状の障害が起きます。

だから、3つの層をセットで対策にします。今回の障害で「検知が遅れた」なら検知の改善、「復旧に時間がかかった」なら緩和（戻し方の整備）を入れます。第1回で見た8つの関門がそれぞれ違う失敗を防いでいたのと同じ構造です。1つの層を厚くしても、他の層の失敗は残ります。

結果：障害対応のチェックリスト

ここまでの内容を、時系列のチェックリストにまとめます。障害の最中に読めるよう、短い項目にしています。

考察：運用は「品質の証明」ではなく「改善のループ」である

ここからは、検証では扱いきれなかった解釈を述べます。運用について最も重要な認識の変化は、「障害は失敗ではなく、情報」だということだと私は考えます。障害が起きたという事実は、システムと組織の想定が現実とずれていた場所を教えてくれます。その情報を活かせば、次に同じ場所で壊れにくくなります。逆に、障害を隠したり、責めたりすると、同じ場所で何度も壊れます。

この性質は、開発フロー全体の学びにも通じます。第1回から第8回までで見てきた8つの関門は、すべて「失敗を早く、安く見つける」ための装置でした。課題・要件は「作るものが違う」失敗を、設計は「変えられない」失敗を、テストは「壊れた」失敗を、リリースは「戻せない」失敗を、そして運用は「気づけない」失敗を防ぎます。運用は、この連鎖の最後であり、次のサイクルの最初です。運用で得た学びが、次の課題定義（第2回）に還元されて、ループが回ります。

もう1つの重要な点は、「壊れ方を選ぶ」という考え方です。すべての壊れ方を防ぐことはできませんが、どう壊れるかは設計できます。「この機能が壊れても、決済の処理は続く」「この部分が遅くなっても、他の機能は影響を受けない」「このサーバーが落ちても、残りで処理が続く」。これは第3回の境界の設計と、第7回のデプロイ戦略の延長線上にあります。障害対応の強さは、障害対応の訓練だけでなく、平時の設計から生まれます。

AI時代の視点を加えます。監視データの量は増え続けており、AIによる異常検知・アラートのトリアージが実用化しています。ただし、「これは対応すべき異常か」の判断と、振り返りでの「なぜ起きたか」の考察は、人間の仕事として残ります。AIは大量のデータから候補を絞るのが得意で、人間は文脈を知っているからです。第8回までで身につけた「失敗を早く見つけ、原因を仕組みから考える」という姿勢は、AIが候補を出してくれる時代にこそ、価値が上がると考えられます。

📌 注目ポイント

• 目標は100%ではなく「許容できる壊れ方」。SLO（例：99.9%＝月43分）で合意する
• エラーバジェットは、開発と運用の対立を数字で解く道具
• 観測はログ・メトリクス・トレースの3本柱。メトリクスで気づき、ログで原因を見る
• 設計時に記録するもの・見つけるIDを決める。後からログは作れない
• アラートは行動に紐づくものだけ。誤報の多いアラートは存在しないのと同じ
• アラートは症状ベースを優先する。原因は予想外のことが多い
• 初動は止血が先、原因は後。戻し方は事前に用意してある（第7回）
• 役割を分ける（指揮・調査・連絡）。全員が同じ調査をすると統制が失われる
• 振り返りは人を責めない。責めると情報が消え、同じ障害が繰り返される
• 再発防止は検知・緩和・予防の3層で考える。予防だけでは尽きない

💡 活用事例：壊れることを前提にしたNetflixの設計

「壊れないようにする」の発想を逆転させた事例が、Netflixのカオスエンジニアリングです。Netflixは2010年代から、本番環境で意図的にサーバーを落とすという取り組みを行っています。代表的なものがChaos Monkeyで、稼働中のサーバーをランダムに停止させます（2011年にオープンソース化され、後に「Simian Army」と呼ばれる一連のツール群に発展しました）。

なぜそんなことをするのか。理由は本記事のテーマそのものです。「壊れないこと」を目指すと、壊れたときの対応が訓練されません。Netflixのサービスは数千のサーバー上で動いており、どれかが落ちることは日常です。大事なのは「落ちないこと」ではなく、「落ちても全体が止まらないこと」です。そこで、日常的に壊すことで、壊れたときに動く仕組み（自動的な切り離し・再ルーティング）が実際に機能するかを確かめます。

この発想は、「もし〜なら」を日常的に試すという点で、開発フロー全体とつながります。故障注入（フォールトインジェクション）や障害訓練（ゲームデー）と呼ばれる手法は、金融・通信など他の分野にも広がっています。重要なのは、訓練を「本番に近い状態」で行うことです。テスト環境でいくら訓練しても、本番のデータ量・トラフィック・依存関係は再現できません。

そして、もう1つ忘れてはならない教訓があります。「バックアップがある」ことと「復元できる」ことは違うという点です。2017年、GitLabは本番データベースを誤って削除する事故を起こしました。復旧を試みたところ、5つのバックアップ手段のうち4つが機能しなかったことが判明し、復旧に約18時間を要しました（当時、同社はこの経緯を公開して報告しています）。この事故は、復元手順を実際に試していなければ、手順は存在しないのと同じであることを示しています。第7回で「戻し方を先に決める」と書きましたが、決めた手順は定期的に試す必要がある——これが、この事例の最も実用的な教訓です。

✅ 要点まとめ

• 運用の目標は「許容できる壊れ方」を決めること。SLOとエラーバジェットで合意する
• 観測はメトリクス（気づく）・ログ（原因）・トレース（経路）の3本柱
• 追跡用のIDを設計に入れる。調査時間が桁で変わる
• アラートは行動に紐づくものだけを鳴らす。誤報は監視全体を無効化する
• 初動は影響確認 → 初報 → 止血。原因の調査は止血の後
• 役割を分ける（指揮・調査・連絡）。タイムラインを記録する
• 振り返りは人を責めない。責めると情報が集まらなくなる
• 改善は検知・緩和・予防の3層で計画する
• 手順は試さないと存在しないのと同じ（バックアップと復元。GitLabの事例）
• 壊れ方を選べる設計（隔離・切り離し）が、障害対応の強さになる

🚀 取り込み方：明日から使う3段階

今日（5分でできること）：自分の担当するシステムについて、「壊れたとき、最初に何をするか」を1行で書いてみてください。書けない場合は、それが最大のリスクです。あわせて、監視画面（またはログ）を1分だけ眺めて、いまの正常な状態がどんな数値かを覚えておきましょう。異常は「正常を知っていること」からしか見つけられません。

今週（小さく試す）：エラー通知の1つを、行動に紐づく形に変えてみてください。悪い例は「エラーが1件発生しました」。良い例は「過去10分でエラー率が5%を超えました。まず◯◯を確認し、次に△△を試してください」。あわせて、追跡用のIDがログに入っているか（1つのリクエストを複数のログで追えるか）を確認し、入っていなければ1箇所だけ追加してみてください。

今月（定着させる）：振り返りの型を作り、直近の小さな障害（またはヒヤリとした出来事）で1回試してみてください。「タイムライン・影響・原因・うまくいったこと・改善項目（担当と期限）」の5項目です。あわせて、戻し方の手順を1つ実際に試してください。前のバージョンに戻す、フラグを切る、といった手順を、本番でなくてよいので1回実行してみます。試した手順だけが、いざというときに使えます。

🔥 ハマりポイント

その1：原因を特定してから直そうとする
「原因が分からないのに戻すのは怖い」という感覚は自然ですが、利用者の被害は待ってくれません。原因が分からなくても、怪しい変更を戻す・機能を切ることはできます。止血してから、落ち着いて原因を調べます。止血の判断を先に行うには、戻し方が事前に決まっていることが前提です（第7回）。

症状：障害の間、ずっと調査しており、影響が長引く。原因：止血を後回しにしている。対処：初動の手順に「止血の判断」を明記する。まず戻せないか考える。

その2：アラートを増やすことで安心する
「気づけるように」と考えてアラートを増やすと、鳴り続ける状態になります。すると誰も見なくなり、本当の異常が埋もれます。アラートの価値は数ではなく、信頼性です。「このアラートが鳴ったら本当に困っている」と言える状態を保ちます。増やすより、鳴らさない基準を作るほうが難しいのです。

症状：「アラートが多すぎて見ていません」という会話。原因：行動に紐づかないアラートの蓄積。対処：通知を止めてよいもの（記録のみ）、即時対応が必要なものに分ける。

その3：障害の後で個人を責める
「なぜ防げなかったのか」という問いは、個人に向けると情報を隠します。すると次の障害で、当事者が自分の関与を報告しなくなります。原因の全体像が見えなくなり、同じ障害が繰り返されます。問いかけるべきは「なぜこの仕組みで防げなかったのか」です（手順・検知・設計のどこが不足していたか）。第5回のレビューと同じで、コードや仕組みについて話し、人について話さないのが原則です。

症状：障害後に「誰が悪かったか」が話題になる。原因：個人責任の追及。対処：振り返りの質問を「仕組み」に向ける。タイムラインと再発防止に集中する。

その4：復元手順を試したことがない
バックアップがあることと、復元できることは違います。手順書があっても、試したことがなければ動かない可能性があります（GitLabの事例）。「戻し方」「復元手順」は、定期的に試す必要があります。試すのは負担ですが、いざというときの1回の失敗が、そのまま長時間の障害になります。

症状：障害時になって手順の不備に気づく。原因：手順を試していない。対処：定期的に復元訓練を行う。少なくとも「読んで、不明点を洗い出す」だけでも効果がある。

その5：振り返りが「反省文」になる
振り返りが「何が悪かったか」の列挙になると、参加したくない場になります。すると形骸化し、学習が起きません。振り返りの目的は改善なので、うまくいったことと改善項目（担当・期限付き）を必ず入れます。改善項目が「気をつける」で終わると、何も変わりません。「検知・緩和・予防」の3層で、具体的な行動まで落とします。

症状：振り返りが「次は気をつけましょう」で終わる。原因：改善が行動に落ちていない。対処：担当・期限・完了条件を決める。次回の振り返りで実施状況を確認する。

🔄 代替技術との比較：監視と考え方の選択肢

運用の設計には複数の考え方があります。状況に応じて選ぶものであり、組み合わせても使えます。

また、インシデント対応の体制にも選択肢があります。当番制（オンコール）を敷く、専任チームを置く、全員で対応する。規模によって正解が変わります。小規模なうちは当番制＋エスカレーション（判断に迷ったら上位に相談する）が現実的です。重要なのは、「誰が対応するか」を事前に決め、連絡先を明示することです（第1回の関門8の出口条件でした）。

📅 今後の展望と、シリーズのまとめ

運用を巡る変化を2つ挙げます。第一に、観測データの活用とAIです。ログ・メトリクス・トレースの量は増え続けており、異常検知・原因候補の提示・アラートのトリアージにAIを活用する流れが進んでいます（AIOpsと呼ばれます）。ただし、最終的な判断（止血するか、戻すか）は人間です。そして、判断の質は事前に決めた基準（SLO・戻し方・役割）に依存します。AIは判断材料を速く集める装置であり、判断の枠組みは人間が設計するという分担になります。

第二に、インシデント対応の標準化です。インシデントコマンド（指揮の仕組み）、ポストモーテムの形式、SLOの運用といった実践が、業界の共通語になりつつあります。これは、障害対応が「個人の経験と胆力」から「訓練できる技術」に変わってきたことを意味します。ジュニアエンジニアにとって良い変化です。第5回のCRMと同じで、手順と訓練があれば、経験の浅い人でも初動で力を発揮できます。

そして、このシリーズのまとめです。全8回で、1つの変更が通る8つの関門を見てきました。

まとめ

この記事を読んだあなたは、次に障害の報せを聞いたとき、「まず影響範囲の確認と止血」を最初に考えるようになります。そして、ふだんの開発の中で、「これは壊れたときにどう気づくか」「どう戻すか」を自然に問うようになります。

開発フローの8つの関門は、あなたを縛る手続きではありません。失敗を早く、安く見つけるための観測所です。そして、このシリーズ全体を貫いていた原則は、たった1つです。「失敗は、早く見つけるほど安い」。課題で見つければ1行の修正、本番で見つければ100倍の代償。この原則に照らせば、8つの関門のどれを厚くし、どれを軽くするかの判断も、自分でできるようになります。

これを読んだあなたは、自分の1行が通る8つの関門を説明でき、いま自分がどの関門にいて、次に何を準備すればよいかを、自分で判断できます。そして、壊れたときには、落ち着いて止血から始められます。開発フローは、暗記する知識ではなく、毎日の仕事で使う地図です。地図を持っている人は、迷ったときに、自分で戻ってこられます。

全8回、お読みいただきありがとうございました。

参考文献

1. Betsy Beyer et al. (eds.), “Site Reliability Engineering: How Google Runs Production Systems”, O’Reilly Media, 2016（SLO・エラーバジェット・ポストモーテムの実践） — https://sre.google/sre-book/table-of-contents/
2. Betsy Beyer et al. (eds.), “The Site Reliability Workbook”, O’Reilly Media, 2018（SLOの実践的な設定方法） — https://sre.google/workbook/table-of-contents/
3. Google, “Postmortem Culture: Learning from Failure”（Blameless Postmortem） — https://sre.google/sre-book/postmortem-culture/
4. Google, “Monitoring Distributed Systems”（症状ベースの監視とアラート設計） — https://sre.google/sre-book/monitoring-distributed-systems/
5. Ariel Tseitlin, “The Antifragile Organization”（Netflixのカオスエンジニアリング）, ACM Queue, 2013 — https://dl.acm.org/doi/10.1145/2491423.2492001
6. Netflix, “Chaos Monkey”（2011年にオープンソース化） — https://netflix.github.io/chaosmonkey/
7. GitLab, “GitLab.com database incident - 2017/01/31”（バックアップ不全と復旧の記録） — https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/
8. AWS, “Post-Event Summaries”（公開されている障害報告の例） — https://aws.amazon.com/premiumsupport/technology/pes/
9. John Allspaw, “Blameless PostMortems and a Just Culture”, 2012 — https://www.etsy.com/codeascraft/blameless-postmortems/
10. Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate”, IT Revolution Press, 2018（復旧時間と頻度の関係） — https://itrevolution.com/
11. DORA, “Accelerate State of DevOps Report” — https://dora.dev/
12. Charity Majors, Liz Fong-Jones, George Miranda, “Observability Engineering”, O’Reilly Media, 2022（観測の3本柱） — https://www.oreilly.com/
13. OpenTelemetry, “OpenTelemetry Documentation”（トレースとメトリクスの標準） — https://opentelemetry.io/docs/
14. PagerDuty, “Incident Response Documentation”（インシデント対応の公開ドキュメント） — https://response.pagerduty.com/
15. ITIL 4 Foundation, AXELOS（インシデント管理の標準的な枠組み） — https://www.axelos.com/
16. 情報処理推進機構（IPA）, 「システム障害に関する調査・分析」 — https://www.ipa.go.jp/