はじめに

SRE領域を扱うチームにジョインして3ヶ月。
チーム自体も本格的に動き出して3ヶ月くらい、SREに詳しいメンバーもいないので辛いところも多いですが、毎日新しい学びと発見があって面白いです。

そんな中である疑問が生まれました。

「SREってなによ？」って他のチームのメンバーに聞かれた時にわたしゃ答えられるのかい...？
これからSREを推進していくにあたって、絶対他チームのメンバーに聞かれるはず...。
というか私だったら聞く。絶対聞く。なにそれ美味しいの？

改めて、SRE本を読んだり、SRE系のオンラインイベントに参加したりして 「SREとは何か？」完全に理解した ので私なりの答えをしたためます！

注意
個人の発言であり組織を代表するものではありません。
個人の解釈も含まれています。正確な情報はGoogleのSRE公式サイト等をご参照ください。

「SREってなによ？」と聞かれた時になんて答えますか？

私はこう答えます！

SREとは、

Googleが提唱する、
信頼性の高いサービスを提供するために
サービス運用に
ソフトウェアエンジニアリングを適用する
エンジニアチーム

です！

SREの定義ってムズくない？

実はSREをわかりやすく一言で定義づけるのは難しいです。
なぜならGoogleが公開している資料でも揺れがあるからです。

まず、開祖であるBenjamin Treynor Sloss様はSRE本(2016年)でこう表現しています。

「SREとは、ソフトウェアエンジニアに運用チームの編成をお願いした時に生じるもの」
SRE is what happens when you ask a software engineer to design an operations team.

開祖の言葉なのでSREの定義として最も的確なのでしょうが 「すまん。どういうことだってばよ？」
抽象度が高くて (　ﾟдﾟ)ﾎﾟｶｰﾝ です.

続いて2020年に公開された動画より、開祖の言葉その2です。
SREの公式ページからも動線があるような動画です。

「システム運用をソフトウェアの問題として扱い、その問題にソフトウェアエンジニアをアサインした時に得られるもの。他の全てはここから来ている。」
It's what you get when treat operations as a software problem and you staff it with software engineers. And everything else came from that.

「ソフトウェアエンジニアの手によってシステム運用をする」というところが明確 になりました！
とはいえ「SREってなによ？」の答えとしてはやはり謎が残りますね。
今ジョインしているPJでは開発エンジニアが運用業務もしているので 「あれ、うちらってもしかして！SREできてる！？We arh SRE！！🎉🎉🎉」

そんなわけあるかいな！www

え、そんなわけない、よね...？

むしろ謎が深まりました。くそぉ。

一方、Google CloudのSREのページではこのように表現されています。

SRE は、信頼性の高い本番環境システムを実行するための職務、マインドセット、エンジニアリング手法のセットです。

おおおお！！めっちゃ具体的！！
あれれ、だけど 開祖が口酸っぱく言っている「ソフトウェアエンジニア」「運用」 というワードがどどっかに行っちゃった...。
一方、信頼性というワードがやっと出てきましたね！

さらにググるといろんな人のいろんな「SREはこうじゃ！」を目の当たりにします。

▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂

私見なのですが、

開祖「曖昧さを残したい。業界の発展のためにSREはオープンソースにした。明確に定義づけてしまうことで、この分野の発展を阻害してしまうかもしれない。」

信徒「曖昧さを消したい。実践できる、想像できる粒度にしたい。」

というモチベーションの違い があるのかなぁと思っていて、いろいろな表現が出回っているように感じています。

俺にまかせろ

とはいえ「SREってなによ？」と聞かれた時に 「SREはきっとみんなの心の中にあるんだよ」 と答えるのはナンセンスでしょう。
そこで SREを完全に理解した私 が抽象度と具体度のバランスに気をつけて良い感じの表現にまとめました！！！

SREとは、

Googleが提唱する、
信頼性の高いサービスを提供するために
サービス運用に
ソフトウェアエンジニアリングを適用する
エンジニアチーム

