次、Workbookを引っ張ってくる。
余談だが、SREになる前にいろんな(SRE / DevOps / Infrastructure as Codeなどに関係する)本を読み漁っていて、今になっていざ現実の課題に解決する場面になって引っ張り出すというシーンが多くなってきた。とってもいいことだと思う。
ちなみにWorkbookにはSLOに関する章が3つもある。SREのCore Principleなだけある。
- Chapter 2 - Implementing SLOs
- Chapter 3 - SLO Engineering Case Studies
- Chapter 5 - Alerting on SLOs
今回は基本的な実装方針である Chapter2と、それをどう文化的になじませるかのケーススタディを書いたChapter3を流し読みしていく。Chapter 5はMonitoringと組み合わせてのAlertingの話なので、まだ先の話ということでpass。
しかし全章目次とintroとsummeryだけ読んでメモっておいてよかった。
SRE Lounge#6で「The Site Reliability Workbook」について登壇してきました - ツナワタリマイライフ
Chapter 2 - Implementing SLOs
Google - Site Reliability Engineering
. Service level objectives (SLOs) specify a target level for the reliability of your service. Because SLOs are key to making data-driven decisions about reliability, they’re at the core of SRE practices
だいじ
We’ll then cover how to use SLOs to make effective business decisions, and explore some advanced topics.
最終的にはビジネス的な意思決定のためにある。
Our experience has shown that 100% reliability is the wrong target
100%を設定するのは間違っている(reasonableではない)
で、SLIの例をhttpリクエストだとかgrpcだとかであげてくれつつ、最初にSLI/SLOをどう決めて実装したらいいか、といったところで
Your first attempt at an SLI and SLO doesn’t have to be correct; the most important goal is to get something in place and measured, and to set up a feedback loop so you can improve.
に安心感を覚える。
で、はじめるのはシンプル
- SLOを定義したいアプリケーションを決定する
- "users"(enduser)を明らかにする
- そのアプリケーションをユーザはどのように体験するかを考慮する
- 抽象的なアーキテクチャダイアグラムを作成する。
- key components, request flow, data flow, critical dependenciesを含む
これ、ちょうどいまProduction Readiness Checklistをやってて、そこでarchitecture diagramを書いてってお願いしていて、「何が含まれてればいいんだ？」って考えてたのとほぼ一致してびっくりした。
ここで架空のシステムを例にSLIの設定方法が説明されてるんだけど、こんなにやんの？！って思ってしまった。
Type of serviceとType of SLIの対応表が以下。ただこれだけネタがあると選びやすい気がする。
| Type of service | Type of SLI |
|---|---|
| Request-driven | Availability |
| Request-driven | Letency |
| Request-driven | Quality |
| Pipeline | Freshness |
| Pipeline | Correctness |
| Pipeline | Coverage |
| Storage | Durability |
(descriptionは本を読んでね)
で、このSLI Specificationから次はSLI implementationにうつる。
まぁ実装に関してはlogなりmonitoringなりでありものを使ってやればいいしどうしても今の仕組みでは計測できないものがあったとき実装を考えるぐらいでいいのかなぁと思う。この本にもengineering workが少なくて済むもんにしなよと言ってる。
でSLOの計算方法とかはまぁそうやねって感じで。
次にSLOのTimewindowの話。例えば月というか30日でやると、週末の数が違ったりするからweeklyがいいよと書いてある。
long(quater)とshort(week)にはそれぞれ利点があって、4weeksぐらいがだいたい一般的にいいんじゃない？ということでした。計測可能なら全部計測したらいいよね。
そして StakehodlerとのSLOの合意。 - Product Manager - Product developer
Once all of these points are agreed upon, the hard part is done.
これができれば大変な部分は終わったようなもので、この合意が将来に渡ってまた難しくなることがあるよ、と言っている。
というわけで、残りは繰り返し改善していくこととadvanced tipsなので流し読み。
おわりに
SLOの導入の仕方がかなり丁寧に書かれていてよかった。SLOやるぞ！どうすれば？ってひとはこの章の前半部分を読むとよろしい。
鍵はどのSLIを設定し、定めたSLOをステークホルダーと合意する、そのプロセスだと思いました。あとはそれだけに終わらない継続的な改善。
エラーバジェットによる開発と信頼性向上のバランスについて合意を取るのが難しそうですが、ひとまず安定しているプロダクトだとSLOの決定と観察からはじめてみてもいいと感じました。
Chapter 3 - SLO Engineering Case Studies
次回！
