1 of 98

The Art of SLOs

混沌のなかにこそ勝機信頼性あり

— 孫子の兵法 (The Art of War)

原文: https://cre.page.link/art-of-slos-slides

https://cre.page.link/art-of-slos-slides

Self link: https://cre.page.link/art-of-slos-slides

Participant Handbook: https://cre.page.link/art-of-slos-handbook

Facilitator Handbook: https://cre.page.link/art-of-slos-howto

SLO Worksheet: https://cre.page.link/art-of-slos-worksheet

Errors in the content? https://cre.page.link/art-of-slos-bug

Want to improve this? https://cre.page.link/art-of-slos-improve

Want to ask a question? https://cre.page.link/art-of-slos-help

Instructors: You'll need to print out enough copies of the handout that all attendees can have one each, and enough copies of the SLO worksheet to cover the activities, which will probably work out as 5-6 copies of the worksheet per group.

This is the presentation for a ~3.5 hour SLO workshop, for use at e.g. conferences or with multiple attendees from different companies. Attendees are expected to be relatively comfortable with SLO terminology: this workshop tries to be activity-driven, though we still cover a reasonable amount of theory.

2 of 98

ようこそ！

恥ずかしがらないで・・・

となりの人にやあってあいさつしてみよう

https://cre.page.link/art-of-slos-slides

ゴール: 登壇者の紹介とプレゼンターがなぜ選ばれたのかというところの背景の紹介

インストラクター: 各テーブルで各自が自己紹介できるようにする（オフライン時）。内向的な人もいるので、うまく和ませること。

セリフ:

大人数がいる大部屋で突然コミュニケーションしてくださいと言われても緊張すると思います。アイスブレークをしたりお互いに自己紹介をすることはオープンコミュニケーションにおいてとても重要です。今後の演習において同じグループで取り組んでいくことになるので、少しでもお互いの人となりを知っておいたほうが良いと思います。時間を取りますので、お互いに名前や会社での職務など、紹介していきましょう。

3 of 98

参加者の約束

私たちは学ぶためにここにいる
質問をする (手を挙げて)
ひとりずつしゃべる
みんな好意的だと考える
「何についてしゃべってるんだっけ？」

https://cre.page.link/art-of-slos-slides

ゴール: ワークショップのガイドラインを紹介する

セリフ:

ワークショップ中のコミュニケーションについていくつかガイドラインを作りたいと思います。

まず、参加者はおそらく学ぶために来ています。ですのでラップトップや電話などで集中できないといったことがないように配慮をお願いします（オフライン用。オンラインであれば、発言がなさそうなときはミュートするなどの配慮をお願いします、など）

次に、不明な点があればいつでも質問してください。質問の時間も設けているので、ぜひお願いします。質問はSlido経由でも構いません。

また、プレゼンテーション中に紹介する内容はさほど議論が起きるようなものではないとは思うのですが、ワークショップ中など含めもし異論があるという場合は他の方を尊重してください。一度に話すのは一人だけにするようにし、他の方の意見から学べるようにしていきましょう。

私たちも広く質問やコメントは受け付けたいと思いますが、同時に資料や演習に取り組んでいる方々の邪魔はしないようにしたいと考えています。

4 of 98

専門用語
なぜサービスには SLO が必要なの？
エラーバジェットを使う
良い SLI を選ぶ
SLO と SLI を作る

https://cre.page.link/art-of-slos-slides

ゴール: ワークショップ中に行うことの整理

セリフ:

本ワークショップではサービスの信頼性を数値化、そしてその信頼性の達成できる目標を設定する方法についてお話します。

議論の際に共通の語彙が使えるように、まず簡単にGoogleでの信頼性に関する概念と、その際に利用する語彙、たとえばサービスレベル目標やサービスレベル指標、すなわちSLOやSLIといった専門用語を紹介します。

次に、信頼性とはなにか、なぜそれがユーザーにとって重要なのか、なぜ「信頼性が高すぎる」という状況があり得るのか、といった話をします。

信頼性の目標を設定することで、どのように許容されるエラーの安全マージンが与えられるか、そしてそのマージンを維持するという目標が組織全体のインセンティブに合致するのかを説明します。

本ワークショップによってあらゆるサービスにおいてSLOが必要不可欠な要素であると納得いただけることを願っています。

さて、それではサービスにおいてどのようなSLIとSLOを設定すべきでしょうか。

ワークショップを通じて、いくつかの練習用のサービスでSLIとSLOの設計をします。

まず参加者全体むけにそのプロセスを解説したあと、小グループに別れてより複雑なユーザージャーニーに取り組んでいきます。

本ワークショップが終わる頃には、これらの概念やツールを理解し、ご自身のサービスや組織において自信を持ってそれを適用させられるようになっていることを期待しています。

質問があれば、お気軽に聞いてください！

5 of 98

Service Level Indicator

サービスの信頼性の定量化できる尺度

https://cre.page.link/art-of-slos-slides

ゴール: SLIについて話すときにこのスライドの内容を話せるようにする

セリフ:

本ワークショップではSLIとSLOという2つの用語を耳にすると思います。多くの方々がすでにこれを聞いたことがあると思いますが、参加者全員が確実に同じ理解となるようにもう一度簡単にこの概念に触れておきたいと思います。

サービスレベル指標（SLI）はサービスの信頼性のある側面を計測する、慎重に選ばれたモニタリングメトリクスです。

理想的には、SLIはその信頼性のユーザー体験と深い相関関係があるべきです。したがって、SLIは良いイベントの数をすべてのイベントの数で割ったものという2つの数字の割合で表現すべきです。

6 of 98

Service Level Objectives

SLI に対する信頼性の目標

https://cre.page.link/art-of-slos-slides

7 of 98

ユーザー？お客様？

お客様というのは、サービスに直接お金を払うユーザー

https://cre.page.link/art-of-slos-slides

8 of 98

サービスには SLO が必要

https://cre.page.link/art-of-slos-slides

9 of 98

信じられないって？

「SLO を導入してから、運用と開発チームとの関係が、�わずかだが注目に値するほど改善した」

— Ben McCormack, Evernote; The Site Reliability Workbook, Chapter 3

「... 明確に定義しないことには、いい仕事をすることは難しい。�「いい仕事」を定義するために SLO はことばを与えてくれる」

— Theo Schlossnagle, Circonus; Seeking SRE, Chapter 21

https://cre.page.link/art-of-slos-slides

10 of 98

どんなシステムでも�最も重要な機能は�信頼性

➊

https://cre.page.link/art-of-slos-slides

ゴール: もっとも中心となる仮定である「サービス信頼性がもっとも重要な機能」を紹介する

ポイント:

＜スライドを読む＞
信頼性がない状態が認識される ⇒ 信頼が失われる

セリフ:

しかし、なぜでしょう？

なぜサービスにSLOが必要だと信じてもらおうとしているのでしょうか。その答えは大元の原則にあります。つまりあらゆるシステムにおけるもっとも重要な機能は信頼性であるという点です。

サービスの信頼性が著しく失われると、ユーザーからの信用や関心も容易に失われます。あるいは単純に信頼性がなさすぎるとみなされます。

素晴らしいユーザー体験を設計したり構築したりするために費やしてきた数え切れないほどの時間が、そこにアクセスできないだけで無に帰すのです。

信頼性がないということはビジネスにとって悲惨な結果をもたらします。不満足に感じたユーザーを競合製品が奪い取り、不名誉な評判によってユーザーの新規獲得も遅く、あるいは全くできなくなってしまいます。

11 of 98

運用者

安定性

どうやったら

信頼性を

自分ごとにして

もらえるだろう？

開発者

アジリティ

https://cre.page.link/art-of-slos-slides

ゴール: インセンティブを合わせることで組織間の壁を取り払う

ポイント:

新規機能開発のイテレーションとサービスの信頼性の綱引き
信頼性の高い運用とは優先順位とインセンティブの共有

ここで挙手で質問してみてもよいかもしれない

DevOpsという用語を聞いたことがある人？DevOpsという用語の理解が隣りに座っている人と同じだと思う人？
CI/CDを実施している人？パイプラインが赤になったときにすべてを投げ売ってその修正をするのは誰ですか？バグが有ると知りながら締め切りが来たからという理由でリリースしたことがある人？

セリフ:

サービスの信頼性が高いというだけでは不十分です。

もしそれだけでいいというならここには居ないはずです。

信頼性というのは組織内の様々なチームが一緒になって取り組まなければいけない共通のゴールです。

多くの企業では、新機能の開発と運用の責任者を分けるのが普通です。

そうすることで各ロールの専門性を高めることができます。しかし、これによってお互いの優先順位が衝突することもありえます。

