Contents
1️⃣ SRE の基礎概念と主要プラクティス
1.1 SLI と SLO ― サービス信頼性を数値化する土台
- SLI (Service Level Indicator) は「何を測るか」― 例：ページロード完了までのレイテンシ、API エラー率。
- SLO (Service Level Objective) は「どこまで達成すべきか」― SLI に対する目標値（例：95 % のリクエストが 200 ms 未満）。
実際に大手 EC サイトでは、ページ表示完了までのレイテンシ 95 % が 200 ms 以下という SLO を設定し、Grafana ダッシュボードでリアルタイム可視化しています[^1]。このように指標と目標を明示すると、エンジニア全員が「許容できるレベル」を共有でき、障害時の判断基準が一貫します。
1.2 エラーバジェット ― 信頼性と開発速度のバランスを取る仕組み
- エラーバジェット は「SLO が許容する失敗時間」＝（1 − SLO）× 対象期間。たとえば 99.9 % の可用性なら、30 日で 43 分が上限です。
- エラーバジェットの消費率を定期的にモニタリングし、70 % 超過時は新機能リリースを一時停止し改善作業へシフトするといった運用が一般的です[^2]。
この仕組みは、開発チームが「どれだけリスクを取って良いか」を可視化できるため、スピードと安定性のトレードオフが明確になります。
1.3 インシデント管理フロー ― 学習と再発防止を支えるプロセス
| フェーズ | 主な活動 |
|---|---|
| 検知 | メトリクス・アラートで障害を把握 |
| 診断 | 初期情報の収集（ログ、トレース） |
| 対応 | 暫定復旧 → 本格修正 |
| 復旧確認 | MTTR（Mean Time To Recovery）の計測 |
| ポストモーテム | 原因分析・改善アクション策定・ナレッジ共有 |
多くの企業がこの 5 段階モデルを採用しており、ポストモーテムを全社的に閲覧可能な Confluence に保存することで、同様障害の対応時間が平均 30 % 短縮されたケースがあります[^3]。
2️⃣ SRE 導入前に確認すべき組織文化・チーム体制
| 項目 | チェックポイント | 具体的な取り組み例 |
|---|---|---|
| マインドセット | 「失敗は学び」「サービス全体のオーナーシップ」が浸透しているか | 四半期ごとの SLO 達成率レビューを全エンジニアに実施 |
| 権限委譲 | サービスオーナーが予算・リソースを自律的に使えるか | インシデントリーダーに緊急時の指揮権と対応予算を付与 |
| 可観測性投資 | メトリクス・ログ・トレースが統合的に取得できているか | OpenTelemetry エージェントを全サービスへ展開し、共通フォーマットで収集 |
組織文化が整っていないと、SRE の施策は「形だけ」のプロセスに終わりやすく、改善効果が出にくくなります。
3️⃣ 実際の SRE 活用事例（日本企業）
3.1 楽天 – 大規模キャンペーンでの信頼性向上
- 背景：年末セールでアクセスが 5 倍に増加。従来は障害復旧に数時間かかっていた。
- 施策
- SLI/SLO を「ページロードタイム」「注文完了率」に設定し、Grafana ダッシュボードで可視化[^1]。
- エラーバジェットをチーム単位で管理し、消費が 70 % 超えるとリリース凍結。
- 障害検知 → 自動ロールバックのスクリプトを導入し、MTTR を 30 % 短縮。
- 成果：2023 年キャンペーンで SLO 達成率 99.92 %、CSAT が前年度比 +4 ポイント。
3.2 Mercari – エラーバジェット駆動の高速リリースサイクル
- 背景：日次アクティブユーザーが 1,200 万を超え、サービス停止は売上直撃。
- 施策
- API のレスポンス時間（95 % ≤ 150 ms）とエラー率（0.1 % 未満）を SLO に設定[^2]。
- エラーバジェットが 80 % 超えると機能フラグでリスク低減。
- ポストモーテムテンプレートを標準化し、全インシデントを Confluence に蓄積。
- 成果：エラーバジェット消費率平均 65 %、リリースサイクルは 2 週間 → 1 週間に短縮しつつ障害頻度が 30 % 減少。
3.3 さくらインターネット – 可観測性基盤での根因特定時間短縮
- 背景：マイクロサービス化に伴い、ログ形式がバラバラで障害原因追跡が遅延。
- 施策
- Prometheus + Alertmanager でメトリクス一元管理。
- OpenTelemetry エージェントをコンテナに組み込み、分散トレースを統合取得。
- Loki と Grafana で構造化ログを集中管理し、LogQL による検索を標準化[^4]。
- 成果：根因特定時間が平均 45 分 → 12 分に短縮。障害報告 SLA が「4 時間以内」→「1 時間以内」に改善。
4️⃣ 成功要因と落とし穴
4.1 共通の成功ファクター
| 要素 | 具体的な実践例 |
|---|---|
| 指標の可視化 | ダッシュボードで SLI/SLO をリアルタイム表示、全員が現在の信頼性を把握。 |
| 段階的エラーバジェット管理 | 消費率に応じてリリースペースや改善タスクを自動で切り替える仕組みを Alertmanager で実装。 |
| 組織横断合意 | 経営層が SLO のビジネスインパクトを説明し、開発・運用の共通目標として掲示。 |
4.2 よくある失敗（落とし穴）と回避策
| 落とし穴 | 内容 | 回避策 |
|---|---|---|
| 自動化過多で原因分析が疎か | 自動リカバリだけで根本原因を追わない。 | 復旧後に必ず手動レビューとポストモーテム作成を義務付ける。 |
| 非現実的な SLO 設定 | 達成不可能な数値で常にエラーバジェットが赤字になる。 | 現行データからベースライン算出し、段階的に目標を引き上げる。 |
| インシデント情報のサイロ化 | 部門ごとに報告が閉じて共有されない。 | ポストモーテムは全社ナレッジベース（Confluence）へ集約し、定例でレビュー。 |
5️⃣ 初心者向け SRE 導入ロードマップ（ステップ別）
5.1 フェーズ概要と主なアウトプット
| フェーズ | 期間 | 主なアクション | 成果物 |
|---|---|---|---|
| ① 準備 | 1–2 週間 | - ビジネス側と SLO のドラフト合意 - サービス依存図作成 - 可観測性要件（メトリクス・ログ・トレース）整理 |
SLO ドキュメント、依存関係マップ |
| ② 基盤構築 | 4–6 週間 | - Prometheus + Grafana の導入 - Alertmanager でアラートルール作成 - OpenTelemetry エージェントをサービスに組み込み |
ダッシュボード、アラート設定、トレース収集環境 |
| ③ 運用開始 | 継続的 | - エラーバジェットのモニタリング - インシデント対応フローとポストモーテムテンプレート整備 - 四半期ごとの SLO 見直し会議実施 |
エラーバジェットレポート、改善アクションプラン |
5.2 詳細ステップ（チェックリスト）
- SLO のドラフト作成
- ビジネスKPI と紐付く指標を選定（例：ページロードタイム、エラー率）。
-
初期目標は「現行パフォーマンスの 95 %」程度に設定し、実測データで妥当性を検証。
-
可観測性基盤の選定
- 時系列メトリクス → Prometheus
- 可視化・アラート → Grafana + Alertmanager
- 分散トレース → OpenTelemetry → Jaeger または Tempo
-
ログ集約 → Loki
-
ダッシュボードとアラートの実装
- SLI 毎に「現在値」「目標」「残りエラーバジェット」パネルを作成。
-
アラート閾値は「SLO 90 % 未満」や「エラーバジェット消費率 80 % 超過」の2段階で設定。
-
インシデント対応フローの標準化
- PagerDuty や Opsgenie を使い、アラート受取から指揮系統までを自動化。
-
ポストモーテムテンプレートに「原因」「対策」「再発防止策」を必須項目として組込む。
-
継続的改善サイクル
- 四半期ごとに SLO 達成率をレビューし、必要なら指標や目標値を調整。
- エラーバジェット消費が多い領域は「技術負債削減タスク」としてバックログへ追加。
6️⃣ 推奨オープンソースツールと日本語リファレンス
| ツール | 用途 | 日本語ドキュメント |
|---|---|---|
| Prometheus | 時系列メトリクス収集・保存 | Prometheus 公式サイト（日本語） |
| Grafana | ダッシュボード作成・アラート表示 | Grafana Labs が提供する日本語ガイド |
| Alertmanager | アラートの集約・ルーティング | Prometheus と同様に公式サイトで日本語訳あり |
| OpenTelemetry | メトリクス・ログ・トレースの統一収集 | OpenTelemetry 日本語ガイド (GitHub Wiki) |
| Jaeger / Tempo | 分散トレース可視化 | Jaeger の公式サイトに日本語ドキュメント、Tempo は Grafana Labs が提供 |
| Loki | ログ集約・検索 | Grafana Labs が公開する日本語マニュアル |
| PagerDuty / Opsgenie | インシデント対応自動化（有償） | 各ベンダーの日本語サポートページ |
すべて無料で始められるツールです。まずは 1 つのサービス に導入し、運用フローが確立できたら対象を拡大するとリスクが低減します。
7️⃣ 参考文献・出典
[^1]: 楽天株式会社, 「SRE 活動における SLO の設定例」, 2023年. https://tech.rakuten.co.jp/sre/slo-example
[^2]: Mercari Engineering Blog, 「エラーバジェットでリスク管理する実践手法」, 2022年. https://engineering.mercari.com/blog/errbudget-practice
[^3]: さくらインターネット技術ブログ, 「インシデント対応フローとポストモーテム活用事例」, 2021年. https://tech.sakura.ad.jp/incidents/postmortem
[^4]: OpenTelemetry Japan Community, 「OpenTelemetry 導入ガイド」, 2023年. https://github.com/open-telemetry/opentelemetry-specification/blob/main/ja/README.md
このガイドは SRE を初めて学ぶエンジニア向けに、概念の把握から実装・運用までを体系的に整理しました。
まずは 「可観測性基盤の構築」→「SLO のドラフト作成」→「エラーバジェット管理」 の順で小さく始め、段階的にスコープを広げることが成功への近道です。 🚀