ストーリー
田
田中VPoE
SLO階層設計とエラーバジェットポリシーが揃った。だが、これらを「設定して終わり」にしてはいけない。SLOは生き物だ。ビジネスの変化、アーキテクチャの進化、ユーザー行動の変化に合わせて継続的に見直す必要がある
あなた
定期的にSLOの値を見直すということですか？
あ
田
田中VPoE
値の見直しだけではない。SLOの「妥当性」「有効性」「運用プロセス」全体をレビューするんだ。SLOが形骸化する最大の原因は、レビューサイクルが回らないことだ
あなた
どのくらいの頻度で、何をレビューすればいいのでしょうか？
あ
田
田中VPoE
3つのレビューサイクルを設計する。「週次のオペレーショナルレビュー」「月次のサービスレビュー」「四半期のストラテジックレビュー」だ。それぞれ目的と参加者が異なる
3つのレビューサイクル
レビュー体系の全体像
┌─────────────────────────────────────────────┐
│ 四半期レビュー（Strategic） │
│ 目的: SLO戦略・ティア制度の妥当性評価 │
│ 参加: VPoE, SREリード, PdM, チームリード │
│ 所要: 2時間 │
├─────────────────────────────────────────────┤
│ 月次レビュー（Service） │
│ 目的: サービス別SLO達成状況と改善策 │
│ 参加: SREリード, サービスオーナー │
│ 所要: 1時間 │
├─────────────────────────────────────────────┤
│ 週次レビュー（Operational） │
│ 目的: エラーバジェット消費状況の確認 │
│ 参加: SRE, オンコール担当, サービスオーナー │
│ 所要: 30分 │
└─────────────────────────────────────────────┘週次オペレーショナルレビュー
目的と参加者
| 項目 | 内容 |
|---|---|
| 目的 | エラーバジェットの消費状況を確認し、短期的な対応を判断する |
| 参加者 | SREチーム、オンコール担当、各サービスオーナー |
| 所要時間 | 30分 |
| 開催タイミング | 毎週月曜日 10 |
アジェンダテンプレート
| 時間 | 議題 | 内容 |
|---|---|---|
| 5分 | エラーバジェットサマリー | 全サービスのバジェット残量を一覧で確認 |
| 10分 | Yellow/Orange/Redサービスの報告 | バジェットが注意域以下のサービスについて状況報告 |
| 10分 | 先週のインシデントとバジェット影響 | インシデントによるバジェット消費量の確認 |
| 5分 | 今週のデプロイ予定とリスク評価 | 大規模変更のリスクをバジェット残量に照らして判断 |
週次レビューのダッシュボード
週次SLOレビューダッシュボード:
┌──────────────────────────────────────────┐
│ エラーバジェット残量一覧（全サービス） │
│ │
│ Payment Service ████████████████░░ 82% │ Green
│ Task Service ███████████████░░░ 78% │ Green
│ API Gateway ████████████░░░░░░ 63% │ Yellow ⚠
│ Search Service ████████░░░░░░░░░ 45% │ Orange ⚠
│ Notification ██████████████████ 95% │ Green
├──────────────────────────────────────────┤
│ 今週のバーンレート推移 │
│ [時系列グラフ: 各サービスのバーンレート] │
├──────────────────────────────────────────┤
│ 先週のインシデントとバジェット影響 │
│ #142 API Gateway タイムアウト: -8% │
│ #143 Search Service インデックス障害: -12% │
└──────────────────────────────────────────┘月次サービスレビュー
目的と参加者
| 項目 | 内容 |
|---|---|
| 目的 | サービス別のSLO達成状況を深掘りし、中期的な改善策を策定する |
| 参加者 | SREリード、各サービスオーナー、該当チームのテックリード |
| 所要時間 | 1時間 |
| 開催タイミング | 毎月第一水曜日 14 |
アジェンダテンプレート
| 時間 | 議題 | 内容 |
|---|---|---|
| 10分 | 月間SLO達成レポート | 全サービスの月間SLI実績とSLO達成状況 |
| 15分 | バジェット枯渇/低下サービスの深掘り | 原因分析、改善策、必要リソース |
| 15分 | ジャーニーSLOの達成状況 | End-to-End品質の評価 |
| 10分 | SLO調整の提案 | SLOの引き上げ/引き下げの提案と議論 |
| 10分 | 来月のアクションアイテム | 改善タスクの割り当てと期限設定 |
月次レビューレポートの項目
| セクション | 内容 | 具体例 |
|---|---|---|
| SLO達成率サマリー | 全サービスの達成/未達成一覧 | 15サービス中13達成、2未達 |
| エラーバジェット推移 | 月初→月末のバジェット残量推移 | Payment: 100%→82%、Search: 100%→45% |
| トップインシデント | バジェット影響が大きかったインシデントTOP3 | #143: Search障害で-12% |
| 改善効果 | 前月の改善アクションの効果測定 | コネクションプール修正でMTTR 30%短縮 |
| SLO調整提案 | データに基づくSLO変更の提案 | Search: 99.5%→99.0%に引き下げ提案 |
四半期ストラテジックレビュー
目的と参加者
| 項目 | 内容 |
|---|---|
| 目的 | SLO戦略全体の妥当性を評価し、組織目標と整合させる |
| 参加者 | VPoE、SREリード、プロダクトマネージャー、全チームリード |
| 所要時間 | 2時間 |
| 開催タイミング | 四半期末の最終週 |
アジェンダテンプレート
| 時間 | 議題 | 内容 |
|---|---|---|
| 20分 | 四半期SLOサマリー | 全サービスの四半期間SLO達成率と傾向 |
| 20分 | ティア制度の見直し | サービスティアの妥当性評価と変更提案 |
| 20分 | ジャーニーSLOの見直し | ユーザージャーニーの変化に伴うSLO更新 |
| 20分 | エラーバジェットポリシーの有効性 | ポリシーが意図通り機能しているかの検証 |
| 20分 | 次四半期の信頼性目標 | ビジネス目標に紐づく信頼性目標の設定 |
| 20分 | 投資判断 | 信頼性改善への追加投資の要否判断 |
四半期レビューで問うべき問い
| カテゴリ | 問い |
|---|---|
| SLOの妥当性 | 現在のSLOはユーザー体験を適切に反映しているか？ |
| SLOの過不足 | SLOが厳しすぎてイノベーションを阻害していないか？SLOが緩すぎてユーザー不満が出ていないか？ |
| ティア制度 | サービスのビジネスインパクトに変化はないか？ティア変更が必要なサービスはあるか？ |
| ポリシーの有効性 | エラーバジェットポリシーは意図通り機能したか？例外プロセスが多すぎないか？ |
| コスト効率 | 信頼性投資のROIは計画通りか？追加投資の必要性はあるか？ |
SLOレビューの成熟度指標
レビュープロセスの成熟度モデル
| レベル | 状態 | 特徴 |
|---|---|---|
| L0: 未実施 | レビューなし | SLOを設定したが振り返りをしていない |
| L1: アドホック | 障害時のみ振り返り | インシデント後にSLOを確認するが定期レビューはない |
| L2: 定期的 | 週次/月次レビューが定着 | 定期的にレビューしているが改善アクションが不十分 |
| L3: データ駆動 | データに基づく改善サイクル | レビュー→アクション→効果測定のサイクルが回っている |
| L4: 自動化 | 自動レポート + プロアクティブ | ダッシュボード自動更新、バーンレート予測による予防的対応 |
目標とする状態
TaskFlow社の目標: 6ヶ月でL2、12ヶ月でL3
L2（定期的）の達成基準:
✓ 週次レビューが4週連続で実施された
✓ 月次レビューが3ヶ月連続で実施された
✓ 全Tier 1/2サービスのSLOダッシュボードが稼働している
✓ エラーバジェットポリシーが全Tier 1サービスで適用されている
L3（データ駆動）の達成基準:
✓ 月次レビューの改善アクション実施率が80%以上
✓ SLO調整がデータに基づいて四半期ごとに実施されている
✓ バジェット枯渇の予測アラートが稼働している
✓ インシデントのバジェット影響が自動算出されているレビュー運用のベストプラクティス
効果的なレビューのための原則
| 原則 | 説明 |
|---|---|
| データで語る | 印象や感想ではなく、SLI実績データに基づいて議論する |
| 非難しない | バジェット枯渇は組織の問題。チームや個人を責めない |
| アクション志向 | 議論だけで終わらず、必ず具体的なアクションアイテムを設定する |
| 時間を守る | レビューが長引くとスキップされやすくなる。アジェンダと時間枠を厳守する |
| 自動化する | レポート作成を自動化し、レビュー準備の負荷を最小化する |
レビュー自動化の対象
| 自動化対象 | ツール/手法 | 効果 |
|---|---|---|
| SLOダッシュボード | Grafana + Prometheus/Datadog | リアルタイムのSLO達成状況表示 |
| 週次レポート | Slackbot + API | エラーバジェット残量の自動通知 |
| 月次レポート | スクリプト + テンプレート | SLO達成率、インシデント影響の自動集計 |
| バーンレートアラート | アラートルール設定 | バジェット消費速度の異常検知 |
| SLO違反予測 | 線形回帰/トレンド分析 | 月末までの枯渇予測 |
アンチパターンと対策
| アンチパターン | 問題 | 対策 |
|---|---|---|
| 儀式的レビュー | 形だけのレビューで改善に繋がらない | アクションアイテムの実施状況を次回レビューで必ず確認 |
| レビュー疲れ | レビューが多すぎて参加者が疲弊 | 自動化による準備負荷の削減、アジェンダの効率化 |
| 責任の希薄化 | 「誰かがやるだろう」でアクションが放置 | 必ずオーナーと期限を明記。タスク管理ツールに登録 |
| 過剰な詳細議論 | 個別のインシデント詳細に時間を費やしすぎ | 詳細はポストモーテムに委ね、レビューでは傾向分析に注力 |
「SLOレビューの質は”レビュー後に何が変わったか”で測る。何も変わらないレビューは時間の無駄だ。逆に、毎回1つでも改善アクションが生まれるなら、そのレビューは組織の価値を高めている」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| 3つのレビューサイクル | 週次（運用）、月次（サービス）、四半期（戦略）の3層構造 |
| データ駆動 | SLI実績データに基づいた客観的な議論と意思決定 |
| 自動化 | レポート生成とアラートの自動化でレビュー準備の負荷を最小化 |
| アクション志向 | レビューの価値はアクションの実施と効果測定で証明する |
チェックリスト
- 3つのレビューサイクル（週次・月次・四半期）の目的と参加者を理解した
- 各レビューのアジェンダテンプレートを理解した
- SLOレビューの成熟度モデルと目標状態を理解した
- レビュー運用のベストプラクティスとアンチパターンを理解した
次のステップへ
次は演習です。ここまで学んだSLI/SLO戦略、階層設計、エラーバジェットポリシー、レビュープロセスを統合して、TaskFlow社のSLI/SLO体系を実際に設計しましょう。
推定読了時間: 30分