例えばこういった経験はないですか。

サービスの開発チームが新規機能の開発スピードに重きをおいて、アジャイル開発のようなプラクティスやpush-on-greenを導入し、プランニングとリリースのサイクルを加速させることに決めました。

これによってサービス運用者の負担が増えました。常に正式版に向けた大量の「ベータ」機能を追いかけなければならなくなったのです。

そして、プロダクション品質に至る前の機能がリリースされ、目に見える障害が発生し多くのお客様がソーシャルメディア上で不満を叫ぶ、という状況は避けられなくなります。

運用チームはプロダクション環境をこうした恐ろしい障害を発生させうる変更から守りための手順を整えることで対抗します。これによって開発者のリリース速度を下げて、結果開発者は悲しみを覚えることになるのです。

こうしたシナリオを避けるために、組織ではサービスの開発者と運用者が強調するためのインセンティブを見つける必要があり、それによって定期的に発生する深刻で不名誉な障害を起こすことなく新機能のリリースを行えるようにする必要があります。

12 of 98

みんながサービスの望ましい信頼性に

ついて納得できる

原理に基づいた方法

https://cre.page.link/art-of-slos-slides

ゴール: 客観的なデータをもとにした信頼性の会話が定着することの利点を証明する

ポイント

「十分に信頼できる」とはどういうことか
SLOはビジネス全体で使える共通言語
SLOの価値

開発
運用
製品
経営層

セリフ

But you can't spend all of your engineering time on reliability, because reliability is not a standalone product. So the question you end up asking is "What is reliable enough?" shortly followed by "How can I objectively measure the reliability of my service?"

That's why we think your services need SLOs. We think of SLOs as a principled way to agree on the desired reliability of a service.

SLOs provide different value to different parts of an organization. We've claimed reliability is the most important feature, but for many product-oriented folks, this brings up a difficult question: When should engineering for increased reliability take priority over that shiny new feature you've been designing for months? If you have an agreed-upon and widely-communicated target for service reliability, you can answer that question with objective data.

For developers in the room, reliability work can get in the way of hacking on cool new projects and meeting those crazy deadlines set by the product folks. Changing systems is the biggest risk to their reliability, so how can you strike a good balance between moving fast and breaking things? If you have a real-time measure of service reliability, you can start to gauge the reliability cost of new code. You'll know when one of your shiny new features has hurt your users instead of delighted them.

And for the ops folks, who are generally on the hook for a service's reliability, agreeing that some measure of unreliability is acceptable and even desirable usually helps reduce the overall operational burden of that service. Rather than burning yourselves out fighting every small fire, you can carve out time to work on proactive projects that stop things from catching fire in the first place.

So SLOs provide a common language and shared understanding, anchoring your conversation about service reliability on concrete data. It's tempting to consider SLOs to be a purely operational concern, but for them to function correctly as a signal for prioritization of engineering work, your reliability targets must be set in conjunction with engineering and product teams. Everyone must agree that the target accurately represents the desired experience of your users.

13 of 98

「信頼性が高い」って？

Netflix, Google 検索, Gmail, Twitter を思い浮かべてみて…

サービスがちゃんと「動いてる」って、どうやって見分ける？

https://cre.page.link/art-of-slos-slides

ゴール: 「信頼性」とはなにかについて参加者全体で議論する

インストラクター: 議論を進めるにあたっていくつか方法を考える

例を1つあげる。たとえばGoogle検索で検索結果を見て答えがありそうなページを開いてみる
各テーブルで1つずつ提案してもらう
大量に提案をもらった場合は「可用性」「レイテンシー」「品質」といった共通のテーマを抜き出す。できれば参加者に見つけてもらうのが良い。
最後に「こうした有名なサービスが期待通りの動作をしていない場合、どれくらいの頻度であれば我慢できますか？」などと聞いてみる

セリフ:

「信頼性」という言葉をインターネットサービスの文脈で使う場合にどのような意味でつかいますか。

サービスが「うまく動作している」あるいはもっと単純に「動いている」ということが何を意味しているのか、少し話し合ってみましょう。

何ができなければいけないか
どんな要素が重要か
サービスの反応に対するあなたの期待値は？

14 of 98

0 ms

300 ms

200 ms

お客様

“HTTP GET / …”

うーむ

目標

契約

https://cre.page.link/art-of-slos-slides

ゴール: SLOとSLAについての違いを知る。SLOは組織内で優先順位付けをするためのものであると話す。

ポイント:

同意（Agreement）はユーザーが離脱しないようにするだけ
目標（Objective）は同意よりも厳しく
目標はユーザーが期待する体験を表すものであるべき
目標の違反にも報いがなければならない

セリフ:

If your service has paying customers, you probably have some way of compensating them with refunds or credits when that service has an outage. Your criteria for compensation are usually written into a Service Level Agreement, which describes the minimum levels of service that you promise to provide and what happens when you break that promise.

The problem with SLAs is that you're only incentivized to promise the minimum level of service and compensation that will stop your customers from jumping ship to a competitor. Customers often feel the impact of reliability problems before these promises are breached, falling far short of the levels of service that keep your customers happy and contributing to a perception that your service is unreliable.

Compensating your customers all the time can get expensive, so what targets do you hold yourself to internally? When does your monitoring system trigger an operational response? To give you the breathing room to detect problems and take remedial action before your reputation is damaged, your alerting thresholds are often substantially higher than the minimum levels of service documented in your SLA. SLOs provide another way of expressing these internal reliability targets.

For SLOs to help improve service reliability, all parts of the business must agree that they are an accurate measure of user experience and to use them as a primary driver for decision making. Your customers probably don't need to be aware of them, but they should have a measurable impact on the priorities of your organization. Being out of SLO must have concrete, well-documented consequences, just like there are consequences for breaching SLAs. For example, slowing down the rate of change and directing more engineering effort towards eliminating risks and improving reliability will get you back into SLO faster. Operations teams need strong executive support to enforce these consequences and affect change in your development practice.

15 of 98

ついてきてる？

https://cre.page.link/art-of-slos-slides

16 of 98

どういうときにもっと高い信頼性が�必要になるんだろう？

https://cre.page.link/art-of-slos-slides

ゴール: 目標値とエラーバジェットについて質問の形で次のセクションを紹介する

ポイント:

＜スライドの文字を読む＞ ⇒ 「信頼性が十分」とはどういう状態か？

セリフ:

SLOを見る方法の一つがこの質問に答えるにあたって役に立つかもしれません。

「いつサービスをより信頼性高くする必要があるだろうか」

しかし実際に、問題は「どこで線を引くべきか？」です。

これまで、SLOは実質SLAが保証する信頼性よりも高いものであるべきだ、という話をしてきました。

これは広告収益で賄っている、ユーザー向けにSLAを持たない多くの「無料」サービスでは役に立ちません。

では信頼性はいつ「十分に高くなる」のでしょうか。目標値からの差分はどう測るのでしょうか。そして目標値に達していなかった場合にはどうしたらよいのでしょうか。

17 of 98

100%

基本的にどんなときでも 100% は誤った信頼性の目標です

— Benjamin Treynor Sloss, VP 24x7, Google; Site Reliability Engineering, Introduction

https://cre.page.link/art-of-slos-slides

Goal: Rationalize an acceptable level of failure.

Points:

Even things like pacemakers are not 100% reliable
Each nine is 10x more cost for 10x less benefit

Words:

You might think that you want to set your targets as high as possible, to serve your users as best you can. But no! The key realization that Ben Treynor Sloss, the founder of SRE at Google, had was that 100% is the wrong reliability target for almost everything^[1]. This is even true for supposedly reliable things like pacemakers, which, according to a paper^[2] published in 2005, had an average reliability of around 99.6% between 1990 and 2002! Making a service more reliable requires increasing commitments of both engineering time and operational support, for ever-decreasing improvements to overall reliability. At some point before you reach 100% reliability, that tradeoff is no longer worth making because the costs outweigh the benefits.

But how do we figure out where the optimal target is? In Google's case, we came to the conclusion that if we aimed to be slightly more reliable than the top consumer ISPs, our users would be substantially more likely to attribute random errors to failures at their ISP. Going back to our discussion of what "reliable" is: how do you normally check whether your internet connection is working? For most people the answer will be "load the Google homepage" or "ping 8.8.8.8".

[1]: https://landing.google.com/sre/interview/ben-treynor.html

[2]: "Pacemakers malfunction less often than defibrillators". AORN Journal. 82: 862. 2005—via https://en.wikipedia.org/wiki/Pacemaker_failure

18 of 98

SLO は、ギリギリ達成できればサービスの典型的なお客様が満足するような、性能や可用性のレベルにすべき

