ストーリー
田
田中VPoE
SLI/SLOとエラーバジェットポリシーを策定した。信頼性の「測り方」と「ルール」は整った。次は「誰が」「いつ」「どのように」障害に対応するかだ
あなた
オンコール体制の設計ですね
あ
田
田中VPoE
そうだ。だが「夜中に電話が鳴ったら対応する」という安易な体制を作ると、燃え尽きと離職を招く。うちの運用チームの離職率30%は、まさにその結果だ
あなた
持続可能な体制にする必要があるんですね
あ
田
田中VPoE
その通り。オンコールは「苦行」ではなく「エンジニアリングの一部」だ。適切に設計すれば、チームの成長機会にもなる
オンコールの目的と原則
オンコールの目的
| 目的 | 説明 |
|---|---|
| SLO維持 | SLO違反を検知し、迅速に対応する |
| ユーザー影響最小化 | 障害の影響範囲と時間を最小限に抑える |
| 組織的学習 | インシデント対応を通じてシステムとプロセスを改善する |
SREオンコールの原則
| 原則 | 説明 |
|---|---|
| 持続可能性 | 人間が長期的に続けられる負荷に設計する |
| データ駆動 | SLOベースのアラートで「本当に対応が必要なもの」だけ通知 |
| エンジニアリング | 繰り返し発生する問題は自動化で解決する |
| 共有責任 | 開発チームもオンコールに参加する |
| 補償 | オンコール対応には適切な報酬と代休を提供する |
オンコールローテーションの設計
ローテーションモデル
| モデル | 構成 | メリット | デメリット |
|---|---|---|---|
| 週次交代 | 1週間ずつ担当 | シンプル、予測可能 | 1週間の精神的負荷 |
| 日次交代 | 1日ずつ担当 | 負荷分散 | 引き継ぎコスト大 |
| Follow-the-Sun | 地理的に分散 | 夜間対応なし | グローバルチーム必要 |
| Primary/Secondary | 1次+2次の2名体制 | 負荷分散、学習機会 | 人数が必要 |
推奨: Primary/Secondary × 週次交代
Week 1:
Primary: エンジニアA（最初に対応）
Secondary: エンジニアB（30分以内に応答なければ自動エスカレーション）
Week 2:
Primary: エンジニアB
Secondary: エンジニアC
Week 3:
Primary: エンジニアC
Secondary: エンジニアA
最低メンバー数: ローテーション = チームサイズ ÷ 2
→ 6名チームなら3週間ローテーション適切なチームサイズ
| チームサイズ | オンコール負荷 | 持続可能性 |
|---|---|---|
| 3名以下 | 高すぎる（月10日以上） | 不可 |
| 4-5名 | やや高い（月6-8日） | 短期的には可能 |
| 6-8名 | 適切（月4-5日） | 持続可能 |
| 9名以上 | 低い（月3日以下） | 理想的 |
オンコール担当は四半期あたり最大で時間の25%（約2週間に1回）を超えてはならない。これを超えると燃え尽きのリスクが急激に上昇する。
アラート設計
アラートの階層
| 階層 | トリガー条件 | 通知先 | 対応期待 |
|---|---|---|---|
| P1（緊急） | SLO違反、またはバーンレート > 10 | PagerDuty → オンコール担当 | 5分以内に応答 |
| P2（重大） | バーンレート > 3、またはエラー率急増 | PagerDuty → オンコール担当 | 15分以内に応答 |
| P3（警告） | バーンレート > 1.5、またはリソース逼迫 | Slack通知 | 営業時間内に対応 |
| P4（情報） | 軽微な異常、トレンド変化 | ダッシュボード表示 | 次回レビューで確認 |
良いアラートの条件
| 条件 | 説明 | 悪い例 |
|---|---|---|
| アクション可能 | 人間が何かするべきアラート | 「CPU 80%超過」（何をすれば？） |
| 緊急性が明確 | 優先度が判断できる | 全アラートがP1 |
| ノイズが少ない | 誤報率が低い | 月100件のアラート、うち80件が誤報 |
| SLOベース | エラーバジェットの消費に連動 | インフラ指標のみのアラート |
アラートノイズの管理
アラート品質の指標:
アクション率 = アクションが必要だったアラート / 総アラート数
目標: アクション率 80%以上
改善アプローチ:
アクション率 < 50% → アラート閾値の見直しが必要
アクション率 50-80% → 段階的に閾値を調整
アクション率 > 80% → 良好オンコール補償と文化
補償の設計
| 補償タイプ | 内容 |
|---|---|
| オンコール手当 | 待機時間に対する定額手当 |
| 対応時間の補償 | 実際の対応時間に対する時間外手当 or 代休 |
| 夜間対応後の休息 | 夜間対応後は翌日午前を休息時間とする |
| 連続対応の制限 | 1シフトで3件以上のインシデント対応後はSecondaryに引き継ぎ |
文化の醸成
| プラクティス | 説明 |
|---|---|
| オンコールハンドオフ | シフト交代時に前担当が状況を引き継ぐ |
| ウィークリーレビュー | 週次でオンコール負荷を振り返る |
| シャドーイング | 新メンバーは2週間、経験者のシャドーから開始 |
| 改善時間の確保 | オンコールで発見した問題の改善時間を20%確保 |
まとめ
| ポイント | 内容 |
|---|---|
| 最小チームサイズ | オンコールには最低6名が必要 |
| ローテーション | Primary/Secondary × 週次交代が推奨 |
| アラート | SLOベースでアクション可能なもののみ |
| 補償 | 適切な手当と休息の保証が持続可能性の鍵 |
チェックリスト
- オンコールローテーションの設計方法を理解した
- アラート階層の設計方法を理解した
- オンコール補償の重要性を理解した
次のステップへ
次は「エスカレーションフロー」です。インシデント発生時の対応フローとエスカレーションの仕組みを学びましょう。
推定読了時間: 30分