ストーリー
田
田中VPoE
SLI/SLOの設計方法とエラーバジェットの考え方を学んだ。最後のピースは「エラーバジェットポリシー」だ。バジェットが減ったとき、組織として何をするかを事前に合意しておく文書だ
あなた
いわば「緊急時の行動計画」ですね
あ
田
田中VPoE
そうだ。ただし、これが最も難しい部分でもある。「バジェットが枯渇したらリリース凍結」と書くのは簡単だが、実際にPMから「この機能は来週リリースしないと競合に負ける」と言われたとき、本当に凍結できるか？
あなた
ポリシーに政治的な圧力がかかる場面ですね…
あ
田
田中VPoE
だからこそ、経営層も含めた合意が必要だ。ポリシーを骨抜きにしたら、SREの仕組み全体が崩壊する
エラーバジェットポリシーとは
定義と目的
| 項目 | 内容 |
|---|---|
| 定義 | エラーバジェットの消費状況に応じた組織の行動規範を定めた文書 |
| 目的 | 信頼性と開発速度のバランスを組織的に管理する仕組みを確立する |
| 対象者 | 開発チーム、SREチーム、PM、経営層 |
| 承認者 | VPoE以上（組織をまたぐ判断権限が必要） |
ポリシーの構成要素
エラーバジェットポリシー:
├── 1. 適用範囲（どのサービスに適用するか）
├── 2. エスカレーション閾値（どの水準で何が起きるか）
├── 3. 凍結ルール（リリース凍結の条件と解除条件）
├── 4. 例外処理（ポリシーを例外的に緩和する手続き）
├── 5. 責任と権限（誰が判断し、誰が実行するか）
└── 6. レビューと更新（ポリシー自体の見直しサイクル）エスカレーション閾値の設計
4段階モデル
| レベル | バジェット残量 | 状態 | アクション | 判断者 |
|---|---|---|---|---|
| Level 0 | 75%以上 | 正常 | 通常開発。リリース制限なし | チーム自律 |
| Level 1 | 50-75% | 注意 | リスクの高い変更にレビュー追加 | テックリード |
| Level 2 | 25-50% | 警戒 | リリース頻度を半減、信頼性タスクを優先 | SREリード + PM |
| Level 3 | 25%以下 | 危険 | 新機能リリース凍結、信頼性回復に専念 | VPoE承認 |
バーンレートによる早期警告
| バーンレート | 意味 | アクション |
|---|---|---|
| ≤ 0.5 | 余裕あり | 制限なし |
| 0.5-1.0 | 計画通り | 通常運用 |
| 1.0-2.0 | やや速い | 原因調査を開始 |
| 2.0-5.0 | 危険 | 緊急対応チーム編成 |
| > 5.0 | 重大 | 即座にLevel 3対応 |
リリース凍結ポリシー
凍結の条件
| 条件 | 詳細 |
|---|---|
| 自動凍結 | バジェット残量が25%以下に到達した時点で自動発動 |
| 手動凍結 | SREリードがバーンレート5.0以上を確認した場合 |
| 部分凍結 | バジェット影響のあるサービスのみ凍結（他サービスは継続可能） |
凍結中に許可される変更
| 許可 | 不許可 |
|---|---|
| セキュリティパッチ | 新機能リリース |
| 信頼性改善（バグ修正） | UIの変更 |
| ロールバック | パフォーマンス最適化以外のリファクタリング |
| 可観測性の改善 | 依存ライブラリの大幅アップグレード |
凍結解除の条件
凍結解除には以下のすべてを満たす必要がある:
1. エラーバジェット残量が50%以上に回復
OR 新しい計測期間（月初め）の開始
2. 枯渇原因のポストモーテムが完了している
3. ポストモーテムのアクションアイテムが着手されている
（完了は不要だが、計画と着手は必須）
4. SREリード + PM + テックリードの3者が解除に合意例外処理の設計
例外の種類
| 例外タイプ | 説明 | 承認者 |
|---|---|---|
| ビジネスクリティカル | 法的要件、規制対応、重大な機会損失 | CTO |
| セキュリティ | 脆弱性の緊急パッチ | セキュリティリード |
| 顧客影響 | 特定顧客向けの緊急修正 | PM + SREリード |
例外申請プロセス
1. 申請者がリスク評価を文書化
- なぜ凍結中にリリースが必要か
- リリースしない場合のビジネスインパクト
- リリースによる信頼性リスクの見積もり
2. SREリードがテクニカルリスクを評価
- バジェットへの追加消費の見積もり
- ロールバック計画の確認
3. 承認者が判断
- 承認/却下/条件付き承認
4. 承認された場合
- カナリアリリース必須
- 15分間の観察期間
- ロールバック閾値の事前設定
5. 結果の記録
- 例外申請は全て記録し、四半期レビューで傾向分析ポリシードキュメントのテンプレート
記載項目
| セクション | 必須内容 |
|---|---|
| 目的と背景 | なぜこのポリシーが必要か |
| 適用範囲 | 対象サービス、対象チーム |
| エスカレーション閾値 | Level 0-3の定義 |
| 凍結ルール | 凍結条件、許可変更、解除条件 |
| 例外処理 | 例外の種類と申請プロセス |
| 責任と権限 | RACI表 |
| 計測と報告 | ダッシュボード、レポート頻度 |
| レビュー | ポリシー見直し頻度（推奨: 半期） |
| 署名 | VPoE以上の承認署名 |
RACI表の例
| アクティビティ | 開発チーム | SREチーム | PM | VPoE |
|---|---|---|---|---|
| SLI計測 | I | R/A | I | I |
| バジェット監視 | I | R/A | I | I |
| Level 1対応 | R | A/C | I | I |
| Level 2対応 | R | A | C | I |
| Level 3対応 | R | R | C | A |
| 凍結判断 | C | R | C | A |
| 例外承認 | I | C | C | A |
R=Responsible, A=Accountable, C=Consulted, I=Informed
まとめ
| ポイント | 内容 |
|---|---|
| ポリシーの本質 | バジェット消費に応じた行動規範を事前に合意する |
| 成功の鍵 | 経営層の承認と、例外処理の設計 |
| 凍結解除 | バジェット回復 + ポストモーテム完了 + 3者合意 |
チェックリスト
- 4段階エスカレーションモデルを理解した
- リリース凍結の条件と解除条件を理解した
- 例外処理プロセスの重要性を理解した
次のステップへ
次は「演習：エラーバジェットポリシーを策定しよう」です。ここまで学んだ知識を活かして、実際のサービスに対するSLI/SLO設計とエラーバジェットポリシーを策定しましょう。
推定読了時間: 30分