演習：エラーバジェットポリシーを策定しよう

ストーリー

田

田中VPoE

SLI/SLOの理論とエラーバジェットポリシーの設計方法を学んだ。ここからは実践だ。うちの主要3サービスに対して、SLI/SLOの設計とエラーバジェットポリシーの策定をしてもらう

あなた

3サービス分ですか。それぞれ特性が違うので、画一的には設計できませんね

あ

田

田中VPoE

その通り。ECサイト、社内API基盤、データパイプライン — それぞれの特性に合ったSLI/SLOが必要だ。そして、3サービス共通のエラーバジェットポリシーを1本策定する

あなた

共通ポリシーにしつつ、サービスごとの差異も反映する必要があるんですね

あ

田

田中VPoE

そうだ。ポリシーが形骸化しないよう、現実的で運用可能なものを作ってくれ

ミッション概要

項目	内容
演習タイトル	エラーバジェットポリシーの策定
想定時間	90分
成果物	SLI/SLO設計書 + エラーバジェットポリシー

前提条件

対象サービス

サービス	概要	月間リクエスト数	ユーザー数
ECサイト	BtoC EC、売上直結	5,000万	50万人
社内API基盤	マイクロサービス間通信	2億	8チーム（内部）
データパイプライン	リアルタイム分析基盤	日次1,000万イベント	データチーム（内部）

現状のパフォーマンスデータ

ECサイト（過去90日）

指標	値
可用性	99.82%
P50レイテンシ	180ms
P99レイテンシ	1,200ms
デプロイ失敗率	18%
月間インシデント数	3-4件

社内API基盤（過去90日）

指標	値
可用性	99.95%
P50レイテンシ	45ms
P99レイテンシ	350ms
エラー率	0.08%

データパイプライン（過去90日）

指標	値
処理成功率	99.7%
平均遅延	3分
P99遅延	25分
データ欠損率	0.02%

Mission 1: ECサイトのSLI/SLO設計

要件

ECサイトに対して以下を設計してください。

ユーザージャーニーの特定: クリティカルパスを3つ以上
SLIの定義: 各ジャーニーに対するSLI（計算式含む）
SLO値の決定: 現状データとビジネス要件から目標値を設定
エラーバジェットの計算: 月間バジェット量を算出

解答例

ユーザージャーニー

#	ジャーニー	クリティカリティ
1	トップページ表示	中
2	商品検索・一覧表示	高
3	商品詳細表示	中
4	カート操作	高
5	決済完了	最高

SLI/SLO設計

SLI	計算式	SLO	エラーバジェット（月間）
可用性	成功レスポンス(2xx,3xx) / 総リクエスト	99.9%	43.2分
ページレイテンシ	P99 ≤ 800ms のリクエスト / 総リクエスト	99.5%	25万リクエスト
決済可用性	決済成功数 / 決済試行数	99.95%	21.6分
決済正確性	正確な金額処理数 / 総決済数	99.99%	月間決済の0.01%

設計根拠

SLO	根拠
可用性 99.9%	現状99.82%から改善目標。99.95%は短期的にコスト高
レイテンシ P99 ≤ 800ms	現状P99 1,200ms。800msはユーザー離脱率を20%削減の推計
決済可用性 99.95%	売上直結。可用性全体より厳しい基準が必要
決済正確性 99.99%	金額の誤りは信頼損失が甚大

Mission 2: 社内API基盤とデータパイプラインのSLI/SLO設計

要件

残り2サービスのSLI/SLOを設計してください。

社内API基盤: 内部サービス間通信の信頼性指標
データパイプライン: データの鮮度と正確性の指標
それぞれECサイトとの関係性（依存関係）を考慮すること

解答例

社内API基盤

SLI	計算式	SLO	エラーバジェット（月間）
可用性	成功レスポンス / 総リクエスト	99.95%	21.6分
レイテンシ	P99 ≤ 200ms のリクエスト / 総リクエスト	99.9%	20万リクエスト
エラー率	エラーレスポンス(5xx) / 総リクエスト	≤ 0.05%	月間10万リクエスト

設計根拠:

