LESSON 15分

ストーリー

田
田中VPoE
Month 1でCI/CD基盤を設計した。素晴らしい成果だ。だが基盤を作っただけでは組織は変わらない。それを運用し、信頼性を守り続ける組織が必要だ
あなた
運用チームを強化する、ということですか？
あ
田
田中VPoE
違う。「運用チーム」という発想自体を変える。うちの組織では「運用は運用チームの仕事」という考えが根強い。開発チームはコードを書いて投げるだけ、運用チームが夜中に障害対応する — この構造が問題なんだ

田中VPoEはホワイトボードに2つの円を描きました。「開発」と「運用」。その間に大きな溝を描きます。

田
田中VPoE
この溝を埋めるのがSRE — Site Reliability Engineeringだ。Googleが提唱した「信頼性をエンジニアリングの問題として捉え直す」アプローチだ
あなた
開発と運用の壁を壊す…DevOpsとは違うんですか？
あ
田
田中VPoE
いい質問だ。DevOpsは「文化と考え方」、SREは「DevOpsを実装した具体的なプラクティス」と言えるだろう。今月は、この組織にSREを根付かせるための設計をしてもらう

SREの起源と定義

Googleでの誕生

SRE（Site Reliability Engineering）は2003年にGoogleのBen Treynor Slossが立ち上げた組織とプラクティスです。

「SREとは、ソフトウェアエンジニアに運用の問題を解かせたときに起きることだ」 — Ben Treynor Sloss

SREの本質

従来の発想SREの発想
運用は繰り返し作業運用の問題はエンジニアリングで解決する
障害は避けるべきもの障害は起きるもの。リスクを定量化して管理する
安定性が最優先信頼性とイノベーション速度のバランスを取る
運用チームがすべて対応開発チームが自分のサービスの信頼性に責任を持つ

SREとDevOpsの関係

観点DevOpsSRE
位置づけ文化・哲学・ムーブメント具体的なプラクティス・フレームワーク
定義「開発と運用の壁を壊す」「信頼性をエンジニアリングする」
実装各組織が独自に解釈SLI/SLO、エラーバジェット等の具体的手法
例え「アジャイル」の思想「スクラム」の具体的フレームワーク
DevOps（文化・考え方）
  ↓ 具体的に実装すると
SRE（プラクティス・手法）
  ├── SLI/SLO/エラーバジェット
  ├── トイル（Toil）の削減
  ├── ポストモーテム
  ├── オンコール体制
  └── カオスエンジニアリング

なぜ今SREが必要なのか

組織の現状

問題現状SREによる解決
障害対応の属人化特定の「運用の達人」に依存ランブック化、オンコールローテーション
開発と運用の対立「壊すな」vs「早く出したい」エラーバジェットで両者の合意を形成
信頼性の定量化不在「なんとなく安定している」SLI/SLOで客観的に計測
改善の機会損失障害対応に追われて改善できないトイル削減で改善時間を確保
ナレッジの分断障害の教訓が共有されないポストモーテムで組織的に学習

Month 2 のロードマップ

Stepテーマ得られる成果
1SRE組織のミッションを定義しようSREの理解、組織モデルの選定
2エラーバジェットポリシーを策定しようSLI/SLO設計、エラーバジェットポリシー
3オンコール体制を設計しよう持続可能なオンコール体制
4ポストモーテム文化を確立しようブレームレスな学習文化
5SREチーム採用・育成計画を策定しようチーム構築ロードマップ
6SRE組織設計を完成させようSRE組織設計書

「CI/CD基盤は作れた。次はそれを守り、育てる組織を作る。技術とプロセスと文化 — 3つを同時に設計するのがL4のSREだ」 — 田中VPoE

まとめ

ポイント内容
SREの定義信頼性をエンジニアリングの問題として解決するアプローチ
DevOpsとの関係DevOpsの具体的な実装がSRE
組織の課題属人化、対立、定量化不在、改善機会の損失

チェックリスト

  • SREの定義と起源を理解した
  • SREとDevOpsの関係を理解した
  • 組織にSREが必要な理由を理解した

次のステップへ

次は「SREの基本原則」を学びます。SREを支える7つの原則を深掘りしましょう。

推定読了時間: 15分