「SLO を満たしている」 ⇒ 「お客様は満足している」

「お客様が不満になる」 ⇒ 「SLO を満たしていない」

https://cre.page.link/art-of-slos-slides

Goal: Describe the concepts underlying the happiness test.

Points:

SLO is the dividing line between happy / unhappy users
Beware of over-aggregation, your users are not all the same

Words:

We have a simple rule of thumb for where SLO targets should be, that generalizes the case: a typical user of your service should be just about happy with the service, when it operates at those targets. If the service was any less reliable, you'd no longer be meeting their expectations and they would start to become unhappy. We call this the "happiness test".

The challenge is quantifying and measuring that happiness, because measuring it directly tends to require the kind of invasive medical procedures that customers are unwilling to consent to. It's bad if you're meeting all of your SLOs and customers are unhappy. You have to make sure you're thinking about all groups of your customers: mobile, desktop, different geographies, etc. The impact of an outage may not be spread equally but SLOs are generally aggregates across your user base; if one customer is getting all of your error budget, they will probably not be happy.

One particular group of users you may need to treat differently are those who work at your company. They'll often have insights into the operation of your services that others might not. This may cause them to behave in unexpected or downright strange ways from the perspective of your service, especially if they're granted early access to new features for testing purposes.

19 of 98

SLO を測って目標をわずかに超えるようにがんばる...

目標

SLI

https://cre.page.link/art-of-slos-slides

20 of 98

…でも高くしすぎない。ユーザーがそれに頼ってしまう

"Workflow", Randall Munroe, XKCD

Source: https://xkcd.com/1172/

目標

!

SLI

https://cre.page.link/art-of-slos-slides

ゴール: 暗黙的なSLOという幻影を取り除く

ポイント:

信頼性を高くしすぎるとユーザー体験がそこで固定される
それがただ運が良かっただけなら、いつか問題となる

セリフ:

最悪なのは、SLOに対して過剰に達成し続けると、ユーザーはいずれその信頼性を常に期待するようになってしまうことです。

これが起きる原因としてよくあるのは、稀だけどダメージが有るイベントをSLOの目標値に入れることのリスクを懸念することです。

運用がきちんと行われたことと運が良かったことが続いて、こうしたイベントが長期間発生しなければ、最終的にこうしたイベントが起きたときにかなり印象が悪くなるでしょう。

自らは知り得ない暗黙的なSLOのようなものに対するユーザーの期待値は、予期せず不満が聞こえ始めるまではわからないものです。

（「ハイラムの法則」も参照のこと→日本語訳）

ハイラムの法則では、APIのユーザ数が十分に多い場合、APIのすべての動作(公的契約の一部として定義されていないものであっても)は、最終的に誰かに依存するようになるということを述べています。些細な例としては、APIの応答時間などの非機能要件が挙げられます。もっと微妙な例は、APIのエラーのタイプを判断するために、エラーメッセージに正規表現を適用することに依存しているユーザかもしれません。API の公開契約ではメッセージの内容について何も記述されておらず、ユーザーがメッセージではなくエラーコードを使用すべきでと明示していたとしても、一部のユーザーがそれを無視してメッセージを使用する可能性があり、メッセージを変更することでそのようなユーザーのための API が本質的に壊れてしまうことになります。

21 of 98

エラーバジェット

SLO は許容可能なレベルの信頼性の欠如を意味する

これは割り当てることができる予算になる

https://cre.page.link/art-of-slos-slides

ゴール: 許容できる不信頼性を予算として使う方法を説明

セリフ:

信頼性100％を目指すわけでなければ、暗黙的に幾ばくかのエラーがユーザーに提供されてしまったとしても良いということです。

SLOの目標値がサービスの信頼性に不満を持ち始める基準値だという点で皆が合意できれば、理論的にはそれより少ない領域でのエラーを提供してもユーザーの幸福度に影響を与えることはありません。たとえば、スリーナイン（99.9%）の目標値があった場合、1000リクエストにつき1回のエラーは配信しても構わないということになります。あるいは完全なダウンタイムで考えた場合は、4週間の周期のうち40分は使えなくても大丈夫ということになります。

SLOを受動的に計測し、エラーが受動的にしきい値を超えてしまう可能性をただ気にして過ごすよりも、許容できる不信頼性を予算として活用し、さまざま開発や運用の活動に利用できます。

22 of 98

実装のしくみ

決められた期間(例: 28 日)における SLO のパフォーマンスを評価

残った予算がエンジニアリング作業の優先順位を決める

https://cre.page.link/art-of-slos-slides

ゴール: SLOをエラーバジェットに変換する際の計測ウインドウの役割を説明する

ポイント:

SLOの目標値をエラーバジェットに変更するにはウインドウが必要
カレンダーウインドウかローリングウィンドウ
28日間、ちょうど4週間を推奨する。これによって週次リリースや週末の影響をうけない

セリフ:

信頼性目標からのパーセンテージを

Figuring out how much budget you've got available from a percentage reliability target means specifying a time window for the events your SLI is measuring. Within Google, we often use fixed, quarterly SLO windows for reporting purposes, and we've seen this pattern at many of our customers’ too. The problem with fixed, calendar-oriented windows is they refill your error budget in one large step as the window rolls over. This makes them unsuitable for operational purposes—your customers are still going to remember yesterday's massive outage on the first day of the new quarter, but your budget has been reset, so everything's fine, right?

Instead, we use shorter rolling windows to drive decisions about operational priorities. Cloud services use a 30-day rolling window, but we generally recommend 28-day rolling windows for new SLOs. Since it's exactly 4 weeks, there's no variation introduced by having five "release days" within the window when you are doing weekly software releases, or five weekends within the window. We also use very short-term rolling windows like 1 or 12 hours to drive alerting—if you burn multiple hours of error budget within an hour, you can be relatively certain that an operational response is necessary!

Once you've decided on the time window, you count the number of events within that window. Multiplying this by the SLO target yields the absolute minimum number of good events that must be served within the window to meet the SLO, which in turn tells you the allowable number of bad events—the error budget. When you subtract the actual number of bad events, you know how much error budget you have remaining. This is a key signal to feed into your project planning cycle: if you have plenty of budget to spare, you can take more risks and move faster, but if you've already used most of your budget, that's a signal that you need to start prioritizing and fixing those pesky bugs instead of building that cool new stuff. If you are way over budget, your users are unhappy and you urgently need to start trading feature velocity for reliability work.

23 of 98

ITIL での近似

SLO を満たしている → ほとんどの運用作業は標準的な変更

SLO を満たさなくなりそう → 通常の変更に戻す

(ごめん、「標準的」と「通常」の違いすらわからない…)

https://cre.page.link/art-of-slos-slides

Goal: Relate error budget mechanics to ITIL change management.

Words:

For those of you coming from more structured environments, we've found this approximation works well when trying to fit SLOs into the world of ITIL change management. When a service is in SLO, the developers and operators have much more leeway to make changes to the service without going through potentially lengthy review and approval processes, something ITIL calls a "standard change". If the service is running low on error budget and looks like it may exhaust it in the near future, those processes kick back in again to catch any changes that might result in burning the rest of the budget. Confusingly, ITIL calls this "normal change".

24 of 98

エラーバジェットは�何に使えばいいの？

https://cre.page.link/art-of-slos-slides

25 of 98

エラーバジェットは

新しい機能のリリース
予定されたシステムの変更
避けられないハードやネットワークの障害
計画停止
リスクの高い実験

などに使える

https://cre.page.link/art-of-slos-slides

ゴール: エラーバジェットの利用方法を列挙

セリフ:

Googleではエラーバジェットを消費する2つの最大の要因はソフトウェアのリリースと設定の変更です。

これが私たちがよく、エラーバジェットを最後まで使って、サービスが復活してSLO以内になるまでは本質的でない変更の追加はペースを緩めるか完全にやめることを勧めている理由です。

もちろん、何かが単に壊れることもありますし、そうした緊急事態や不測の事態に備えてエラーバジェットに遊びを設けておくことも大事でしょう。

本質的なメンテナンスのためにサービスを止めなければならない場合は、エラーバジェットを使って止めることもできるでしょう。ダウンタイムがあることを事前にお知らせしておけば、ユーザーはそれを知っているので、突然実施するよりは不満は持たないかもしれませんが。

最後に、有用な使い方としては実験があります。理想的には、SLOの目標値が満足と不満足の境界にあることです。しかしどうやってそれが正しい場所にあるかを知るのでしょうか。もしユーザーの満足度を測るゲージを思いついたら、それをテストするための実験をすると良いでしょう。

たとえば、ユーザーの一部はちょうどSLOになるように振る舞いを変更して、その満足度のメトリクスが下がるかどうかを観察するのです。

