Contents
1️⃣ SRE（Site Reliability Engineering）とは何か ― 目的・主な手法
🔹 定義
SRE は Google が提唱した「サービスの可用性・性能を数値で管理し、ビジネスに直結する信頼性を高める」エンジニアリング文化です。[^1]
| キーワード | 説明 |
|---|---|
| SLI（Service Level Indicator） | 可観測な指標例：リクエスト成功率、レイテンシの 99 パーセンタイルなど |
| SLO（Service Level Objective） | SLI に対して設定する目標値（例：月間成功率 ≥ 99.9%） |
| エラーバジェット | 「許容できる障害時間」＝ 1 – SLO。これを消費した割合で新機能リリースの可否を判断する |
🔹 目的
- 信頼性を定量化し、開発速度とバランスさせる
- インシデント対応の自動化・標準化により MTTR（平均復旧時間）を短縮
「エラーバジェットが 30 % 消費されたら新機能リリースを一時停止し、信頼性改善に注力する」← 典型的な意思決定ルールです。
🔹 主な実装例
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# SLO 定義（Prometheus の alerting rule） apiVersion: monitoring.coreos.com/v1 kind: ServiceLevelObjective metadata: name: request-success-rate spec: target: 0.999 # 99.9% indicator: type: ratio good: sum(rate(http_requests_total{code=~"2.."}[5m])) total: sum(rate(http_requests_total[5m])) |
上記は Prometheus と SLO Operator を組み合わせた例です。
2️⃣ DevOps とは何か ― 目的・主な手法
🔹 定義
DevOps は 開発（Development）と運用（Operations）の壁を取り払い、ソフトウェア提供サイクル全体を高速化・安定化させる文化・プロセスです。[^2]
| キーワード | 説明 |
|---|---|
| CI/CD | 継続的インテグレーション / デリバリー。コード変更から本番デプロイまでを自動化 |
| IaC（Infrastructure as Code） | Terraform、Pulumi などでインフラ構築・管理をコード化 |
| フィードバックの高速化 | プロダクションメトリクスやユーザー行動データをリアルタイムで開発に還元 |
🔹 目的
- リードタイム（コード → 本番） を短縮し、ビジネス価値を迅速に提供
- サイロ化した組織構造を解消して、全員が同じ目標に向かう文化を醸成
🔹 主な実装例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# GitHub Actions の CI ワークフロー（簡易版） name: CI on: push: branches: [ main ] jobs: build-test-deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Run tests run: ./gradlew test - name: Build Docker image run: docker build -t myapp:${{ github.sha }} . - name: Deploy to GKE uses: google-github-actions/deploy-gke@v0 |
このパイプラインはコードのプッシュ → テスト実行 → コンテナビルド → GKE デプロイ を 30 分以内で完了させます。
3️⃣ 共通点と視点・フォーカスの違い
| 項目 | DevOps の主な取組例 | SRE の主な取組例 |
|---|---|---|
| 自動化 | GitHub Actions / Jenkins による CI/CD | 同一パイプラインにエラーバジェット監視を統合 |
| 可観測性 | アプリケーションログ・メトリクスの集中管理（Datadog） | Prometheus + Alertmanager で SLI をリアルタイム可視化 |
| フィードバックサイクル | ユーザーヒートマップや A/B テスト結果を即時反映 | ポストモーテムから SLO 改訂へフィードバック |
- 共通基盤：自動化と標準化は両者の土台。
- 差分：DevOps は「開発速度」に、SRE は「運用信頼性」に重点を置く。
4️⃣ プラクティスと主要指標の比較
📌 CI/CD vs インシデント管理・ポストモーテム
| プラクティス | DevOps の実装例 | SRE の実装例 |
|---|---|---|
| CI/CD | Jenkins + GitHub Actions で PR ビルド自動化 | 同パイプラインにエラーバジェット消化率アラートを追加 |
| インシデント管理 | PagerDuty にアラート集約・オンコールスケジュール管理 | Incident.io の SLO ダッシュボードでエラーバジェットと SLA を同時可視化 |
| ポストモーテム | Confluence テンプレートで情報共有 | Google の “Blameless Postmortem” 方式 → 根本原因分析 + SLO 改訂 |
- CI/CD は開発速度、インシデント管理・ポストモーテム は信頼性向上に直結します。
📊 エラーバジェット活用例
| シナリオ | 条件 | アクション |
|---|---|---|
| エラーバジェット 70 % 消化 | 今月の障害で許容ダウンタイムが残り 30 % | 新機能デプロイを一時停止し、障害原因の根本解決にリソースシフト |
| エラーバジェット 90 % 超過 | SLO 未達が続きエラーバジェット枯渇 | 緊急リリース凍結＋全チームで信頼性改善タスクを実施 |
📈 主な指標比較
| 指標 | DevOps の目標例 | SRE の目標例 |
|---|---|---|
| MTTR (Mean Time To Recovery) | N/A | < 15 分 |
| MTBF (Mean Time Between Failures) | N/A | > 30 日 |
| デプロイ頻度 | 1 回/日以上 | エラーバジェットが 70 % 未満なら 2 回/日 |
| リードタイム（コード→本番） | < 1 時間 | N/A |
| エラーバジェット消化率 | N/A | ≤ 70 %（月次レビュー） |
指標は組織の成熟度に合わせて段階的に導入すると効果的です。
5️⃣ 組織形態・役割とツール／技術スタック
👥 DevOps チーム vs SRE チーム の構成例
| ロール | 主な担当業務 | 必要スキル |
|---|---|---|
| DevOps エンジニア | CI/CD パイプライン構築、IaC（Terraform／Ansible）導入、コンテナ化（Docker/K8s） | スクリプト言語 (Bash, Python)、クラウドサービス（AWS/GCP/Azure） |
| SRE エンジニア | SLO/SLI 定義、可観測性基盤設計（Prometheus／Grafana）、インシデント対応・ポストモーテム | メトリクス収集・分析、統計的信頼性評価、障害復旧フロー構築 |
役割を分離しつつ 情報共有（例：同一 Grafana ダッシュボード）を徹底すると、開発速度と安定性の両立が容易になります。
🛠️ 主なツール・技術スタック
| カテゴリ | DevOps 推奨ツール | SRE 推奨ツール |
|---|---|---|
| CI/CD | Jenkins, GitHub Actions, Azure Pipelines | 同上＋Spinnaker（デプロイ戦略管理） |
| IaC | Terraform, Pulumi, Ansible | 同上 |
| 監視・可観測性 | Datadog (統合モニタリング) | Prometheus + Alertmanager、Google Cloud Monitoring (旧 Stackdriver) |
| ロギング | Elastic Stack (ELK) | Loki + Grafana（メトリクスとログの相関） |
| インシデント管理 | PagerDuty, Opsgenie | 同上＋Incident.io の SLO ダッシュボード |
ツールは 目的別に選定し、API で連携させる ことが「DevOps と SRE が同一パイプラインで協働」する鍵です。
6️⃣ 導入判断ガイドラインと比較表サンプル
📍 成熟度別のアプローチ
| 成熟度 | 主な課題 | 推奨ステップ |
|---|---|---|
| 初期（自動化未整備） | 手作業デプロイ、リードタイムが数日単位 | DevOps：CI/CD と IaC をまず導入し、デプロイ時間を 1 h 未満に短縮 |
| 中間（高速リリースだが障害頻発） | 障害が多く MTTR が長い | SRE：エラーバジェットと可観測性基盤を追加。SLO 達成率を 99.9 % 以上に引き上げ |
| 高度（安定運用＋継続的イノベーション） | スケール拡大と品質維持が同時課題 | DevOps + SRE の統合フレームワークを構築し、共通プラットフォームで「高速 + 高信頼」を実現 |
各フェーズで KPI を測定しながら 次のステップへ移行することが失敗回避のポイントです。
📊 DevOps と SRE の比較表
| 項目 | DevOps | SRE |
|---|---|---|
| 目的 | 開発と運用の壁をなくし、リリース速度を上げる | サービス信頼性を数値で管理し、エラーバジェットで開発速度と安定性を調整 |
| 主導部門 | 開発チーム／プラットフォームチーム | 信頼性・インフラチーム（SRE） |
| 主要指標 | デプロイ頻度、リードタイム、変更失敗率 | MTTR、MTBF、エラーバジェット消化率、SLI/SLO 達成率 |
| 対象フェーズ | 開発 → ビルド → テスト → デプロイ全般 | リリース後の運用・障害対応・改善サイクル |
| メリット | 市場投入までの時間短縮、開発者の自己完結感向上 | 高可用性、ユーザー体験の安定、リスク可視化 |
| デメリット | 信頼性指標が薄くなる可能性あり | エラーバジェット管理に慣れが必要で、一時的に開発速度が制限されることも |
7️⃣ 次のステップ（実践ロードマップ）
- 現状評価シートを作成し、上記成熟度マトリクスと照らし合わせる。
- パイロットプロジェクトで① CI/CD の自動化、② エラーバジェットの可視化のいずれか（もしくは両方）を 1〜3 ヵ月実装し、KPI を測定。
- 成果が出たら 段階的に拡張し、最終的には DevOps と SRE が同一プラットフォーム上で連携する「統合フレームワーク」を全プロダクトへ適用。
参考文献・リンク
[^1]: Google Cloud. Site Reliability Engineering: How Google Runs Production Systems. https://cloud.google.com/site-reliability-engineering
[^2]: Microsoft Docs. DevOps practices and principles. https://learn.microsoft.com/ja-jp/devops/
[^3]: Google Cloud Blog. Introducing Error Budgets. https://cloud.google.com/blog/products/gcp/introducing-error-budgets
[^4]: CNCF. Prometheus – Monitoring system & time series database. https://prometheus.io/
[^5]: GitHub Docs. GitHub Actions documentation. https://docs.github.com/en/actions
[^6]: PagerDuty. Incident Management Best Practices. https://www.pagerduty.com/resources/incident-management-best-practices/
[^7]: Incident.io. SLO‑driven incident response. https://incident.io/blog/slo-driven-incident-response
本稿は、DevOps と SRE の違い・共通点を整理し、組織がどのタイミングで何を導入すべきかを示す実務的ガイドとして作成しました。