障害対応はどこで終わるのか – 復旧、安定化、恒久対応、再発防止を分ける

障害対応では、どこで終わったと判断するかが意外に難しくなります。HTTP 200 が返るようになった。Pod が再起動した。アラートが消えた。利用者からの問い合わせが止まった。原因が分かった。恒久対応を入れた。再発防止策を完了した。これらはすべて似ていますが、同じ状態ではありません。

障害対応を早く終えたい気持ちは自然です。しかし、復旧したことと、安定したことと、根本原因が説明できることと、再発防止が完了したことを混ぜると、同じ障害を繰り返しやすくなります。障害対応の終了条件は、気分やアラートの有無ではなく、段階ごとに定義しておく必要があります。

復旧は終わりではなく利用者影響の停止である

最初に目指すべきなのは、利用者影響を止めることです。サービスが完全に元通りでなくても、主要機能が使えるようになり、エラー率や遅延が許容範囲に戻り、問い合わせや業務停止が収まるなら、それは暫定復旧と呼べます。

ただし、暫定復旧は障害対応の終了ではありません。フェイルオーバーしただけ、再起動しただけ、詰まったキューを一時的に流しただけ、負荷を下げるために一部機能を止めただけ、という場合があります。この状態で対応完了とすると、根本原因や残ったリスクが見えなくなります。

段階	主な目的	完了条件の例
暫定復旧	利用者影響を止める。	主要機能が利用でき、エラー率や遅延が許容範囲へ戻る。
安定化	再悪化しないことを確認する。	一定時間、同じ指標が悪化せず、キューや再試行も収束する。
原因整理	何が起きたかを説明できるようにする。	発生時刻、影響範囲、直接原因、誘因、検知経路を記録する。
恒久対応	同じ条件で再発しないようにする。	設定、コード、構成、運用手順の変更が実装・検証される。
再発防止	組織として学習する。	監視、Runbook、レビュー、訓練、責任分界の改善まで完了する。

アラートが消えたことと安定したことは違う

アラートが消えると、障害が終わったように見えます。しかし、アラートは設定された条件を満たさなくなったことを示すだけです。キューがまだ残っている、再試行が続いている、片系運用のままになっている、手動変更が残っている、監視抑制が解除されていない、という状態は十分にあり得ます。

安定化では、アラートの有無だけでなく、関連する指標をまとめて見ます。リクエスト数、エラー率、p95 / p99 レイテンシ、キュー長、DB 接続数、外部 API の応答、バッチ遅延、ログ量、再試行回数、フェイルオーバー後の負荷分布を確認します。

特に注意すべきなのは、障害の後処理が遅れて表面化するケースです。障害中に溜まったキューが一気に流れる、再試行が集中する、キャッシュが失効する、片系に寄った負荷が通常時より高い状態で続く。こうした状態では、表面上のアラートが消えても再発や二次障害のリスクが残ります。

原因が分かっただけでは恒久対応ではない

原因が分かると、対応が終わったように感じることがあります。たとえば、特定のバッチが重かった、DB コネクションが枯渇した、キャッシュミスが集中した、外部 API の遅延でスレッドが詰まった、という説明ができる状態です。これは重要ですが、まだ恒久対応ではありません。

原因整理は、何を変えるべきかを決めるための材料です。恒久対応は、その材料をもとに、設計、設定、コード、監視、運用手順へ変更を入れることです。原因を説明できても、同じ条件で同じ障害が起きるなら、障害対応はまだ閉じていません。

分かったこと	恒久対応として考えること
DB コネクションが枯渇した。	プールサイズ、タイムアウト、待ち行列、アプリケーション側の接続保持を見直す。
夜間バッチがピーク処理と競合した。	処理時間帯、リソース分離、優先度、停止条件を設計する。
外部 API 遅延で処理が詰まった。	タイムアウト、リトライ間隔、サーキットブレーカー、縮退動作を設計する。
監視が遅れて検知した。	SLI、アラート条件、通知経路、ダッシュボードを見直す。
手順が属人化していた。	Runbook、権限、承認経路、訓練を整備する。

暫定対応を残したまま閉じない

障害対応では、暫定対応が必要になることがあります。設定を一時的に緩める、処理を止める、キャッシュを消す、特定ノードを切り離す、手動でキューを流す、監視を抑制する。これらは利用者影響を止めるためには有効ですが、そのまま残すと次の障害要因になります。

暫定対応には、必ず期限と戻し条件を付けるべきです。誰が、いつ、何を確認して、どの状態へ戻すのか。戻さないなら、なぜ恒久設定として採用するのか。暫定対応のまま運用が続くと、後から見る人にはそれが設計なのか緊急回避なのか分からなくなります。

障害対応を閉じる前には、暫定変更の棚卸しが必要です。構成差分、手動変更、監視抑制、切り離したノード、止めたジョブ、追加したスケール、変更した閾値、増やしたログレベルを確認し、戻すものと恒久化するものを分けます。

