SRE という言葉は、求人票でも技術ブログでもよく見かけるようになりました。
ただ「インフラ担当の新しい呼び方」くらいの理解で止まっている人も多いはずです。
私も SRE は未経験で、いまその考え方を学んでいる最中。
調べていくと、SRE は職種名である前に運用という仕事の設計思想だと分かってきました。
「ソフトウェアエンジニアに運用チームを設計させたらどうなるか」
出発点は、Google の Benjamin Treynor Sloss による一文です。
SRE とは「ソフトウェアエンジニアに運用チームを設計させたときに起きること」だと、Google の SRE 本は定義しています（Google SRE Book: Introduction）。
従来型のシステム管理者チームを雇う代わりに、ソフトウェアエンジニアを 50〜60%、システムやネットワークに強い人材を 40〜50%という構成でチームを組む。
この人員構成には理由があります。
自動化する能力と、手作業を嫌う動機の両方をチームに持たせるためでした。
従来のやり方では、サービスが大きくなるほど運用要員も比例して増えていく。
その線形の成長を断ち切るのが、SRE の出発点です。
運用作業に 50% の上限を引く
思想を制度に落とし込んだのが、有名な 50% ルールでした。
Google では、SRE がチケット対応・オンコール・手作業といった運用業務に使う時間を全体の 50% までに制限しています。
残りの半分は、開発とエンジニアリングに充てなければならない。
エンジニアリングの時間を先に確保しておく、という順序が肝心なところ。
一見すると窮屈な縛りに見えますが、狙いははっきりしています。
上限があるからこそ、人を増やして凌ぐ代わりに、自動化で解くしかなくなるわけです。
SRE 本は「サービスを管理するチームはコードを書かなければ溺れる」と表現していました。
運用の負荷が上限に触れたときが、仕組みを作り直す合図。
エラーバジェットが対立をほどく
もうひとつの中心概念が、エラーバジェットです。
開発チームは速く出したい、運用チームは落としたくない——この対立は、どちらも正しいだけに厄介でした。
SRE の答えは、100% の信頼性を目指さないと最初に決めてしまうことです。
たとえば可用性の目標を 99.99% と置けば、残りの 0.01% が「壊してよい枠」になる。
その枠を新機能のリリースや実験に使える予算として扱えば、速度と安定性は取り合いではなく、同じ予算の配分の話に変わります。
目標を 100% に置いた瞬間、この会話は成立しなくなる。
「どれくらい落ちてよいか」を先に合意しておくのが、SRE の作法なのです。
DevOps との関係は「実装」
では DevOps との違いは何か。
SRE Workbook は冒頭に class SRE implements interface DevOps と書いています（Google SRE Workbook: How SRE Relates to DevOps）。
つまり両者は対立する概念ではなく、DevOps という考え方に対する具体的な実装のひとつが SREという関係です。
同章は DevOps の柱を CALMS（文化・自動化・リーン・計測・共有）として整理し、それぞれに SRE の実践を対応づけています。
計測の柱には SLO、自動化の柱にはトイル削減、文化の柱には非難しないポストモーテムと共有オーナーシップ。
柱ごとに対応する実践が示されているので、DevOps を掛け声で終わらせずに済みます。
DevOps が広い哲学で、SRE がその中で責任範囲を絞った具体策、と捉えると迷いません。
DevOps 側の背景は、こちらで整理しました。
最後に
SRE を一言でまとめるなら、運用をソフトウェアの問題として解き直す考え方でした。
50% ルールで自動化を強制し、エラーバジェットで速度と安定の対立をほどく。
信頼性は祈るものではなく、数字で合意して配分するもの。
この視点は、チームの技術判断に責任を持つ立場からも避けて通れないところだと感じています。
以上です。
コメントを残す