はじめに
SRE (Service Reliability Engineering) 部の村上です！
お久しぶりになってしまいましたが皆様いかがお過ごしでしょうか？
さて、私は SRE 部に 2024年12月に JOIN させていただきました。
2026年1月に本記事を執筆しているので、おおよそ1年が経過したということになります。
この1年の取り組みや議論を通じて様々な学びがありました。
特に「SRE とはなにか？」について非常に活発に議論を行い、私の中である一定の理解・納得を得ることができたかなと思います。
本記事では、SRE とはなにかについて、私の今の見解をまとめていければと思います。
SRE はインフラ屋ではないということ
まずこれを1年前の私に強く伝えたいということで、一番最初に書いちゃいます！
SRE の募集要項には、AWS 等のクラウドや、オンプレサーバ、Kubernetes 等のインフラのお世話を中心に書かれることが多いので、「インフラ屋の拡張」と思ってしまうことが多いと思います。
（私も正直そう思っていたということをここで懺悔します…！）
確かに、（詳細は後ほど述べますが） 「SRE」は「運用」と関わりがとても深く（むしろ運用そのものとも言える）、更に「インフラ」も「運用」と関わりが深いため、「SRE」と「インフラ」は自然と関わりが深くなります。
また、組織によっては SRE がインフラ（あるいは Platform）を強く担当するケースもあります。
しかし、それは「SRE の仕事の一部になり得る」という話であって、「本質そのものではない」と私は理解しました。
インフラ屋なのであれば “Infrastructure Engineering” にしておけばよいわけで “Site Reliability Engineering” である必要はないですよね。
「SRE」 は “Site Reliability Engineering”…つまり広範なシステム・サービスの信頼性のための工学であるわけです。
（ここで言う信頼性は、ざっくり言えば「期待される振る舞いを、期待される水準で、継続的に提供できること」だと思っています。可用性だけではなく、遅延、正確性、復旧性、運用しやすさ等も含み得ます。）
では、SRE というのは何でしょうか。
SRE とは？
弊社の SRE 部において、「SRE とはなにか」ということについてたくさんの議論が交わされました。
議論の末、我々が採用した定義は以下のようなものになりました。
サイトリライアビリティエンジニアリングは、組織がシステム、サービス、製品において適切なレベルの信頼性を持続的に達成できるよう支援することを目的とした工学分野である。
これは、『SREをはじめよう ─個人と組織による信頼性獲得への第一歩, David N. Blank-Edelman 著』からの引用になります。
ここで重要な考えは以下です:
- ビジネスの要求に対して必要十分な信頼性を提供できるようにすること
- 信頼性のための対応はコストが掛かるということを念頭に置き、そのバランスを取ること
- 上記が、持続的に達成できるようにすること
- ビジネスの要求の変化に対して「必要十分な信頼性とはなにか」が更新され、それに応じて体制や仕組みも更新されること
つまり、SRE は「信頼性を上げる人達、あるいはそのための手法」ではなく、 「どのくらい信頼性が必要か」を組織として合意し、その水準を「継続的に」実現できるように、仕組み・設計・運用・改善のサイクルを作る（回す）ための工学 と捉えるのが良いと考えています。
ここで特に強調したいのは、「合意」と「継続性」です:
- 合意: 信頼性は「無限に高ければ良い」わけではなく、コスト（開発速度、人員、運用負荷）とのトレードオフになるので、どこを狙うかを合意しないと破綻してしまう
- 継続性: 一回「頑張って改善して終わり」ではなく、状況の変化（利用者増、要件変化、依存先変化、組織体制変化）に合わせて更新し続けないと、どこかのタイミングで信頼性の過不足が発生してしまう
SRE の成り立ちと拡張
SRE の成り立ち─運用との関わり
ここまでは、「そうだよね」と納得いただけるものになるかなと思います。
ところで、SRE の書籍には SRE が整備・実施する項目について大体以下のような項目が並びます:
- SLO
- 監視・モニタリング
- インシデント対応
- ポストモーテム
- Toil の削減
- 運用の自動化
- リリースや変更管理
- キャパシティプランニング
- etc…
お決まりの項目だと思いますが、なぜこれらが SRE の文脈で出てくるのでしょうか？
これは、SRE の成り立ちを考えてみると分かります。
歴史的に、システムを動作させるために開発チームと運用チームとを分けて配置していることが多いのは皆さんもご存知かと思います。
これはとても合理的です。 役割を分けた方がそれぞれが専門性を高められますし、開発チームは開発に集中できるからです。
しかし、開発が進み、サービスが大きくなるほど、運用は複雑化していきます。
手作業が増えたり、割り込み対応が増えたり、属人化したりして、だんだん「人が頑張って支える」形になりがちです。
SRE という考え方は、この問題の解決方法の一つとして生まれたと考えられます。
『SRE サイトリライアビリティエンジニアリング ─Googleの信頼性を支えるエンジニアリングチーム, Betsy Beyer,…著』より:
Google 内で規定されることになったサイトリライアビリティエンジニアリングとは、いったい何なのでしょうか。私の説明は単純明快です。SRE とは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。
つまり、運用を「人手の気合い」で回すのではなく、ソフトウェアエンジニアリングとして設計し直す、ということです。
そして、「SRE は、元々は運用をエンジニアリングするところから始まり、実装が積み重なったもの」と捉えることができます。 そして、先ほどの「お決まりの項目」のいくつかに繋がっていきます。
それは、（私の想像ですが）恐らくこうです:
- 開発が進む
- 組織が分業され、開発と運用が分かれる
- 運用が複雑化する（割り込み・手作業・属人性が増え、スケールしづらくなる）
- 運用を仕組み化…エンジニアリングしたいという機運が高まる
- SRE の最初の定義「ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの」が生まれる
- その結果として、先述の「お決まりの項目」に上がってくるような運用の仕組み化・自動化が必要になり、整備されていく
このように「SRE」は「運用」と関わりがとても深いということがご理解いただけたと思います。
ビジネスを意識した SRE の定義の拡張
一方で、現場の運用をエンジニアリングするだけだと、次の壁に当たります。
それは、「運用をエンジニアリングし、仕組み化したり信頼性を向上させるというのは望ましいように聞こえるが、それはビジネス的にペイするのか？」という問題です。
信頼性を 100% にすることはできず、信頼性を上げようとすればするほどコスト（開発速度、人員、運用負荷）とのトレードオフになっていきます。
一方で、運用を仕組み化したり信頼性を向上させる取り組みを行わなければ、ユーザに信頼されずに利用率の低下や、メンバーの疲弊による離脱などを招き、プロダクトを維持することができなくなります。
このトレードオフを解決する…つまり、どこまで信頼性にリソースを割いていいのか、あるいはどこまで信頼性の低下を許容できるのかは、ビジネス判断が必要になります。
そのため、「どのくらいの信頼性が必要か」を SLO のような形で合意し、それを状況の変化に合わせて更新し続けられるようにする必要があります。
こうして、SRE は、ビジネスとのバランスを取るために「運用をうまく回すための工夫」から、 「組織がシステム、サービス、製品において適切なレベルの信頼性を持続的に達成できるよう支援するための工学」 という定義へ繋がっていったのだと捉えています。
そして、ここまでくると、先述の「お決まりの項目」全てに繋がっていくということが明らかになったのがお分かりいただけるかと思います。
ここまで、SRE とは何かについてまとめさせていただきました。
- SRE は、元々は運用をエンジニアリングするところから始まり、その実装が積み重なったものであること
- これを拡張・応用することで、ビジネスを意識した適切なリソース配分への貢献が可能になり、以てビジネスや組織全体に貢献していくこと
…と捉えるのが、SRE のファーストステップとしては良いのではないでしょうか。
そして、このように捉えると、SRE の主要素である「インシデント対応」「SLO」等への理解が非常にスムーズになると感じております。
次の記事では「インシデント対応」「監視・モニタリング」「SLO」等の関連と考え方について現在の見解を述べていきたいと思います。
（#2 に続く）