ECサイトが依存するため、ECサイトのSLOより高い可用性が必要
内部通信のため、ユーザー向けより厳しいレイテンシ基準（200ms）

データパイプライン

SLI	計算式	SLO	エラーバジェット（月間）
処理成功率	成功イベント / 総イベント	99.9%	月間1万イベントの損失許容
データ鮮度	遅延 ≤ 10分のイベント / 総イベント	99.5%	0.5%のイベントが10分超過可能
データ正確性	正確に処理されたイベント / 総イベント	99.99%	月間1,000イベントの誤り許容

設計根拠:

データパイプラインは分析用途のため、リアルタイム性よりも正確性を重視
10分の遅延許容は、ビジネスダッシュボードの更新頻度（15分）から逆算

依存関係の考慮

ECサイト（SLO 99.9%）
  └── 依存: 社内API基盤（SLO 99.95%）
        └── 依存: データベース（SLO 99.99%）

ルール: 依存先のSLOは依存元より高く設定する
理由: 依存先の障害が依存元のバジェットを消費するため

Mission 3: エラーバジェットポリシーの策定

要件

3サービス共通のエラーバジェットポリシーを策定してください。

エスカレーション閾値: 4段階（Level 0-3）
凍結ルール: 条件、許可変更、解除条件
例外処理: 例外の種類と申請プロセス
RACI表: 各アクティビティの責任者
運用ルール: 計測方法、報告頻度、レビュー頻度

追加の制約

開発チームが「面倒だ」と感じない程度のシンプルさ
PMが「ビジネスを止めるな」と言ったときに対応できる例外処理
経営層が承認できるレベルの根拠と明確さ

解答例

エラーバジェットポリシー v1.0

1. 適用範囲

本ポリシーは以下のサービスに適用する：

ECサイト（Tier 1: 売上直結）
社内API基盤（Tier 2: 内部基盤）
データパイプライン（Tier 3: 分析基盤）

2. エスカレーション閾値

Level	バジェット残量	アクション	通知先
0（正常）	75%以上	制限なし	なし
1（注意）	50-75%	Tier 1サービスへの変更にSREレビュー追加	Slackチャンネル
2（警戒）	25-50%	リリース頻度半減、信頼性スプリント開始	PM + テックリード
3（危険）	25%以下	新機能リリース凍結	VPoE + CTO

3. 凍結ルール

凍結条件:

バジェット残量 25%以下（自動判定）
バーンレート 5.0以上が1時間継続（SREリード判断）

凍結中の許可変更:

セキュリティパッチ
信頼性改善（バグ修正、パフォーマンス改善）
ロールバック
可観測性の追加

凍結解除条件:

バジェット残量 50%以上に回復 OR 新計測期間開始
枯渇原因のポストモーテム完了
アクションアイテム着手済み
SREリード + PM + テックリードの合意

4. 例外処理

例外タイプ	承認者	最大承認時間
法規制対応	CTO	2時間
セキュリティ緊急	セキュリティリード	1時間
売上影響（日次100万円以上）	VPoE	4時間

例外承認時の追加条件：

カナリアリリース必須（対象ユーザー5%以下）
15分の観察期間
ロールバック閾値の事前設定

5. RACI表

アクティビティ	開発	SRE	PM	VPoE
SLI計測の実装	R	A	I	I
バジェット監視	I	R/A	I	I
Level 1対応	R	A	I	I
Level 2対応	R	A	C	I
Level 3対応	R	R	C	A
凍結判断	C	R	C	A
例外承認	I	C	C	A
ポストモーテム	R	R	I	I

6. 運用ルール

項目	内容
計測ウィンドウ	30日間ローリング
ダッシュボード更新	リアルタイム（1分間隔）
週次レポート	毎週月曜に自動配信
SLOレビュー	四半期ごと
ポリシーレビュー	半期ごと

達成度チェック

観点	達成基準
SLI設計	ユーザー視点の指標が選定され、計算式が明確
SLO設計	現状データとビジネス要件に基づく妥当な目標値
依存関係	サービス間の依存を考慮したSLO設計
ポリシー	4段階エスカレーションと凍結ルールが定義されている
運用可能性	シンプルで実行可能な設計になっている

推定所要時間: 90分