ストーリー

SREの定義

SRE（Site Reliability Engineering）は、Googleが2003年頃にBen Treynor Slossによって提唱した、ソフトウェアエンジニアリングのアプローチでシステム運用の課題を解決する手法です。

SREの本質

「SREとは、ソフトウェアエンジニアにオペレーションの設計を依頼したときに起こることである」 — Ben Treynor Sloss

SREの基本原則

graph TD
    Title["SREの基本原則"]
    Title --> P1["1. エンジニアリングで運用を改善する<br/>手作業を自動化・効率化する"]
    Title --> P2["2. SLI/SLOでサービスレベルを定量化する<br/>「感覚」ではなく「データ」で判断する"]
    Title --> P3["3. エラーバジェットで変更速度と<br/>信頼性のバランスを取る<br/>100%の信頼性は目指さない"]
    Title --> P4["4. トイルを削減する<br/>50%ルール：作業時間の50%以上を<br/>エンジニアリングに"]
    Title --> P5["5. 障害を受け入れ、そこから学ぶ<br/>ブレイムレスなポストモーテム"]

    classDef title fill:#1a1a2e,stroke:#e94560,color:#fff
    classDef principle fill:#0d6efd,stroke:#0a58ca,color:#fff

    class Title title
    class P1,P2,P3,P4,P5 principle

Googleが生み出した背景

なぜSREは生まれたのか

Googleは2000年代初頭、急激なサービス拡大に伴い、従来のシステム管理アプローチでは対応できない課題に直面しました。

SREの成長

// SREの歴史的マイルストーン
interface SreMilestone {
  year: number;
  event: string;
  impact: string;
}

const sreTimeline: SreMilestone[] = [
  {
    year: 2003,
    event: 'Google SREチーム発足',
    impact: 'Ben Treynor Slossが初代SREチームを結成',
  },
  {
    year: 2014,
    event: 'SRECon初開催',
    impact: 'SREコミュニティの形成が始まる',
  },
  {
    year: 2016,
    event: 'SRE本出版（O\'Reilly）',
    impact: 'SREプラクティスがオープンに共有される',
  },
  {
    year: 2018,
    event: 'SRE Workbook出版',
    impact: '実践的なガイドラインが公開',
  },
  {
    year: 2020,
    event: 'SRE採用企業の急増',
    impact: 'Netflix, LinkedIn, Twitter等が大規模導入',
  },
];

SRE vs DevOps

SREとDevOpsは補完関係にあります。DevOpsが「文化と哲学」を提示するのに対し、SREは「具体的な実装方法」を提供します。

比較表

SREはDevOpsのclass実装

Google VP of Engineering であるBen Treynorは、「SREはDevOpsのinterface実装である」と表現しています。

// DevOpsを抽象的なインターフェースとして定義
interface DevOps {
  // 原則
  reduceOrganizationalSilos(): void;
  acceptFailureAsNormal(): void;
  implementGradualChange(): void;
  leverageToolingAndAutomation(): void;
  measureEverything(): void;
}

// SREはDevOpsの具体的な実装
class SiteReliabilityEngineering implements DevOps {
  reduceOrganizationalSilos(): void {
    // SREチームは開発チームと共同でSLOを設定し、
    // 責任を共有する
    this.defineSharedSLOs();
    this.shareOwnership();
  }

  acceptFailureAsNormal(): void {
    // エラーバジェットにより、一定の障害を許容する
    this.calculateErrorBudget();
    this.runBlamelessPostmortems();
  }

  implementGradualChange(): void {
    // カナリアリリースとエラーバジェット消費率で
    // 変更の安全性を制御する
    this.useCanaryDeployments();
    this.monitorBurnRate();
  }

  leverageToolingAndAutomation(): void {
    // 50%ルール：SREの業務時間の50%以上を
    // エンジニアリング作業に充てる
    this.enforceHalfEngineering();
    this.automate('toil');
  }

  measureEverything(): void {
    // SLI/SLOですべてを計測する
    this.defineSLIs();
    this.setSLOs();
    this.trackErrorBudget();
  }
}

50%エンジニアリングルール

SREの最も重要な運用原則の1つが「50%ルール」です。

50%ルールとは

SREエンジニアの業務時間のうち、最大50%を運用作業（トイル）に、残りの50%以上をエンジニアリング作業に充てるというルールです。

なぜ50%なのか