26 of 98

開発チームが自己管理するようになる�エラーバジェットは開発チームにとっても貴重な資源になる
システム稼働時間に対する責任を共有する�インフラ障害もエラーバジェットを消費する

開発と SRE の共有のインセンティブになる�イノベーションと信頼性のいいバランスを見つけられる
開発チームが自分でリスクを管理できる�エラーバジェットをどう使うかを開発チームが決める
非現実的な信頼性の目標は魅力的でなくなる�そういう目標はイノベーションの速度を落とす

エラーバジェットの利点

https://cre.page.link/art-of-slos-slides

27 of 98

まだついてきてる？

https://cre.page.link/art-of-slos-slides

28 of 98

演習

信頼性の原則

https://cre.page.link/art-of-slos-slides

29 of 98

社員のみなさんへ

先日のシステム障害に対する否定的な報道をうけて、私たち全員が、サービスの信頼性についてもっと真剣に受け止める必要があると確信しました。

この公開書簡では、将来のみなさんの正しい意思決定を促すために、信頼性に関する 3 つの原則を示したいと思います。

https://cre.page.link/art-of-slos-slides

Aim to spend about 10 minutes on this activity in the classroom.

The audience plays the part of Eleanor Exec, the CEO of a company who just suffered a major outage of their services. They must choose the "right" reliability principle in three different contexts from a list of available options.

It's probably best if you read the slide text out yourself, to ensure (a) there's enough time for people to read it themselves if they want to, or (b) that they have some idea of the text if they can't read it for some reason.

Suggested approach:

If you're running short on time, just ask the room for a show of hands for each slide.

If you've got plenty of time to spare, try this:

Ask the tables to decide amongst themselves which of the options they'd choose.

Stress that there's no need to reach a consensus at the table.

Choose a table that hasn't yet volunteered an opinion.

Ask which option they thought was the correct choice and why.
Ask if they reached consensus.
If they didn't reach consensus, ask who disagreed and get them to explain their choice.

Ask for a show of hands from the other tables to see if anyone else disagreed with their choice.

Ask any dissenters why they thought a different approach was better.

Ask if anyone had different reasons for choosing the same option.

Note: I have tried to make sure that most of the options seem plausible to provoke discussion in the workshop, but my take on the "right" answers would be 3, 5, 2. It doesn't really matter if they choose the same "right" answer as the one I had in mind, as long as they can justify their answer well.

30 of 98

信頼性に対して財政的なコミットをすることで、ユーザーの信頼を取り戻す必要があります。
ユーザーが将来のシステム障害を許容、あるいは楽しめるような方法を見つける必要があります。
機能を追加する以前に、信頼性に対するユーザーの期待に応える必要があります。
ユーザーを幸せにする機能をもっと早く作る必要があります。
今後二度と障害を起こすようなことがあってはなりません！

最初の原則は、ユーザーに関することです。私たちは今回ユーザーを失望させてしまいましたが、ユーザーはもっと優遇されるべきです。ユーザーは、私たちのサービスを利用したら、幸せになるべきなのです！

私たちのビジネスは...

https://cre.page.link/art-of-slos-slides

Proposed "right" answer: 3. It's a bit generic but it most closely matches what we teach.

1: It's entirely rational for a business to decide it needs SLAs, but making every outage, however minor, an SLA violation could get expensive—this is why we suggest having SLOs as well as SLAs!

2: This tries to keep users happy but doesn't actually say anything about improving reliability.

"tolerate" might also be interpreted to include things like graceful degradation, which is a good choice for improving perceived availability at the expense of quality.

4: This is contrary to our observation that a major source of outages is feature iteration speed and system change.

5: This is contrary to the SRE maxim that "100% is the wrong reliability target" but shows an admirable strength of conviction that may appeal to people.

31 of 98

短い反復で、早く失敗し、エラーを早期に発見する必要があります。
リスク軽減のため運用チームが新機能の設計を担う必要があります。
信頼性が高いことが確認できた場合にのみ、新機能を公開する必要があります。
制御された小さなステップでソフトウェアを構築してリリースする必要があります。
システムの信頼性が低い場合に、機能リリースの頻度を下げる必要があります。

2番目の原則は、サービスの構築方法に関するものです。信頼性を組み込むために、開発プロセスを変更する必要があります。

私たちのビジネスは...

https://cre.page.link/art-of-slos-slides

32 of 98

運用チームと開発チームが信頼性の責任を共有する必要があります。
運用作業とチームの優先順位を信頼性の目標に結び付ける必要があります。
運用負荷を削減するためにシステムをより強固にする必要があります。
障害が発生するのを防ぐために、全リリースで運用チームに拒否権を与える必要があります。
Twitterでの否定的な苦情を運用チームに直接通知する必要があります。

3番目の原則は、私たちの運用の実践に関するものです。今日私たちがしていることはうまくいきません。運用チームが燃え尽きており、インシデント率が高すぎます。改善するには、別のやりかたで行う必要があります。

私たちのビジネスは...

https://cre.page.link/art-of-slos-slides

33 of 98

これらの原則を実践するために、Google からいくつかのアイデアを借ります。次のステップは、サービスの SLO をいくつか定義し、それらに対するパフォーマンスの測定を開始することです。

読んでくれてありがとう！

Eleanor Exec, CEO

https://cre.page.link/art-of-slos-slides

34 of 98

休憩！

https://cre.page.link/art-of-slos-slides

35 of 98

いい SLI を選ぶ

https://cre.page.link/art-of-slos-slides

36 of 98

https://cre.page.link/art-of-slos-slides

Goal: Understanding the happiness of your users means measuring their experience as directly as possible.

Points:

Approximate measures of user happiness from your service metrics
Measure from the perspective of your users

Words:

Our happiness test says that an SLO should represent the dividing line between happy and unhappy users. But we can't measure that happiness directly, so we have to find some way of approximating the happiness of our users with metrics we can directly measure. We start by restating CRE's second principle: users become unhappy when the service they are trying to use doesn't behave the way they expect it to.

This means that if you want to understand the reliability of your service, you have to measure its performance from the perspective of your users. It doesn't matter if it's your database being down or your load balancers sending requests to bad backends: from the user's perspective these conditions all collapse to "the website does not load, and I am now sad". Similarly, it doesn't matter which component of the system is overloaded, the user's complaint is "the website is slow, and I am now sad".

If we can find a way of quantifying "the website does not load" or "the website is slow" from our monitoring data, we can tell how unhappy our users are in aggregate.

37 of 98

time

不満なユーザー

https://cre.page.link/art-of-slos-slides

Goal: Distinguish bad vs good metrics.

Points:

Red area ⇒ increased support requests ⇒ more unhappy users
Maybe some already existing metrics correlate with outage?
Bad ideas: load average, cpu or memory utilization, thread-pool fullness, queue length

Words:

To show how this works in practice, let's consider the interval highlighted in red, where we know our users were unhappy, because we saw many more support requests during that time.

You might be wondering why we can't use "requests for support" as an SLI directly. There's a few reasons:

First, it's a trailing indicator: while it does accurately measure "unhappy users", it's of no use if we want to proactively prevent those users from becoming unhappy.
Second, many users who are unhappy with a service will silently stop using it because the burden of filing a support ticket is too high. We need to capture these users in any SLI we create.
Third, users don't need support when the service is working correctly. This means we get no signal at all from this SLI most of the time, so we can't base an error budget on it.

But we've got plenty of monitoring metrics we're already collecting about our services! Maybe some of those changed during this time period, and we can use them as SLIs?

Like most of you, we've got system metrics like load average, CPU utilization, memory usage, and bandwidth graphed and visible on our monitoring dashboards. Sharp changes in these are often associated with outages, but they don't make for good SLIs. If you think about it from the perspective of your users, they don't directly see your CPUs pegged at 100%, they see your service responding slowly. The same goes for internal service metrics like threadpool fullness or request queue length.

38 of 98

時間

指標

BAD

GOOD

https://cre.page.link/art-of-slos-slides

39 of 98

時間

指標

上下していて指標の悪化がわかりにくい

指標

BAD

GOOD

https://cre.page.link/art-of-slos-slides

40 of 98

時間

指標

指標の悪化がサービスで起きる問題と相関する

指標

時間

BAD

GOOD

https://cre.page.link/art-of-slos-slides

41 of 98

時間

指標

指標の S/N 比が悪い

指標は良好な�S/N 比を示す

指標

?

✓

BAD

GOOD

https://cre.page.link/art-of-slos-slides

Goal: Distinguish bad vs good metrics.

Points:

SLIs must provide clear definition of good and bad events
Variance in bad metric makes distinguishing good events from bad a challenge

