Contents
SREとエラーバジェットの基本概念
サイトリリアビリティエンジニアリング（SRE）は、ソフトウェア開発を基盤にシステムの信頼性を維持する手法です。このフレームワークの核心には「エラーバジェット」という概念があります。エラーバジェット計算式やSLO設定方法といった具体的なキーワードを含め、サービス運用におけるリスク管理と信頼性向上のバランスを講義します。
エラーバジェットとは何か
エラーバジェットは、「許容できる障害量」を定量化することで、チームがリスク管理を行いながら開発と運用の両立を目指します。例えば年間の可用性目標（SLO）が99.9%の場合、1年間に8.76時間のダウンタイムを許容する計算になります（365日×24時間×0.001）。この「8.76時間」がエラーバジェットです。
SREの役割と目的
SREは、開発チームと運用チームの境界を曖昧にし、信頼性を数値で管理する文化を構築することを目的としています。具体的には、以下の役割を担います：
- サービスの可用性やパフォーマンス目標（SLO）の設定
- 障害発生時の影響範囲と対応策の設計
- モニタリング・自動化ツールの活用による安定した運用
SLI(SERVICE LEVEL INDICATOR)の選び方
SLI（サービスレベルインジケータ）は、サービスの信頼性を測定するための指標です。しかし、「どの指標を選ぶべきか」は悩むポイントです。ユーザー体験と実装コストのバランスが重要になります。
ユーザーにとって重要な指標の特定
ユーザー視点で選ぶことが基本です。以下の3つの観点を考慮しましょう：
- 直接的な影響を受けるユーザー行動（例：API応答時間、ページロード率）
- サービスの本質的価値（例：支払い処理の成功率、ログイン失敗率）
- 競合サービスとの比較軸（例：スムーズなUI操作、データ取得の正確性）
測定可能性と実装コストのバランス
SLIは測定・集計が容易であることが前提です。以下に代表的なSLIとその特性を比較します：
| SLIの種類 | 測定方法 | 実装難易度 | 例 |
|---|---|---|---|
| 可用性 | 正常応答率 | ★★☆☆☆ | API呼び出し成功数 |
| レイテンシー | 応答時間の百分位（P95） | ★★★☆☆ | ページロード時間 |
| エラー率 | エラーコードの発生率 | ★★☆☆☆ | 4xx/5xxエラー数 |
| スループット | 単位時間あたりの処理件数 | ★★★★☆ | ログインリクエスト数 |
メモ：SLIは「ユーザーが感じやすい指標」を選ぶことが重要です。たとえ技術的には測定可能でも、ビジネス的な意味を持たない指標は無意味です。
SLO(SERVICE LEVEL OBJECTIVE)設定の実践例
SLO（サービスレベルオブジェクティブ）は、SLIを基に定量的に設定されるサービス目標です。2026年の最新データによると、99.9%の可用性が業界標準として広く採用されています。
業界標準値とカスタマイズのバランス
以下は主要クラウドプロバイダーのSLO例です：
| 企業名 | サービス | SLO（年間） | メモ |
|---|---|---|---|
| AWS | EC2 | 99.95% | 設定可能なオプションあり |
| Google Cloud | Compute Engine | 99.95% | 通常契約で標準 |
| Azure | Virtual Machines | 99.99% | プレミアムプラン限定 |
注意：SLOは「ユーザーにとって価値がある水準」を設定することが重要です。例えば、金融系サービスでは100%の可用性が求められることもあります。
定量的目標の設定方法
SLO設定方法には以下のようなステップがあります：
- SLIを選定（例：API応答成功率）
- 過去データから信頼性のベースラインを確認（例：99.5%）
-
ユーザー満足度とリスク許容範囲を考慮し、SLOを設定
-
例：
- SLI: API応答成功率
- SLO: 年間で99.9%以上（つまり1年間に8.76時間の障害は許容）
- エラーバジェット計算式: エラーバジェット = (1 - SLO) × 総リクエスト数
エラーバジェット算出式の具体例
エラーバジェット計算式は、SLOと総アクセス量から導かれます。具体的な算出プロセスを見てみましょう。
SLOから誤差許容範囲の計算
公式：
|
1 2 |
エラーバジェット = (1 - SLO) × 総リクエスト数 |
例：SLOが99.9%、総リクエスト数が36,500万回の場合：
- エラーバジェット = 0.001 × 36,500万 = 36,500件の許容エラー
注意点：SLOは「年間」で設定されることが一般的ですが、月単位や週単位でも分割可能です。
時間軸に沿った配分方法
エラーバジェットを時間軸に配分することで、運用チームがリスクを意識しながら進めるようになります。
- 例：年間の36,500件を12ヶ月に均等に分配 → 月ごとの許容エラーは3,041件
- モニタリングツールでこの数値と「残りのエラーバジェット」をリアルタイム表示することで、チームが進捗を確認できます。
Burn Rate(消費率)の可視化手法
Burn Rate（消費率）は、エラーバジェットを時間単位でどのくらい使っているかを示す指標です。この数値を可視化することで、チームがリスクに意識を持ちやすくなります。
リアルタイムダッシュボードの活用
以下のような要素を備えたダッシュボードが効果的です：
- エラーバジェット残量（百分比表示）
- 消費率曲線（グラフで時間軸上に可視化）
- SLO達成率の変動（リアルタイム更新）
異常検知とアラート設定
エラーバジェットが閾値に近づくと、自動でチームに通知する仕組みを導入しましょう：
- 予定外のエラー増加（例：1日で10件以上）
- 消費率が過去3日間平均より15%以上上昇
- 残りのエラーバジェットが10%未満
例：GrafanaやPrometheusなどのツールでアラートポリシーを設定可能です。
運用チームとの合意形成プロセス
エラーバジェットは、単に技術的な数値ではなく、運用チームと開発チームの協力体制を築くための基盤です。
ステークホルダーの要望整理
以下のような活動が重要です：
- SLOの妥当性チェック（例：99.9%は現実的か？）
- 障害発生時の対応プロセスの共有（例：緊急対応と通常対応の境界線）
- エラーバジェットの運用における責任範囲の明確化
リスクとリソース配分の議論
エラーバジェットを実装する際は、以下のようなリスクとリソース配分について話し合う必要があります：
- エラーバジェットが0に達した場合の対応策（例：運用停止、開発作業の中止）
- SLO目標の見直しを検討するタイミング（例：3回以上SLO未達成）
- リソース投入の優先順位（例：エラーバジェットが少ないサービスに集中投資）