オンコール対応が「特定の人に集中する」「深夜対応が続いて疲弊する」状態になっていませんか。
「またアラートが来た」「今週で3回目の深夜対応だ」「ちゃんと引き継ぎが完了していなくて障害の詳細を知らないまま対応しなきゃいけない」——こういった状況は、オンコール体制が設計されていないチームで繰り返し起きます。
オンコールは、エンジニアの善意や根性で回すものではありません。ローテーション・エスカレーション・アラート設計・引き継ぎプロセスを組み合わせた、持続可能な仕組みとして設計する必要があります。
この記事では、SREの視点からオンコール体制を疲弊なく回し続けるための設計方法を解説します。
この記事でわかること
– オンコール体制設計の基本構成（4つの柱）
– ローテーション設計の具体的な考え方
– エスカレーションポリシーの作り方
– アラート疲労（Alert Fatigue）を防ぐアラート設計
– 引き継ぎ（ハンドオフ）プロセスの標準化
– オンコール文化を健全に保つためのポイント
オンコール設計の4つの柱
オンコール体制を「疲弊しない」ものにするには、次の4つを設計する必要があります。
| 柱 | 概要 |
|---|---|
| ① ローテーション設計 | 誰が・いつ・どの頻度で担当するか |
| ② エスカレーションポリシー | 対応できないとき・深刻な障害のとき誰に上げるか |
| ③ アラート設計 | 対応が必要なアラートだけが飛ぶようにする |
| ④ 引き継ぎプロセス | 交代時に情報が確実に伝わる仕組み |
この4つのどれかが欠けると、オンコールは「特定のエンジニアが無制限に対応し続ける体制」になりがちです。
① ローテーション設計
ローテーションの基本単位
一般的なローテーションは週次（1週間ごと）が多いですが、チームの規模や文化によって変わります。
| パターン | 向いているケース |
|---|---|
| 週次ローテーション | チームが4人以上、サービスが比較的安定している |
| 日次ローテーション | 深夜対応が多い、チームの心理的負荷を分散したい |
| 2週次ローテーション | チームが小規模（2〜3人）でやむを得ない場合 |
週次を基本にしつつ、深夜帯だけ日次にするハイブリッド設計も現実的な選択肢です。
最低限必要な人数
「何人いればオンコールを回せるか」はよく聞かれる質問です。目安は以下のとおりです。
- プライマリ（一次対応）: 1名
- セカンダリ（バックアップ）: 1名
- エスカレーション先: 1名（マネージャーまたはシニアSRE）
合計3名体制が最小構成です。週次ローテーションで「1週に1回のペースで担当が回ってくる」ようにするには、最低でも4〜5名のオンコールプールが必要です。
それ以下の人数で回している場合、いつかバーンアウトが起きます。人数が足りないなら、オンコールの対象サービスを絞る・SLOを見直す・採用を優先するという判断が必要です。
「同じ人に偏る」を防ぐ工夫
- 休暇・出張・体調不良時の代替担当を事前に決めておく
- スキルレベルに差がある場合は「シャドーイング期間」を設けて段階的に参加させる
- 新メンバーは最初の1〜2ヶ月間、プライマリではなくセカンダリとして参加する
② エスカレーションポリシー
エスカレーションが必要なケース
オンコール担当が一人ですべてを解決する必要はありません。以下のケースでは迷わずエスカレーションします。
- 対応開始から15〜30分以内に原因が特定できない
- サービス全体が停止しており、影響範囲が大きい
- セキュリティインシデント（不正アクセス・情報漏洩の疑い）
- 対応に権限が必要（本番DBの直接操作、緊急リリースなど）
「一人でなんとかしなければ」という心理がエスカレーションを遅らせます。エスカレーションは「負け」ではなくフローの一部です。
エスカレーション階層の設計例
レベル1：プライマリ（オンコール担当）
↓（15分解決できない / 深刻な障害と判断）
レベル2：セカンダリ（バックアップ担当）
↓（30分解決できない / 全サービス停止クラス）
レベル3：エスカレーション先（シニアSRE / マネージャー）
↓（経営判断が必要 / 大規模インシデント宣言）
レベル4：インシデントコマンダー（最上位責任者）
この階層をPagerDutyやOpsGenieなどのインシデント管理ツールに設定しておくと、時間経過で自動的にエスカレーションが実行されます。
「誰に連絡するか」を事前に決める
エスカレーション先はツール上に設定されていなければ意味がありません。「Slackで聞こう」「メールしよう」では夜中に機能しない可能性があります。
- 電話番号・Slackユーザー名を明記したRunbookを整備する
- 深夜対応が必要な場合は電話連絡を許可するルールを明文化しておく
③ アラート設計——「疲弊の元凶」を断つ
オンコール疲弊の最大の原因は不要なアラートが多すぎることです。「アラートが飛んできたが特に対応不要だった」が続くと、本物の障害アラートに対する反応が鈍くなります。これをアラート疲労（Alert Fatigue）と呼びます。
アラートの優先度分類
| 優先度 | 意味 | 通知方法 |
|---|---|---|
| P1（クリティカル） | 今すぐ対応しないとサービス停止 | 電話 / PagerDuty緊急 |
| P2（ウォーニング） | 1〜2時間以内に対応が必要 | Slack通知 / PagerDutyノーマル |
| P3（情報） | 翌営業日までに確認すれば良い | Slackのみ / メール |
P1以外は深夜に鳴らさないが基本原則です。
AWSでのアラート設計例
CloudWatchを使った実装例：
- P1: CloudWatch Alarm → SNS → PagerDuty（電話エスカレーション付き）
- P2: CloudWatch Alarm → SNS → Slack通知のみ
- P3: CloudWatch Logs Insights の定期レポートをメール送信
詳しいCloudWatchアラート設計については以下の記事も参考にしてください。
📌 合わせて読みたい：CloudWatchアラームの設定方法と実践的なチューニング
アラートをチューニングする習慣
オンコールを始めたら、最初の1〜2ヶ月は毎週アラートのサマリーを確認します。
チェックすべき指標：
– 1週間で何件のアラートが飛んだか
– そのうち実際にアクションが必要だったアラートは何件か
– 同じアラートが繰り返し飛んでいないか
「実際にアクションが必要だったアラートの割合」が70〜80%を下回るなら、アラートのチューニングが必要です。
④ 引き継ぎ（ハンドオフ）プロセス
引き継ぎで失敗するパターン
「なんとなく交代した」「前の担当者がどのインシデントを認識しているか知らずに対応を始めた」というのがオンコールの引き継ぎでよくある失敗です。
引き継ぎが不十分だと、前週の対応状況を知らないまま障害対応することになり、原因調査が無駄に長くなります。
ハンドオフドキュメントの標準フォーマット
週次交代のタイミングで以下を埋めたドキュメントを引き渡します。
## 引き継ぎサマリー（YYYY-MM-DD）
### 今週の対応件数
- P1: X件 / P2: X件 / P3: X件
### 継続中の問題・要注意事項
- （例）APIのレイテンシが木曜から上昇傾向。原因調査中。
- （例）DBのコネクション数が増えている。来週前半に確認を。
### 今週行ったアドホック対応
- （例）木曜 2:00 に CloudFront の設定変更を本番反映。影響なし確認済み。
### 来週注意すべきスケジュール
- （例）月曜 10:00 に大型キャンペーン開始。アクセス増加見込み。
### 引き継ぎ確認
- 担当者確認: □完了
このドキュメントはConfluenceやドキュメント管理ツールに残すことで、過去の傾向分析にも使えます。
引き継ぎミーティングの設定
可能であれば、オンコール交代日に15〜30分の引き継ぎ会を設定します。ドキュメントを読むだけでなく口頭で補足することで、ニュアンスの引き継ぎが格段に良くなります。
オンコール文化を健全に保つために
オンコール手当・代休の整備
オンコールは「業務外の時間を拘束する」行為です。適切な補償がないと「この会社ではやっていけない」というモチベーション低下に直結します。
- 深夜対応1件あたりの手当（金額を明示する）
- 週のオンコール担当期間中の代休取得ルール
- 深夜対応翌日は午前中の業務を免除するなどの配慮
これらが整備されていない場合、オンコール対応に参加したくないエンジニアが増え、特定の人に負担が集中するサイクルが始まります。
ポストモーテムと連携させる
重大なインシデントが発生した際は、オンコール対応の記録をポストモーテムに自動でつなぐフローを設計します。「対応記録」→「ポストモーテム」→「アラートのチューニング」→「Runbookの更新」のサイクルを回すことで、オンコールの品質は継続的に向上します。
📌 合わせて読みたい：ポストモーテムの書き方完全ガイド｜blameless文化を現場に根付かせる5つのポイント
「オンコールを学びの場にする」姿勢
疲弊しにくいオンコール文化の共通点は、オンコールを「苦役」ではなく「システムを最も深く理解できる機会」として捉えていることです。
オンコール中に障害を経験したエンジニアは、そのシステムの弱点・依存関係・回復方法を身体感覚として覚えます。この経験は、設計書を読むだけでは得られない実践的な知識です。
新メンバーに対して「最初はセカンダリとして参加してもらい、対応の流れを見てもらう」期間を設けることで、オンコールそのものが技術育成の場になります。
まとめ：オンコールは「設計する」もの
オンコール体制の設計を整理します。
| 要素 | チェックポイント |
|---|---|
| ローテーション | 週次単位で設計・4〜5名以上のプールがある |
| エスカレーション | 階層が明確・ツールに設定済み |
| アラート設計 | P1だけが深夜に鳴る・アクション率を定期確認 |
| 引き継ぎ | 標準フォーマットあり・口頭引き継ぎも実施 |
| 文化・補償 | 手当・代休が整備されている |
オンコールが「特定のエンジニアの善意」で回っている状態は、いつか崩壊します。仕組みとして設計することで、チーム全員が安心して持続的にサービスを守れる体制になります。
疲弊しないオンコール体制は、SREとしての腕の見せどころの一つです。
オンコール設計ができるSREになるには
オンコール設計・インシデント対応・SLO設計などのSREプラクティスは、転職市場でも高い評価を受けるスキルです。
実際に手を動かして学びたい方は、現役SREが設計した実践的な講座で体系的に学ぶことができます。
📌 SRE転職・キャリアについて詳しく知りたい方はこちら
関連記事
📌 インシデント対応フローの設計｜検知から復旧・振り返りまでSRE流に解説
📌 ポストモーテムの書き方完全ガイド｜blameless文化を現場に根付かせる5つのポイント
コメント