LESSON 30分

ストーリー

田
田中VPoE
オンコール体制の仕組みを一通り設計した。だが、仕組みを作っただけでは不十分だ。体制が「健全に」機能し続けているかを継続的に監視する必要がある
あなた
オンコール体制自体のモニタリングですね
あ
田
田中VPoE
そうだ。うちの運用チームの離職率30%は、オンコール負荷の偏りが原因の一つだ。誰かに負荷が集中していないか、アラートノイズが多すぎないか、燃え尽きの兆候はないか — これらを定量的に管理する
あなた
メトリクスで健全性を可視化する、ということですね
あ
田
田中VPoE
その通り。「なんとなく大丈夫」ではなく、データに基づいて健全性を判断する。SLOでサービスの健全性を測るように、オンコール体制の健全性もメトリクスで測る

オンコール健全性メトリクス

負荷メトリクス

メトリクス計算式健全基準危険信号
ページ数/シフト1シフトあたりのアラート数≤ 2件/日> 5件/日
夜間対応数/月22:00-07
≤ 2回/月/人> 4回/月/人
対応時間/シフト実際にインシデント対応に費やした時間≤ 4時間/週> 8時間/週
連続対応なし日数アラートなしのシフト日数≥ 50%< 30%

品質メトリクス

メトリクス計算式健全基準危険信号
MTTA（応答時間）アラート→応答の時間≤ 5分> 15分
MTTR（復旧時間）検知→復旧の時間≤ 1時間> 4時間
アクション率対応が必要だったアラート/全アラート≥ 80%< 50%
自動復旧率自動で復旧したインシデント/全インシデント≥ 30%< 10%
エスカレーション率エスカレーションされたインシデント/全インシデント≤ 20%> 40%

チーム健全性メトリクス

メトリクス計測方法健全基準
負荷の偏りGini係数 or 標準偏差均等に分散
対応スキルの分布各メンバーが対応可能なサービス数全員が2サービス以上
新人の成長シャドー期間後の単独対応成功率3ヶ月以内に80%以上
チーム満足度四半期アンケート（1-5スコア）≥ 3.5

燃え尽き防止

早期発見のシグナル

シグナル説明対応
応答時間の増加MTTAが徐々に長くなる負荷の確認と分散
アラートの見逃しSecondaryへのエスカレーション増加負荷軽減、休息の確保
改善活動の停滞ポストモーテムのアクションアイテムが放置エンジニアリング時間の確保
チーム内の不満1on1での不満表明、オンコール回避行動補償の見直し、体制の改善

負荷管理のプラクティス

プラクティス説明
アラートバジェットチームあたりのアラート上限を設定（例: 週10件以下）
ノイズハント月次でアクション不要だったアラートを特定し削除
トイルスプリント四半期ごとにトイル削減に集中するスプリントを実施
オンコール休暇年に1回、2週間のオンコール免除期間を各メンバーに付与
負荷レビュー月次で負荷の偏りをチームで確認

継続的改善サイクル

改善フレームワーク

1. 計測（Measure）
   └── オンコール健全性メトリクスの収集

2. 分析（Analyze）
   └── トレンド分析、ボトルネック特定

3. 改善（Improve）
   ├── アラート閾値の調整
   ├── ランブックの追加・更新
   ├── 自動化の推進
   └── ローテーションの見直し

4. 検証（Verify）
   └── 改善前後のメトリクス比較

改善の優先順位

優先度対象期待効果
高ノイズアラートの削除即座に負荷軽減
高頻発するインシデントの根本対策中期的な負荷軽減
中ランブックの自動化対応時間の短縮
中ローテーションの最適化負荷の均等化
低新規ツール導入長期的な効率改善

まとめ

ポイント内容
3種のメトリクス負荷、品質、チーム健全性の3軸で管理
燃え尽き防止早期シグナルの検知とアラートバジェットの設定
継続的改善計測→分析→改善→検証のサイクルを回す

チェックリスト

  • オンコール健全性メトリクスの3つのカテゴリを理解した
  • 燃え尽き防止のプラクティスを理解した
  • 継続的改善サイクルの回し方を理解した

次のステップへ

次は「演習：オンコール体制を設計しよう」です。ここまで学んだ知識を活かして、実際にオンコール体制を設計しましょう。

推定読了時間: 30分