EXERCISE 90分

ストーリー

田中VPoE
SLI/SLO戦略、階層設計、エラーバジェットポリシー、レビュープロセス — 4つの要素を学んだ。ここからはTaskFlow社の全サービスに対してSLI/SLO体系を設計してもらう
あなた
全15サービスのSLOを設計するんですか?
田中VPoE
そうだ。ただし闇雲に設計するのではなく、ティア制度に基づくSLO基準水準、依存関係を考慮した階層設計、エラーバジェットポリシー、レビュープロセスの全てを含んだ包括的な体系だ。この設計書が経営会議で「SLI/SLO運用の正式開始」を承認してもらうための提案資料になる

ミッション概要

項目内容
演習タイトルSLI/SLO体系設計書
想定時間90分
成果物SLI/SLO体系設計書(階層SLO + エラーバジェットポリシー + レビュープロセス)
対象組織TaskFlow株式会社(Step 1, 2と同一)

前提条件

サービス一覧とティア分類

TaskFlow社 サービスカタログ:

Tier 1(クリティカル):
  1. API Gateway        - 全リクエストの入り口
  2. Payment Service    - 決済処理

Tier 2(重要):
  3. Task Service       - タスクCRUD(コア機能)
  4. Project Service    - プロジェクト管理
  5. Auth Service       - 認証・認可
  6. Notification Service - 通知配信

Tier 3(標準):
  7. Search Service     - 全文検索
  8. Report Service     - レポート生成
  9. File Service       - ファイルアップロード・管理
  10. Analytics Service - 利用状況分析

Tier 4(低優先):
  11. Batch Service     - バッチ処理(夜間集計等)
  12. Admin Service     - 管理者ツール
  13. Migration Service - データ移行ツール
  14. Sandbox Service   - テスト用サンドボックス
  15. Webhook Service   - 外部連携Webhook

依存関係情報

主要な依存関係:

API Gateway → Auth Service → Database
API Gateway → Task Service → Database, Cache
API Gateway → Project Service → Database
API Gateway → Payment Service → Database, External Payment Gateway
API Gateway → Search Service → Elasticsearch
API Gateway → Report Service → Database, S3

Task Service → Notification Service → SQS → Email/Push Provider
Project Service → Notification Service → SQS → Email/Push Provider
Payment Service → Notification Service → SQS → Email/Push Provider

Report Service → Analytics Service → Data Warehouse
Batch Service → Database, Data Warehouse, S3

現状のSLI実績(直近3ヶ月平均)

サービス可用性実績P99レイテンシ実績エラーレート実績
API Gateway99.97%180ms0.02%
Payment Service99.95%350ms0.04%
Task Service99.93%220ms0.05%
Project Service99.92%250ms0.06%
Auth Service99.98%80ms0.01%
Notification Service99.85%N/A(非同期)0.12%
Search Service99.80%500ms0.15%
Report Service99.70%3000ms0.20%

Mission 1: サービスSLI/SLO定義

要件

以下を設計してください。

  1. 全15サービスのSLI定義(サービスタイプに応じたSLI選択)
  2. 全15サービスのSLO値設定(ティア基準水準と実績データに基づく)
  3. SLO設定の根拠(各SLOの値がなぜその水準かの説明)
解答例

Tier 1 サービス

サービスSLI計算式SLO根拠
API Gateway可用性2xx+3xx応答数 / 総リクエスト数99.95%全リクエストの入り口。実績99.97%から余裕を持たせつつTier 1基準を満たす
API Gatewayレイテンシ200ms以内の応答数 / 総リクエスト数99.0%P99が180ms。200ms閾値で99%目標は現実的
Payment Service可用性成功トランザクション数 / 総トランザクション数99.95%決済は売上直結。実績99.95%でギリギリだがTier 1基準
Payment Serviceレイテンシ500ms以内の応答数 / 総リクエスト数99.0%外部ゲートウェイ依存あり。P99 350msから余裕を確保

Tier 2 サービス

サービスSLI計算式SLO根拠
Task Service可用性成功応答数 / 総リクエスト数99.9%コア機能。実績99.93%から0.03%マージン
Task Serviceレイテンシ300ms以内の応答数 / 総リクエスト数99.0%P99 220ms。300ms閾値で十分な余裕
Project Service可用性成功応答数 / 総リクエスト数99.9%実績99.92%。Tier 2基準を満たす
Auth Service可用性成功認証数 / 総認証試行数99.95%全サービスの依存先。Tier 2だがSLOは高めに設定
Auth Serviceレイテンシ100ms以内の応答数 / 総リクエスト数99.5%認証は低レイテンシが重要。P99 80msで余裕あり
Notification Service配信率30秒以内に配信されたイベント数 / 総イベント数99.5%非同期のため可用性より配信率。実績99.85%から余裕

Tier 3 サービス

サービスSLI計算式SLO根拠
Search Service可用性成功応答数 / 総リクエスト数99.5%検索ダウン時はフォールバック可。実績99.80%から余裕
Report Service可用性成功生成数 / 総リクエスト数99.5%バッチ的性格が強い。実績99.70%から引き上げ
Report Service鮮度60秒以内に生成完了した割合95.0%レポート生成は時間がかかるため基準を緩和
File Service可用性成功アップロード/ダウンロード数 / 総操作数99.5%S3依存で安定しているが、Tier 3基準を適用
Analytics Service鮮度データが1時間以内に反映される割合99.0%分析はリアルタイム性が低い

Tier 4 サービス

