🐙SRE Workbookから学んだこと：SLO・エラーバジェット・オンコール設計
Google SRE Workbook を読んで、特に実務に直結すると感じた概念とルールをまとめた。
SLI / SLO / SLA
| 用語 | 意味 | 例 |
|---|---|---|
| SLI (Service Level Indicator) | 測定可能なサービス品質の指標 | 成功リクエスト率、P99レイテンシ |
| SLO (Service Level Objective) | SLIに対する内部目標値 | 「99.9%のリクエストを300ms以内に返す」 |
| SLA (Service Level Agreement) | 顧客との契約上の合意。違反時にペナルティが発生する | 「月間99.5%の可用性を保証する」 |
SLOはSLAより厳しく設定するのが原則。SLAを下回る前にチームが行動できる余裕を持たせる。
「信頼性が十分か否か」を主観的に議論するのではなく、数値で合意することで、PM・開発・SREの3者が同じ基準で話せるようになる。そして100%の可用性を目標にしてはならない。それは開発を完全に止めることを意味する。
エラーバジェット
エラーバジェット = 1 - SLO
SLOが99.9%（月間）であれば、エラーバジェットは0.1%。30日 × 24時間 × 60分 × 0.1% ≈ 43.2分が許容できる停止時間になる。
この「バジェット」をどのように使うかは開発チームが決める。新機能リリース、インフラ変更、実験はすべてバジェットを消費する。
| 消費状況 | アクション |
|---|---|
| 0〜50% | 通常どおり開発・リリース |
| 50〜75% | リリースの影響分析を強化 |
| 75〜100% | リリース凍結、信頼性改善にスプリントを割く |
| 100%超 | SLAへの影響を検討 |
SREと開発が対立するのではなく、同じバジェットを共有するパートナーになれるのが最大の価値。
ルール: エラーバジェットで優先度を決める
「信頼性か速度か」の議論は、ステークホルダーが変わるたびに繰り返される。この議論に毎回リソースを使うのは非効率だ。
エラーバジェットポリシーを事前合意することで解決する：
- バジェット残あり → 新機能開発・実験を積極的に進める
- バジェット75%消費 → リリース前の影響分析を強化する
- バジェット枯渇 → 新機能リリースを凍結し、信頼性改善を最優先にする
この判断を感情・政治・個人の意見で覆さないことが肝心。
例外はある——セキュリティパッチや法的要件はバジェット関係なく対応する。ただし例外は文書化する。
オンコール設計
設計なしのオンコールは、夜中の頻繁なページング・特定エンジニアへの集中・燃え尽きへとつながる。オンコールは「当番」ではなくシステムとして設計する必要がある。
適切なオンコール負荷の基準（Googleの目安）
- 1シフト（12時間）あたりのインシデント：2件以下
- 週のオンコール比率：25%以下（週4日中1日相当）
- 2人ペア制：プライマリ + バックアップで単一障害を防ぐ
シフト設計のポイント
- 12時間シフト（24時間連続は避ける）
- グローバルチームでは「Follow the Sun」方式
- 週次でローテーション
シフト交代時には「現在進行中の問題・未解決アラート・直近の変更」を引き継ぐ。ランブック（操作手順書）をインシデントチケットにリンクしておく。
対応が遅かった・判断が間違っていたを責めない。ポストモーテムで学習に変える。
ルール: オンコール当番中も戦略的作業時間を確保する
オンコールが「反応的対応だけ」になると：
- エンジニアの燃え尽きと離職が増加
- Toilが削減されず、翌シフトも同じ状況が続く
オンコール当番のシフト中であっても、少なくとも50%の時間をプロジェクト作業（自動化・改善・ドキュメント整備）に充てる。
実践として：
- 週のオンコール負荷を記録し（インシデント件数・対応時間）、月次でチームに共有
- 負荷が高かった週は翌週のスプリントで「Toil削減タスク」を優先的に割り当てる
- オンコールシフトのレトロスペクティブを月次で実施
SEV1の大規模インシデントが発生した週は50%を超えることは許容する。ただし翌シフト以降に必ず改善タスクを組み込む。
出典
- Google SRE Workbook（Betsy Beyer他）第2章「Implementing SLOs」
- Google SRE Workbook（Betsy Beyer他）第8章「On-Call」