On-Call

アラート設計とランブック作成で持続可能なオンコール体制を作る

よくあるシナリオ：アラート地獄で離職するエンジニア

FinTechクライアントで優秀なエンジニアが立て続けに退職。理由はオンコール疲弊。週に50件以上のアラートが鳴るが8割はFalse Positive。深夜に起こされてサーバーを見ると「特に問題なし」。「何かあったら嫌だから」でアラートを追加し続けた結果、本当に重要なアラートが埋もれていた。

よくある課題

深夜アラートの8割がFalse Positiveで睡眠が取れない
アラートが多すぎて重要な通知を見逃す「アラート疲れ」
ランブックが古く実際の対応手順と乖離している
オンコール負担の偏りでエンジニアが燃え尽き離職

良いアラートの条件

良いアラートの 4 条件

Actionable（対処可能）

✅アラートを受けたら何をすべきか明確

❌「CPUが高い」だけで何をすべきか不明

Accurate（正確）

✅本当に問題が起きている時だけ発火

❌誤検知が多くアラート疲弊を生む

Urgent（緊急度相応）

✅Severity に応じた通知方法（PD / Slack）

❌全部 PagerDuty で夜中に起こされる

SLO-based（SLO 起点）

✅エラーバジェット消費率に基づいた閾値

❌「なんとなく 80% になったら」という閾値

核心概念を押さえる

オンコールたとえるなら「救急当直医」

本番システムの問題に24/7対応する当番制度。良い体制は「週8時間以内の対応時間」「60%以上の睡眠確保」がGoogleの基準。

例：ローテーション: 週単位で担当者交代→一人への集中を防ぐ→持続可能な体制

アラート品質たとえるなら「消防署の出動基準」

良いアラートは「アクション可能・緊急・ユーザー影響あり」の3条件を満たす。FalsePositiveを排除して信号対雑音比を高める。

例：BAD: CPU使用率80%で通知 / GOOD: エラー率が5%超過でユーザー影響確認

ランブックたとえるなら「パイロットの緊急手順書」

障害対応の手順書。深夜3時に半覚醒状態でも実行できる具体性が重要。「確認コマンド→判断基準→対処手順」の3点セット。

例：DBスロークエリ対応: 1)pg_stat_activityで確認 2)3秒超ならkill 3)EXPLAIN ANALYZE実行

アラートSLOたとえるなら「アラートの品質指標」

アラートにもSLOを設定。FalsePositive率<20%・初動5分以内・週の対応時間<8時間を目標に定量管理。

例：先月のFalsePositive率が35%→アラート閾値を見直し→今月は15%に改善

オンコールローテーションたとえるなら「当直医の交代制度」

特定の人に負担が集中しないよう週次で交代。Primary/Secondaryの二段階体制でエスカレーションパスを明確化。

例：週次ローテーション→8人チームなら8週に1回の当番→持続可能なオンコール体制

オンコールメトリクスたとえるなら「当直の健康チェック」

週次対応件数・FalsePositive率・深夜対応率を定期測定。数値で改善効果を見える化し、過負荷を早期検知。

例：先月比: 深夜対応-30%、FalsePositive率-20% → ランブック改善の効果が数値で確認

ランブック（Runbook）の構成

概要必須

このランブックが対応するアラートと状況

影響範囲必須

どのサービス・ユーザーに影響するか

診断手順必須

コピペできるコマンド・確認すべきダッシュボード

対処手順必須

ステップバイステップの具体的な操作

エスカレーション

解決できない場合の連絡先・次のステップ

確認方法

問題が解決したかを確認するクエリ・手順

ポイント: 「寝起き5分でも対応できる」レベルに具体化すること。コマンドはコピペできる形で。

AI で SRE の仕事はどう変わるか

これまで人がしていた作業

深夜アラートを受けてから手動でログを調査
ランブックを読みながら手順を一つずつ実行
過去の類似インシデントを記憶から探す
アラート閾値を経験則で設定・調整

AI が担う作業

アラート受信→ログ自動解析→根本原因候補を即提示（PagerDuty Copilot）
過去インシデントと照合し「この対応で解決した」を提案（FireHydrant AI）
FalsePositive率を分析し最適なアラート閾値を自動調整（Dynatrace Davis AI）
オンコール対応のパターンを学習し自動初期対応を実行（Opsgenie AI）

人に残る役割

未知の障害パターンの診断と対応判断
アラート設計の方針とSLO目標の決定
オンコール文化・心理的安全性の組織設計
AI対応では解決できないビジネス影響の大きな障害対応

主なツール：PagerDuty Copilot、FireHydrant AI、Opsgenie、Dynatrace Davis AI、Better Stack

この先の見通し：2027年にはAIエージェントが80%の定型インシデントを自律対応し、人間は複雑・高リスクな障害のみを担当する体制が標準化。オンコールの負担は現在の1/3以下に。SREのオンコール役割は「AIエージェントの監督者」へシフトし、深夜対応による燃え尽きが過去のものになる。

導入による効果の目安（業界の一般的な傾向）

FalsePositive削減: -70%; アラート品質改善
深夜対応件数: -50%; AI自動対応の効果
MTTA短縮: -40%; 初動対応の自動化
エンジニア満足度: +80%; 燃え尽き防止の効果