サービスSLISLO根拠
Batch Serviceジョブ成功率99.0%夜間実行、リトライで対応可能
Admin Service可用性99.0%社内ツール、営業時間のみ使用
Migration Serviceジョブ成功率95.0%不定期使用、手動リトライ可
Sandbox Service可用性95.0%テスト用、SLO自体が参考値
Webhook Service配信成功率99.0%リトライ機構あり

Mission 2: ジャーニーSLOと階層設計

要件

以下を設計してください。

  1. 主要ジャーニーSLO(5つ以上) の定義
  2. 依存関係に基づくSLO整合性の検証
  3. SLO階層図(ジャーニー → サービス → インフラの対応関係)
解答例

ジャーニーSLO

ジャーニー関与サービスSLISLO理論的上限
タスク作成Gateway→Auth→Task→DB→Notification2秒以内に完了99.9%99.75%
プロジェクト一覧Gateway→Auth→Project→DB→Cache3秒以内に表示99.9%99.80%
決済完了Gateway→Auth→Payment→External→Notification5秒以内に完了99.9%99.75%
全文検索Gateway→Auth→Search→Elasticsearch1秒以内に結果表示99.5%99.40%
レポート生成Gateway→Auth→Report→Analytics→S360秒以内に完了99.0%99.35%
ファイルアップロードGateway→Auth→File→S310秒以内に完了99.5%99.85%

SLO整合性の検証

ジャーニー: タスク作成(SLO 99.9%)
  Gateway:      99.95%
  Auth:         99.95%
  Task:         99.9%
  DB:           99.99%
  Notification: 99.5% (非同期・非クリティカル)

  クリティカルパスの理論的上限:
  0.9995 × 0.9995 × 0.999 × 0.9999 = 99.84%

  問題: 理論的上限(99.84%) < ジャーニーSLO(99.9%)
  対策:
    案1: Task ServiceのSLOを99.95%に引き上げ → 99.89%(まだ不足)
    案2: 加えてAuth ServiceのSLOを99.99%に引き上げ → 99.93%(達成可能)
    案3: ジャーニーSLOを99.8%に引き下げ

  → 案2を採用。Auth Serviceは全サービス共通依存なので
    高SLO投資の費用対効果が高い

SLO階層図

ジャーニーSLO          サービスSLO              インフラSLO
─────────────        ──────────────          ─────────────
タスク作成 99.9% ─┬── Gateway 99.95% ──┬── RDS 99.99%
                  ├── Auth 99.99%      ├── ElastiCache 99.99%
                  ├── Task 99.95%      └── ECS 99.95%
                  └── Notification 99.5%

決済完了 99.9% ──┬── Gateway 99.95%
                 ├── Auth 99.99%
                 ├── Payment 99.95%
                 └── Notification 99.5%

全文検索 99.5% ──┬── Gateway 99.95% ──── Elasticsearch 99.9%
                 ├── Auth 99.99%
                 └── Search 99.5%

Mission 3: エラーバジェットポリシーとレビュープロセス

要件

以下を設計してください。

  1. ティア別エラーバジェットポリシー(4段階)
  2. バーンレートアラート設定(Tier 1/2向け)
  3. レビュープロセス設計(週次・月次・四半期)
  4. SLO運用開始のロードマップ
解答例

ティア別エラーバジェットポリシー

Tier 1:

ステージバジェット残量アクション
Green75-100%通常開発。週次レビューで状況報告
Yellow50-75%SREレビュー付きデプロイ。信頼性タスク30%
Orange25-50%新機能一部凍結。VPoE報告。カナリア必須
Red0-25%完全機能フリーズ。全リソースを信頼性回復に

Tier 2:

ステージバジェット残量アクション
Green60-100%通常開発
Yellow30-60%リスク評価強化。信頼性タスク30%
Orange10-30%大規模変更凍結。SREリード報告
Red0-10%機能フリーズ。ポストモーテム必須

Tier 3/4: 閾値は設定するがアクションは勧告レベル(強制力なし)

バーンレートアラート

サービスティアページアラートチケットアラート報告アラート
Tier 11hバーンレート>14.46hバーンレート>63dバーンレート>1
Tier 21hバーンレート>14.46hバーンレート>61wバーンレート>1
Tier 3なし6hバーンレート>101wバーンレート>1.5
Tier 4なしなし1wバーンレート>2

レビュープロセス

レビュー頻度参加者主要議題
週次SLO毎週月曜 30分SRE + オンコールバジェット残量確認、今週のデプロイリスク
月次サービス月初水曜 1時間SREリード + サービスオーナーSLO達成率、改善策、SLO調整提案
四半期戦略四半期末 2時間VPoE + 全リードティア見直し、ポリシー有効性、投資判断

SLO運用開始ロードマップ

フェーズ期間対象マイルストーン
Phase 1: パイロット月1-2Tier 1(2サービス)SLI計測開始、SLOダッシュボード稼働
Phase 2: 拡大月3-4Tier 1+2(6サービス)エラーバジェットポリシー適用、週次レビュー開始
Phase 3: 全社展開月5-6全サービス全サービスSLO設定完了、月次・四半期レビュー開始

達成度チェック

観点達成基準
SLI/SLO定義の網羅性全15サービスのSLIとSLOが定義されている
階層設計の整合性ジャーニーSLO→サービスSLO→インフラSLOの整合性が検証されている
ポリシーの実用性ティア別のエラーバジェットポリシーが具体的なアクションとともに定義されている
レビュープロセスの設計3つのレビューサイクルが参加者・アジェンダとともに設計されている
ロードマップの現実性段階的な展開計画が現実的なタイムラインで示されている

推定所要時間: 90分