はじめに

タイトルにもある「SRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本」を読みました。

2024/4 現在、kindle unlimitedでも読めます。100pほどでまとまっているため、SREについて軽く理解したい方にオススメです。

読書したメモとして、内容を自分なりに整理してみます。

SREとは何か？

DevOpsを実践する方法論

DevOpsとSREの関係を以下のように記載するgoogleのドキュメントが存在します。

Site Reliability Engineering (SRE) is a term (and associated job role) coined by Ben Treynor Sloss, a VP of engineering at Google.7 As we can see in the previous section, DevOps is a broad set of principles about whole-lifecycle collaboration between operations and product development. SRE is a job role, a set of practices (described next) we’ve found to work, and some beliefs that animate those practices. If you think of DevOps as a philosophy and an approach to working, you can argue that SRE implements some of the philosophy that DevOps describes, and is somewhat closer to a concrete definition of a job or role than, say, “DevOps engineer.”8 So, in a way, class SRE implements interface DevOps.

サイト信頼性エンジニアリング（SRE）は、Google のエンジニアリング担当副社長であるベン・トレイナー・スロス（Ben Treynor Sloss）氏によって作られた用語（およびそれに関連する職務）である7。前節で述べたように、DevOps は、運用と製品開発のライフサイクル全体のコラボレーションに関する広範な原則の集合である。SRE は仕事の役割であり、私たちが効果的だと判断した一連のプラクティス（次に説明する）であり、それらのプラクティスを活性化するいくつかの信念である。DevOps を哲学や仕事へのアプローチと考えるなら、SRE は DevOps が説明する哲学の一部を実装しており、例えば「DevOps エンジニア」よりも仕事や役割の具体的な定義にいくらか近いと主張することができる8。

引用元

これらを読むに、DevOpsとSREの関係性が以下のように説明できます。

DevOpsとは、サイロを無くしましょう、開発～テスト～デプロイを自動化しましょう、というような哲学に過ぎない
SREはこのような考え方をどう実践していくか？という実際の方法論またはプラクティス

例えば、DevOpsの代名詞であるCI/CDパイプラインですが、DevOpsの文脈では、どういったデプロイ方法が良いか？や、デプロイ時間は何分以内に収めるべきか？という議論はなされません。

SREの観点でユーザーに提供されるべき可用性を定義することで、初めて上記した指標の目標値が決定されます。

SREとはDevOpsのどのような実装なのか

SREをGoogleで最初に立ち上げたSlossさんは
「信頼性こそがあらゆるプロダクトの基本的な機能だ」と発言しました。

この考えを踏まえ、SREとは、
サービスのreliability(信頼性)を担保することを目的にDevOpsを実践することだと解釈しました。

次に、reliability(信頼性)を担保する、とは具体的に何を意味するのか？
どういう指標にどういう目標値を設定するのか？を整理します。

SREで取り扱う指標

reliabilityはユーザー視点で計測される

SREは、プロダクトの信頼性を担保するためにDevOpsを頑張る、という考え方です。

Benjaminが信頼性（reliability）に関して「監視が信頼性を決めるのではなく、ユーザーが決めるものだ」と発言しています。

と本文でもあるように、ユーザーに届ける機能として、reliabilityを担保しようとします。
ですので、reliabilityはユーザー視点で計測する必要があります。

・ユーザーの視点にたったSREな計測指標

プロダクトにアクセスすると1秒以内にレスポンスが返却され、描画が完了すること

SREではこういった視点で計測指標を決定することが求められます。
こういった指標をSLIと呼びます。

逆に、以下のような指標はあくまで運用側の視点であり、SREの考え方にそぐわないわけですね。

・運用者の視点にたったSRE的には微妙な計測指標

Appサーバーから応答（200 OK）が返却されること

CUJ（Critical User Journey）

ユーザーに対して担保するreliabilityの指標SLIを考える際に、CUJ（Critical User Journey）を定義することが重要です。

本文では、CUJを以下の通りに定義しています。

サービスの中から最もユーザーにとって頻繁に行う作業、もしくは重要な一連の操作

ユーザー視点に立った上で、プロダクトが担保したいreliabilityの指標を考えるため、
プロダクトの最も重要なユーザー行動を分析・定義することが必要です。

SLI、SLO、SLA

それぞれ、SREを行っていくうえで重要となる指標です。

SLI(サービスレベル指標)

