SREとは何か

ストーリー

「コードレビューとテストで開発段階の品質は守れるようになった。 でも、本番環境で動き続けるサービスの品質はどう守る？」

松本先輩が本番環境のダッシュボードを見せた。

「SRE、Site Reliability Engineering だ。 Google が生み出した、本番環境の信頼性を エンジニアリングで解決するアプローチ。 『品質の番人』の仕事は開発で終わりじゃない。 本番で動き続けてこそ本当の品質だ」

SRE の概要

SRE とは

SRE（Site Reliability Engineering）は、Google が2003年に始めたエンジニアリング手法です。「ソフトウェアエンジニアリングのアプローチで運用の問題を解決する」という考え方に基づいています。

従来の運用:                    SRE:
├── 手動オペレーション          ├── 自動化
├── 経験と勘                   ├── データ駆動の意思決定
├── 変更は少ない方が安全       ├── 適度な変更が信頼性を高める
├── 運用チーム vs 開発チーム    ├── 同じチームで協力
└── 100%の可用性を目指す       └── 適切な信頼性目標を設定

SRE の基本原則

SRE と DevOps の関係

DevOps = 文化・哲学
  「開発と運用の壁を壊し、協力してサービスを提供しよう」

SRE = 具体的な実践方法
  「DevOps の哲学を、具体的な方法論とツールで実現しよう」

→ SRE は DevOps の具体的な実装の一つ

なぜ 100% の可用性を目指さないのか

99.9% vs 99.99% の現実

可用性を1ナイン上げるごとに:
├── コストは約10倍に増加
├── エンジニアリングの複雑性が急増
└── 変更の速度が低下

→ ユーザーが気づかない範囲でのダウンタイムは許容し、
  その「予算」をイノベーションに使う

ユーザーの体感

ユーザーの接続環境:
├── ISP の可用性: 99.9%
├── ルーターの可用性: 99.9%
├── Wi-Fi の可用性: 99%
└── デバイスの可用性: 99.9%

→ 全体の可用性: 約 99.7%

サービスが 99.99% でも、ユーザーの実体験は約 99.7%
→ サービスだけ 100% を目指しても意味が薄い

SRE エンジニアの役割

SRE エンジニアの仕事:

50% ソフトウェアエンジニアリング
├── 自動化ツールの開発
├── モニタリングシステムの構築
├── インフラのコード化
└── 信頼性向上のための開発

50% 運用
├── オンコール対応
├── インシデント対応
├── キャパシティプランニング
└── ポストモーテムの実施

まとめ

チェックリスト

• SREの定義と基本原則を説明できる
• SREとDevOpsの関係を理解した
• 100%の可用性を目指さない理由を説明できる
• SREエンジニアの役割を理解した

次のステップへ

SREの概要を理解したら、次はSLI/SLOの設計方法を学びます。サービスの信頼性を具体的な数値で定義する方法を見ていきましょう。

推定読了時間: 30分