← エピソード一覧に戻る Episode 171 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 4分で信用を失う世界
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発の SLO 設計を扱います。Google SRE の availability table では、99.99% の月次可用性に許される停止時間はわずか 4.32 分です。数字の響きは立派ですが、守る難しさも一気に跳ね上がります。
ミカ
ミカです。4.32 分って、会議でちょっと画面共有にもたついたら半分くらい使ってしまいそうな短さですね。高い数字ほど安心だと思っていましたけど、SaaS では高すぎる目標が逆に首を締めることもあるんですか。
タカシ
まさにそこが今日のテーマです。前回の可観測性が異変を見つける話だとすれば、今回は『何をどこまで守れれば十分か』を決める話です。SLO がないと、開発は品質を盛りすぎるか、逆に顧客期待を甘く見るかのどちらかにぶれやすいんですね。
ミカ
なるほど。監視の話というより、経営と開発の約束の作り方なんですね。今日は SLI、SLO、error budget がどうつながって、実際にどこで失敗しやすいのかを知りたいです。
Chapter 2 原則 ― 100%を目指さないほうが強い
タカシ
Google SRE は、100% を insist するのは現実的でも望ましくもないと書いています。そこまで求めると、イノベーションの速度が落ちたり、過度に保守的で高コストな設計になったりするからです。だから SLO は、無停止宣言ではなく現実的な品質目標なんです。
ミカ
完璧を目指すほど良い、ではないんですね。たしかに経営でも、ゼロミスを掲げた瞬間に承認が増えて、誰も動けなくなることがあります。SaaS の信頼性も、同じ罠に入るわけだ。
タカシ
そこで出てくるのが error budget です。これは `1 - SLO` で決まる許容失敗枠で、たとえば 99.9% の SLO なら 0.1% が予算です。Google の例では、4 週間で 100 万リクエストあるサービスなら、99.9% 目標は 1,000 件の失敗までを予算として扱えます。
ミカ
予算って言い方が分かりやすいですね。広告費みたいに、使っていい枠が見えるから、今は攻めていいのか、もう守りに回るべきかを話しやすい。信頼性を感覚論から会計っぽい言葉に変えてくれる感じがします。
タカシ
その通りです。ただし、何を good service とみなすかが雑だと全部崩れます。Google Cloud は availability SLI を成功レスポンス比率、latency SLI を閾値以内で返せた比率のように定義しています。CPU 使用率ではなく、顧客がちゃんと目的を達成できたかで測るのが基本です。
ミカ
サーバーが元気でも、請求ボタンだけ押せなければ顧客体験は壊れていますもんね。健康診断で脈拍は正常だけど、財布だけ開かないみたいな話で、SaaS では導線単位で測らないと意味が薄そうです。
Chapter 3 具体例 ― EvernoteとSlackはどう使ったか
ミカ
でも実務では、最初から完璧な SLO を作るのは難しそうです。何を測るかだけでも揉めそうですし、プロダクト、インフラ、CS で見たい景色も違いそうです。実際の会社は、どこから始めているんでしょう。
タカシ
Evernote の事例が参考になります。彼らはまず『ユーザーが複数クライアントからノートにアクセスし同期できること』を中心体験に置き、初期 SLO を月次 99.95% uptime に設定しました。1 分ごとの外部プローブで status page を見て、複数地域から確認する、かなり素直な始め方です。
ミカ
意外とシンプルですね。しかも『全部の体験を一気に測る』ではなく、いちばん大事なユーザー行動から入っている。最初の SLO は完成品じゃなくて、意思決定に使えるラフスケッチでいい、という感じがします。
タカシ
まさにそうです。Evernote は maintenance window も、ユーザーが困るなら downtime とみなしましたし、毎月 review を回しながら改善しています。『Perfect is the enemy of good』という言葉どおり、最初から完璧な測定より、改善を回す共通物差しを作ることを優先したんですね。
タカシ
Slack の事例も面白いです。Slack は顧客契約で 99.99% の availability SLA を持ちつつ、内部では SDI-R を事実上の error budget として使い、機能開発を続けるか、信頼性改善へ振るかを leadership まで含めて判断しています。つまり SLO を技術指標で終わらせていません。
ミカ
そこが大事ですね。現場だけが budget を気にしても、上が『今期は全部出して』と言ったら崩れます。SLO が効く会社は、数字を leadership の優先順位までつなげているから、開発と経営の会話が同じ土俵に乗るんだなと分かります。
タカシ
さらに Slack は共通の metrics、alerts、dashboards を自動整備し、どの regression がどのチーム責任かまで結び付けています。SLO は値を決めるだけでなく、誰が持つか、いつ止めるか、どこでレビューするかまで設計して初めて機能します。
Chapter 4 失敗パターン ― 数字だけ立派なSLO
ミカ
逆に言うと、SLO を作ったのに現場が楽にならない会社も多そうです。表には立派な 99.99 が並んでいるのに、障害のたびに大騒ぎで、どの機能を止めるかも決まっていない、みたいな状態ですね。
タカシ
典型的な失敗は五つあります。まず 100% や 5 nines を見栄で掲げること。次に SLI が CPU やメモリのような内部指標に寄っていること。さらに全社 1 本の SLO で全部を表そうとすること、error budget を使わないこと、そして SLA と内部 SLO の距離を設計しないことです。
ミカ
一枚の通知表で、数学も体育も音楽も同じ点数にしてしまう感じですね。本当は請求、ログイン、分析バッチで重要度も許容遅延も違うのに、全部を平均すると、守るべき所と手を抜いていい所の区別が消えてしまう。
タカシ
その通りです。Google の調査でも、SLO を使う組織の 90% は目標未達時に何らかの action を取りますが、54% は SLO を定期的に見直していません。つまり、反応はしても設計を更新しない会社が多い。SLO は固定資産ではなく、事業と一緒に育てる運用品なんです。
ミカ
作って終わりではなく、四半期ごとにメニューを見直す飲食店みたいなものですね。客層が変わったのに同じ看板メニューだけ出していたらズレますし、SaaS でもエンタープライズ顧客が増えたら、求められる導線や厳しさは変わりそうです。
Chapter 5 クロージング ― 重要導線3本から始める
タカシ
実務ではまず、ログイン、課金や請求、主要 API の三つくらいから始めてください。それぞれに成功率と遅延の SLI を置き、契約上の SLA、内部 SLO、alert 閾値を分ける。そして error budget の消費率に応じて、通常運転か、要注意か、機能凍結かを明文化するのが第一歩です。
ミカ
高い数字を掲げる前に、誰のどの体験を守るのかを決めるわけですね。SLO って、信頼性の看板というより、経営と開発で『ここを落としたらまずい』をそろえる会話の土台なんだとよく分かりました。
タカシ
その理解で十分です。SLO 設計ができると、品質を守りながら速度も守れるようになります。次回は、障害が起きたときに信用をさらに削らないためのインシデント対応を扱いましょう。今回もありがとうございました。
ミカ
ありがとうございました。99.99% という数字を見る目が、今日でかなり変わりました。高いほど正義ではなく、事業に合った約束こそが強い。皆さんも自社なら何を三つ守るか、ぜひ考えてみてください。