Contents
SLO と SLI の基本概念
| 用語 | 定義・例 |
|---|---|
| SLI (Service Level Indicator) | 実際に測定する指標。例：1 分間あたりの成功リクエスト率（Success Rate） |
| SLO (Service Level Objective) | SLI に対して設定した目標値。例：月間で 99.9% の Success Rate を維持する |
| エラーバジェット | 許容できる障害時間。計算は ErrorBudget = (1‑SLO) × 対象期間（秒） で求められる |
要点
- SLI は「何を測るか」＝観測データそのもの。
- SLO は「どこまで許容するか」＝ビジネス側が決めた目標。
- エラーバジェットは SLO と実績のギャップ を時間に換算した指標で、チーム全体のリスク可視化に直結します。
エラーバジェットの計算式と期間別換算例
基本式
|
1 2 |
ErrorBudget (秒) = (1 – SLO) × PeriodSeconds |
- SLO は小数表記（例：99.9 % →
0.999）。 - PeriodSeconds は対象期間を秒単位に変換した値。
- 月間（30日） →
30 × 24 × 3600 = 2,592,000 秒 - 週間（7日） →
604,800 秒 - 年間（365日） →
31,536,000 秒
期間別換算例（99.9 % と 99.95 % の二ケース）
| SLO | 対象期間 | 計算式 | エラーバジェット（秒） | ダウンタイム換算 |
|---|---|---|---|---|
| 0.999 (99.9 %) | 月間（30日） | (1‑0.999) × 2,592,000 |
2,592 | 43分12秒 |
| 0.999 | 週間（7日） | (1‑0.999) × 604,800 |
604 | 10分04秒 |
| 0.999 | 年間（365日） | (1‑0.999) × 31,536,000 |
31,536 | 8時間45分36秒 |
| 0.9995 (99.95 %) | 月間（30日） | (1‑0.9995) × 2,592,000 |
1,296 | 21分36秒 |
※ 本表の数値はすべて
SLO = 0.999または0.9995を前提に、30日＝2592000 秒で計算しています。
計算例（月間 SLO=99.9 %）
エラーバジェット = (1‑0.999) × 2,592,000 = 2,592 秒 → 43分12秒 が許容ダウンタイムです。
要点
- 高い SLO は「許容できるダウンタイム」を劇的に縮小させます。
- 期間を変えるだけで、チームは 「今月どれくらい障害が出ても OK」 を直感的に把握できます。
監視データからエラーバジェット消費率をリアルタイムで算出する手順
1. SLI 指標の決定と取得方法
| 手法 | 具体例 |
|---|---|
| Prometheus (PromQL) | sum(rate(http_requests_successful[5m])) / sum(rate(http_requests_total[5m])) |
| Datadog | service.uptime（秒） と service.downtime（秒）の比率を算出 |
| CloudWatch | RequestCount と 4XX/5XXErrorCount を組み合わせて成功率を算出 |
要点 – SLI の測定窓は SLO の評価期間と同等（例：30日移動平均）に統一すると、スパイクが過大評価されるリスクを低減できます。
2. エラーバジェット消費率の計算フロー
1️⃣ 対象期間の総秒数 (PeriodSeconds) を取得
2️⃣ 同期間の障害時間（DowntimeSeconds）を集計
3️⃣ エラーバジェット (秒) = (1‑SLO) × PeriodSeconds
4️⃣ 消費率 (%) = DowntimeSeconds ÷ ErrorBudget × 100
5️⃣ 残量 (%) = 100 % – 消費率
Python スクリプト例（Prometheus API から取得）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
#!/usr/bin/env python3 import requests, pandas as pd, json, sys # ------------------------------------------------- # ★設定項目（プロジェクトごとに変更） SLO = 0.999 # 例：99.9% PERIOD_DAYS = 30 # 月間対象期間 PROM_URL = "http://prometheus.example.com/api/v1/query_range" QUERY = 'sum(rate(http_requests_total[5m])) - sum(rate(http_requests_successful[5m]))' START = "2026-03-01T00:00:00Z" END = "2026-04-01T00:00:00Z" STEP = "60" # ------------------------------------------------- def fetch_downtime(): params = {"query": QUERY, "start": START, "end": END, "step": STEP} resp = requests.get(PROM_URL, params=params).json() values = resp["data"]["result"][0]["values"] df = pd.DataFrame(values, columns=["timestamp", "downtime"]) df["downtime"] = df["downtime"].astype(float) return df["downtime"].sum() def error_budget(slo, days): return (1 - slo) * days * 24 * 3600 def main(): downtime_sec = fetch_downtime() budget_sec = error_budget(SLO, PERIOD_DAYS) consumed_pct = downtime_sec / budget_sec * 100 result = { "error_budget_sec": int(budget_sec), "downtime_sec": int(downtime_sec), "consumed_percent": round(consumed_pct, 2), "remaining_percent": round(100 - consumed_pct, 2) } print(json.dumps(result, ensure_ascii=False, indent=2)) if __name__ == "__main__": main() |
- 出力例
|
1 2 3 4 5 6 7 |
{ "error_budget_sec": 2592, "downtime_sec": 312, "consumed_percent": 12.05, "remaining_percent": 87.95 } |
要点 – スクリプトは CI/CD パイプラインに組み込めば、
残量 < 30 %のとき自動的にデプロイをブロックできます。
エラーバジェット残量管理とリリース判断への活用フロー
残量可視化・アラート設定例
| フェーズ | 実施内容 |
|---|---|
| 集計 | 前節で算出した消費率を毎日 00:00 に Grafana ダッシュボードへプッシュ |
| 閾値設定 | - 警告：残量 < 50 % → Slack/Teams 通知 - 停止：残量 < 30 % → CI/CD が --skip-deploy フラグでデプロイを中止 |
| レビュー | 残量が 30 % 未満になるたびに「障害原因分析ミーティング」を開催し、改善策を即時実装 |
テキストベースのフローチャート
|
1 2 3 4 5 6 7 |
[エラーバジェット残量取得] ├─ (≥50%) → 通常デプロイ │ ├─ (<50% & ≥30%) → 警告通知 + デプロイは続行（リスク評価必須） │ └─ (<30%) → デプロイ自動停止 → 障害原因分析 → 改善実装 → 残量回復後に再デプロイ |
要点 – 閾値ベースの自動アクションは「感覚的判断」から脱却し、定量的根拠でリリースを制御できる唯一の手段です。
計算で陥りやすい落とし穴と対策
| 落とし穴 | 具体例 | 回避策 |
|---|---|---|
| 測定間隔の不整合 | SLO が月間 99.9 % なのに、SLI を 1 分単位で集計 → 短時間スパイクが過大評価される | ① SLI の集計窓を 30日移動平均 に合わせる ② 粒度は「5 分」や「1 時間」に統一し、ノイズ除去 |
| サービス境界の曖昧さ | マイクロサービス群全体で単一 SLO を設定 → 特定サービスだけが頻繁に超過し、全体指標が歪む | ① ビジネス機能（例：認証・決済）ごとに境界を明示 ② 各コンポーネントのエラーバジェットは 加重平均 で算出 |
| データ欠損 | 監視ツールがメンテナンス中で数時間分のログが取得できない | 欠損期間は「最悪ケース」（全障害）として保守的にカウントし、後から補正しない |
| 時間帯別 SLO 未設定 | 夜間トラフィックが少なくても同一 SLO を適用 → 無駄なエラーバジェット消費 | ピーク／オフピークで別々の SLO（例：夜間 99.5 %）を設計し、期間ごとに別バジェットを管理 |
要点 – 測定方法・サービス範囲が統一されていないとエラーバジェットは「見かけ上」しか機能しません。事前に定義を固めることが精度向上の鍵です。
実務で使えるツール例（Python・Excel）
1. Python スクリプト（自動集計 & CI 連携）
- 特徴
- CSV/JSON の障害時間データを読み込み → エラーバジェット・消費率を即出力。
-
GitHub Actions、GitLab CI、Jenkins 等のパイプラインに
exit 1で失敗させるロジックを組み込める。 -
主要関数（抜粋）
|
1 2 3 4 5 6 7 8 9 10 |
def calc_error_budget(slo: float, days: int) -> float: """エラーバジェット(秒) を返す""" return (1 - slo) * days * 24 * 3600 def evaluate_budget(budget_sec: float, downtime_sec: float, threshold: float = 30.0): """残量が閾値未満なら例外を送出""" consumed = downtime_sec / budget_sec * 100 if (100 - consumed) < threshold: raise RuntimeError(f"エラーバジェット残量が {threshold}% 未満です（{consumed:.2f}% 消費）") |
2. Excel テンプレート（非エンジニア向け）
| シート | 内容 |
|---|---|
| Input | B2: 期間（日), B3: SLO (小数), B4: 障害時間合計(秒) を入力 |
| Calc | 数式で自動算出。主要セルは以下の通り |
| セル | 内容 | 数式 |
|---|---|---|
| D2 | エラーバジェット（秒） | =(1-B3)*B2*24*3600 |
| D3 | 消費率（%） | =B4/D2*100 |
| D4 | 残量（%） | =100-D3 |
- 可視化
- 棒グラフで「エラーバジェット vs 障害時間」
-
条件付き書式：残量 < 30 % → 背景赤、< 50 % → 背景黄
-
自動更新
Power Query でdowntime.csvをインポートすれば、CSV が更新されるたびに数値がリアルタイム反映。
要点 – Python は「自動化・CI」向け、Excel は「非エンジニアへの可視化・手軽なレポート作成」向きです。両者を組み合わせることで組織全体でエラーバジェット管理が統一できます。
まとめ & 実装チェックリスト
| チェック項目 | 内容 |
|---|---|
| SLI / SLO の定義 | ビジネス側と合意し、測定窓・単位を明確化 |
| エラーバジェット計算式の実装 | ErrorBudget = (1‑SLO) × PeriodSeconds をコード/Excel に落とし込む |
| 期間別換算例の正確性 | 30日＝2,592,000 秒、99.9 % → 2,592 秒 (=43分12秒) を使用 |
| 監視データ取得フロー | Prometheus/Datadog などから SLI データを自動取得し、障害時間を集計 |
| 消費率・残量の可視化 | Grafana ダッシュボード／Excel グラフでリアルタイム表示 |
| 閾値設定と自動アクション | 警告 50 %未満、デプロイ停止 30 %未満 のポリシーを CI に組み込む |
| 落とし穴の対策実装 | 測定間隔・サービス境界・データ欠損のハンドリングを事前に設計 |
| ドキュメント化 | 計算根拠、スクリプト、Excel テンプレートへのリンクを社内 Wiki に掲載 |
最終的な効果
- エラーバジェットが 数値 で管理できるため、リスク評価が客観的に。
- 閾値ベースの自動アクションで「障害が出たら即停止」→ リリース失敗率が大幅減少。
- SLI・SLO の共通言語化で、開発・運用・ビジネス側のコミュニケーションコストが低減。
参考文献
[^1]: Google Cloud Platform – Site Reliability Engineering: How Google Runs Production Systems (ISBN 978-1491929124)
[^2]: The Site Reliability Workbook, O'Reilly Media, 2023.
本稿は、実務での即時適用を前提に作成しました。組織固有の要件がある場合は、数値や閾値をカスタマイズしてご利用ください。