オンコールは器用さではスケールしない。退屈な規律でスケールする。十年のポケベル、 三大陸、そしてイスマイリアで暴れたcronジョブの忘れがたい事件を経て、これが新しい ローテーション相手に実際に渡す短いリストだ。わざと一ページに収めている — 収まらない なら、午前3時に誰も読まないマニュアルを書いている。

第一のルール：誰も読んでいない

午前3時、君は読んでいない。パターンマッチングしている。壁一面の文字を落ち着いて 吸収すると前提するランブックはフィクションを書いている。残ったページには三つだけ ある：一行の症状、実行する正確なコマンド、次に確認する正確なもの。段落だらけの 説明版は半年以内にアーカイブ行きだ。本番の事故中に誰も開かないから。

「背景」節があるなら、それは未来の君のためであって、オンコール中の君のためでは ない。一番下に置け。

第二のルール：最初の行動は「人に伝える」

何かに触れる前に — ロールバックする前に、プールをスケールする前に、ノードを蹴る 前に — インシデントチャンネルに投稿する。二行だけ：見えているもの と これから やること。それだけだ。

これは摩擦に感じる。摩擦だ。ただし、君がオンコールに入れる中で最も安い摩擦だ。 三人のエンジニアが矛盾するコマンドを叩き、データベースが四分のあいだに二度 再起動される診断を防ぐ。どうして知っているかは聞くな。

最初に確認するものの順位付きリスト

順序が重要だ。ダッシュボードでこの五つが二クリック以内に届かないなら、君は インシデント前の問題を無視している。

  1. 直近一時間でデプロイしたか？ ページの60%はこれだ。君は知っている。 まずロールバック、それからデバッグ。デバッグ先行ロールバック後行は、三時間 の障害と、いったい誰の変更だったのかを非常に丁寧に追跡するSlackスレッドを 生む。
  2. データベースは無事か？ CPU、コネクションプールの飽和、レプリケーション 遅延。データベースはほぼ常にリクエストパスの最遅ノードであり、傷つけたとき に回復に最も時間がかかるものだ。
  3. 一つのリージョン / AZ / パーティションだけか？ 壊れて見えるが eu-central-1 でだけ壊れているなら、修正はコードではなくロードバランサ層にある可能性が高い。
  4. アップストリームのAPIが変わったか？ プロバイダは平日の午前10時に破壊的 変更を投入し、「チェンジログに書いてあった」ふりをする。
  5. トラフィック形状が変わったか？ 誰かの連携が本番に出て、君は今40倍の リクエストを受けている。サービスを書き直し始める前に、送信元IPの分布を確認 しろ。

この五つで原因が見つからないなら、ペースを落とせ。次の一手は常に「ログを ゆっくり、外側から内側へ読む」だ — 「推測して再起動する」ではない。

英雄行為は悪臭だ

初めて14時間のインシデントを一人で乗り切って皆が拍手した日、これが仕事だと 思った。十回目で、もっと多くの人を、もっと早く呼ぶべきシステムを自分が 抱え込んでいたことに気づいた。

エンジニアではなく英雄になっているサイン：

  • ランブックを理解しているのは自分だけ。
  • 使っているダッシュボードが自分のブックマークにしか存在しない。
  • 修正を筋肉の記憶で覚えている — そして一度も書き残していない。
  • 「自分がやった方が早い」からエスカレートしないと決めた。

どれもインシデント後のアクション項目だ。「ランブックを文書化」「ダッシュボードを 共有フォルダに移動」「トレーニング資料に節を追加」。君の英雄行為は技術的負債だ。 君のローテーションが次の誰かの継承トラウマになる前に返せ。

ポケベルは人事評価ではない

この記事から一つだけ持ち帰るなら：ポケベルが鳴るのはシステムが壊れるからだ。 システムが壊れるのはエンジニアリングが難しいからだ。ポケベルに起こされたから といって、君は遅い・劣っている・シニアでない、わけではない。君は現れた人だ。

ここでのアンチパターンは「誰が捕まえるべきだったか？」と問うポストインシデント レビューだ。答えはいつも「システム」だ — CI、テスト、アラーム、ガードレール、 正しい質問をしなかった設計レビュー。「誰が」の質問は恥辱劇場で、次のインシデント を難しくする。名指しされるのを避けるため、人々はページングを遅らせ始めるからだ。

正気を保ってくれた具体的な習慣

どれも積み重なる退屈なものだ：

  • 個人用ポケベルログをつけている。 時刻、ページ、最初に確認したこと、 実際の原因、知っていたら確認したもの。インシデントごとに五行。一年経つと、 公式ポストモーテムが見逃すパターンが浮き上がる。
  • 反射ではなく、意識的な確認で消音する。 アラートが間違っているなら、 その夜のうちにアラートを直す。消音して忘れたら、午前4時に再び鳴らされ、 それは当然の結果だ。
  • 「ページされたがインシデントではない」をバグとして扱う。 誤ページは 優先度ゼロの運用課題であって、民衆税ではない。チームが非イベントで 起きることを常態化すれば、ローテーションはゆっくり崩れる。
  • 引き継ぎは書面で。常に。 「報告事項なし」は文だ。「03:00のページを 無視した、たぶん自然に解決する」は引き継ぎだ。「おやすみ」は放棄だ。

実際に使われるランブックテンプレート

## 症状
<一文、ポケベルが言ったこと>

## 即時対応
<コマンド、ダッシュボードURL、「Xにエスカレート」>

## 確認
<うまくいったかを知る方法>

## 動かなかった場合の次の手
<最大三つ、順序付き>

## 背景
<それ以外すべて — なぜ、歴史、リンク>

上の四節が一画面に収まらないなら、一つのふりをした二つのランブックだ。分けろ。

そして最後に：睡眠

睡眠不足からエンジニアリングで脱出はできない。ローテーションが四半期に一度 以上君を起こすなら、それはエンジニアリングの問題だ — 個人の耐久力の問題では ない — そして君の仕事は、強くなることではなく、システムを静かにすることで 直すことだ。

私がローカルファーストのエージェントコントロールプレーン（Fulcrum）を 動かしているのは、部分的には、十年前に書き留めたインシデント対応の習慣を チームが何度も再発明するのを見るのに疲れたからだ。ポケベルは敵ではない。 敵は、うるさいポケベルをそれを持っている人の性格的特徴として扱う組織だ。