Words:

This matters because SLIs need to provide a clear definition of good and bad events, and a metric with lots of variance and poor correlation with user experience is much harder to set a meaningful threshold for. Because the "bad" metric has a large overlap in the range of values, our choices are to set a tight threshold and run the risk of false-positives, or to set a loose threshold and risk false-negatives. Worse, choosing the middle ground means accepting both risks. The "good" metric is much easier to set a threshold for because there is no overlap at all. The biggest risk we have to contend with is that perhaps the SLI doesn't recover as quickly as we might have hoped for after the outage ends.

42 of 98

SLO

SLI

https://cre.page.link/art-of-slos-slides

43 of 98

SLI :

良いイベント

有効なイベント

× 100%

https://cre.page.link/art-of-slos-slides

Goal: Express SLIs like this!

Points:

SLI equation has useful properties

Intuitive
Translates to percentage reliability SLO targets
Consistent format makes building tooling easy

The term "valid" implies that known-bad events are excluded from SLI

Words:

We generally recommend that you express your SLIs as the proportion of a set of events that were considered to be "good".

Expressing all your SLIs in this form has a couple of useful properties. First, your SLIs fall between 0% and 100%, where 0% means nothing works and 100% means nothing is broken. This scale is intuitive and directly translates to percentage-reliability SLO targets and error budgets.

Second, your SLIs have a consistent format which can serve as an interface for abstraction. Consistency allows common tooling to be built around your SLIs. Alerting logic, error budget calculations, and SLO analysis and reporting tools can all be written to expect the same inputs: good events, valid events, and your SLO threshold.

But what do we mean by "valid" and why don't we use "all events" in the SLI equation? Sometimes you may need to exclude some events recorded by your underlying metrics from being included in your SLI, so they don't consume your error budget. A good example here might be ignoring 300 and 400 HTTP response codes as irrelevant to your service's SLO performance. This phrasing allows you to make this exclusion explicit and specific by declaring those events to be "invalid".

44 of 98

3–5 SLIs^*

^* ユーザージャーニーあたり

https://cre.page.link/art-of-slos-slides

Goal: 3-5 SLIs per user journey. (Obvious but included for consistency.)

Points:

A "user journey" is the set of interactions a user has with a service while achieving a single end result

Similar to Critical User Interactions (CUIs) from user experience (UX) research

SLIs tell you something is wrong—you need other monitoring systems to tell you what

Words:

It may be tempting to rush off and start looking at which metrics might make good SLIs for your services, but we've got one more recommendation for you first.

In general, your users are using your service to achieve some set of goals, so your SLIs must measure their interactions with your service in the pursuit of those goals. We're going to call a set of interactions to achieve a single goal a "user journey"—a term we've borrowed from the field of user experience research. You may also have heard people talk about CUIs, or Critical User Interactions. You should aim to have around 3-5 SLIs covering each user journey, even if your system and your user journeys are relatively complex. A service with too many SLIs places an additional cognitive burden on the people operating that service, especially if those SLIs start to contradict each other.

We're not recommending you ditch all your other monitoring and observability systems once you've started measuring SLIs. The way we think about it is that a deterioration in your SLIs is an indication that something is wrong. Once that problem has become bad enough to provoke some form of incident response, you'll need those other systems to debug and help you figure out what that is.

45 of 98

SLO

SLI

https://cre.page.link/art-of-slos-slides

46 of 98

ビジネスの視点からみて

どれくらいの�パフォーマンスが

必要だろう？

https://cre.page.link/art-of-slos-slides

Goal: SLOs that represent business requirements.

Points:

"Aspirational" SLO targets should represent the long-term reliability needs of the business

Words:

The ideal is that your reliability targets reflect the needs of your business. As we said earlier, being too reliable has a cost—if your service is amazingly reliable but your users would be happy with two nines because its failure modes are acceptable, maybe that means you can take more risks and ship features faster. Not being reliable enough is often more costly: what if the only thing keeping your users with you is that your competitors reliability is even worse than yours—for now!

We call SLOs based on a business need "aspirational SLOs", because it's entirely reasonable for you to not be able to meet them initially. Over time, with some engineering effort, this is the level of reliability that your operations, development, product and executive functions want to reach, that represents your best guesses at what level of reliability is right for your services, customers and business over the long term.

47 of 98

ユーザーの期待は

過去のパフォーマンスに

ものすごくひっぱられる

https://cre.page.link/art-of-slos-slides

Goal: Start with historical data if you have it.

Points:

"Achievable" SLO targets are based on already-existing data
Past performance is not indicative of future reliability

Words:

But if you have or can derive historical data for your SLIs, we recommend that you look at this data and base your first SLOs on the past performance of your service. Starting from this point means you can be reasonably sure of your ability to meet the SLO over the short-to-medium term. If your users are happy enough with your service at the moment, you can be reasonably sure that this SLO is not set too low.

We call SLOs based on past performance "achievable SLOs", since you should not set the SLO threshold such that you cannot expect to meet it most of the time. Just remember that past performance is not indicative of future reliability—the data you're basing your judgements on may not be representative of the long term reliability achievable by your service.

The difference between these two targets is a useful signal. If the business needs better performance than what your service is currently capable of achieving, that's kind of a problem. But it's common for there to be some divergence when you're just setting out on your SLO journey.

48 of 98

?

継続的な

改善

https://cre.page.link/art-of-slos-slides

Goal: SLOs are not fixed, iterate on them over time.

Points:

Making different assumptions:

Aspirational ⇒ business thinks this will keep users happy
Achievable ⇒ current performance keeps users happy

Regular SLO reviews create a feedback loop to drive convergence
This requires an external signal of user happiness, e.g. support requests or social media

Words:

What's needed is some way to drive convergence between the two targets over time. Aspirational SLOs are best guesses at what the business thinks makes the user happy, and achievable SLOs are making the assumption that current performance makes the user happy. To validate these assumptions, you need to find some external signals that indicate the happiness or discontent of your user base. Good examples of these are support requests, forum complaints, and Twitter.

Understanding any discrepancies between these signals of user happiness and your SLOs, particularly instances where your users were sad but you were still in SLO, will help you refine your SLO targets. Significantly overperforming your SLO means that you have error budget to spend—maybe you could safely take more risks. Significantly underperforming your SLO may mean that you're taking too many risks, or—if your users are happy—you should relax your SLO targets.

When you're just starting out, checking your SLOs against these signals more frequently is a good idea. You don't want to wait a whole year to find out that the first shot at setting reliability targets was way off! As you gain more confidence that your targets are in the right place, you can revisit them less frequently, but we recommend doing so at least once a year. A lot can happen in a year: your user base may grow dramatically or your business might pivot to new markets with different requirements.

49 of 98

おなかいっぱい？

https://cre.page.link/art-of-slos-slides

50 of 98

SLO と SLI を作る

https://cre.page.link/art-of-slos-slides

51 of 98

?

https://cre.page.link/art-of-slos-slides

Goal: Who are your users?

Points:

Explain what's coming:

Introduce game
Walk through process once
After lunch, you do this with other user journeys

Developing SLIs ⇒ think carefully about users’ expectations

Words:

In this workshop, we're going to figure out some SLOs and SLIs for the server-side architecture supporting a mobile game. In the next 30 minutes, we will introduce you to our example game. We'll walk you through our process for developing SLOs and SLIs for one simple user journey, then we'll be turning the tables and expecting you to go through the same process to develop more SLOs for the game, which cover more complex and realistic user journeys.

When we develop SLOs and SLIs for this game, we have to think carefully about who the users are, how they interact with that service, and what expectations they have about its reliability. As we said earlier, they'll have a set of goals they want to achieve, and they'll get sad when they can't achieve those goals.

52 of 98

みんなのゲーム: Fang Faction

Web サーバー

API サーバー

リーダーボード

プロファイル

ゲーム�サーバー

リーダーボードの�生成

ロード

バランサー

https://cre.page.link/art-of-slos-slides

Goal: Introduce the game.

Points:

Game background and technical details:

2 data stores, user profiles and leaderboards
Pool of game servers with their own databases
API servers and web servers behind L7 load balancer
JSON-RPC, REST, web socket connection for game-state updates

Words:

Each of those goals involves one or more interactions with our game's serving infrastructure. You can find a copy of this diagram along with information about the game in your handout.

In the game, players build and manage a post-apocalyptic settlement, recruit survivors to their faction, and wage war on other players. Like many games, it makes revenue by selling in-game currency for real world money, which players can then use to skip time gates, upgrade buildings and get more recruits.

