オンコール疲弊を防ぐ運用設計の手順

TL;DR

• オンコール疲弊は「アラートが多い」だけが原因ではなく、ローテ設計・アラート分類・Runbook・文化の 4 階層が同時に欠けている状態
• まず 5 問の症状診断で自チームの疲弊度を可視化し、3 個以上 YES なら設計欠落と判定する
• 段階的対策の優先順位は ローテ → アラートチューニング → AI triage → 体制設計 の順。逆順で着手すると効果が出ない（経験則）
• AI triage（PagerDuty Copilot・Datadog Bits AI）は重複 page の集約と Runbook 自動提示に効くが、P0/P1 の最終判断は人間に残す
• SPACE Satisfaction を月次で取り、Δ で疲弊兆候を早期検知する。DORA Failed Deployment Recovery Time と組み合わせて経営層と会話する

「夜中の呼び出しで頭が回らない」が常態化したチームへ

こんにちは、みねです。

SRE・Platform から「もう page が来ても起きない」「翌日のレビューが死んでいる」という声が出るチームは少なくない。私が見たチームでは当番ローテのメンバーの 3 割が直近 1 年以内に離職を口にしていた（経験則）。

対策の議論は「アラートを減らそう」で終わりがちだが、半年後アラート総数は減ったのに page で起こされる回数は変わらない――というチームを何度も見てきた。原因は ローテ設計・アラート分類・Runbook・ポストモーテム文化の 4 階層が同時に崩れていることで、1 階層だけ直しても再発する。

本記事は SRE・EM・Platform Lead 向けに、症状診断 → 根本原因 → 段階的対策 4 ステップ → アンチパターンの順で運用設計を整理する。読み終わった時点で「最初に着手すべき 1 つ」が決まっている状態がゴールだ。アプリ層の retry・冪等性はエラーハンドリング設計ガイドで扱っており、本記事は「人間が起きずに済む運用層」の話で補完関係にある。

症状診断：5 つの問いで判定

「忙しい気がする」では対策が打てない。以下 5 問のうち 3 個以上 YES なら設計欠落と判定する（経験則）。

これは Google SRE の On-Call の章 が示す「sustainable on-call」条件の簡易版だ。YES 0-1 個なら閾値チューニング等の単発対策で十分。本記事の対象は YES が 3 個以上のチームだ。

根本原因：疲弊は「アラート過多」ではなく設計の欠落

原因を 4 つに分解する。4 つは連動して悪化するため、アラートだけ減らしてもローテが偏っていれば疲弊は止まらない。

原因 1: ノイジーアラート（cause を鳴らしている）

「CPU 90% 超過」「Pod 再起動」「エラー 5 件」は原因（cause）側で、ユーザー影響（symptom）とは限らない。Google SRE Workbook の Alerting on SLOs は page すべきは user impact のある symptom のみと明示している[公式値]。cause alert は調査の手がかりとしては有用だが page にすべきではない。観測の足場の考え方はエージェントの可観測性設計と同じで、ログ・トレースは充実させつつ page は絞る。

原因 2: ローテーションの偏り

属人化エスカレ、24h × 7 日連続当番、Primary 1 名で Secondary 不在――「とりあえず古株が見る」で済ませた負債だ。休めない構造が退職連鎖の主因になる。

原因 3: Runbook 不在で都度ググる

page で「これ何だっけ」と Slack を漁る運用は初動の MTTR を 10-30 分悪化させる（業界目安）。AWS の Well-Architected Operational Excellence Pillar でも Runbook 整備が運用成熟度の前提だ。

原因 4: blame 文化で再発防止が形骸化

postmortem が責任追及で終わるとメンバーは障害を隠す方向に動く。Atlassian の Incident Management ハンドブック も Google SRE の Postmortem Culture も blameless（人ではなくシステムを問う）を前提に置く[公式値]。

段階的対策 1: ローテーション設計（最初に着手）

破綻したローテでは他対策の人手が確保できない。ここを最初に整える。

Primary / Secondary 2 段構成

Primary 1 名のみは業界で推奨されない。Google SRE Workbook の人数指針は multisite 24/7 で最低 5 名/site（余裕込み 6 名/site）、single-site 24/7 で 8 名（余裕込み 9 名） が公式値[公式値]（Google SRE - On-Call 参照）。本記事で示す 3 TZ × 各 10 名以上 は、引き継ぎ・休暇・兼務を見込んだ筆者の保守的な経験則で、少人数では引き継ぎコストが page 削減効果を上回るため Follow-the-sun を諦める判断もある（経験則）。

ローテ設計は 担当頻度 と 連続シフト長 を分けて考える。Google SRE は「shift length は 12 時間に制限し、連続担当は 1 週間より短くする（例: 3 days on, 4 days off）」を推奨[公式値]。個人の担当頻度は隔週以上に空けるが、1 回のオンコール期間は 12h シフト、または長くても 3-4 日で交代 とするのが疲労累積を抑える設計（経験則 + 公式値）。

on-call comp（手当）の選択肢