解説します。

Googleが提唱する、
巨人の肩的な意味もありますが、一方で Googleのような超規模環境に由来する問題 や ヒーロー的エンジニア達 の存在を前提にしたお話もあるので 「全部を鵜呑みしないように！」 という思いを込めています。
信頼性の高いサービスを提供するために
開祖の言葉に信頼性という言葉は登場しませんが、信頼性こそSREの「目的」 にあたる大事な部分だと考えています。
「システム運用をソフトウェアエンジニアに任せる」ことは目的ではなく手段 なのです。
また、信頼性という言葉はシステム運用の本質 を表しているようで素敵ですよね。
信頼性は素直にRASISの信頼性と捉えて問題ないでしょう。
ちなみに 「じゃあSREのSiteってなんやねん。どこから来てんねん。」 と思う方もいると思いますが、こちらも素直に 「Webサイト」 の意味です。ただしBigTableやGCPというプロダクトもGoogle SREのターゲットとなっています。ここらへんを読むと分かりますが 要するにSiteは「名残り」 です。気にすんな。
サービス運用に
SREが取り組むのは あくまでサービス運用という領域でそこに責任 を持ちます。
例えば、パフォーマンスの問題を改善するために開発エンジニアと協業することもあるでしょうが、位置付けを忘れてはいけない という思いを込めています。
@hamachi4708 さんの記事「「自己組織化」「心理的安全性」って結局なんなのか？」にインスパイアされたのですが、自己組織化したチームを目指すには明確な境界と責任(裁量)が必要 です。
そしてSREの信条に明記されていますが、SREの責任(裁量)はこちらです。私は丸暗記しています。

「可用性、パフォーマンス、レイテンシ、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を持つのがSREチーム」
SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s).

ソフトウェアエンジニアリングを適用する
(ここが表現されていないと開祖がマサカリを投げてきそうです...)
まず、SREでは 「ソフトウェアエンジニア」と「システムエンジニア」 を区別して表現しています。
要するに 「Dev」と「Ops」 です。
とーってもとーってもざっくり言うと OpsにDev要素を取り込む ことで 「とりあえず運用カバーで！」を消し去ろうぜ！ もっと言えば 自動化ツールレベルでなくソフトウェアレベルのもの作っちゃおうぜ！ と言うお話です。
そうしないと信頼性を維持、向上させることは難しい からです。
従来の手作業中心のOps活動はサービスのスケールと比例して手作業も増えます。手作業が増えれば信頼性の向上にパワーを注げなくなります。
また、自動化によって ヒューマンエラーの削減ができれば故障間隔を伸ばせる し、自動復旧ができるようになれば復旧時間を短縮 できます。
※「おやや？DevOpsというワードが出てきたけどSREと何が違うの？」と思ったあなた！
安心してください！SRE本にてちゃんと言及していますよ！
エンジニアチーム
ここが一番悩みました...。SREは文脈によって形を変える のです。
あるいは この世界には存在する言葉で適切に表してくれるものがないので「SRE is what ~」なのかも しれませんね。
SREはシステム運用における思想であって、文化であって、手法であって、領域であって、組織論であって、役割なのです。
正直ここは 文脈によって好きな言葉を使って良い と思いますが、一番私がしっくりくるのは 「エンジニアチーム」 でした。
1人SREなんて言葉もありますけども。

まとめ

「SREとは」について考えを深めてみました。
正直、お仕事としての関心ごとはSREの中身(原則)だと思います。
「エラーバジェット」「SLO」「トイルの撲滅」などなど実践的なもの多く、とりあえず始めてみたくなりますが、困った時の判断の拠りどころとして、SREを志向する際のお行儀として、最低限「SREとは」について話せること、根拠を言えることが大事だと考えています。

以上、「SREってなによ？」と聞かれた時の私なりの答えでした！
ぜひ、先輩SREのみなさまの「SREとは」も教えてください！