Dev Study
← 出して、戻して、直す — 変更と復旧の実務
レッスン 11 / 12·約 7 分·第24期 出して、戻して、直す

状態を持つ人を1人に決める — 変更は班に、状態は指揮役に

リクエストがアプリケーションに届くまで
  1. ブラウザURL入力
  2. DNS名前→IP
  3. ルータ経路選択
  4. ロードバランサ振り分け
  5. Nginx受け口
  6. アプリ処理今ここ
  7. DB保存

壊れたときに打てる手は、壊れる前に用意した分しかありません。今回は道具ではなく、誰が状態を持ち、誰が変更するかという取り決めを用意します。

まず結論

障害対応では、全体の状態を持つ人を1人(指揮役)に決めます。システムを変更するのは、その下で動く operations team だけです。

原典は、委任していない役は指揮役が持つとします。指揮役は、役を他の人に渡して自分が操作役(OL)になるか、操作役を他の人に割り当てるかを選べます。「指揮役は手を動かさない」とは書かれていません。

? 読む前に予測

SRE Book 第14章は、インシデントの最中にシステムを変更してよいのは誰だと書いているでしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

状態を持つ人と、変更する班

障害の最中、情報は各自の頭の中に散らばります。SRE Book 第14章は、その散らばりを1か所に集める役を置きます。

The incident commander holds the high-level state about the incident. They structure the incident response task force, assigning responsibilities according to need and priority. De facto, the commander holds all positions that they have not delegated.

指揮役は全体の状態を持ち、委任していない役はすべて自分が持ちます。そのうえで、変更する側を限定します。

The operations team should be the only group modifying the system during an incident.

変更するのは班です。「1人に決める」のは状態を持つ指揮役で、手を動かす人数ではありません。ここを混ぜると「1人で直せ」という誤読になります。

SRE Book 第14章の役割(Workbook 第9章は IC・CL・OL の3役)
指揮役 (IC)全体の状態を持つ・委任していない役も持つ
役を割り当てる
Ops lead の班システムを変更する唯一の班
Communication外への顔・定期の更新
Planning平常からの逸れを記録し、戻せるようにする
  • ・SRE Book は4役、Workbook は IMAG の説明として3役(CL と OL が IC に報告)。本数は文書で違う
具体実物

全員が善意で動いた障害

同じ章は、架空の会社と架空の人物で「管理されない障害」を描きます。当番は技術作業に埋もれ、周りは状況を知りません。

Nobody knew what actions their coworkers were taking.

そこへ、呼ばれた別のエンジニアが本番に変更を入れます。章はこれを Freelancing と名づけます。

Malcolm was making changes to the system with the best of intentions. However, he didn’t coordinate with his coworkers—not even Mary, who was technically in charge of troubleshooting. His changes made a bad situation far worse.

誰も怠けていません。調整されない変更が、担当者の Mary にさえ知らされないまま事態を悪化させた、と書かれています。「全員で直せば早い」は、この型を招きます。

✓ ここまでの確認

SRE Book 第14章の「管理されない障害」の物語で、善意の変更が事態を悪化させた型は何と呼ばれていますか。

抽象原理

状態は人ではなく文書に置く

状態を1人が持つなら、その人が倒れたら終わりではないか。原典の置き方は、状態を文書に書き出すことです。

The incident commander’s most important responsibility is to keep a living incident document.

This living doc can be messy, but must be functional. とあり、Retain this documentation for postmortem analysis と続きます。Workbook 第9章の原則にも Keep a working record of debugging and mitigation as you go. があります。第15期で見た事後検証は、この最中の記録を材料にします。

文書があるから交代できます。SRE Book は交代を明示させます("You’re now the incident commander, okay?"、了承を得るまで抜けない)。

具体実物

いつ始め、何を書き残すか

指揮役を立てるには、まず宣言が要ります。SRE Book は早い宣言を勧め、著者チームの目安を挙げます。

My team follows these broad guidelines—if any of the following is true, the event is an incident:

条件は3つ。別チームの関与が要るか、顧客に見えているか、1時間集中して分析しても未解決か。どれか1つで宣言です。2016年刊の本の、1チームの目安です。

書き残す中身の見本として、本教材の実演(メモアプリを壊して戻す通し演習、スクリプト非掲載)の出力を抜粋します。

本教材の実演の出力(スクリプト非掲載・5行を抜粋)コマンド出力
[09:42:02] ===== 5 フラグ On の直前の時刻を控える(戻す目標)→ フラグ On → 利用者がタイトルを付ける =====
restore target: 2026-09-26 00:42:02.716457+00
[09:42:03] ===== 6 検知(本文が空の行を数える)→ 緩和: 原因を調べる前にフラグを切る =====
empty bodies: 2
empty bodies after mitigation (データは戻っていない): 2

3行目の「フラグを切る」は、収まったら戻すかを決める変更の記録で、Planning の役が追う「平常からどう逸れたか」にあたります。2行目は戻す目標の時刻、5行目は、緩和の後もデータは戻っていないという状態です。見出しは日本時間、目標は UTC(+00)で書かれており、時刻には時間帯を添えます。

✓ ここまでの確認

SRE Book 第14章の著者チームは、挙げた3つの条件をどう使ってインシデントを宣言していますか。

⇄ 2つを見比べる
具体例 A

インシデントの指揮役と状態文書

指揮役が全体の状態を持ち、文書に書き出す。変更は operations team に限る。交代は口頭で明言し、了承を得て移る。投票はしない。

具体例 B

分散合意のリーダー(第12期)

Raft はまずリーダーを1人決め、そのリーダーが書き込みを配る。資格は過半数の支持であって過去の肩書きではない。

人の組織と機械の合意。共通するものと、違うものは何でしょうか。

誰が書くかと、書き手がどう交代するかを分けてください。

この章のまとめ

  • 全体の状態を持つのは指揮役1人。委任していない役も指揮役が持つ。
  • システムを変更するのは operations team だけ。「1人」は変更する人数ではない。
  • 善意でも調整なしの変更は Freelancing。原典の物語では事態を悪化させた。
  • 指揮役の最重要の責任は生きたインシデント文書。事後検証の材料になる。
  • 宣言は3条件のどれか1つで。著者チームの目安。
  • 委任していない役は指揮役が持つ。指揮役は、役を渡して操作役になるか、操作役を割り当てるかを選べる。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

SRE Book 第14章が、指揮役のもっとも重要な責任として挙げているのはどれですか。

用語集(4語)
指揮役 (Incident Commander, IC)
インシデントの全体の状態を持つ人。SRE Book は、委任していない役はすべて指揮役が持つと書く。
Ops lead / OL
運用の道具を使って対応する役。SRE Book は、最中にシステムを変更するのは operations team だけとする。
生きたインシデント文書
最中に書き続ける状態文書。乱雑でもよいが機能すること。事後検証のために残す。
Freelancing
調整せずに各自がシステムを変更すること。SRE Book 第14章が、管理されない障害の危険の1つとして挙げる。