インシデントハンドリングの基本 — 障害対応で最も重要なこと

SRE 入門 4 部作の最終回は、エラーバジェットを実際に燃やす瞬間、障害対応です。障害対応の力の差は、たいてい技術ではなく手順で決まります。有能な個人が夜中に一人で直す組織と、誰がオンコールでも同じ品質で対応できる組織の差です。この記事はその手順の骨格を整理します。障害をユーザーの視点で説明する入門編は IT 常識 #4 で扱ったので、この記事は対応する側の視点です。

原則その一 — 復旧が原因究明より先です #

障害の最中に最もよくある罠は「なぜそうなったか」を掘ることです。インシデント中の問いは「原因は何か」ではなく「ユーザーへの影響をいまどう終わらせるか」です。原因が分からなくても復旧はできる場合が多いのです。直前のデプロイのロールバック、問題のインスタンスの隔離、キャッシュされた応答へのフォールバック、トラフィックの迂回がそうです。多くの組織のランブックの最初の項目が「最近何が変わったか → 戻せ」である理由です。

原因の究明は復旧の後、ポストモーテムの仕事です。そのために、復旧の過程で証拠(ログ、指標のスナップショット、タイムライン)を作業の合間にその場で残しておく習慣が必要です。診断そのものが行き詰まったときの技術的な手順は、サーバーが遅い理由シリーズのような体系を事前にランブックにしておくのが答えで、インシデント中にゼロから考え出すものではありません。

役割の分離 — 直す人が指揮しません #

一定規模以上のインシデントで最も重要な構造は役割の分離です。

• インシデントコマンダー(IC) — 対応全体を指揮します。状況把握、作業の割り当て、優先順位の決定を行い、自分ではキーボードを触りません。 デバッグに潜った人は全体の絵を見失うからです。
• 作業担当(ops) — 実際の調査と復旧の作業を行います。発見と変更を IC に報告します。
• 伝達担当 — 状況を要約して利害関係者(経営陣、CS、必要なら顧客告知)に定期的に知らせます。この役割がないと、作業者が 5 分おきに「いまどうですか?」に答えることになり、復旧が遅れます。

小さいチームで三人いなくても原則は保てます。二人なら一人が IC + 伝達、一人が作業を受け持ち、一人なら最低限「10 分ごとに状況を一行記録」で伝達チャンネルの代わりにします。肝心なのは指揮・伝達という仕事が存在することを知っていることです。

深刻度の等級と宣言 — 判断を事前に作っておきます #

「これはインシデントか?」を夜中の 3 時に悩ませてはいけません。深刻度の等級と宣言の基準を平時に定義しておきます。

バーンレートのアラートとつなげると宣言の基準が自然になります。速い消費のアラートは SEV1〜2 の候補、遅い消費は SEV3 のチケットです。そして迷ったら高い等級で宣言して後で下げるほうが、低く取ってから引き上げるより常に安上がりです。過小な宣言は対応の遅れで、過大な宣言はせいぜい少しの気まずさで終わります。

ポストモーテム — 非難なしに、しかし曖昧にもせず #

復旧が終わったらポストモーテムを書きます。形式は組織ごとに違っても、四つは必ず入ります。タイムライン(検知から復旧まで、時刻とともに)、影響(ユーザーの何 % が何分、予算をいくら消費)、原因分析(直接の原因と、それを可能にした構造)、アクションアイテム(担当者と期限の付いた再発防止策)です。

「非難のない(blameless)」の意味はよく誤解されます。責任を問わないという意味ではなく、「誰がミスしたか」を「何がそのミスを可能にしたか」に変えるという意味です。「A さんが本番に間違った設定を入れた」で止まれば得るものがありません。「設定変更に検証のステップがなく、ステージングと本番の設定ファイルが同じ画面で編集される」まで行って初めてシステムが直ります。個人を責めれば次から事実が隠され、隠された事実の上にはどんな再発防止も成り立ちません。そしてアクションアイテムは期限と担当者がなければ書かなかったのと同じです。四半期ごとに未実施のアクションアイテムをレビューするルーティンまでがポストモーテムです。

オンコール — 持続可能でなければ回りません #

このすべての手順の前提は、対応する人、オンコールです。オンコールが崩れる組織の共通点は技術ではなく負荷です。

• アラートの質 — 対応の要らないアラート(情報性のもの、自動復旧するもの)が呼び出しで届くと、オンコールは速く消耗します。呼び出しは「いま人の行動が必要なもの」に限定し、残りはチケット・ダッシュボードに回します。バーンレート方式がこの区分を自然に作ってくれます。
• 負荷の上限 — 交代の周期あたりの呼び出し回数を観測し、一定のラインを超えたらアラートの整理と根本原因の除去が機能開発より優先する、というルールを置きます。第 1 回で見たトイルの上限と同じ原理です。
• ランブック — 繰り返すアラートには「このアラートが来たら何を見る → 何をする」を書いたランブックを付けます。ランブックのないアラートは毎回そのシステムを知る人を探させ、その人がやがて単一障害点になります。

まとめ #

• インシデント中の目標は原因究明ではなくユーザー影響の終了です。ロールバック・隔離・フォールバックのような復旧の手段を先に使います。
• 指揮(IC)・伝達・作業の役割を分けます。直す人が指揮までやると、両方が遅くなります。
• 深刻度の等級と宣言の基準は平時に定義します。迷ったら高く宣言して下げるほうが安上がりです。
• ポストモーテムはタイムライン・影響・構造的な原因・期限付きのアクションアイテムで書き、「誰が」ではなく「何が可能にしたか」を問います。
• オンコールはアラートの質、負荷の上限、ランブックで持続可能にします。持続不可能なオンコールの上には、どんな手順も成り立ちません。

これで SRE 入門 4 部作が終わりました。SLI・SLO で目標を数字にし、エラーバジェットで速度と安定性のルールを立て、インシデントの手順で予算を守ります。この三つの循環が SRE の骨格です。