The serving infrastructure is relatively simple. There are two data stores, a set of API servers and web servers, and a set of game servers with their own databases all sitting behind a layer 7 HTTP load balancer. The game has both a mobile client and a web UI. The mobile client makes requests to our serving infrastructure via JSON RPC messages transmitted over RESTful HTTP. It also maintains a web socket connection to receive game-state updates. Browsers talk to the web servers via HTTPS. Leaderboards are updated every 5 minutes.

Notes for presenter:

This example and a lot of the accompanying advice comes from the chapter on SLOs from the Site Reliability Workbook. There's a lot of good background reading there!

We will return to this diagram a couple of times in the deck. It is strongly suggested that you see these as natural pause points, where you ask the audience questions instead of talking to them.

53 of 98

SomeUser のプロファイル

SomeUser

かえる族�Faction Score: 31337

Midwest Canyon

https://fangfactiongame.com/profile/someuser

チーム:	かえる族
リーダー:	SomeUser
メールアドレス:	user@example.com

更新

1.

2.

3.

4.

5.

6.

Tri-Bool 65535

Tri Repetae 61995

Triassic Five 52391

Tricksy Hobbits 37164

かえる族 31337

Trite Examples 29243

https://cre.page.link/art-of-slos-slides

Goal: Introduce "loading user profile" journey.

Points:

Slide shows:

Mock-up of a user's profile page
Sequence diagram of interactions to load page

Sequence diagram is also on page 18 of handout
Ask: What are user's expectations when they try to load this page?

Words:

I'm sure you can imagine a number of user journeys for this game. We're going to keep things simple for now, so we can step through the process without too many complicating factors, but you'll find some more complex journeys in your handout.

Our game allows players to log into their account via a web browser and keep track of their settlement while they aren't actively playing on their device. Here you can see a mock-up of what a player sees when they are logged into the game's website and open their profile page. On the right is a sequence diagram showing the requests and responses involved in serving this page to them. You can also find this on page 18 of your handout. The dotted lines are requests that are not observable from our serving infrastructure. What do you think their expectations are for this page? What would disappoint them, and make them think the service is not reliable?

Notes for presenter:

The players are probably going to expect things like:

The page loads in a reasonable time
They see their avatar image
They see their leader name, faction name and email address
They see the high scores for the area they're in
The CSS loads properly so the page looks right

54 of 98

プロファイルページの読み込み

Web サーバー

API サーバー

リーダーボード

プロファイル

ゲーム�サーバー

リーダーボードの�生成

ロード

バランサー

https://cre.page.link/art-of-slos-slides

55 of 98

SLI Menu

リクエスト / レスポンス	可用性レイテンシー品質
データ処理	カバレッジ正確性鮮度スループット
ストレージ	スループットレイテンシー

https://cre.page.link/art-of-slos-slides

56 of 98

可用性

レイテンシー

プロファイルページの読み込みに成功する

プロファイルページの読み込みが速い

https://cre.page.link/art-of-slos-slides

57 of 98

可用性

レイテンシー

成功をどう定義するか
成功/失敗はどこに記録されるか

速さをどう定義するか
タイマーはいつ開始/停止するか

プロファイルページの読み込みに成功する

プロファイルページの読み込みが速い

https://cre.page.link/art-of-slos-slides

58 of 98

可用性

レイテンシー

有効なリクエストのうち、しきい値よりも速く処理された割合

有効なリクエストのうち、正常に処理された割合

成功をどう定義するか
成功/失敗はどこに記録されるか

速さをどう定義するか
タイマーはいつ開始/停止するか

プロファイルページの読み込みに成功する

プロファイルページの読み込みが速い

https://cre.page.link/art-of-slos-slides

59 of 98

可用性

レイテンシー

有効なリクエストのうち、しきい値よりも速く処理された割合

有効なリクエストのうち、正常に処理された割合

成功をどう定義するか
成功/失敗はどこに記録されるか

速さをどう定義するか
タイマーはいつ開始/停止するか

プロファイルページの読み込みに成功する

プロファイルページの読み込みが速い

https://cre.page.link/art-of-slos-slides

60 of 98

可用性

レイテンシー

/profile/{user} に対する HTTP GET リクエストのうち、しきい値よりも速く処理された割合

/profile/{user} または /profile/{user}/avatar に対する HTTP GET リクエストのうち、正常に処理された割合

成功をどう定義するか
成功/失敗はどこに記録されるか

速さをどう定義するか
タイマーはいつ開始/停止するか

プロファイルページの読み込みに成功する

プロファイルページの読み込みが速い

https://cre.page.link/art-of-slos-slides

Goal: Refining SLIs from specification to implementation.

Points:

Avatar included for availability, excluded for latency

Avatar latency is likely to be higher and more variable than
Bimodal latency distribution

Suggested words:

Here I've chosen to include avatar images in the availability SLI, but exclude them from the latency SLI.

Avatar images are uploaded by users and we don't know how large they'll be. We can realistically assume that images take longer to load than HTML. This means that including avatar image latency into our SLI would make the underlying latency distribution bimodal and introduce a lot of variance.

If you remember what we talked about earlier, this could cause problems when we're trying to set a latency SLO target, because we can't accurately target just one of the two loading times. Our users might be unhappy with a 500ms increase in page loading time, but that could still be less than the average time it takes to serve an avatar image, which they're still happy with in aggregate. Since the page is still broadly usable even before the avatar image loads, page loading time is the metric we care about more, so that's what we'll base our SLI on.

61 of 98

可用性

レイテンシー

/profile/{user} に対する HTTP GET リクエストのうち、しきい値よりも速く処理された割合

/profile/{user} または /profile/{user}/avatar に対する HTTP GET リクエストのうち、正常に処理された割合

成功をどう定義するか
成功/失敗はどこに記録されるか

速さをどう定義するか
タイマーはいつ開始/停止するか

プロファイルページの読み込みに成功する

プロファイルページの読み込みが速い

https://cre.page.link/art-of-slos-slides

Goal: Refining SLIs from specification to implementation.

Points:

HTTP status codes are an easy definition of "success"
Latency threshold is often easier to set alongside SLO target

Words:

Next, we need to be more specific about what "successfully" and "quickly" really mean. Our company just wants to get something simple measured quickly, so we're going to use the HTTP status code as an indicator of success.

The latency threshold is a bit harder. If you've got historical data, it's common to choose the cutoff point where requests are too slow in tandem with the SLO target that specifies what percentage of requests are allowed to be slower than the cutoff.

Optional:

Conceptually, there's an inverse s-curve relationship between user happiness and response latency. The latency threshold describes a point on that curve, and the SLO target describes what proportion of requests must be below that threshold for your users to remain happy, effectively reducing the s-curve to a step function. It can be valuable to approximate the s-curve more accurately by setting a second SLO targeting broad-based latency instead of long-tail, e.g. 75% of requests < 200ms and 99% of requests < 1s.

62 of 98

可用性

レイテンシー

/profile/{user} に対する HTTP GET リクエストのうち、X ms の範囲内で処理されたリクエストの割合

/profile/{user} または /profile/{user}/avatar に対する HTTP GET リクエストのうち、ステータスが200番台、300番台または 400 番台 (excl. 429) を返す割合

成功をどう定義するか
成功/失敗はどこに記録されるか

速さをどう定義するか
タイマーはいつ開始/停止するか

プロファイルページの読み込みに成功する

プロファイルページの読み込みが速い

https://cre.page.link/art-of-slos-slides

Goal: Refining SLIs from specification to implementation.

Points:

X ms is a placeholder, the SLI is technically incomplete

We're going to choose the threshold based on historical data in the back page of the handout

Status codes can be substituted in:

429 is "Too Many Requests"

Still need to decide where to measure

Suggested words:

Since the company has historical data for this particular endpoint, that's what we're going to do here with this "X milliseconds" construct. That makes this SLI implementation incomplete—you need a threshold to convert the latency distribution to a binary good/bad signal. We'll be asking you to figure out what thresholds are appropriate in a bit!

Rather than enumerate every possible code for our availability SLI, we'll assume that any 500-class codes are bad, and exclude 429s from our "good requests" too because it's what our servers return to users when they're overloaded.

But there's still one piece of the puzzle missing. We haven't said how or where we're going to measure any of this!

63 of 98

SLI Menu

測定の戦略	アプリケーションレベルのメトリックスログ処理フロントエンドインフラのメトリックス人工的なクライアント/データクライアントサイドへの埋め込み

https://cre.page.link/art-of-slos-slides

Goal: SLI implementation is mostly measurement strategy.

Points:

Five broad measurement strategies, none perfect
Creating SLI implementation is a key engineering decision
Using more than one measurement strategy is valuable—they can be complementary

Words:

