役割と宣言

一行まとめ

大きなインシデントで真っ先に崩れるのは、サーバーではなく「今、誰が何をしているのか」です。役割を分け、早めに宣言し、 決定ごとにオーナーを決めることが、その秩序を守ります。

なぜこれが必要だったのか

明け方に決済エラーのアラートが鳴ったとしましょう。チャンネルに5人が入ってきて、全員が有能で、全員が正しいことをします。1人は ロールバックを始め、別の人は同じ瞬間に同じサーバーを再起動し、3人目はキャッシュをクリアすべきか尋ねますが、誰も答えません。 カスタマーセンターは何が起きているのか分からず、「確認中です」を繰り返すだけです。GoogleのSRE本の第14章(Managing Incidents)は、まさにこうした 「管理されていないインシデント」を冒頭の場面として示します — 個人の実力ではなく調整の不在がインシデントを大きくする、ということです。

宣言を先延ばしにするのも同じ根から来ています。「大したことではないかもしれないのに、無駄に大ごとにしてしまうかも」と先延ばしにします。しかし宣言のコストはチャンネル1つと 役割3つであり、遅れた宣言のコストは、その間誰も告知せず誰も指揮しなかった時間のすべてです。

どのように動くのか

役割は3つが基本です(規模が大きくなれば計画・記録の担当を加えます)。

役割	やること	やらないこと
IC(指揮)	優先順位・決定・役割の割り当て、状況把握	自分の手で直すこと — 手がふさがると指揮が空く
Ops(運用)	システムを実際に変える手	独断で範囲を広げること
Comms(告知)	決められた間隔で外部に状況を告知	推測の数字を出すこと

いくつかのルールがこの表を支えます。役割は明示的に渡します — 「ICを渡します」とともに記録が残ってこそ、次の人が分かります。 決定にはオーナーがいます — オーナーのいない決定は、2人が同時に行うか、誰も行いません。手を付ける前に「今これをやって いる」と知らせれば、重複する作業がなくなります。多くのチームがチャットボットのコマンド(/declare、/role、/ownなど)でこれを記録に残します。

宣言の基準はあらかじめ決めておきます。ユーザーへの影響が見える、1人で30分以内に終わらせる自信がない、2つ以上のチームが必要だ — このうち 1つでも当てはまれば宣言します。そして時間を測ります。最初のアラート → 最初の応答(ack) → 宣言 → 緩和 → 終了。これらの間隔が次の改善の出発点です。

状況告知には形式があります。何がどれだけ(数字)、いつから影響を受けているのか、誰が指揮しているのか、次の告知はいつなのか。 数字は「たくさん」ではなくデータから数えた値でなければならず、次の告知時刻は重大度別の間隔を守ります。間隔を守ることが 数字より重要なときもあります — 「まだ原因は分かっていません。30分後に改めてお知らせします」も告知であり、沈黙は告知ではありません。

チャンネルの記録はこのように残ります。ボットコマンドがあれば、後から誰がいつ何を担当したのかを機械的に数え直せます。

13:04:47 jun     결제 오류 경보 받았습니다. 보는 중이에요
13:17:12 jun     /declare sev2 결제 실패 증가        ← 첫 경보에서 13분
13:17:54 alex    /role ic @alex
13:18:56 alex    /role comms @blake
13:27:05 alex    /decide D1 결제 v2 기능 플래그 끄기  ← 주인(/own)이 없다
13:28:05 casey   /doing D1
13:29:04 drew    /doing D1                         ← 앞사람이 끝내기 전 — 겹쳤다
13:35:52 alex    /role ic @erin                    ← IC 를 넘겼다. 이 뒤의 alex 는 손이다

最後に呼び出しです。指揮は、呼び出し(ページング)が人に届いて初めて始まります。呼び出しサービスはアラート名をルーティングルールでチームに結び付け、そのチームの エスカレーションポリシーを段階ごとにたどり、段階ごとにその時刻の当番(交代表が当番表より優先)を探して、その人の連絡手段で 呼び出します。この鎖の輪が1つ切れるだけで最初の段階は静かに失敗し、次の段階(たいていはチームリーダー)は15分か20分後にようやく鳴ります。 エスカレーションはセーフティネットであって、最初の応答ではありません。

現場でよく見る姿

最もよくある失敗は、ICが手を動かすことです。ロールバックを一番よく知っている人がICを担当し、自分でロールバックをしているうちに30分間誰も 告知せず、ほかの決定が止まります。そのため、ICを渡した後に手を動かすのは構いませんが、ICのまま手を動かしたことは記録で 明らかになるべきです。2番目によくあるのは、呼び出しがまったく届かないことです。新しく来た人の連絡先が空だったり、休暇中の交代が 退職者を指していたり、アラート名が変わってルーティングルールと合わなかったりすると、指揮は始まることすらできません。指揮は呼び出しが届くところから始まります。

こうした欠陥はインシデントが起きて初めて表に出るため、成熟したチームはインシデントとインシデントの合間に確認します。1週間の当番表をシミュレーターに入れて「どの時刻に 鳴っても誰が受けるのか」を事前に回してみて、宣言までにかかった時間とICが手を動かした回数を四半期ごとに数えます。数字があってこそ、次の 四半期に改善したかどうかを言えます。

次のラボでやること

決済インシデントのチャンネル記録(チャット・呼び出し・注文)を開き、宣言までにかかった時間、役割が移った流れ、ICが手を動かした決定、オーナーのいない決定と 重複した作業をデータで見つけ、決められた形式の状況告知を計算した数字で書きます。最後に、3つのチームの呼び出しがなぜ20分間 誰にも届かなかったのかを呼び出し設定から見つけて直します。