1. 時給ベース: 当番時間に時給の 25-50% 上乗せ（業界目安）
2. page ベース: 1 件固定額（深夜は 2-3 倍）
3. PTO 振替: 当番週ごと 0.5 日の振替休暇

PTO 振替が最もエンゲージメントに効きやすかった（経験則）。手当は数ヶ月で慣れるが「確実に休める」は疲弊回復に直結する。Failed Deployment Recovery Time との接続はDORA と SPACE の選び方で扱っている。

段階的対策 2: アラートチューニング

ローテが整ったら page 自体を減らす。鍵は 3 ティア再分類と symptom-based alerting だ。

棚卸しして 3 ティアに振り直すだけで page 数は半減することが多い（経験則）。Tier 2-3 は page しないルールを徹底する。「念のため page」が最もチームを壊す。

cause alert（CPU・メモリ・Pod 再起動）は symptom alert（SLO 違反・エラーレート）に置き換える。Prometheus Alertmanager なら以下のような symptom-based ルールに寄せる。さらに Google SRE Workbook が推奨する multiwindow, multi-burn-rate で page と ticket を切り分ける（Alerting on SLOs 参照、14.4x over 1h/5m で page、6x over 6h/30m で page、1x over 3d で ticket）[公式値]。

# Bad: cause alert（CPU は ticket に降格）
- alert: HighCPU
  expr: rate(node_cpu_seconds_total[5m]) > 0.9

# Good: symptom alert（user impact を page）
- alert: APILatencySLOViolation
  expr: histogram_quantile(0.95, rate(http_req_duration_seconds_bucket[5m])) > 0.5
  for: 5m

# Good: multiwindow multi-burn-rate（page）
- alert: APIErrorBudgetBurnFast
  expr: |
    (job:slo_errors_per_request:ratio_rate1h{job="api"} > (14.4 * 0.001))
    and
    (job:slo_errors_per_request:ratio_rate5m{job="api"} > (14.4 * 0.001))
  for: 2m

# Good: multiwindow multi-burn-rate（ticket、長期）
- alert: APIErrorBudgetBurnSlow
  expr: |
    (job:slo_errors_per_request:ratio_rate3d{job="api"} > (1 * 0.001))
  for: 1h

retry で吸収できる page 候補は自動化に回す。429 Too Many Requests で深夜に起こされるケースは exponential backoff + jitter で 95% 自動回復する（経験則）。詳細はエラーハンドリング設計ガイドで扱う。月次レトロで「先月の false positive」を降格する運用も必須。

段階的対策 3: AI triage の段階導入

ローテとアラートが整ってから AI triage を入れる。土台が無い状態で先に AI を入れても効果が薄い。

PagerDuty AIOps：重複 page の集約

PagerDuty AIOps（Copilot 含む）の event correlation は同一原因の複数 page を 1 incident に集約する。「DB 接続エラー」「API 5xx」「Health check fail」が別々に page される運用が 1 件にまとまる。ユースケースは PagerDuty State of Digital Operations Report に整理されている。

Datadog Bits AI / Watchdog と auto-runbook

Datadog の Incident Management と Bits AI / Watchdog は、メトリクス・ログ・トレースを束ねて summary / contributing factors / remediation 候補 / related incidents を自動提示し、Bits AI SRE investigation で原因仮説の追跡を補助する[公式値]。Runbook の自動提示は自社で runbook と incident history を連携している場合に成立する運用 wraps で、製品単体の標準機能ではない（条件付き）。境界線設計はAIエージェント運用Runbook設計で扱っている。

人間の最終判断を残す境界線

AI triage は便利だが P0 / P1 の最終判断は人間に残す。AI が「P2」と判定しても、本番影響が広範なら人間が P0 に上げ直せる権限を保つ。

durable workflow で人間介入を最小化する考え方はエージェントループの永続化で、auto-runbook のセキュリティ層はAIコーディングのセキュリティ設計、緊急アクセスの権限管理は認可設計のやり直しを併せて参照してほしい。

段階的対策 4: 体制設計とポストモーテム

最後に文化と計測を整える。後回しにすると対策 1-3 が半年で形骸化する。

blameless postmortem の定例化

人ではなくシステムを問う運用にする。Google SRE の Postmortem Culture と Atlassian ハンドブック を 最小テンプレ（公式要素を簡略化） にしたものが以下。実運用では owner / status / 共有範囲・承認者を必ず追加する。

1. メタデータ: owner / status / incident date / published date / severity
2. What happened: timeline と detection / resolution / recovery のファクト
3. Impact: 影響範囲（user 数・SLO 違反時間）と関連顧客
4. Root cause: システム要因（人為要因と分けて記述、causal chain と mitigations を systems / process / roles で整理）
5. Action items: 仕組み側の Priority Action / Improvement Action（owner と tracking ID を必須）
6. What went well: うまくいった対応の言語化
7. Sharing & approvals: 共有範囲（チーム / 部門 / 全社）と承認者

最小は 1〜5 だが、6〜7 を省くと再発防止と組織学習が抜ける（経験則）。Atlassian は severity 2 以上の incident に postmortem 実施を推奨している[公式値]。

