オンコール
On-Call ・ オンコール
障害発生時に対応する担当者を輪番で決めておく体制。アラートの受け手を保証する。
✦ 30秒で試す — 航海当番が寝過ごしても、5分後には次の人の電話が鳴るこの変更で、重大な障害を見逃す危険は？予想してみる概要
オンコールは、「今この瞬間に障害が起きたら誰が対応するか」を輪番（ローテーション）で決めておく体制です。担当者は当番の期間中、業務時間外でも通知を受け取れる状態を保ち、アラートが飛んできたら一定時間内に応答して初動にあたります。病院の当直医のソフトウェア運用版、と言えばイメージしやすいでしょう。
24時間止められないサービスにとって、監視がどれだけ優秀でも、その通知を受け取って動く人間がいなければ意味がありません。オンコールは「アラートには必ず受け手がいる」ことを制度として保証する仕組みであり、インシデント対応プロセスの入口を人の側で支える土台です。同時に、担当者の睡眠と生活を犠牲にしかねない制度でもあるため、いかに持続可能に設計するかが常に問われます。
なぜ生まれたか
明示的なオンコール制度がない組織で障害が起きると、何が起きるでしょうか。「詳しいあの人」の携帯に深夜の電話が集中し、その人が休暇中なら誰も気づかないままサービスは朝まで止まり続けます。逆に全員にアラートを送れば、「誰かが見るだろう」とお互いに譲り合って結局誰も動かない。責任の所在が曖昧なままでは、検知から対応開始までの時間は運任せになります。
さらに深刻なのは特定個人への集中です。暗黙のうちに一人がすべての夜間対応を背負う状態は、その人の疲弊と離職で突然崩壊する、運用の単一障害点にほかなりません。オンコールは、対応責任を「明示的に・輪番で・一人ずつ」割り当てることでこの両方を解決します。当番が明確なら譲り合いは起きず、輪番なら負荷は分散され、知識も特定個人に閉じません。Google の SRE はこれを感情論ではなく工学として扱い、当番の負荷上限や補償のルールまで含めて制度設計する対象へと引き上げました。
詳細
ローテーション設計
基本形は「一次（プライマリ）対応者を1人、期間を区切って交代する」です。交代の粒度は1週間が代表的で、長すぎれば疲弊し、短すぎれば引き継ぎのオーバーヘッドが嵩みます。一次対応者が応答できない場合に備えて二次（セカンダリ）対応者を置き、さらにその先のエスカレーション先（テックリードやマネージャ）まで連鎖を定義しておきます。地理的に分散したチームなら、各地域の日中だけを担当してアラートを地球上でリレーする「フォロー・ザ・サン」体制により、誰も深夜対応をしない設計も可能です。
人数も重要です。Google の SRE 本は目安として、1拠点で24時間を回すならローテーションに最低8人、2拠点で昼夜を分け合うなら各拠点に最低6人を挙げています。一次と二次の当番を立てても、1人に当番が回ってくる間隔が十分にあく人数です。あわせて、オンコール（呼び出しへの対応を含む運用作業）に使う時間は業務時間の25%まで、12時間のシフトで対応するインシデントは平均2件まで、という上限も示しています。1件のインシデントには調査・緩和・ポストモーテムまで含めて数時間かかるので、それ以上は「対応」ではなく「消耗」になるからです。
ただし、フォロー・ザ・サンは拠点の数だけ引き継ぎが発生します。引き継ぎのたびに文脈が落ちないよう、次の節で述べる引き継ぎの型が欠かせません。
エスカレーション — 応答がなければ次へ
オンコールの信頼性は「一人の頑張り」ではなく「連鎖の設計」で担保します。アラートが発報されたら一次対応者に通知し、一定時間（たとえば5分）応答（ACK、確認応答）がなければ自動的に二次対応者へ、それでも応答がなければマネージャへと、PagerDuty や Opsgenie のようなツールが機械的にエスカレーションします。人間の善意や気合いではなく仕組みで「必ず誰かに届く」を保証するのがポイントです。
応答した担当者の仕事は、その場で自力解決することではなく「初動」です。影響を見極め、手に負えなければ躊躇なく詳しい人を呼び、重大ならインシデント対応体制を立ち上げる。オンコール担当を「一人で全部直せる人」と定義してしまうと担当できる人が育たないため、「適切に助けを呼べること」を合格ラインにするのが健全な設計です。そのために、アラートごとの初動手順をまとめたランブック（手順書）と、いつでも上位へ助けを求めてよいという明文化されたルールを整備しておきます。
アラート疲れとの戦い
オンコール制度の最大の敵は、障害そのものではなく「鳴りすぎるアラート」です。緊急でない通知や誤検知で夜中に何度も起こされ続けると、人は必ず麻痺します。狼少年アラートに慣れた担当者が本物の重大アラートを見逃す — これが「アラート疲れ（alert fatigue）」で、多くの重大事故の背景に潜んでいます。対策の原則は、深夜に人を起こしてよいのは「緊急かつ人間の判断が必要なもの」だけに絞ることです。緊急でないものはチケットや朝のダッシュボード確認に回し、対応が毎回同じものは自動化します。SLO ベースのアラート、つまり個々のサーバの CPU 使用率ではなく「ユーザー影響が出ているか・エラーバジェットを急速に消費しているか」で発報する設計は、この絞り込みの実践形です。SRE の文脈では、先に挙げた「1シフトあたりのインシデント数」の上限を超えたら、アラートの棚卸しや根本対策に開発時間を振り向ける、という負荷管理まで含めてオンコール設計と呼びます。
引き継ぎと持続可能性
当番交代時の引き継ぎも品質を左右します。継続監視中の事象、今週多発したアラートとその対処、進行中の変更予定などを短いドキュメントや引き継ぎミーティングで次の担当者に渡すことで、「先週から燻っていた問題に新しい当番が白紙から向き合う」無駄を防ぎます。当番期間中に対応した内容は記録に残し、繰り返し発生するものはポストモーテムやアラート改善の入力にします。オンコールで観測された痛みが、アラート設計・自動化・アーキテクチャ改善へと還流する — このループが回っている組織では当番は「学びの機会」になり、回っていない組織では「罰ゲーム」になります。夜間対応への金銭的補償や代休、当番明けの負荷調整といった処遇面も含め、オンコールは技術と人事制度の両輪で設計すべきテーマです。
試問
24時間動くWebサービスで、夜間は当番の1人がスマホで警報を受けます。監視から届く8つの通知を、深夜でも当番を起こすもの・翌朝の作業に回すもの・人を呼ばずに自動で片付けるものに振り分けます。
8つの通知を、深夜に当番を起こすもの・翌朝に回すもの・人を呼ばず自動で片付けるものに仕分けよ
項目を選んでから、入れる箱を選びます