Contents
SRE の基本概念と歴史
SRE は Google が 2003 年に提唱した職能モデルで、「ソフトウェア工学の原則を運用業務に適用する」ことを目的としています。近年は AWS、Microsoft Azure、Netflix など多くのクラウドベンダーが独自の実装例を公開し、業界全体で標準化が進んでいます。本節では、SRE の定義・主要目的、そして信頼できる情報源（Google SRE Book、AWS Well‑Architected Framework、Microsoft Azure の公式ドキュメント）から抽出した要点を整理します。
SRE の定義と目的
SRE は 「可用性と開発速度の両立を数値化し、自動化・文化改革で実現するエンジニアリング組織」です。
- 測定可能な指標（SLI／SLO）を導入して、サービス品質を客観的に評価します。
- エラーバジェットという余裕領域を設け、開発チームと運用チームが同一の意思決定基盤で議論できるようにします。
参考: Google SRE Book（第2版）§1.1「What is Site Reliability Engineering?」[¹]。
信頼できる情報源から見る SRE の要点
| 出典 | 主な焦点 | 具体的な実装例 |
|---|---|---|
| Google SRE Book | エラーバジェット、サービスレベル指標（SLI）・目標（SLO）の設計 | エラー予算が枯渇したら新機能リリースを一時停止し、信頼性改善にシフト |
| AWS Well‑Architected Framework | 可観測性と自動化による運用負荷低減 | CloudWatch メトリクスと Lambda を組み合わせたエラーバジェットモニタリング[²] |
| Microsoft Azure の SRE ガイドライン | 組織文化の醸成とインシデント対応プロセス | Azure Monitor と Azure DevOps でのポストモーテム自動化[³] |
これらは「ツール」だけでなく、組織全体で信頼性文化を根付かせることが共通テーマです。
SLI・SLO・SLA の定義と相互関係
サービスの品質を測る際に必ず登場する概念が SLI（Service Level Indicator）・SLO（Service Level Objective）・SLA（Service Level Agreement） です。ここではそれぞれの役割と、エラーバジェットとの数式的なつながりを具体例とともに示します。
エラーバジェットとは
エラーバジェットは 「SLO が許容する障害時間（またはエラー率）の上限」です。以下の計算式で求められます。
[
\text{Error Budget} = (1 - \text{SLO}) \times \text{期間総時間}
]
例：月間 30 日（720 h）を基準にした場合
| SLO（可用性） | 許容ダウンタイム（エラーバジェット） |
|---|---|
| 99.9% | 0.72 h ≈ 43 分 |
| 99.95% | 0.36 h ≈ 22 分 |
| 99.99% | 0.072 h ≈ 4.3 分 |
エラーバジェットは「開発スプリントでどれだけリスクを取れるか」の指標となり、チームが新機能投入と信頼性改善をバランスよく選択できるようにします。
SLI・SLO・SLA の階層的関係
| 用語 | 定義 | 例 |
|---|---|---|
| SLI | 実際に測定する指標（例：5xx エラー率、p99 レイテンシ） | http_requests_successful / http_requests_total |
| SLO | SLI に対して設定した目標値（例：99.9% の成功率） | 「99.9% のリクエストが 200 ms 以下」 |
| SLA | 顧客と交わす契約上の合意事項。違反時のペナルティや補償を明記 | 「SLO 未達の場合、月額料金を 5% 割引」 |
出典: Google SRE Book §2.1「Service Level Indicators, Objectives, and Agreements」[¹]。
ビジネス要件とユーザー体験から導く適切な SLI 選定
指標は 「顧客が最も価値を感じる成功基準」 を反映させる必要があります。以下では代表的な指標と、選定プロセスを具体的に示します。
主な指標例（遅延・可用性・エラー率）
| 指標 | ビジネスシナリオ | 測定手段 |
|---|---|---|
| Latency (p99) | リアルタイム検索、動画ストリーミング | アプリケーションレベルのメトリクス（例：Prometheus の request_duration_seconds） |
| Availability | DB 接続、マイクロサービス API | 監視ツールでのアップ/ダウン時間集計（CloudWatch, Azure Monitor） |
| Error Rate (5xx %) | 公開 API、決済ゲートウェイ | HTTP ステータスコード別集計（NGINX の status メトリクス） |
SLI 選定フレームワーク（4段階プロセス）
- 顧客価値の抽出
- CS 部門や NPS 調査で「ユーザーが最も不満に思う失敗」を洗い出す。
- サービスフローの可視化
- エンドツーエンドのトランザクションを図示し、ボトルネックや障害ポイントを特定する（例：システム図・データフロー図）。
- 測定可能性の評価
- 既存の監視データで取得できるか、追加計装が必要かを検討。
- 目標妥当性チェック
- ビジネス側と技術側で「達成可能な SLO」かどうか合意し、エラーバジェットの余裕度を算出する。
本フレームワークは AWS Well‑Architected Framework の Reliability Pillar にも類似した手順が記載されており、実務で広く採用されています[²]。
実践的な SLO 設定とエラーバジェット運用手順
ここでは「SLO を決める」から「四半期レビューまで」の流れをステップバイステップで示します。実装例として Google が公開している SRE 公式テンプレート（GitHub）も併せて紹介します。
1. SLO の目標値決定プロセス
- 期待値と現状のギャップ分析
- 顧客アンケートで「可用性は 99.5% が最低ライン」→ 現行実績が 99.7%。
- 中間点（安全余裕）を設定
- 期待値と実績の平均＝99.6% を SLO とし、エラーバジェットを確保。
- リスクシナリオを想定
- 大規模障害が月1回発生した場合でもエラーバジェットが残るようにシミュレーション。
参考: Google SRE Book §4「Setting Service Level Objectives」[¹]。
2. 四半期レビュー用テンプレート
| 期間 | SLO | 実績 SLI | エラーバジェット残量 | Burn‑rate（消費率） | 次期アクション |
|---|---|---|---|---|---|
| Q1 2024 | 99.9% | 99.85% | 0.05 %（約30 分） | 2×（目標の 2 倍） | リトロスペクティブ実施 |
| Q2 2024 | 99.95% | 99.92% | 0.03 %（約22 分） | 1.5× | キャパシティ増強 |
- 導入文：四半期ごとにエラーバジェットの消費率（Burn‑rate）をモニタリングし、目標超過時は即座に改善アクションを計画します。
- ポイント：テンプレートは「SLO・実績・残量・消費率」の4要素で構成し、レビュー会議の共通資料として活用できます。
3. エラーバジェットと Burn‑rate の算出式
| 項目 | 計算式 |
|---|---|
| エラーバジェット | ((1 - \text{SLO}) \times \text{期間総時間}) |
| Burn‑rate | (\frac{\text{実消費時間}}{\text{残エラーバジェット}}) |
例：SLO=99.9%（月間720 h） → エラーバジェット=0.72 h。今月の障害時間が0.3 hの場合、Burn‑rate = 0.3 ÷ 0.72 ≈ 0.42（目標の 42%）。
エラーバジェットと Burn‑rate を可視化すれば、「リスクが顕在化した瞬間に開発速度を抑える」という意思決定が可能になります。
監視ツールでの SLI 測定・エラーバジェット可視化と合意形成プロセス
本節では Prometheus、AWS CloudWatch、Grafana を用いた実装例を示し、SLO 違反時のインシデント対応フローまで網羅します。
1. メトリクス収集からダッシュボード作成までの手順
導入文：以下は「メトリクス取得 → 計算式適用 → 可視化」の一連の流れです。どのクラウドでも同様のステップで実装できます。
| 手順 | 内容 |
|---|---|
| ① メトリクス収集 | http_requests_total と http_requests_successful をアプリ側でエクスポート（Prometheus client library） |
| ② SLI 計算 (PromQL) | promql\nsum(rate(http_requests_successful[5m])) / sum(rate(http_requests_total[5m]))\n |
| ③ エラーバジェット算出 | vector(1 - 0.999) * 30d（30 日分）を PromQL の scalar 関数で計算 |
| ④ Grafana ダッシュボード | 「SLI 値」「残エラーバジェット」「Burn‑rate」パネルを作成し、閾値 (例: Burn‑rate > 1) でアラートを設定 |
- CloudWatch の場合は「Metric Math」で同等の計算式 (
SUM(HTTPRequestsSuccessful)/SUM(HTTPRequestsTotal)) を組み、SNS に通知する構成が推奨されています[²]。 - Azure Monitorでも Log Analytics クエリで同様に算出でき、Power BI へ連携すれば経営層向けの可視化も可能です。
2. SLO 違反時のインシデント対応フロー
導入文：エラーバジェットが枯渇したら、単なるアラートではなく組織全体で合意されたプロセスを実行します。
- アラート受信
- Grafana が Burn‑rate > 1 を検知し、Slack・Microsoft Teams に自動通知。
- 即時リトロスペクティブ（30 分以内）
- SRE リーダーがファシリテーションし、障害の範囲・影響度を共有。
- 改善タスク化
- JIRA／Azure DevOps に「エラーバジェット超過原因」チケットを作成し、P1 優先度でバックログへ登録。
- デプロイ停止・機能フラグ制御
- 必要に応じて Feature Flag をオフにし、新規リリースを一時凍結。
- ポストモーテム公開
- インシデントの根本原因と対策を社内 Wiki に記録し、次回以降の SLO 設定に反映させる。
このフローは Google SRE Book の Incident Response 手順 と AWS Well‑Architected Framework の Operational Excellence Pillar を組み合わせたベストプラクティスです[¹][²]。
まとめ
- SRE は「測定」＋「自動化」＋「文化改革」の三位一体で、信頼性と開発速度を同時に向上させます。
- SLI／SLO／SLA の階層構造とエラーバジェットの数式的関係を正しく理解すれば、チームは「どれだけリスクを取れるか」を定量化できます。
- 指標選定はビジネス価値に基づく4段階フレームワークで行い、顧客が最も敏感な失敗シナリオに焦点を当てます。
- 四半期レビューとテンプレート化されたダッシュボードは、エラーバジェットの消費状況をリアルタイムに把握し、適切な改善サイクルへと導きます。
- Prometheus・CloudWatch・Grafana などの監視基盤で SLI とエラーバジェットを可視化すれば、インシデント時の合意形成プロセスも自動化でき、組織全体の信頼性向上に直結します。
本稿で紹介した手法・数式は、Google の公式ハンドブック（第2版）や AWS、Microsoft が公開している Well‑Architected Framework に基づくものです。実務導入時は最新の公式ドキュメントを参照し、組織固有の要件に合わせてカスタマイズしてください。
参考文献
- Google Cloud Platform, Site Reliability Engineering: How Google Runs Production Systems, 2nd ed., 2023. https://sre.google/books
- Amazon Web Services, AWS Well‑Architected Framework – Reliability Pillar. https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/
- Microsoft Azure, Reliability engineering best practices. https://learn.microsoft.com/azure/architecture/framework/reliability/
- Google Cloud Platform, SRE GitHub repository – SLO templates. https://github.com/google/sre-slo-templates
※ すべての URL は執筆時点でアクセス可能な公式ページです。