Game day と SPACE Satisfaction で兆候を取る

四半期 1 回、当番以外が対応する Game day を実施する。属人化崩しに効き、chaos engineering 系プラクティスは ThoughtWorks Technology Radar でも継続評価されている。

疲弊兆候は月次 3 問サーベイ（5 段階）の Δ で追う（業界目安）。

• 直近 4 週、業務後に十分回復できたか
• 次の当番に行くのは気が重いか（逆スコア）
• チームのオンコール体制を後輩に勧められるか

SPACE Satisfaction 軸の簡易実装で、3 ヶ月連続で平均が下がったら設計を見直す。DORA Failed Deployment Recovery Time（旧 MTTR）との接続はDORA と SPACE の選び方で詳しい。

アンチパターン 4 つ

1: 「とりあえずアラートを全部 page」

「見逃したら怖い」で全 alert を page にすると、半年で全員が page を無視する。Tier 2-3 への降格を前提にする。

2: AI triage を最初に入れる

土台が無い状態で AI を入れても、AI が「ノイズをノイズのまま要約する」だけになる。順序は ローテ → アラート → AI で固定する。

3: postmortem を「振り返り会」と呼んで形骸化

呼称が「振り返り」になると人を責めない原則が緩み、action item が「気をつけます」で終わる。blameless postmortem という固有名詞で運用する。

4: 当番手当を入れて満足する

手当はエンゲージメントに効くが疲弊そのものは消せない。手当 + ローテ設計 + アラート整理をセットで動かす。

まとめ

オンコール疲弊はアラート過多だけが原因ではなく、ローテ・アラート分類・Runbook・文化の 4 階層が同時に崩れている。対策は ローテ → アラートチューニング → AI triage → 体制設計 の順で逆から着手しない。AI triage は P0/P1 の最終判断を人間に残し、SPACE Satisfaction を月次で取って Δ で兆候を検知する。

:::message 3 ヶ月後の自分への申し送り：page 数が減ったかではなく、当番後の翌日に PTO を取れたかを KPI にする。前者は減らしやすいが、後者が改善しない限り疲弊は止まらない。 :::

自チームの運用設計テンプレや 5 問診断シートが必要であれば、相談導線（記事下フォーム / X DM）から声をかけてほしい。

FAQ

Q1: オンコール手当の業界相場はどのくらいか？

業界目安として時給アップは 25-50%、page 1 件固定額の場合は深夜で 2-3 倍が一般的。手当の絶対額より、当番週後に確実に休めるか（PTO 振替）が疲弊回復には効く（経験則）。手当だけで満足すると半年後にまた退職連鎖が起きやすい。

Q2: Tier 1/2/3 に振り直すと page 数はどれくらい減るか？

経験則として棚卸し後に 30-50% 減るチームが多い。「念のため page」が Tier 2 / 3 に降格される量が多いほど効く。降格後に Tier 2-3 を翌営業日対応する運用を作らないと滞留して別の負債になる。

Q3: PagerDuty AIOps と Datadog Bits AI、どちらを先に入れるべきか？

メイン監視基盤として使っているほうを優先する。AI のために両方を新規導入するのは順序が逆で、Tier 1/2/3 のアラート分類が済んでから AI を入れる。AI は整理された page の集約は得意だが、ノイジーな page を綺麗にする能力は限定的だ（経験則）。

Q4: 少人数チーム（SRE 3-4 名）でも Follow-the-sun は組めるか？

組まないほうが現実的だ。Google SRE Workbook の公式値では multisite 24/7 で最低 5 名/site（余裕込み 6 名/site）が推奨され[公式値]、本記事の 3 TZ × 各 10 名以上は引き継ぎ・休暇・兼務を見込んだ保守的な経験則。少人数なら Primary/Secondary 2 段 + 担当頻度を隔週以上に空けて 12h / 3-4 日交代の連続シフト + PTO 振替で疲弊を抑え、深夜 page は AI triage と自動 retry で減らす。

Q5: 上層部が「責任の所在を明確にしろ」と要求する場合は？

「人を責めない」と「責任を曖昧にする」は別だと整理する。blameless postmortem は システム要因と人為要因を分けて記述するため責任の所在は明確になる。action item を仕組み側に倒すと再発防止が働く。Google SRE Workbook の Postmortem Culture の章はこの説明資料に使える[公式値]。

References

• Google SRE Workbook - On-Call — sustainable on-call の設計指針
• Google SRE Workbook - Postmortem Culture — blameless postmortem の原典
• Google SRE Workbook - Alerting on SLOs — symptom-based alerting の根拠
• Atlassian Incident Management - Being On-Call — 業界標準ハンドブック
• AWS Well-Architected Operational Excellence Pillar — Runbook 整備の成熟度モデル
• PagerDuty State of Digital Operations Report — AIOps の業界調査
• Datadog Incident Management — Bits AI / Watchdog 公式
• ThoughtWorks Technology Radar — AIOps / chaos engineering の業界レーダー