Broadly speaking, there are five ways to measure an SLI, and none of them are perfect. Your handout has some details about the pros and cons of each. Making an informed engineering decision on which measurement strategy to use, based on the current needs of your service, is an important part of refining your SLI specification into concrete implementation.

It's entirely reasonable to use more than one strategy for each specification. For example, you may choose to use real-time metrics from your load-balancing infrastructure to drive short-term operational response, but base your long-term SLOs on reconstructing user journeys from session IDs in server-side logs.

64 of 98

可用性

レイテンシー

ロードバランサーで測定した、/profile/{user} に対する HTTP GET リクエストのうち、X ms の範囲内にレスポンス全体を送信したものの割合

ロードバランサーで測定したステータスが/profile/{user} または /profile/{user}/avatar に対するすべての HTTP GET リクエストのうち、200番台、300 番台または 400 番台 (excl. 429) を返す割合

成功をどう定義するか
成功/失敗はどこに記録されるか

速さをどう定義するか
タイマーはいつ開始/停止するか

プロファイルページの読み込みに成功する

プロファイルページの読み込みが速い

https://cre.page.link/art-of-slos-slides

Goal: Refining SLIs from specification to implementation.

Points:

Sometimes we choose to trade off coverage and accuracy for ease of implementation.
These SLIs contain lots of explicit detail, and could be measured by a monitoring system.

Words:

In this case, the company decided the metrics provided by their load balancer were good enough to establish some initial SLIs without investing too much engineering effort. This is an entirely reasonable trade-off to make: your first SLIs are almost certainly going to need some improvement, so the sooner you start gathering data and begin the cycles of iteration, the better.

These final SLI implementations provide a lot of explicit detail about what exactly is being measured and how they are measured. If you give them to someone, they could actually build something that evaluates these metrics and gives you performance data!

65 of 98

演習

ポストモーテム

https://cre.page.link/art-of-slos-slides

66 of 98

可用性

レイテンシー

ロードバランサーで測定したステータスが、/profile/{user} または /profile/{user}/avatarに対するHTTP GET リクエストのうち、200番台、3XX または 4XX (excl. 429) を返す割合

および

5秒ごとに外形監視で測定される/profile/prober_user 及びリンクのある全てのリソースに対するHTTP GETリクエストのうち "ProberUser"を含む有効なHTMLを返す割合

ロードバランサで測定した、/profile/{user} に対する HTTP GET リクエストのうち、X ms の範囲内にレスポンス全体を送信したものの割合

https://cre.page.link/art-of-slos-slides

ゴール: カバレッジのギャップを埋める

ポイント:

合成クライアントに基づいた追加の可用性SLI

レスポンスのBodyに正しいデータが入っているか検証する
フロントエンド側のリクエストのルーティングとCDNへのリクエストもテストできる
これが唯一の方法ではないが、良い指標になっていると思う

Words:

The way we've chosen to close the monitoring gap identified in the postmortem is to augment the load balancer metrics with a black-box prober which inspects and verifies the response body, but this is by no means the only way. This prober also validates that our front-end infrastructure is doing the right thing with request routing, and tests that our CDN is serving content correctly—two other gaps in the previous SLI. We augmented the current SLI with another one because only using a prober would reduce the coverage of the SLO: probing for one specific user is not measuring the general user experience.

While we've not chosen to measure a latency SLI with the prober, doing so would be easy. We avoided this because unless we run our prober in multiple, disparate places far removed from our infrastructure (think Pingdom), it's a strictly worse measure than the one derived from the load balancer metrics, which covers all user requests rather than those just made by the prober.

67 of 98

SLI は障害モードを網羅している？

API サーバー

リーダーボード

プロファイル

ロード

バランサー

外形監視

可用性

レイテンシー

ゲーム

サーバー

リーダーボードの�生成

Web サーバー

https://cre.page.link/art-of-slos-slides

ゴール: ユーザージャーニーのおさらいをしてSLIがそれをカバーするか確認する

ポイント:

SLIは障害モードを「ユーザーの観点から」捕捉しなければいけません
SLIが障害に対して反応すること自体がどのように重要か考える
すべての障害に反応するようにするのは現実的ではないので、障害の影響とコストとの兼ね合いを良く考えるべき

Words:

This outage illustrates why you should take a critical look at your infrastructure when creating your SLIs.

When we're considering the failure modes of our infrastructure, we're trying to answer four questions:

Can we measure the SLIs we've created where we want to measure them, given this infrastructure?
Do the SLIs adequately capture the user journey and its failure modes?
Are there any exceptions or edge cases to consider?
Do the SLIs capture multiple journeys with differing requirements?

We say "adequately capture" because reaching 100% coverage of all possible failure modes is again the wrong target.

Distributed systems fail in complex and surprising ways, so 100% is an unrealistic goal. If the failure mode is sufficiently rare that it won't eat more than a fraction of your error budget, then it's reasonable to argue that it's safe for your SLIs not to capture it. Failure modes that are outside of your control, and your users are unlikely to blame you for, are best left out of your SLIs. Things like failures at consumer ISPs or mobile phone carriers would fall into this bucket—you can't do much about them, but in some cases, it can be useful for your support teams to know they have happened.

You also have to perform some form of cost-benefit analysis. In some cases, extending your SLI to cover a particular failure mode could cost months of engineering effort and require re-architecting your service, your monitoring systems, or both—when building detailed client-side instrumentation from scratch, for example.

Instructors:

Depending on time here, get the audience to think about whether there are other failure modes that might not be captured by the current SLIs. The journey, once more:

To render the page, the player's http request must be routed by the load balancer to one of the web servers.
The player profile is loaded from the user profile data store.
The user profile contains their current area and score.
The leaderboard for the player's area is loaded from the leaderboards data store.
The response is assembled and returned to the user's browser.
The browser then requests the avatar image, which is served via similar means.

68 of 98

演習

SLO の目標値を決める

https://cre.page.link/art-of-slos-slides

69 of 98

ジャーニーの信頼性の目標には何を設定しよう？

サービス	SLO の種類	目標
Web: プロファイル	可用性
Web: プロファイル	レイテンシー
...	...

過去 28 日で 99.95% 成功

過去 28 日でリクエストの 90% < 500ms

目標には目標値と測定期間の両方がないといけない

https://cre.page.link/art-of-slos-slides

70 of 98

まだ眠くない？

https://cre.page.link/art-of-slos-slides

71 of 98

休憩！

https://cre.page.link/art-of-slos-slides

72 of 98

ワークショップ: SLI と SLO を設定してみよう

これまでの手順に沿ってゲーム内通貨の購入ジャーニーに取り組もう:

メニューから SLI の仕様を選ぶ (冊子の 6 ページを参照)
定義を置き換えて詳細な SLI の実装を作る
ユーザージャーニーを順に追って網羅できているか確認する
ビジネス要件から野心的な SLO を設定する

もし終わったら、別のジャーニーにも取り組んでみる

45 分ぐらいでやってみよう

https://cre.page.link/art-of-slos-slides

Instructors: Having gone through the example app and the process, the workshop itself is basically making the people in the room repeat the process twice more for themselves, while providing advice / guidance. There are five more complex, example user journeys in the handout. The next slide shows the architecture diagram. Once you've explained the process you'll want to advance to that and leave it up for people refer to.

Instructions for facilitating workshop:

Print out many copies of https://cre.page.link/slo-worksheet-print and distribute them. Walk the group through the example in the worksheet if you think they need a refresher on the content from this deck.

Walk through the user journeys from the handout. If there are enough people, divide the audience into groups of 4-5 people and ask each group to tackle the "Buy In-Game Currency" journey first, because we have a model answer for it later in the deck. It should take roughly 40-45 minutes to set some SLIs for this journey. If there's time for a second journey—there should be if you're doing a full-day event, we budget 90m for the practical exercise—then they can choose another one at random.

For each journey, walk through picking SLI Types (the "SLI Menu" may be helpful here). For each SLI Type, fill out the template in the SLO Worksheet, refining the SLI specification into an implementation. Consider the journey and where the SLI may not cover failure modes of the infrastructure. Finally, set aspirational SLO targets. This last part is the least important, any number with a reasonable justification is perfectly fine.

73 of 98

みんなのゲーム: Fang Faction

Play

Store

Web サーバー

API サーバー

リーダーボード

プロファイル

ゲーム�サーバー

リーダーボードの�生成

ロード

バランサー

https://cre.page.link/art-of-slos-slides

74 of 98

休憩！

https://cre.page.link/art-of-slos-slides

75 of 98

ゲーム内通貨の購入

モデル解答

https://cre.page.link/art-of-slos-slides

76 of 98

ジャーニーの分解

5 つのリクエストとレスポンスのペア

