今日の文書 — Runbook（運用手順書）
Runbook（運用手順書） — 特定のアラートや定型作業について、当番の人が、その場で、上から順に実行すれば終わるように書いた手順書。設計書（Day017）が「誰がどこまで担当するか」を決める文書なのに対し、Runbook は「鳴ったとき、この人は何を打ち、何が出たら次に何をするか」だけを書く。読み手は、その業務を知らず、眠く、急いでいて、一人である。
この文書の勝負どころ: 未経験者が深夜に実行できるか。
今日はこれを実務の言葉に言い換える。実行できるとは、手順の全ステップが「打つもの」「出るはずの値」「違った場合の次」の3点で閉じていることである。読み手に判断を求める言葉（適宜・必要に応じて・状況を見て）が残っていれば、それは手順ではなく、書き手が決めきれなかった跡である。
| 比べる文書 | 何を決めるか | 読み手 |
|---|---|---|
| 運用設計書（Day017） | 体制、担当の分界、止める権限、朝の既定動作 | 運用リーダー・承認者 |
| Runbook（今日） | 1つのアラートごとの操作と分岐、電話をかける条件 | 当番（深夜に初見で読む） |
| 監視設計書（次の次） | 何をアラートにするか。鳴る条件としきい値 | 運用・SRE |
| ポストモーテム（カテゴリ11） | 起きたことの振り返り。Runbook を直す入口になる | 関係者全員 |
Runbook を良くする3つのポイント（この回で使う）:
| ポイント | 中身 | 今日の題材では |
|---|---|---|
| 分岐は画面の値で書く | 「遅いとき」でなく STATE= と DONE= の値で分ける | 「RUNNING で DONE が増えない」 |
| 各手順の終わりに行き先を書く | 「終了」「手順3へ」。続きを読者に探させない | 全分岐の末尾に行き先 |
| 出口を最初に置く | 手順で解決しないとき・分からないときの行き先を冒頭に | 「迷ったら村上に電話」 |
出典: Google「SRE Workbook」の On-Call の章に、「Playbooks contain high-level instructions on how to respond to automated alerts」「Each alert should have a corresponding playbook entry」「Details in playbooks go out of date at the same rate as production environment changes」とある（https://sre.google/workbook/on-call/ 、2026-10-19 に取得、要約ツール経由で文を確認。章の全文を通読したわけではない）。同じ章に「The on-call engineer is never alone」。Google の SRE Book「Being On-Call」（https://sre.google/sre-book/being-on-call/ 、同日取得）の「Feeling Safe」の節にも、エスカレーションを「principled way to react」とする記述がある。
シナリオ
あなたは株式会社ノヴァストア EC事業本部・販促システム部の MOpsチームマネージャー・宮田（Day004〜Day033の続き）。
2028年8月14日（月）。Day033 の受入テストは 8/21（月）〜22（火）、判定は 8/24（木）、同梱の本番は 8/28（月）から。同梱の判定は夜間バッチで、22:00に取り込み、2:00に判定（通常約35分）、判定の完了後に印字データ（約20分）、7:00に印字、8:00に出荷（Day017 の時刻割。所要時間は仮定）。判定バッチが 3:00 になっても完了しないとアラート JUDGE-LATE が出て、委託の監視センターが当番に電話をかける。
Day017 で決まったのは運用グループの動ける範囲だった。再実行は1回まで、判定の中身・同梱の可否には関与しない、6:30までに復旧しない朝は「同梱なし」で出荷する（案B、6/27 に今井課長が決定）。しかし、それは設計書に書いてあるだけで、3:05 に起こされた当番がどの画面で何を打つかは、まだどこにも書かれていない。
- 提出: 8/17（木）17:00 までに村上さん（運用リーダー）へ。読み合わせは 8/21（月）15:00（30分）。夜間リハーサルは 8/25（金）22:00（受入環境で、わざとバッチを止めて当番に初見で操作してもらう）。本番 8/28
- 読み手: 柴田さん（情報システム部 インフラ運用グループ、入社2年目。新登場。8/28 の週から夜間当番に入る。同梱の業務も「贈り物」の意味も知らない）。村上さん（運用リーダー。手順書を承認し、夜間の最終の電話先になる）。長谷川さん（判定バッチを作った開発リード。電話を受ける側）
- カタログの主な読み手（当番担当者）が Lv2（他部署の読み手）とそのまま一致するのでルール5の工夫は不要
- 制約: 運用グループの夜間操作は手順書にある範囲だけ（Day017）。夜間の呼び出しは判定バッチ関連で年6回ほど〔仮定: 現行バッチの過去12か月の失敗6回が同じ頻度で続くと置く。Day017 の仮定〕。1回の対応は起こされてから最短10分で「電話」か「終了」にしたい〔仮定: 運用グループの目標〕。電話番号は別紙の連絡先表（今回は XXXX で表記）
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | 柴田さん（インフラ運用グループ 入社2年目）が本番の実行者。村上さん（運用リーダー）が承認者。長谷川さん（開発リード）は電話を受ける側として読む |
| 何を判断するために読むか | 柴田さん: 今、何を打つか、いつ電話をかけるか。村上さん: 運用グループがこの手順の範囲で夜間を引き受けてよいか、自分に電話が来る条件は何か。長谷川さん: 自分への電話が来る条件と、そのとき当番が言うこと |
| 何を知っているか | 柴田さん: ジョブ管理コマンドの基本、サーバへの接続、別システムの再実行の経験。村上さん: 運用グループの権限、委託先との契約、夜間の呼び出しの負担。長谷川さん: 判定バッチの中身 |
| 何を知らないか | 柴田さん: 「贈り物」の判定、同梱カードの意味、朝の出荷の流れ、今夜が普段と違うのかどうか。村上さん: 判定バッチの中身、柏物流センターの早番の動き |
| 何を気にしているか | 柴田さん: 間違った操作で本番を壊さないか、夜中に誰かを起こしてよいのか、判断を迫られて責められないか。村上さん: 夜間の呼び出しが増えないか、運用が業務判断を背負わされないか |
| 読む時間と場面 | 3:05、自宅の布団の中、スマホかノートPCの画面。寝起きで10分以内に最初の判断をする。電話は鳴ったばかり。読み合わせの会議は日中の30分、リハーサルは 8/25 夜 |
この読み手が変わると何が変わるか: 読み手が長谷川さん（開発）なら、バッチの処理順と失敗しやすい箇所を先に書き、判定の中身は触れる範囲に含める。読み手が経験を積んだ村上さんなら、手順の途中は短くてよいが、電話をかける条件と時刻は変えない。柴田さんが読むときは、画面の値で分岐し、電話に逃げる出口を最初に見せる。
4段階で見る — R-01「判定バッチが遅れたとき（JUDGE-LATE）」の手順
以下は同じ Runbook の R-01「判定バッチが遅れたとき（アラート JUDGE-LATE）」の手順の部分を4段階で書き分けたもの。差が出るのは項目の数ではなく、3:05 に寝起きの人が、一度も止まらずに最後まで進めるかである。
タブで精読、「横に並べる」で差を一望できる（横並びは各段階の要点3行だけ）。
行数 10・12・16・15、字数 Bad235 → Good428 → Better543 → Best711字（空白を除く・実測）。Best 全体は最長だが、村上さんへのメモ（手順書の外・6行）を除いた手順書の本文は 9行・492字で、行数は Good（12行）より少ない。1行が長く、行数と字数で順位が変わる回。
「状況を確認」「必要に応じて」「関係者」「適切に」。打つコマンドも、出る値も、行き先もない。
起こされた人は設計書の節を開いて探す。
電話番号も、いつかけるかもない。概要・前提・手順・連絡先の型は完璧。コマンドが1つ入る。
だが「進み具合を見て必要に応じて待機」は何を見て何分待つかが読み手任せ。
連絡先は名前だけ。いつ・何と言うか・出ないときがない。分岐が STATE と DONE の値で決まる。各手順の末尾に「終わり／手順3へ」。
時刻（3:05・3:30・4:30・6:30）が入り、背景を落とした。
だが手順4は設計書を開かせ、電話の台詞と「迷ったら」の出口がない。決めることは村上さんへのメモ（手順書の外）に分け、本文は決定済みの結果だけ。
最初に「迷ったら電話。夜中でも構わない」。電話の台詞と番号つき。
「決定済み・確認不要」で6:30の判断を当番に背負わせない。"as necessary", "people concerned", "appropriate action". No command, no value, no next step.
The reader must open the design doc to find section 5.4.
No number, no time to call.Overview / Prerequisites / Procedure / Contacts, all in the standard form. One command.
But "check progress and wait as needed" leaves what to look at to the reader.
Contacts are names only: no when, no script, no fallback.Branches on STATE and DONE values; every step ends with Done / go to Step N.
Times added (03:05, 03:30, 04:30, 06:30); background dropped.
Step 4 still sends the reader to the design doc; no script, no exit line.Decisions move to a note for Murakami, outside the runbook; the body holds only what is decided.
Exit first: "If unsure, call. Night calls are expected." Call script and numbers included.
"Already decided. No need to confirm." so the on-call does not carry the 6:30 call.■ 判定バッチ遅延時の対応（夜間）
アラート JUDGE-LATE が出たら、まずバッチの状況を確認してください。
原因を調査し、必要に応じて再実行してください。
それでも解決しない場合は、関係者に連絡してください。
朝の出荷に影響が出る場合は、状況を見て適切に対応してください。
管理コンソール（URL は設計書を参照）で状態を見られます。
詳細は運用設計書 第3.2節・第5.4節を参照のこと。
連絡先: 開発（長谷川）、物流（今井）
※判定の内容を変更しないこと。
※ジョブの強制停止は慎重に。Late judgement batch (night)
When JUDGE-LATE fires, first check the status of the batch.
Investigate the cause and re-run it if necessary.
If it is still not resolved, please contact the people concerned.
If the morning shipping may be affected, please take appropriate action depending on the situation.
You can see the status in the admin console (see the design document for the URL).
For details, refer to the Operations Design Document, sections 3.2 and 5.4.
Contacts: Development (Hasegawa), Logistics (Imai)
Note: Do not change the content of the judgement.
Note: Be careful when force-stopping a job.英語では "if necessary" "appropriate action" "people concerned" が一番の問題になる。読み手が「で、何を打つの？」と聞き返せない場面で使われる。
R-01 判定バッチ遅延（JUDGE-LATE）
【概要】判定バッチ judge_insert_nightly が 3:00 までに完了しないと発報する。判定は送り先と購入履歴から、同梱カードを入れるかを決める（背景は設計書 2.1）。
【前提】本番サーバに接続でき、jobctl が使えること。
【手順】
1. jobctl status judge_insert_nightly でジョブの状態を確認する。
2. 実行中の場合は、処理の進み具合を見て、必要に応じて待機する。
3. 失敗している場合は、再実行する（jobctl run judge_insert_nightly --rerun）。
4. 再実行しても完了しない場合は、開発担当に連絡する。
5. 朝の出荷に間に合わない場合は、同梱なしでの出荷に切り替える（設計書 5.4）。
6. 対応内容を引き継ぎノートに記録する。
【連絡先】開発: 長谷川 / 物流: 今井 / 運用リーダー: 村上（別紙参照）
【注意】再実行は慎重に行うこと。判定ルールには触れないこと。Badから何が変わったか: 概要・前提・手順・連絡先・注意と型が整い、コマンドが1つ入った。④次の行動が「ある」状態になり、①結論の位置も「何のRunbookか」が冒頭で分かる。
まだ足りないもの:
- 手順2「進み具合を見て必要に応じて待機」は、何を見て、何ならOKで、何分待つかが書かれていない。柴田さんは自分で決めることになる
- 手順4「再実行しても完了しない」は、いつの時点か不明。手順5「間に合わない場合」も、何時に何を見て間に合わないと判断するかが設計書の中にある
- 連絡先は部署と名前だけ。いつかけるか、何と言うか、出なかったらどうするかがない
- 背景（設計書 2.1）と概要が3:05 の布団の中では要らない。読み手プロファイルの「何を知らないか」に答える内容が、必要な場面を選んでいない
R-01 Judgement batch delay (JUDGE-LATE)
[Overview] Alert fires if judge_insert_nightly has not finished by 03:00. The batch decides whether to include the promo card (see Design Doc 2.1).
[Prerequisites] Production access and the jobctl command.
[Procedure]
1. Check the job state with: jobctl status judge_insert_nightly
2. If it is running, check progress and wait as needed.
3. If it has failed, re-run it (jobctl run judge_insert_nightly --rerun).
4. If it still does not finish, contact the developer.
5. If shipping cannot be met, switch to shipping without the card (Design Doc 5.4).
6. Record what you did in the handover note.
[Contacts] Dev: Hasegawa / Logistics: Imai / Ops lead: Murakami (see Appendix)
[Caution] Re-run with care. Do not touch the judgement rules.型は整っている。ただし "check progress and wait as needed" と "If shipping cannot be met" は、何を見て・いつ判断するかが読み手任せ。
R-01 判定バッチが遅れたとき（アラート JUDGE-LATE・3:00 に発報）
使う場面: JUDGE-LATE が鳴ったとき。ほかのアラートには使わない。
手順1（3:05）状態を5分あけて2回見る:
jobctl status judge_insert_nightly
STATE=SUCCESS: アラートを閉じて終わり
STATE=RUNNING で DONE が増えている: 3:30 にもう一度手順1
STATE=FAILED、または5分間 DONE が増えない: 手順2へ
手順2 再実行（1回だけ）:
RUNNING なら先に jobctl stop judge_insert_nightly
jobctl run judge_insert_nightly --rerun（約35分）
STATE=SUCCESS: 終わり。FAILED: 手順3へ。再実行は二度しない
手順3 長谷川さんに電話（4:30 になっても SUCCESS でない場合も）。出なければ10分後に村上さん
判定の中身には触らない
手順4 6:30 に jobctl status printdata_nightly が SUCCESS でない: 同梱なしに切り替える（設計書 5.4）
jobctl run insert_off_today、柏の早番リーダーに電話
記録: 引き継ぎノートに時刻と STATEGoodから何が変わったか: ★ここが学習の中心。読み手プロファイルの「何を気にしているか」（間違った操作で壊さないか）と「読む時間と場面」（3:05・寝起き・一人）の2項目に対応した変更が4つある。
- 「必要に応じて」が値の分岐になった。 手順1の3つの分岐は、
STATE=とDONE=の値だけで決まる。柴田さんは「進み具合を見る」を自分の判断にしなくてよい。5分あけて2回見るのは、「止まっている」と「遅いだけ」を見分ける最短の方法〔仮定: 10分未満で見分けたい。リハーサルで確かめる〕 - 各手順の終わりに行き先が書いてある。 「終わり」「手順3へ」。続きを探して設計書を開く必要がなくなった（Bad では5.4節を探す必要があった）。④次の行動が具体的になった
- 時刻が入った。 3:05・3:30・4:30・6:30。いつ電話するかが決まり、夜中に人を起こす判断を当番が背負わない（②読み手適合）
- 背景と概要を落とした。 3:05 に「なぜ同梱するか」は要らない。「使う場面」の1行だけ残した
それでもまだ足りないもの（Best へ）:
- 手順4が「設計書 5.4」を指していて、ここで設計書を開く。6:30 の決定は 6/27 に済んでいるのに、読み手に決まったことだと伝わらない（柴田さんは「本当にこのまま出荷して怒られないか」で止まる）
- 電話は番号も言うこともない。長谷川さんの寝起きの耳に、何を最初に伝えるか
- 「迷ったら」の出口が最初にない。分岐のどれにも当てはまらない画面が出たとき（例:
jobctlがログインできない）に、柴田さんは手順を最後まで読み返す - この手順書が初見の人で最後まで通るか確かめた跡がない。書き手は分かっているので、抜けが見えない
- 手順書を変えたとき誰が直すか（Runbook は環境の変化と同じ速さで古くなる）がない
R-01 Judgement batch is late (alert JUDGE-LATE, fires 03:00)
Use when: JUDGE-LATE fires. Not for other alerts.
Step 1 (03:05) Check state twice, 5 min apart:
jobctl status judge_insert_nightly
STATE=SUCCESS: close the alert. Done.
STATE=RUNNING and DONE is rising: check again at 03:30 (Step 1)
STATE=FAILED, or DONE flat for 5 min: go to Step 2
Step 2 Re-run (once only):
If RUNNING, first: jobctl stop judge_insert_nightly
jobctl run judge_insert_nightly --rerun (about 35 min)
SUCCESS: done. FAILED: Step 3. Never re-run twice.
Step 3 Call Hasegawa (also if still not SUCCESS at 04:30). No answer in 10 min: call Murakami.
Do not touch the judgement logic.
Step 4 At 06:30, if printdata_nightly is not SUCCESS: switch to no-card shipping (Design Doc 5.4)
jobctl run insert_off_today; call the early-shift leader at Kashiwa
Log: time and STATE in the handover note.英語の運用手順書の型（"Use when"、"Step N"、ステップ末尾の "Done" / "go to Step N"）に寄せた。分岐を値で書くところは日本語と同じ。
【村上さんへ（手順書の外）】決めてほしい3点。8/18 12:00 に決まらなければ★で進める
① 再実行の上限: ★1回／2回（2回は4:25 までに終わるが、同じ原因なら2回目も落ちる見込み）
② 長谷川さんが10分出ないときの先: ★村上さん／副当番（長谷川さんが8/17までに立てる）
③ 6:30 に電話する先: ★柏の早番リーダー（森田さん）／ 柏の事務所の代表番号
リハーサル 8/25 22:00 で柴田さんが初見で完走できなければ、手順書を直して再度
---
R-01 判定バッチが遅れたとき（JUDGE-LATE）版 8/17
迷ったら止まって村上 090-XXXX-0001 に電話。夜中でも構わない（指示）
3:05 jobctl status judge_insert_nightly を5分あけて2回
SUCCESS→アラートを閉じて終わり
RUNNING でDONE増→3:30にもう一度（4:30を過ぎたら3へ）
FAILED／DONE増えず→2へ
2. （RUNNINGなら先に jobctl stop）jobctl run judge_insert_nightly --rerun。35分待つ。再実行はこの1回だけ。SUCCESS→終わり。FAILED→3へ
3. 長谷川 090-XXXX-0002 に電話。「JUDGE-LATE、再実行 済／未、STATE=○」と言う。10分出なければ村上。電話までがあなたの仕事
4. 6:30に jobctl status printdata_nightly がSUCCESSでない→ jobctl run insert_off_today、柏の早番 090-XXXX-0003 に「今日は同梱カードなしで出荷」。決定済み（6/27 今井課長）。確認は要らないBetterから何が変わったか:
- 手順書の中に決めることを置かない。 再実行の上限・電話の先・6:30の電話先は、承認者の村上さんが読む「手順書の外」のメモに分け、3択と推奨（★）と、決まらないときの既定を付けた。手順書の本文は決定済みの結果だけになる（①結論の位置・④次の行動）
- 出口を最初に置いた。 「迷ったら止まって電話。夜中でも構わない」を冒頭に。SRE Workbook の「The on-call engineer is never alone」を、指示として書いた形（⑤想定反論: 「夜中に人を起こすのは悪いのでは」を先に潰す）
- 電話の台詞を入れた。 長谷川さんが最初に聞きたい3点（アラート名・再実行の済み未済・STATE）。柴田さんは台本を読むだけでよい
- 手順4に「決定済み」を入れた。 6:30の判断を柴田さんが背負わない。確認は要らない
- 設計書への参照を消した。 本文に「設計書 5.4」が1つもない。背景は設計書にあるが、3:05 に開かせない
- 版と検証を書いた。 版 8/17。リハーサルで初見の人が最後まで通るか確かめるまでは「未検証」と見える形にする
- 実測（日本語・空白を除く）: Bad 10行・235字、Good 12行・428字、Better 16行・543字、Best 15行・711字。村上さんへのメモ（6行・約220字）を除いた手順書の本文は 9行・492字で、行数は Good より少ない。ただし字数は Good より 64字多く、Best 全体は最長なので、厳密な「Best が最短」の逆転ではない（1行が長くなり、行数と字数で順位が変わる型）。Good の概要・前提・背景・注意と、Better の注記を、決定と出口と台詞に置き換えた
今回はBestまで作るべきか: Best必要。Runbook は実行する人が判断を迫られる場面で読まれる文書で、Better の水準だと「迷ったら」の出口と「電話で何を言うか」が抜ける。ただしRunbook 全体を Best にする必要はない。年6回ほどしか鳴らない R-02 以降（軽微なアラート）は Better で足りる。過剰品質も妥協と同じ判断ミスであり、Best を作るのは「夜間に人を起こすアラート」だけにする。
[To Murakami, outside the runbook] Three decisions needed. If undecided by Aug 18 12:00, we proceed with (*)
1. Re-run limit: (*) once / twice (twice ends by 04:25 but the same cause will likely fail again)
2. If Hasegawa does not answer in 10 min: (*) Murakami / a backup on-call (Hasegawa names one by Aug 17)
3. Who to call at 06:30: (*) the early-shift leader (Morita) / the Kashiwa office line
Rehearsal Aug 25 22:00: if Shibata cannot finish it cold, we revise and repeat.
---
R-01 Judgement batch is late (JUDGE-LATE) v Aug 17
If unsure, stop and call Murakami 090-XXXX-0001. Night calls are expected.
03:05 jobctl status judge_insert_nightly, twice, 5 min apart.
SUCCESS -> close the alert. Done.
RUNNING, DONE rising -> check again at 03:30 (after 04:30, go to 3)
FAILED, or DONE flat -> go to 2
2. (If RUNNING, first jobctl stop) jobctl run judge_insert_nightly --rerun. Wait 35 min. One re-run only. SUCCESS -> done. FAILED -> 3
3. Call Hasegawa 090-XXXX-0002. Say: "JUDGE-LATE, re-run done/not done, STATE=x". No answer in 10 min: Murakami. Your job ends at the call.
4. 06:30: if printdata_nightly is not SUCCESS -> jobctl run insert_off_today; call the early shift at Kashiwa 090-XXXX-0003: "Ship today without the card." Already decided (Jun 27, Imai). No need to confirm.BLUF（結論を先に）は手順書では「迷ったら電話」と「版」。英語では "Night calls are expected" と書くと、"Don't hesitate to call" より事実の言い方になり、指示として読める。決定を求める部分は "(*) = default" の記号で推奨を明示。
日英差分ノート
1. 「必要に応じて」と "as needed" — どちらも曖昧だが、英語の方が聞き返せない
- 日本語の運用手順書では、「適宜」「必要に応じて」「状況を見て」が丁寧で責任を分け合う言葉として通ってしまう。書き手が決めきれなかった跡が、礼儀の中に隠れる
- 英語の Runbook では "as needed" "if necessary" はそのまま曖昧と読まれる。夜間の英語の読み手（海外拠点の当番など）は聞き返せず、やらないか、やり過ぎるかに振れる
- どちらの言語でも、値と時刻で書き換える。ただし日本語は敬体（〜してください）を言い切り（〜する）に変えると行が短くなる。英語は最初から命令形で、そこが同じ長さの日本語より短くなる原因の一つ
2. 夜中に電話をかける許可 — 日本語は「指示」にしないと使われない
- 日本語の職場では、夜中の電話は遠慮の対象で、「ご連絡ください」と書いても、当番は朝まで一人で抱えがち。Best では「夜中でも構わない（指示）」と許可ではなく指示の形にした
- 英語（SRE の文化）では "escalate" 自体が通常の手順で、"Night calls are expected" と事実として書ける。ここでの日英の差は文法でなく、電話をかける心理的なコストの差である
- 英語版では「迷ったら」に当たる文がエスカレーションの正当化を含む（"Night calls are expected."）
3. 構成の差 — 英語は "Use when" と "Done" を明示する
- 英語の Runbook では冒頭に "Use when / Not for"、各ステップの末尾に "Done" や "go to Step N" を置くことが多い。日本語は文脈で読ませがちだが、Best では日本語にも「終わり」「3へ」を置いた
- 日本語版の「【概要】【前提】【手順】」のような見出し付きの型は、英語版では Good のときだけ出て、Better 以降は "Use when" に統合される
頻出表現
| 日本語 | English | トーンの強さ |
|---|---|---|
| 〜してください | Run: / Do: | 強い・命令。手順書では正解 |
| 必要に応じて | as needed / if necessary | 弱い・曖昧。手順書では避ける |
| 状況を見て判断 | use your judgement | 弱い。読み手に責任を渡す言葉 |
| 迷ったら電話 | If unsure, call X | 強い・出口 |
| 夜中でも構わない | Night calls are expected | 中立・許可の言葉 |
| 再実行は1回だけ | One re-run only / Never re-run twice | 強い・禁止 |
| 決定済み。確認不要 | Already decided. No need to confirm | 強い・柴田さんを迷わせない |
| 〜を参照 | See ... | 弱い。本文からは外す |
差分5軸まとめ
| 軸 | Bad | Good | Better | Best |
|---|---|---|---|---|
| ① 結論の位置 | ない（「状況を確認」で始まる） | 概要にあるが「何を打つか」は手順の3番目 | 手順1にコマンドと分岐が冒頭 | 「迷ったら電話」を最初に、分岐が続く |
| ② 読み手適合 | 想定していない | 一般の運用担当向けの型 | 3:05・寝起き・一人に合わせ、背景を落とした | 柴田さんの「間違えて壊さないか／起こしてよいか」に直接答える |
| ③ 事実と解釈の分離 | 混在（「適切に」「原因を調査」） | 手順と注意が分かれる | 値で分岐。ただし6:30の根拠は設計書 | 決定済みの事実（6/27）と、未決（村上さんへの3点）が分かれる |
| ④ 次の行動 | 不明（「関係者に連絡」） | 手順にある。ただし条件が曖昧 | 時刻と行き先がある | 電話の台詞・番号・出ないときの先まで確定 |
| ⑤ 想定反論 | 無視 | 一部（「慎重に」） | 一部（再実行は1回） | 「夜中に起こすのは悪い」「本当に出荷してよいか」を先に潰す |
Best版・全文
日本語版 全文を見る
夜間バッチ運用手順書 R-01「判定バッチが遅れたとき（JUDGE-LATE）」第1版（2028/8/17）
【提出メモ（村上さん・今井課長へ。手順書の外）】
決めてほしいことが3点あります。8/18（金）12:00 までに決まらなければ、★の案で進めます。8/21 の読み合わせで変えられます。
| # | 決めること | 案 | 比べるところ |
|---|---|---|---|
| ① | 再実行の上限 | ★A: 1回 ／ B: 2回 | Bでも 4:25 までに終わる（3:15 開始＋35分×2）。ただし失敗の原因が同じなら2回目も落ちる見込みで、運用が判定の中身に近づく（Day017: 運用は判定の中身に関与しない）。A の方が長谷川さんに電話が早く届く（最悪 4:30 → 100分の余裕）。〔仮定: 過去の失敗6件の原因の内訳は未集計〕 |
| ② | 長谷川さんが10分出ないときの先 | ★A: 村上さん ／ B: 副当番（長谷川さんが 8/17 までに立てる） | A は決まるのが早い。B は夜間の負担が分散するが、副当番が立たなければ空になる |
| ③ | 6:30 に電話する先 | ★A: 柏の早番リーダー（森田さん）／ B: 柏の事務所の代表番号 | A は出荷の現場に直接伝わる。B は番号が変わらないが、早番に伝わる前に時間がかかる |
見直す条件: 稼働後3か月の JUDGE-LATE の記録で、2回目の再実行で直った例が2件以上ある（①）／ 長谷川さんへの電話が3回以上つながらなかった（②）／ 早番のシフトが変わった（③）。
この手順書が使えることの確かめ: 8/25（金）22:00 に受入環境で、バッチをわざと止めて、柴田さんに初見で操作してもらう（Google SRE Workbook の "Wheel of Misfortune" 演習に近い）。合格は、3つの分岐（成功・停止・失敗）のそれぞれで、手順書以外の質問が0件。質問が出た箇所は手順書を直す。〔仮定: 合格基準は運用グループで未確認。8/21 の読み合わせで村上さんと決める〕
【R-01 本文】
R-01 判定バッチが遅れたとき（JUDGE-LATE） 版 8/17 検証: 8/25 リハーサル予定（未検証）
迷ったら、そこで止まって村上 090-XXXX-0001 に電話する。夜中でも構わない（これは指示）。
3:05 に始める。
- 状態を、5分あけて2回見る。
jobctl status judge_insert_nightlySTATE=SUCCESS→ アラートを閉じて終わりSTATE=RUNNINGでDONEの数が増えている → 3:30 にもう一度1へ。4:30 を過ぎても終わらなければ3へSTATE=FAILED、または5分間DONEが増えない → 2へ
- 再実行する。この1回だけ。
STATE=RUNNINGなら先にjobctl stop judge_insert_nightlyjobctl run judge_insert_nightly --rerun35分待つSTATE=SUCCESS→ 終わり ／STATE=FAILED→ 3へ
- 長谷川 090-XXXX-0002 に電話する。「JUDGE-LATE、再実行 済／未、STATE=（画面の値）」と言う。 10分出なければ村上に電話する。あなたの仕事は、ここまで。 判定の設定やデータには触らない。
- 6:30 に
jobctl status printdata_nightlyを見る。SUCCESSでなければ:jobctl run insert_off_today- 柏物流センターの早番リーダー 090-XXXX-0003 に電話し、「今日は同梱カードなしで出荷してください」と言う
- これは決定済み（6/27、今井課長）。確認は要らない
- 落ち着いてから、引き継ぎノートに時刻と
STATEを書く（後でよい）。
この手順書が扱わないこと: ほかのアラート（R-02 以降）、22:00 の取り込みの失敗、倉庫システム側の障害、監視センターが電話をかけるまでの手順。
English 全文を見る
Nightly Batch Runbook R-01 "Judgement batch is late (JUDGE-LATE)", v1 (Aug 17, 2028)
[Cover note to Murakami and Imai, outside the runbook]
Three decisions are needed. If they are not made by Fri, Aug 18 at 12:00, we proceed with the starred (*) option. You can change it at the Aug 21 read-through.
| # | Decision | Options | Trade-off |
|---|---|---|---|
| 1 | Re-run limit | (*) A: once / B: twice | B still ends by 04:25 (start 03:15 + 35 min x 2). But if the cause is the same, the second run will likely fail too, and Ops moves closer to the judgement logic (Day 17: Ops does not touch it). A reaches Hasegawa earlier (worst case 04:30, leaving 100 min). [Assumption: the causes of the past 6 failures have not been tallied] |
| 2 | If Hasegawa does not answer in 10 min | (*) A: Murakami / B: a backup on-call (Hasegawa names one by Aug 17) | A is decided today. B spreads the night load, but is empty if no one is named |
| 3 | Who to call at 06:30 | (*) A: the early-shift leader (Morita) at Kashiwa / B: the Kashiwa office line | A reaches the shipping floor directly. B keeps one number, but takes longer to reach the early shift |
Revisit when: in the first three months, two or more JUDGE-LATE cases are fixed by a second re-run (1) / Hasegawa could not be reached three or more times (2) / the early-shift schedule changes (3).
How we will know the runbook works: on Fri, Aug 25 at 22:00, in the acceptance environment, we stop the batch on purpose and let Shibata run it cold (close to the "Wheel of Misfortune" exercise in the Google SRE Workbook). Pass = zero questions outside the runbook in each of the three branches (success, stuck, failed). Where a question comes up, we fix the runbook. [Assumption: the pass criterion is not yet agreed; we set it with Murakami on Aug 21]
[R-01 body]
R-01 Judgement batch is late (JUDGE-LATE) v Aug 17 Verified: Aug 25 rehearsal planned (not yet verified)
If unsure, stop and call Murakami 090-XXXX-0001. Night calls are expected (this is an instruction).
Start at 03:05.
- Check the state twice, 5 minutes apart.
jobctl status judge_insert_nightlySTATE=SUCCESS-> close the alert. Done.STATE=RUNNINGandDONEis rising -> check again at 03:30 (step 1). If it is still not finished after 04:30, go to 3.STATE=FAILED, orDONEhas not moved for 5 minutes -> go to 2.
- Re-run. Once only.
- If
STATE=RUNNING, first runjobctl stop judge_insert_nightly jobctl run judge_insert_nightly --rerunWait 35 minutes.STATE=SUCCESS-> done.STATE=FAILED-> go to 3.
- If
- Call Hasegawa 090-XXXX-0002. Say: "JUDGE-LATE, re-run done/not done, STATE=(the value on screen)." No answer in 10 minutes: call Murakami. Your job ends here. Do not touch the judgement settings or data.
- At 06:30, run
jobctl status printdata_nightly. If it is notSUCCESS:jobctl run insert_off_today- Call the early-shift leader at Kashiwa 090-XXXX-0003 and say: "Please ship today without the card."
- This is already decided (Jun 27, Imai). No need to confirm.
- When you are calm, write the time and
STATEin the handover note (can wait).
Not covered: other alerts (R-02 onward), a failure of the 22:00 import, a problem on the warehouse system side, and the steps before the monitoring center calls you.
完成の定義チェックリスト
Runbook を出す前に必ず確認する項目。「雑・妥協」を防ぐための外部基準。1つでも未チェックなら、まだ出さない。
今日の演習
Bad の「それでも解決しない場合は、関係者に連絡してください」の1行だけを、3〜4行に書き直す。 手順:
- 「それでも」がいつを指すのか、時刻か値で書く（例: 再実行が
FAILED、または 4:30 になってもSUCCESSでない） - 「関係者」を1人の名前と電話番号に置き換える
- 電話で最初に言う言葉を1行書く
- 出なかったときの先と待つ時間を書く
別の読み手向けに R-01 を作り直す。 柴田さんでなく、海外拠点（英語が母語でない当番）が同じ手順書を読む場合の、英語版を元の版として作る。変えるところ:
- コマンドと値はそのまま。日本語の固有名（柏、早番リーダー、同梱カード）を英語で何と呼ぶかを最初の表で定義する
- 電話番号を、時差を含む連絡手段（チャット→電話）に置き換えるか決める（夜間の電話の許可の書き方も変わる）
- 8/25 のリハーサルの合格基準を、言語が違う人の場合に書き換える
取り組む前のヒント
- 「2人の当番が別々に読んで、同じ操作をするか」で測る。 同じにならない箇所は、数字でなく未決の判断が抜けている
- 分岐が3つを超えたら、手順を分ける。1つの手順に判断が3つ以上あると、寝起きの人は読み落とす
- 電話の台詞は短く。受け手が最初に聞きたい3点（何のアラートか／何をしたか／今の値）
- 「検証済み」と書けるのは、書き手以外の初見の人が通したときだけ。書き手が通しても抜けは見えない
実務での使いどころ
Runbook は、監視設計書（何を鳴らすか）で決めたアラートごとに1つ作る文書で、「各アラートに対応する手順があること」は鳴らしてよいかの条件にもなる（SRE Workbook: "Each alert should have a corresponding playbook entry"）。Day017 の運用設計書が決めた分界（運用が動ける範囲）が、そのまま手順の「触らない」「1回だけ」「電話」の線になる。
- 前: 運用設計書（Day017: 担当の分界、朝の既定動作）、テスト仕様書（Day033: 8/25 のリハーサルの入力になる）
- 後: 監視設計書（次: どの条件で JUDGE-LATE を鳴らすか。今日の 3:00 の根拠）、SLO 文書（朝8:00 の出荷のどこまでを約束するか）、ポストモーテム（鳴った日の振り返りと Runbook の修正。カテゴリ11）
- 横: リリース計画書（8/28 の切り戻し）、ADR（再実行の回数を設計に取り込むか）
この回の設計メモ（迷った他案・扱わなかった範囲・出所）
題材の選び方で迷ったこと
- Day017 の運用設計書の続きにした。設計書が「誰がどこまで」を決め、Runbook が「鳴ったときの操作」に下ろす関係。他案の「ログイン障害の Runbook」は読み手が顧客対応と混ざるため、Day017 の夜間バッチの続きを選んだ
- 比べるセクションは手順（分岐）の部分に絞った。Runbook の他の部分（目的・前提・権限・用語・連絡先表）は Good までに型として揃い、Better と Best で差が出るのは分岐と出口のため
- 読み手を「村上さん（承認者）」でなく「柴田さん（実行者）」にしたのは、カタログの主な読み手（当番担当者）と一致し、Lv2（他部署・業務を知らない）とも一致するため
- 当初は Best が Good より短くなると見込んでいた。実測すると、手順書の本文は行数で Good より少ないが、村上さんへのメモを含めた Best 全体は最長だった（見込みは外れ）。「決めることを手順書の外に出す」と決めた結果、本文では Good の概要・前提・背景・注意と Better の注記が不要になった
採らなかった案
| 案 | 採らなかった理由 |
|---|---|
| 手順書の中に「再実行の上限」を選ぶ欄を置く | 3:05 の読み手に決めさせることになる。決定は承認者のメモに分けた |
| フローチャートで分岐を図にする | スマホで3:05 に読む場面で図は崩れる。値の分岐の方が検索・コピーできる。〔仮定〕 |
| 全アラートを1枚に | 年6回の JUDGE-LATE と、軽微なアラートで要求が違う。Best は夜間に起こすものだけ |
| 英語版を元の版にする | Lv4・Lv5c の回で行う。今回は日本語版が元 |
扱わなかった範囲（黙って絞らない）
- R-02 以降（他のアラート）、22:00 取り込みの失敗、倉庫システムの障害、監視センターが電話をかけるまでの手順
- 手順書のバージョン管理の道具（Git か Wiki か）。SRE Workbook は "Details in playbooks go out of date" と述べるが、道具の選定は監視設計書・ADR で扱う
- 実在のオンコール文化の比較（PagerDuty の公開ドキュメント等）は取得しておらず、本文で根拠にしていない
出所と確かさのラベル
- SRE Workbook の On-Call の章: 要約ツール経由で引用文を確認（原文全体は未通読）。SRE Book の「Being On-Call」: 同じく「Feeling Safe」の節のエスカレーションの記述を要約で確認
- 数値（35分・20分・3:00 の発報・電話番号・過去の失敗6回）はシナリオ内の仮定。実測ではない。6:30 の既定動作（案B）は Day017 の決定を引き継いだ
- 「5分あけて2回」の根拠、「合格基準」は仮定。リハーサルと稼働後の実績で見直す
何が起きているか: