SRE 実践 #4 オンコール運用 — ローテーション、エスカレーション、負荷管理
アラートシステムがどれだけ良くても、そのページを受けるのは結局人間です。オンコール(on-call)は SRE 実践の中で最も人間味のある領域で、運用を誤れば最も確実に人を燃やし尽くす領域でもあります。今回はオンコールを持続可能な制度にする設計要素を扱います。
ローテーション — まず最低人数から計算します #
オンコールローテーションの最初の問いは「何人必要か」です。答えは思ったより大きいです。
- 24 時間 365 日をひとりで担うのはローテーションではなく人質事件です。休暇、病欠、退職を考慮すると、ひとつのローテーションに最低 5〜6 人が現実的な下限です。それより少ないとオンコールの周期が早く回りすぎて、消耗が始まります。
- 人数が足りない小さなチームは、無理にローテーションを作るより、複数チームでサービス群を束ねて共同オンコールを組むか、業務時間外にページする対象を最小限に絞るほうが正直な選択です。
勤務編成は 2 つの形が基本です。
- 週単位のシフト(終日): ひとりが 1 週間 24 時間オンコール。単純ですが夜間ページの負担が大きいため、夜間ページがまれなチームに向きます。
- 日中・夜間の分離、またはタイムゾーン分散(follow-the-sun): 拠点が分散した組織なら、各地域が自分の日中だけカバーするのが理想です。夜間の呼び出しそのものが消えます。
どちらの形でも 一次(primary)と二次(secondary) を置きます。一次が応答できない状況(移動中、障害の重複)のバックアップであり、新メンバーが二次で先に経験を積む訓練経路にもなります。
エスカレーション — 詰まったときの経路を先に描きます #
エスカレーションポリシーは「誰が、いつ、誰に助けを求めるか」の事前合意です。
- 自動エスカレーション: ページに N 分間応答(ack)がなければ、呼び出しツールが自動で二次 → チームリードの順に上げます。人が寝過ごす、電波がない、という状況は必ず起きるので、このチェーンはツールの設定で強制されなければなりません。
- 判断によるエスカレーション: 応答はしたが 30 分進展がない、または影響範囲が広がっているなら、他チームや上位の対応体制を呼びます。ここで大事な文化がひとつあります。エスカレーションは失敗ではなく手順です。「もう少しひとりで粘るべきだった」という空気のある組織では、障害の時間が伸びます。
- インシデント指揮体制: 影響の大きい障害では役割を分離します。指揮者(incident commander)は調整と意思決定だけ、実務者は対処だけ、コミュニケーターは状況共有だけを担います。対処する人が同時に報告文書を書く構造は、両方を駄目にします。
ハンドオフ — シフトはドキュメントで引き継ぎます #
シフトの交代を口頭の挨拶だけで済ませると、進行中の案件の文脈が消えます。ハンドオフは短くても形式を持たせます。
- 進行中のインシデントと現在の状態、次の確認時点
- 今回のシフトで鳴ったページの要約と処理結果
- 予定されているリスク要因(大型デプロイ、マイグレーション、トラフィックイベント)
- 静かだった場合も「静かだった」と明記(記録がないことと問題がないことは別です)
週単位のローテーションなら、チームミーティングの 5 分の固定アジェンダにするのが最も持続可能な形です。
負荷管理 — ページ件数に上限を設けます #
オンコールが崩壊するのは劇的な大障害のせいではなく、小さなページが毎晩続く慢性状態のせいです。だから負荷を数字で管理します。
- シフトあたりのページ件数を追跡します。 この数字がしきい値(例: 12 時間シフトで 2 件)を継続的に超えるなら、個人の忍耐ではなくシステムの問題として扱います。原因は 2 つにひとつです。アラートの品質が悪いか(第 3 回の誤検知整理の対象)、システムの信頼性負債が実際に大きいか(エンジニアリング投資の対象)。
- オンコール中はプロジェクト業務を期待しません。 オンコールシフトの成果物は対応、そして対応の過程で見つけた問題の記録です。オンコール担当に普段どおりのスプリントコミットを求める組織は、どちらかをこっそり諦めさせることになります。
- フォローアップ時間を制度化します。 オンコール週に見つかった問題(不正確なランブック、繰り返される手動復旧)を返済する時間を、次のスプリントに明示的に割り当てます。これがないと同じページが毎月繰り返されます。
報酬も負荷管理の一部です。夜間・週末の待機が無償のボランティアである組織では、オンコールの忌避は道徳の問題ではなく合理的な選択です。オンコール手当、代休など形は組織ごとに違いますが、待機のコストを組織が認めること自体が、制度の持続可能性を決めます。
オンコール担当の 30 分 — ランブックが必要な理由 #
ページを受けたオンコール担当の最初の 30 分は、おおよそ決まっています。確認(ack)→ 影響の把握(SLI ダッシュボード)→ 直近の変更確認(デプロイ、設定)→ 緩和(ロールバック、スケールアウト、トラフィック遮断)→ 必要ならエスカレーション。この流れでオンコール担当に必要なのは、システム全体への深い知識ではなく、アラートごとのランブックと診断の順序です。
ランブックに最低限入れるものは 3 つです。このアラートの意味(どの SLI がなぜ)、最初の確認項目(ダッシュボードのリンク、直近デプロイの確認コマンド)、そして検証済みの緩和手段(ロールバック手順、フィーチャーフラグ)。完全な原因究明は昼にやればいいのです。深夜の目標は診断ではなく、ユーザー影響を止めることです。
まとめ #
- ローテーションは最低 5〜6 人が下限です。人数が足りなければ共同オンコールやカバー範囲の縮小が正直な答えです。一次・二次の構造はバックアップであり訓練経路です。
- エスカレーションは自動(無応答時)と判断(進展なし)の 2 層で設計し、エスカレーションを失敗とみなさない文化を作ります。
- ハンドオフは短い形式のドキュメントに固定します。「静かだった」という記録も記録です。
- シフトあたりのページ件数に上限を設け、超過が続くならアラート品質か信頼性負債の問題に昇格させます。オンコール中のプロジェクト業務を期待せず、フォローアップ時間を制度化します。
- 深夜対応の目標は原因究明ではなく影響の停止です。だからランブックが必須です。次回はその障害が終わったあとのこと、ポストモーテムです。