Datadog SLO 101 を読んだ
Datadog のブログに、SLOに関するシリーズがある。今日は一つ目のブログを読んだ。
以下、大雑把な意訳と感想。
GoogleのSRE本で紹介されたSLO(service level objectives)は、それを利用することでプロダクト開発と運用タスクのバランスをとって、最終的にはプロダクトのユーザ体験を高めることができる、というもの。
このブログでは、SLI, SLO, SLA,エラーバジェットの説明、SLOは誰にとって重要なのか、SLO設定に当たってとりあげるべきSLIについて説明があった。
用語の説明
Service Level Indicators (SLIs)
ユーザに提供しているサービスのレベルを測るメトリクス。例えば可用性、レイテンシー、スループットなど。
Service Level Objectives (SLOs)
目標サービスレベル。SLIによって計測される。
Service Level Agreements (SLAs)
提供されるサービスのレベルに関して、サービスの提供者とサービスの利用者の間で交わされる契約、合意。 これを下回った場合は料金の減額などが行われる。
Error bugets
直訳するとエラー予算。SLOを守るにあたって許容されるエラーの累積値の上限。 エラーバジェットが残っている間は新規開発などが許されるが、それを下回った場合は不具合の修正や設計の見直しが求められる。
SLOは誰にとって重要なのか？
エンドユーザ
サービスの品質に対するエンドユーザの期待値は高い。ただ100%の信頼性は無理。
SLOを設定することで、製品開発(ユーザに新しい価値を提供するが、何かを壊す可能性もある)と、信頼性(ユーザの幸福度をキープする)のバランスをとることができる。
製品開発エンジニア(dev)、運用エンジニア(ops)
歴史的に製品開発エンジニアと運用エンジニアが分かれていて、それぞれの目標が利益相反していた。 大雑把にいうと、製品開発エンジニアは新しい機能を追加することに責任をもつが、運用エンジニアは出来上がったものの信頼性に責任を持つ。
SLOとエラーバジェットを設定することで信用性に関して同じ責任感を持つことができるようになる。
エラーバジェットが残っているうちは、製品開発者エンジニアは新しい機能をリリースできるし、運用エンジニアは長期的な改善プロジェクトを進めることができる。 エラーバジェットが残り少なくなったら、製品開発者エンジニアは手を止めて信頼性の向上のため、運用エンジニアと共に直近の改善活動をする必要がある。
簡単にいうとエラーバジェットは、製品開発エンジニアと運用エンジニアの仕事を調整するための数値化手法ですよ、という話。
SLIからSLOへ
良いSLIを選ぼう
すべてのSLIが良いSLIではない。 ユーザ体験に直接影響する指標に絞りましょう。 例えば買い物サイトにおいて、サーバのCPU使用率が高くても、ユーザの買い物がスムースにできていれば問題ない。この例ではCPU使用率は良くないSLIと言える。
ユーザに近い位置で計測することを勧める。
SLIの選択には、GoogleのSRE本が参考になる。 https://sre.google/workbook/implementing-slos/#slis-for-different-types-of-services
SLIをSLOにする
SLOは例えば、30日間で99％のリクエストのレイテンシーが250ms以下である、といったものになる。
SLOを設定するにあたっては以下の注意事項がある。
- 現実的になろう。100%のSLOは無理。
- 最初から正解のSLOは出せないので運用しながらよくしていきましょう。
- 複雑にしすぎないように。ユーザ体験に直結するものに絞りましょう。
SLO設定にあたってのチェックリストをDatadogが用意している。 https://www.datadoghq.com/pdf/SLOChecklist_200619.pdf
感想
SLOやエラーバジェットを設定するのはすぐにできそうだが、それをうまく運用するにはチームメンバーとの協力が必要。 設定値に納得感がないといけないし、下回った場合にどうするか事前に決めておく必要がある。
