オンコール

概要

オンコールは、「今この瞬間に障害が起きたら誰が対応するか」を輪番（ローテーション）で決めておく体制です。担当者は当番の期間中、業務時間外でも通知を受け取れる状態を保ち、アラートが飛んできたら一定時間内に応答して初動にあたります。病院の当直医のソフトウェア運用版、と言えばイメージしやすいでしょう。

24時間止められないサービスにとって、モニタリングがどれだけ優秀でも、その通知を受け取って動く人間がいなければ意味がありません。オンコールは「アラートには必ず受け手がいる」ことを制度として保証する仕組みであり、インシデント対応プロセスの入口を人の側で支える土台です。同時に、担当者の睡眠と生活を犠牲にしかねない制度でもあるため、いかに持続可能に設計するかが常に問われます。

なぜ生まれたか

明示的なオンコール制度がない組織で障害が起きると、何が起きるでしょうか。「詳しいあの人」の携帯に深夜の電話が集中し、その人が休暇中なら誰も気づかないままサービスは朝まで止まり続けます。逆に全員にアラートを送れば、「誰かが見るだろう」とお互いに譲り合って結局誰も動かない。責任の所在が曖昧なままでは、検知から対応開始までの時間は運任せになります。

さらに深刻なのは特定個人への集中です。暗黙のうちに一人がすべての夜間対応を背負う状態は、その人の疲弊と離職で突然崩壊する、運用の単一障害点にほかなりません。オンコールは、対応責任を「明示的に・輪番で・一人ずつ」割り当てることでこの両方を解決します。当番が明確なら譲り合いは起きず、輪番なら負荷は分散され、知識も特定個人に閉じません。Google の SRE はこれを感情論ではなく工学として扱い、当番の負荷上限や補償のルールまで含めて制度設計する対象へと引き上げました。

詳細

ローテーション設計

基本形は「一次（プライマリ）対応者を1人、期間を区切って交代する」です。交代の粒度は1週間が代表的で、長すぎれば疲弊し、短すぎれば引き継ぎのオーバーヘッドが嵩みます。一次対応者が応答できない場合に備えて二次（セカンダリ）対応者を置き、さらにその先のエスカレーション先（テックリードやマネージャ）まで連鎖を定義しておきます。地理的に分散したチームなら、各地域の日中だけを担当してアラートを地球上でリレーする「フォロー・ザ・サン」体制により、誰も深夜対応をしない設計も可能です。人数も重要で、ローテーションが4人を切ると当番頻度が高くなりすぎて持続しにくい、というのが経験則としてよく語られます。

エスカレーション — 応答がなければ次へ

オンコールの信頼性は「一人の頑張り」ではなく「連鎖の設計」で担保します。アラートが発報されたら一次対応者に通知し、一定時間（たとえば5分）応答（ACK、確認応答）がなければ自動的に二次対応者へ、それでも応答がなければマネージャへと、PagerDuty や Opsgenie のようなツールが機械的にエスカレーションします。人間の善意や気合いではなく仕組みで「必ず誰かに届く」を保証するのがポイントです。

応答した担当者の仕事は、その場で自力解決することではなく「初動」です。影響を見極め、手に負えなければ躊躇なく詳しい人を呼び、重大ならインシデント対応体制を立ち上げる。オンコール担当を「一人で全部直せる人」と定義してしまうと担当できる人が育たないため、「適切に助けを呼べること」を合格ラインにするのが健全な設計です。そのために、アラートごとの初動手順をまとめたランブック（手順書）と、いつでも上位へ助けを求めてよいという明文化されたルールを整備しておきます。

アラート疲れとの戦い

オンコール制度の最大の敵は、障害そのものではなく「鳴りすぎるアラート」です。緊急でない通知や誤検知で夜中に何度も起こされ続けると、人は必ず麻痺します。狼少年アラートに慣れた担当者が本物の重大アラートを見逃す — これが「アラート疲れ（alert fatigue）」で、多くの重大事故の背景に潜んでいます。対策の原則は、深夜に人を起こしてよいのは「緊急かつ人間の判断が必要なもの」だけに絞ることです。緊急でないものはチケットや朝のダッシュボード確認に回し、対応が毎回同じものは自動化します。SLO ベースのアラート、つまり個々のサーバのCPU使用率ではなく「ユーザー影響が出ているか・エラーバジェットを急速に消費しているか」で発報する設計は、この絞り込みの実践形です。SRE の文脈では「1シフトあたりのインシデント数」に上限を設け、超えたらアラートの棚卸しや根本対策に開発時間を振り向ける、という負荷管理まで含めてオンコール設計と呼びます。

引き継ぎと持続可能性

当番交代時の引き継ぎも品質を左右します。継続監視中の事象、今週多発したアラートとその対処、進行中の変更予定などを短いドキュメントや引き継ぎミーティングで次の担当者に渡すことで、「先週から燻っていた問題に新しい当番が白紙から向き合う」無駄を防ぎます。当番期間中に対応した内容は記録に残し、繰り返し発生するものはポストモーテムやアラート改善の入力にします。オンコールで観測された痛みが、アラート設計・自動化・アーキテクチャ改善へと還流する — このループが回っている組織では当番は「学びの機会」になり、回っていない組織では「罰ゲーム」になります。夜間対応への金銭的補償や代休、当番明けの負荷調整といった処遇面も含め、オンコールは技術と人事制度の両輪で設計すべきテーマです。