APIサーバからSKUのリストをフェッチする
Play ストアからSKUの詳細を　フェッチする
ユーザーはPlayの課金フローを　　起動する
APIサーバにトークンを送信する
Playストアはトークンを確認する

1

2

3

4

5

https://cre.page.link/art-of-slos-slides

77 of 98

ジャーニーの分解

ジャーニーには 2 つの部分がある�A: SKU のフェッチ

APIサーバからSKUのリストをフェッチする
PlayストアからSKUの詳細を　フェッチする
ユーザーはPlayの請求フローを　　起動する
API サーバにトークンを送信する
Playストアはトークンを確認する

1

2

https://cre.page.link/art-of-slos-slides

78 of 98

ジャーニーの分解

ジャーニーには 2 つの部分がある�B: アイテムの購入

API サーバからSKUのリストをフェッチする
PlayストアからSKUの詳細を　フェッチする
ユーザーはPlayの課金フローを　　起動する
API サーバにトークンを送信する
Playストアはトークンを確認する

3

4

5

https://cre.page.link/art-of-slos-slides

説明:

ジャーニーの2番目のパートは、ユーザーが購入する特定のアイテムを選択した後に発生します。これにより、Play ストアの「請求フロー」がトリガーされ、アプリからデバイスの制御が奪われ、Play サービスのフレームワークに渡されます。 Play サービスのフレームワークは、クレジットカードの詳細を取得したり、Play ストアに問い合わせて、選択したアイテムの料金をユーザーに請求したりするなどの処理を行います。購入が成功した場合、請求フローはステータスコードを返し、また、注文 ID や購入トークンも返します。ユーザーが選択したアイテムをサーバーに付与できるように、サーバーは購入が成功したかどうかを知る必要があります。したがって、デバイスは completePurchase の API コールを介して注文 ID と購入トークンをサーバーに送信します。二重支出攻撃を防ぐために、ユーザーにアイテムを提供する前に、Play ストアで購入トークンを検証する必要があります

79 of 98

ジャーニーの分解

ユーザーはアイテムを購入しない　　　かもしれない :-(

APIサーバからSKUのリストをフェッチする
PlayストアからSKUの詳細を　　フェッチする
ユーザーはPlayの課金フローを　　起動する
API サーバにトークンを送信する
Playストアはトークンを確認する

この部分は別々に考えないといけない！

1

2

https://cre.page.link/art-of-slos-slides

80 of 98

ジャーニーの分解

2 つのリクエストはAPI サーバに　　　　全くヒットしない！

API サーバからSKUのリストをフェッチする
PlayストアからSKUの詳細を　フェッチする
ユーザーはPlayの課金フローを　　起動する
API サーバにトークンを送信する
Playストアはトークンを確認する

サーバーやロードバランサーのメトリックだとジャーニーを網羅できないかも :-(

2

3

https://cre.page.link/art-of-slos-slides

81 of 98

2

3

ジャーニーの分解

2 つのリクエストはAPI サーバに　　　　全くヒットしない！

API サーバからSKUのリストをフェッチする
PlayストアからSKUの詳細を　フェッチする
ユーザーはPlayの課金フローを　　起動する
API サーバにトークンを送信する
Playストアはトークンを確認する

サーバーやロードバランサーのメトリックだとジャーニーを網羅できないかも :-(

...クライアントから情報収集するならユーザーに同意を得ないといけない

https://cre.page.link/art-of-slos-slides

82 of 98

購入フロー

どのSLIを使う？

購入フローのジャーニーは

リクエスト/レスポンス

SLI メニューをみると

可用性とレイテンシの SLI

を使えばよさそうだ

https://cre.page.link/art-of-slos-slides

83 of 98

購入フローの可用性

仕様

Bは売上につながるので、そこから始めよう！

API サーバからSKUのリストを　　フェッチする
PlayストアからSKUの詳細を　　　　フェッチする
ユーザーはPlayの課金フローを�起動する
API サーバにトークンを送信する
Playストアはトークンを確認する

可用性SLI の仕様

正常に処理された有効なリクエストの割合

3

4

5

https://cre.page.link/art-of-slos-slides

84 of 98

購入フローの可用性

有効なリクエスト

可用性SLI

正常に処理された有効なリクエストの割合

… どのリクエストが有効なんだろう？

ユーザーはPlayの請求フローを

起動する

API サーバにトークンを送信する?
Playストアはトークンを確認する?

課金フローが開始されたってことは、ユーザーが購入する意志を示した、ということ

ユーザーがクライアントからの情報収集に同意してくれれば、その意志を捕捉できる

3

https://cre.page.link/art-of-slos-slides

85 of 98

購入フローの可用性

正常の基準

可用性SLI

情報収集に同意したユーザーが開始した課金フローのうち成功したものの割合

… 成功したことはどうやってわかる？

一連のやりとりが成功するってことだ！

良いステータスコード:購入トークン
良いステータスコード:口座情報更新
良いステータスコード:有効なトークン

トークンが無効な場合、APIコールに対して 402を返答する

3

4

5

https://cre.page.link/art-of-slos-slides

86 of 98

購入フローの可用性

測定

可用性SLI

情報収集に同意したユーザーが開始した課金フローのうち成功したものの割合

課金フローは以下を返す

OKおよび購入トークン
または FEATURE_NOT_SUPPORTED
または ITEM_UNAVAILABLE
または USER_CANCELED

/api/completePurchase は以下を返す

200 OKおよびパース可能なJSON
または 402 Payment Required

… でも、どこでそれを測定しよう？

3

4

https://cre.page.link/art-of-slos-slides

87 of 98

3

4

購入フローの可用性

測定

可用性SLI

情報収集に同意したユーザーが開始した課金フローのうち成功したものの割合

課金フローは以下を返す

OKおよび購入トークン
または FEATURE_NOT_SUPPORTED
または ITEM_UNAVAILABLE
または USER_CANCELED

/api/completePurchase は以下を返す

200 OKおよびパース可能なJSON
または 402 Payment Required

… でも、どこでそれを測定しよう？

ゲームクライアントで測定して、非同期で報告させよう！

https://cre.page.link/art-of-slos-slides

88 of 98

購入フローのレイテンシ仕様

Bのレイテンシも測定したいよね

API サーバからSKUのリストをフェッチする
PlayストアからSKUの詳細を　フェッチする
ユーザーはPlayの課金フローを�起動する
API サーバにトークンを送信する
Playストアはトークンを確認する

レイテンシSLI の仕様

しきい値よりも速く処理された有効なリクエストの割合

3

4

5

https://cre.page.link/art-of-slos-slides

89 of 98

購入フローのレイテンシ�有効なリクエスト

レイテンシSLI

しきい値よりも速く処理された有効なリクエストの割合

… どのリクエストが有効なんだろう？

ユーザーはPlayの課金フローを�起動する
API サーバにトークンを送信する
Playストアはトークンを確認する

3 じゃないの？

変動が大きすぎて、S/N 比が悪い
課金フローは、端末を操作する時間が長い

4

https://cre.page.link/art-of-slos-slides

90 of 98

購入フローのレイテンシ�「遅すぎる」しきい値

レイテンシSLI

しきい値よりも速く処理された/api/completePurchaseリクエストの割合

… で、十分に速いって何だろう？

ざっくり見積もると

トークンの確認 <= 500ms
データベースへの書き込み <= 200ms
ちょっと切り上げると...

https://cre.page.link/art-of-slos-slides

91 of 98

購入フローのレイテンシ�測定

レイテンシSLI

1000ms以内に処理される/api/completePurchaseリクエストの割合

… で、どこでそれを測定しよう？

いつからいつまでを測る？

https://cre.page.link/art-of-slos-slides

92 of 98

購入フローのレイテンシ�測定

レイテンシSLI

ロードバランサーで測定された

1000ms以内に完全なレスポンスがクライアントに返されている

/api/completePurchasリクエストの割合

https://cre.page.link/art-of-slos-slides

93 of 98

ちょっとだけ宣伝させて...

https://cre.page.link/art-of-slos-slides

94 of 98

https://cre.page.link/art-of-slos

https://cre.page.link/art-of-slos-slides

95 of 98

SLO をもっと勉強したい？ Coursera のコースを受けてみて:

https://cre.page.link/coursera

https://cre.page.link/art-of-slos-slides

96 of 98

この本は HTML なら無料で読めるよ！

https://landing.google.com/sre/books/

https://cre.page.link/art-of-slos-slides

97 of 98

ありがとう！

アンケートにも答えてね！

Insert QR code link

to feedback form

in this space!

Insert QR code link

to feedback form

in this space!

https://cre.page.link/art-of-slos-slides

98 of 98

Q&A

パネリストに質問をどうぞ！

https://cre.page.link/art-of-slos-slides