再発防止は反省文ではなく設計変更である

再発防止という言葉は、精神論になりがちです。注意する、確認を徹底する、気をつける、という対策だけでは、同じ条件が来たときに同じ事故が起きます。再発防止は、人間の注意力に依存する部分を減らし、システムや運用の構造を変えることです。

たとえば、検知が遅れたなら監視条件を変えます。手順が曖昧だったなら Runbook を更新します。変更作業で起きたならレビュー項目やロールバック条件を変えます。容量不足ならキャパシティ設計を見直します。依存先障害で連鎖したならタイムアウト、リトライ、バックプレッシャーを設計します。

再発防止を完了とするには、対策が実装され、検証され、運用に組み込まれている必要があります。チケットを作っただけ、会議で話しただけ、報告書に書いただけでは、再発防止は完了していません。

障害報告は責任追及ではなく判断材料である

障害報告は、誰が悪かったかを決めるためだけの文書ではありません。次に同じ種類の事象が起きたとき、より早く検知し、より小さく止め、より正しく復旧するための判断材料です。

報告に必要なのは、時系列、影響範囲、検知方法、直接原因、背景要因、暫定対応、恒久対応、残リスク、再発防止策です。ここで重要なのは、事象と判断を分けることです。何が起きたのか、なぜそう判断したのか、どの選択肢を捨てたのかが残っていないと、後から検証できません。

報告項目	残す意味
時系列	検知、判断、対応、復旧、安定化の流れを追えるようにする。
影響範囲	利用者、機能、地域、取引、業務への影響を明確にする。
検知経路	監視で見つけたのか、問い合わせで見つけたのかを分ける。
判断理由	なぜその暫定対応を選び、他の方法を選ばなかったのかを残す。
残リスク	まだ残っている暫定状態や未対応事項を明確にする。
再発防止	構造として何を変えたのかを確認する。

終了条件をあらかじめ分けておく

障害対応をきれいに終えるには、発生してから終了条件を考えるのでは遅くなります。インシデント対応の設計として、どの状態を暫定復旧と呼ぶのか、どの状態を安定化と呼ぶのか、どの状態でクローズできるのかを事前に決めておくべきです。

たとえば、利用者影響が止まった時点でステータスページや関係者連絡では復旧と表現しても、内部チケットは安定化確認や恒久対応が終わるまで閉じない、という運用が考えられます。外部向けの復旧宣言と、内部の完了条件は同じである必要はありません。

この分離がないと、外部向けに復旧と伝えた瞬間に、内部でも対応が終わったことになりがちです。実際には、そこから原因整理、暫定対応の戻し、恒久対応、再発防止、報告という作業が残っています。

チケットを閉じる前に確認すること

障害対応の終了条件を運用に落とすなら、チケットを閉じる前の確認項目まで具体化しておく必要があります。復旧報告を出した後も、内部チケットには暫定対応、残リスク、恒久対応、再発防止、関係者への共有が残ることがあります。ここを曖昧にすると、障害は終わったことになっていても、設計上の弱点は残り続けます。

確認項目	閉じてよい状態	閉じてはいけない状態
利用者影響	主要機能が戻り、影響範囲と復旧時刻を説明できる。	問い合わせが減っただけで、影響範囲が不明なまま。
暫定対応	戻すもの、恒久化するもの、期限付きで残すものが分かれている。	手動変更や監視抑制が残っているか分からない。
原因整理	直接原因と背景要因を分けて記録している。	単一の原因名だけで説明している。
恒久対応	実装済み、または期限と責任者つきの作業として管理されている。	会議で話しただけでチケット化されていない。
再発防止	監視、Runbook、試験、レビュー項目のどれを変えるか決まっている。	注意する、確認する、徹底するで終わっている。

この確認表があると、障害対応のクローズは担当者の感覚ではなくなります。早く閉じることより、何を残して閉じるかを明確にすることが重要です。

まとめ

障害対応は、アラートが消えたところで終わるわけではありません。復旧、安定化、原因整理、恒久対応、再発防止、報告完了は、それぞれ別の状態です。これらを混ぜると、利用者影響は止まっていても、同じ障害が再発する構造が残ります。

まず利用者影響を止める。次に再悪化しないことを確認する。何が起きたのかを時系列と影響範囲で整理する。暫定対応を戻すか恒久化する。根本原因に対して設計や運用を変える。再発防止策を実装し、検証し、報告として残す。この順序で考えると、障害対応の終了条件はかなり明確になります。

復旧したことと、終わったことは同じではありません。障害対応の品質は、復旧の速さだけでなく、何を残して閉じたかで決まります。終わり方を設計することは、次の障害を小さくするための運用設計そのものです。

参考書籍

参考資料

• Google SRE Book: Postmortem Culture
• Google SRE Book: Managing Incidents
• Google SRE Book: Addressing Cascading Failures

関連する記事