EXERCISE 90分

ストーリー

田中VPoE
オンコールの基本、エスカレーション、ランブック、健全性管理を学んだ。これらを統合して、うちの組織に合ったオンコール体制を設計してもらう
あなた
Step 1で設計したSRE組織モデルと整合させる必要がありますね
田中VPoE
そうだ。SRE部門10名(外部採用2名 + 既存運用チーム8名)という制約の中で、持続可能な体制を作る。加えて、将来的に開発チームもオンコールに参加する移行計画も含めてほしい
あなた
開発チームの巻き込みは段階的に、ですね
田中VPoE
その通りだ。いきなり「来月からオンコールに入れ」では反発必至だ。まずSREチームが見本を見せ、開発チームにはシャドーイングから始める

ミッション概要

項目内容
演習タイトルオンコール体制の設計
想定時間90分
成果物オンコール体制設計書

前提条件

組織構成(Step 1の設計を踏襲)

SRE部門(10名):
├── SREリード × 1(外部採用・経験者)
├── SREエンジニア × 1(外部採用)
├── プラットフォームエンジニア × 3(運用チームから転換)
├── 可観測性エンジニア × 2(運用チームから転換)
└── インフラエンジニア × 3(運用チームから転換)

対象サービス:
├── ECサイト(Tier 1)
├── 社内API基盤(Tier 2)
└── データパイプライン(Tier 3)

現状の課題

課題詳細
夜間対応月平均8回(特定の2名に集中)
アラート数月200件以上(アクション率30%)
MTTR平均4.2時間
ランブック存在しない
シフト体制なし(問題があれば山田部長に電話)

Mission 1: オンコールローテーション設計

要件

SRE部門10名でのオンコールローテーションを設計してください。

  1. ローテーションモデル: Primary/Secondary × 週次交代
  2. スケジュール: 3ヶ月分のローテーション表
  3. スキル要件: 各メンバーの対応可能範囲を定義
  4. 新人育成: シャドーイング計画
  5. 制約: SREリードは通常のローテーションに入らない(エスカレーション先)
解答例

ローテーションモデル

項目設計
モデルPrimary/Secondary × 週次交代
ローテーション人数8名(SREリード除く、SREエンジニア1名 + 既存7名)
1人あたりの頻度4週間に1回(Primary or Secondary)
シフト時間平日: 09:00-18
(通常業務) + 18:00-09
(オンコール)、週末: 終日

ローテーション表(Phase 1: 最初の3ヶ月)

PrimarySecondary備考
1SREエンジニア(外部採用)プラットフォームASREエンジニアがリード
2プラットフォームB可観測性A
3インフラAインフラB
4可観測性BプラットフォームC
5プラットフォームASREエンジニア
6可観測性AインフラA
以降ローテーション

スキルマトリクス

メンバーECサイトAPI基盤データPL育成計画
SREエンジニア(外部)全サービスカバー
プラットフォームA3ヶ月でデータPLを習得
プラットフォームB×6ヶ月でAPI基盤を習得
可観測性A3ヶ月でECサイトを習得
可観測性B3ヶ月でECサイトを習得
インフラA6ヶ月でデータPLを習得
インフラB6ヶ月で全サービスを習得
プラットフォームC×最初の3ヶ月はシャドーのみ

シャドーイング計画

Month 1-2: プラットフォームC + 自信のないメンバーがシャドー
  → 経験者のPrimaryにSecondaryとしてペア
  → ランブック作成に参加

Month 3: シャドー卒業テスト
  → ゲームデイで模擬インシデントに単独対応
  → 合格: 通常ローテーションに参加
  → 不合格: 追加1ヶ月のシャドー

Mission 2: エスカレーションフローとアラート設計

要件

  1. エスカレーションフロー: 時間ベース + 重大度ベースのフロー図
  2. アラート設計: Step 2で設計したSLOに基づくアラート一覧
  3. アラートノイズ削減計画: 月200件→目標50件以下への改善計画
  4. コミュニケーションプラン: インシデント時の連絡体制
解答例

エスカレーションフロー

アラート発報

  ├──[P1/P2]──→ PagerDuty → Primary On-call
  │                          ├── 5分応答なし → Secondary
  │                          ├── 15分未解決 → SREリードに通知、IC任命
  │                          ├── 30分未解決 → EM通知
  │                          └── 60分未解決 → VPoE通知

  ├──[P3]──→ Slack通知 → 営業時間内に対応

  └──[P4]──→ ダッシュボード → 週次レビューで確認

SLOベースアラート設計

アラートSLI条件優先度
EC可用性バーンレート高EC可用性 99.9%バーンレート > 10(5分間)P1
EC可用性バーンレート警告EC可用性 99.9%バーンレート > 3(15分間)P2
ECレイテンシ劣化EC P99 ≤ 800msP99 > 800ms(10分間)P2
決済エラー急増決済可用性 99.95%バーンレート > 5(5分間)P1
API基盤エラーAPI可用性 99.95%バーンレート > 5(10分間)P1
APIレイテンシAPI P99 ≤ 200msP99 > 200ms(10分間)P2
データPL遅延鮮度 ≤ 10分遅延 > 10分(15分間)P3
データPL処理失敗処理成功率 99.9%バーンレート > 5(30分間)P2

アラートノイズ削減計画

フェーズ期間施策目標
Phase 1Month 1全アラートの棚卸し、重複削除200→120件
Phase 2Month 2閾値の見直し、SLOベースへ移行120→70件
Phase 3Month 3自動復旧の実装、グルーピング70→50件以下

Mission 3: ランブック・プレイブック整備計画

要件

  1. 優先ランブック一覧: 最初に作成すべきランブック10本のリスト
  2. ランブックサンプル: 最も頻発する問題のランブック1本を詳細作成
  3. プレイブック: レイテンシ劣化時の調査プレイブック
  4. テスト計画: ゲームデイの実施計画
解答例

優先ランブック一覧

#ランブック名対象サービス頻度優先度
1ECサイトデプロイロールバックECサイト月2回P1
2DB接続プール枯渇対応API基盤月1回P1
3キャッシュサーバー障害対応ECサイト月1回P1
4決済ゲートウェイ障害対応ECサイト月0.5回P1
5Kubernetesポッド再起動全サービス月3回P2
6証明書更新手順全サービス年4回P2
7データパイプライン再処理データPL月1回P2
8CDN障害時のフェイルオーバーECサイト年2回P2
9ディスク容量逼迫対応全サービス月1回P3
10DNS障害対応全サービス年1回P3

ゲームデイ計画

項目内容
頻度月1回(第3水曜日 14:00-16
参加者SREチーム全員 + 対象チームの開発者1名
シナリオ前月のインシデント or ランブックの検証
進行SREリードがシナリオ注入、参加者がランブックに従い対応
評価対応時間、手順の正確性、改善点
成果ランブック更新、改善タスク起票

達成度チェック

観点達成基準
ローテーション持続可能な頻度で全メンバーに公平に分配されている
エスカレーション時間ベースと重大度ベースの両方が定義されている
アラートSLOベースでアクション可能なアラートのみ設計されている
ランブック優先度が高い問題のランブックが作成されている
健全性体制の健全性を測るメトリクスが定義されている

推定所要時間: 90分