障害対応の指揮

大きな障害では、全員が原因を調べ始めて誰も全体を見ていない、という状態になりがちです。そこで役割を分けます。EM はインシデントコマンダー（IC：指揮をとる人）を担うことが多いですが、自分で原因を調べるのではなく、情報を整理して判断することに集中します。

最初に「私が IC です。調査は A さん、連絡は B さん」と宣言し、チャットのチャンネルを1つに決めます。状況の更新は「今わかっていること・影響・次にやること・次の更新時刻」の形で、30分ごとなど決まった間隔で出します。原因が分からなくても、まず影響を止める（切り戻し・機能フラグで止める）ことを優先します。長引いたら担当者を交代させ、休ませるのも IC の仕事です。

責めないポストモーテム

重大度（SEV：severity）は、障害の大きさを段階で表したものです。最初に重大度を決めると、誰を呼ぶか・誰に報告するか・夜中でも対応するかが自動的に決まり、迷う時間が減ります。

迷ったら高いほうで宣言するのがこつです。大げさに宣言して後から下げるのは簡単ですが、低く見積もって人が集まらないと、復旧が遅れます。

障害の最中は、技術の対応と同じくらい連絡が大事です。連絡が途切れると、サポートや経営から個別の問い合わせが殺到し、対応する人の手が止まります。連絡は連絡担当に任せ、決まった形と間隔で出します。

【SEV1・更新 #3】14:30
今わかっていること：決済 API の一部でエラー。原因は調査中
影響：14:05 から、カード決済の約 30% が失敗
やっていること：直前のリリースを切り戻し中
次の更新：15:00

「次の更新時刻」を必ず書くのがポイントです。新しい情報がなくても、その時刻には「変化なし、調査を続けています」と出します。

ポストモーテム（障害の振り返り）は、数日〜1週間以内に書きます。責めない（ブレームレス）とは、「誰がミスしたか」ではなく「なぜその操作ができてしまったか」「なぜその判断がその時は正しく見えたか」を問うことです。人を責めると、次から事実が隠されて、同じ障害がくり返されます。

• 構成：概要・影響（時間・利用者数）・時系列・原因・うまくいったこと・改善点・対策。
• 対策には担当者と期限をつけ、チケットにして追いかける（書いて終わりにしない）。
• 「注意する」「気をつける」は対策にしない。仕組み（自動チェック・権限・アラート）で防ぐ。

SRE の「ポストモーテムの構成」

ポストモーテムで決めた対策が、実行されないままたまっていくのはよくある失敗です。書いて終わりにしない仕組みを作ります。

対策が多すぎて回らないなら、数を絞ります。効果の大きい2〜3個を確実にやるほうが、10個並べて手つかずになるよりよい結果になります。

障害対応は、本番で初めてやるとうまくいきません。平常時に練習しておくと、役割の分担や連絡の形が身につき、手順書の穴も見つかります。

訓練では、IC 役をふだん指揮しない人にも回します。EM がいないときに障害が起きても、チームで対応できるようにするためです。終わったら短い振り返りをして、手順書と連絡の形を直します。このサイトの障害対応の演習も、指揮する立場の練習に使えます。