オンコール管理

英語名 On Call Management
読み方 オンコール マネジメント
難易度
所要時間 30分〜1時間
提唱者 Google SRE / PagerDuty
テンプレート あり ↓
目次

ひとことで言うと
#

障害対応当番(オンコール)のローテーション・エスカレーション・報酬を設計し、対応品質を維持しつつエンジニアの燃え尽きを防ぐ運用フレームワーク。

押さえておきたい用語
#

押さえておきたい用語
On-Call Rotation(オンコール ローテーション)
障害対応の当番を一定周期でチームメンバーに回す仕組みを指す。
Escalation Policy(エスカレーション ポリシー)
ファーストレスポンダーが対応できない場合に上位の対応者に引き継ぐルールを指す。
Pager Load(ページャー ロード)
オンコール期間中に受けるアラートの件数と対応負荷。持続可能な上限の目安がある。
Toil Budget(トイル バジェット)
SREの工数のうち手動の繰り返し作業に充てる上限。50%以下がGoogleの推奨である。
Runbook(ランブック)
既知のアラートに対する標準化された対応手順書。オンコール対応の属人化を防ぐ手法。

オンコール管理の全体像
#

オンコール管理:ローテーション・エスカレーション・改善の3本柱
ローテーション週単位の当番交代最低3名でローテーションPrimary + Secondary体制休日・深夜の負担を公平に負担の公平な分散エスカレーション段階的な引き継ぎ5分無応答→Secondary15分未解決→TL/EMSev1→VP/CTO通知一人で抱えない仕組み継続的改善アラートの根本対応繰り返しアラートの自動化Runbookの整備・更新Pager Loadの月次レビュー呼ばれない状態を目指すオンコール健全性の指標Pager Load週2件以下が理想深夜呼び出し率月1回以下を目標アクション不要率低いほどアラートの質が高いこれらの指標が悪化したらアラート設計・インフラ改善で根本対応する
オンコール管理の構築フロー
1
制度設計
ローテーション・エスカレーション・報酬を定義
2
ツール整備
PagerDuty/OpsGenie等でスケジュールを自動化
3
Runbook整備
頻出アラートの対応手順を文書化する
月次レビュー
Pager Loadを分析しアラートの根本対応を行う

こんな悩みに効く
#

  • 特定のエンジニアにオンコール負担が偏っている
  • 深夜の呼び出しが多くてエンジニアが疲弊している
  • アラートの大半がアクション不要の誤報で対応モチベーションが下がっている

基本の使い方
#

ローテーションとエスカレーションを設計する
最低3名でローテーションを組み、Primary + Secondaryの2層体制にする。1シフトは1週間が標準。エスカレーションは「5分無応答→Secondary」「15分未解決→EM/TL」のように段階を定義する。
報酬・代休のルールを明確にする
深夜・休日の対応には手当または翌営業日の代休を付与する。「オンコールに入ること自体」と「実際に呼ばれたこと」の両方に報酬を設定するのが公平。ルールが曖昧だと不満がたまる。
Pager Loadを月次でレビューし根本対応する
週のアラート件数・深夜呼び出し回数・アクション不要率を追跡する。繰り返し発生するアラートはRunbookを整備し、さらに自動化できるものは自動復旧に移行する。「呼ばれない状態」が理想。

具体例
#

例1:SaaS企業がオンコール負担を公平化する

エンジニア40名のBtoB SaaS。オンコールは「システムに詳しい人」に偏っており、特定の3名が月の 80% を担当していた。3名のeNPSは -15 まで低下。

ローテーション制を導入。全SREメンバー8名で週次ローテーション、Primary + Secondary体制。深夜呼び出し1回あたり 5,000円 の手当 + 翌日午前の代休を制度化。

指標BeforeAfter
特定3名の負担割合80%12.5%(8名均等)
深夜呼び出し/月/人6回1.5回
SREメンバーのeNPS-15+22

半年間の離職者はゼロ。以前は退職を考えていたメンバーも「公平になった」と評価。

例2:EC企業がアラートの根本対応でPager Loadを削減する

月間売上8億円のEC。オンコールのPager Loadが 週25件 あり、そのうちアクション不要が 60%。エンジニアが「どうせ誤報」と思い始め、本当に重要なアラートの対応が遅れるようになっていた。

月次のPager Loadレビューを開始。Top5のアラートを分析。

アラート週間件数対応
DB接続エラー(一時的)8自動リトライで解消。アラート削除
メモリ使用率80%超5閾値を90%に変更
バッチジョブタイムアウト4タイムアウト値を調整
外部API応答遅延3Circuit Breaker導入
ディスク使用率3自動ログローテーション

3ヶ月で 週25件 → 週4件 に削減。アクション不要率も 60% → 12% に改善。

例3:スタートアップが少人数でオンコール体制を構築する

エンジニア6名のスタートアップ。これまで障害時は「気づいた人が対応する」方式で、深夜にCTOの携帯に電話がかかる状態が続いていた。

6名で週次ローテーション(Primary + Secondary)を導入。少人数のためRunbookを徹底的に整備し、誰でも対応できる体制を目指した。

主要な15パターンのアラートにRunbookを作成。各Runbookは「症状確認(30秒)→ 対応手順(3ステップ以内)→ エスカレーション基準」の構成で統一した。

導入前はCTOが月 20回 呼ばれていたが、ローテーション + Runbook整備で全メンバーが対応可能になり、CTOへのエスカレーションは月 2回 に減少。CTOが本来の開発業務に集中できるようになった。

やりがちな失敗パターン
#

  1. ローテーション人数が少なすぎる — 2名だと1週おきにオンコールになり燃え尽きる。最低3名、理想は6名以上で回す
  2. 報酬なしでオンコールを「義務」にする — プライベートの時間を拘束する以上、手当や代休がないとモチベーションが維持できない
  3. アラートの誤報を放置する — アクション不要率が50%を超えると「アラート=ノイズ」という認識が定着し、本当の障害を見逃す
  4. Runbookを更新しない — 半年前のRunbookはインフラ変更で使えなくなっていることがある。月1回の棚卸しで正確性を確認する

まとめ
#

オンコール管理はローテーション・エスカレーション・継続的改善の3本柱で、障害対応の品質とエンジニアの健全性を両立するフレームワーク。ローテーションで負担を公平に分散し、報酬・代休で制度的に補償する。Pager Loadの月次レビューでアラートの根本対応を進め、「呼ばれない状態」 を目指すのが最も重要な改善方針になる。

オンコール管理のフレームワークテンプレート

このフレームワークを実際に使ってみましょう。