CUJの一部または全部を、ユーザーにどの程度のreliabilityで提供したいか？を指す指標です。

本書では、Youtubeを例に、以下のような参考例が記載されています。

クライアント端末から、https://youtube.comにアクセスした際、リクエストに対するレスポンスのうち「HTTPレスポンスコード2xx、3xx、4xx（429TooManyRequestsは除く）を返すもの(=良いレスポンス)の割合

youtubeにアクセスし、一連のサービスを楽しむ、というCUJが提供できる可用性が求められるようなSLIです。

（一連のサービス全てに対し、可用性を担保するのはややハードルの高いSLIだなと感じました。小さいサービスでは、CUJの中でもよりクリティカルな部分だけは壊れないようにする、などの整理があっても良いのかな？と感じます。）

SLO(サービスレベル目標)

SLIの具体的な目標値と計測期間がSLOとなります。

本書では、Youtubeを例に、以下のような参考例が記載されています。

過去30日間のyoutube.comのレスポンスのうち99.9%が良いレスポンスを返さなければいけない

SLA(サービスレベルアグリーメント)

SLOに関して、ユーザーと交わす法的な契約のことを指します。
SLOが達成できなかった場合の補償が定義されています。

本書では、Youtubeを例に、以下のような参考例が記載されています。

YouTube有償サービス利用者に、3日間の無償利用期間をサービスクレジットとして提供する

ユーザー視点でreliabilityが提供できているか、を担保する

このように、SREの考え方では、ユーザーにプロダクトのCUJが提供できているか？の視点で計測指標を策定し、運用します。
SREはDevOpsの実装である、という関係性がなんとなく理解できました。
DXやアジャイルの文脈で、ユーザーに価値が届くことが大事、なマインドが伝わってきます。

SRE implements interface DevOps のための思考（抜粋）

SREで実践される思考や試作のうち、気になったものを抜粋してまとめます。

ポストモーテム

障害から学ぶ、という施策です。
本書では、以下のように説明されています。

インシデントの影響範囲、その際の対応内容の詳細、根本原因、インシデントを再発させないようにするためのアクションなどを記録として残します。

そしてさらに重要なのは、一度ポストモーテムを作成したら終わりではなく、定期的にメンバー内でレビューすることにより貴重な経験値として活用していくということです。

Opsよりなテクニックで、とても大切な施策だと感じました。

トイル

自動化すべき物事、およびその定義です。
本書では、以下のように説明されています。

Googleでは以下のようなことをトイルとみなして対応すべき項目としています。

手作業であること

繰り返されること

自動化できること

サービスの成長に対してスケールしない作業

デプロイやテストはまさにこれらの項目が当てはまりますね。
システムで解決できるものはさっさとしてしまえ、というメッセージを感じます。

SRE implements interface DevOps のための技術（抜粋）

何故大事か？はおおむね理解できていますが、大事そうなものを抜粋しました。

クラウドネイティブアーキテクチャ
CI/CD
リポジトリ、イメージ
IaC
ロールバック、ブルーグリーンデプロイ、カナリアリリース
イミュータブルインフラストラクチャ
コンテナとkubernetes

SREの概念が理解できた今、これらがなぜSREの観点で重要か？が理解できます。
ユーザーに一定のreliabilityを提供する必要があるからですね。

おわりに

SREとDevOpsのなんとなくの関係が、タイトルの通りざっくり理解できました。
読むと「当たり前じゃん」と思うことが多いですが、それだけ実際の現場のサイロ化などは深刻ということなのでしょうか・・・。

SREやDevOpsに関する細かいプラクティスはまだまだ勉強できていないので、
この本を皮切りに、他の本も読んでいきたいです。

LeanとDevOpsの科学とか・・・。

はじめに

SREとは何か？

DevOpsを実践する方法論

SREとはDevOpsのどのような実装なのか

SREで取り扱う指標

reliabilityはユーザー視点で計測される

CUJ（Critical User Journey）

SLI、SLO、SLA

SLI(サービス レベル指標)

SLO(サービス レベル目標)

SLA(サービス レベルアグリーメント)

ユーザー視点でreliabilityが提供できているか、を担保する

SRE implements interface DevOps のための思考（抜粋）

ポストモーテム

トイル

SRE implements interface DevOps のための技術（抜粋）

おわりに

SLI(サービスレベル指標)

SLO(サービスレベル目標)

SLA(サービスレベルアグリーメント)