運用作業の比率が高すぎる場合の悪循環:

  手動運用作業が増える
    ↓
  自動化する時間がない
    ↓
  さらに手動作業が増える
    ↓
  エンジニアが疲弊する
    ↓
  品質が下がる → 障害増加
    ↓
  さらに運用作業が増える（負のスパイラル）

50%ルールはこの悪循環を断ち切る仕組み

50%ルールの実践

interface SreTimeAllocation {
  engineering: {
    automation: number;       // 自動化開発
    tooling: number;          // ツール開発
    architecture: number;     // アーキテクチャ改善
    performanceWork: number;  // パフォーマンス改善
  };
  operations: {
    oncall: number;          // オンコール対応
    manualTasks: number;     // 手動タスク
    tickets: number;         // チケット対応
    meetings: number;        // 運用関連ミーティング
  };
}

function evaluateTimeAllocation(allocation: SreTimeAllocation): string {
  const engineeringTotal =
    allocation.engineering.automation +
    allocation.engineering.tooling +
    allocation.engineering.architecture +
    allocation.engineering.performanceWork;

  const operationsTotal =
    allocation.operations.oncall +
    allocation.operations.manualTasks +
    allocation.operations.tickets +
    allocation.operations.meetings;

  const total = engineeringTotal + operationsTotal;
  const engineeringRatio = engineeringTotal / total;

  if (engineeringRatio >= 0.5) {
    return `健全: エンジニアリング比率 ${(engineeringRatio * 100).toFixed(0)}%`;
  } else {
    return `要改善: エンジニアリング比率 ${(engineeringRatio * 100).toFixed(0)}% - トイル削減が必要`;
  }
}

SREチームの構成と役割

典型的なSREチーム構成

SRE導入モデル

graph TD
    Title["SRE導入モデルの比較"]

    Title --- Centralized["集中型SRE<br/>独立したSREチームが<br/>全サービスを担当<br/><br/>向いている場面:<br/>大規模組織、<br/>共通基盤が必要"]
    Title --- Embedded["組込型SRE<br/>開発チームに<br/>SREエンジニアが配属される<br/><br/>向いている場面:<br/>自律的な開発<br/>チームがある場合"]
    Title --- Consulting["コンサルティング型<br/>専門SREチームが<br/>各チームを支援・教育する<br/><br/>向いている場面:<br/>SRE導入初期、<br/>文化醸成が必要"]

    classDef title fill:#1a1a2e,stroke:#e94560,color:#fff
    classDef model fill:#0d6efd,stroke:#0a58ca,color:#fff

    class Title title
    class Centralized,Embedded,Consulting model

SRE導入のロードマップ

SREプラクティスを既存の組織に導入する際の典型的なロードマップです。

# SRE導入ロードマップ
phase_1_foundation:
  duration: "1-2ヶ月"
  activities:
    - SLI/SLOの定義
    - 基本的なモニタリングの整備
    - エラーバジェットの計算
  success_criteria:
    - 主要サービスにSLOが設定されている
    - エラーバジェットの消費状況が可視化されている

phase_2_process:
  duration: "2-3ヶ月"
  activities:
    - オンコール体制の構築
    - インシデント対応フローの確立
    - ランブックの作成
  success_criteria:
    - オンコールローテーションが運用されている
    - インシデント対応の平均復旧時間が改善している

phase_3_engineering:
  duration: "3-6ヶ月"
  activities:
    - トイル削減の自動化プロジェクト
    - オブザーバビリティ基盤の構築
    - カオスエンジニアリングの導入
  success_criteria:
    - トイル比率が50%以下
    - メトリクス・ログ・トレースの統合基盤が稼働

phase_4_culture:
  duration: "6ヶ月〜"
  activities:
    - ブレイムレスポストモーテムの定着
    - 50%ルールの遵守
    - SREプラクティスの全チーム展開
  success_criteria:
    - ポストモーテムが定期的に実施されている
    - エンジニアリング作業比率が50%以上を維持

まとめ

チェックリスト

• SREの定義と基本原則を説明できる
• SREが生まれた背景と課題を理解した
• SREとDevOpsの違いと関係性を説明できる
• 50%エンジニアリングルールの意義を理解した
• SRE導入モデルの種類と選択基準を把握した

次のステップへ

次は「信頼性エンジニアリングの基礎」を学びます。MTBF/MTTR/MTTDなどの信頼性メトリクスと、可用性のNines（9の数）の概念を深掘りしていきましょう。

推定読了時間: 30分