SRE部の今福です。
私事ですが早いもので入社してから半年以上が経ちました。
今回はSLOに関して漠然とした知識だけ持っていた自分が実践を通して気付かされたSLOに対する心構えについて紹介します。
SLOを導入・運用するうえで必要な手順や考え方を網羅的に学びたい方は、技術書やブログ（SLO入門, ゼロから始める SLO設計）を読んでいただくと良いと思います。
正直当たり前のことを挙げているので既にSREを実践されている方にとっては退屈な記事かもしれません。
それでも読んでいただいた方に共感や新たな気づきが得られれば嬉しく思います。
１つ目：SLOはユーザー目線で設定すること
SLOはユーザーが期待通りにサービスを利用できるための目標値なので、ユーザー目線で設定することは本来当たり前です。
ただ私にとってこれはSLOをプロダクトで導入する際に見失いがちな観点でした。
実際にあった例として、とあるプロダクトで根幹機能に外部サービスを利用しており、SLIにおいて外部サービスは計測の範囲外にするかどうかという議論になりました。
当時の自分は、外部サービスはプロダクトの責任領域ではないので範囲外にしてもよいのではないかと思っていました。
しかしユーザー目線で考えれば原因はどうでもよく、サービスが利用できなくなれば信頼性は下がるはずであり例外的に扱うのは適当とは言えません。
そこで自分は、SLOはユーザー目線で考え、そこに含まれるさまざまな要因を踏まえて設定されるべきだと、SLOの本来の目的に立ち返ることができました。
もちろん、外部サービスの障害によってSLO違反が多発するのであれば代替サービスの利用や内製化などの判断が必要になることもあります。
信頼性回復手段の難易度やコストなどを踏まえつつ、プロダクトとして現実的な選択をしていく点は悩ましいところです。
２つ目：プロダクトに寄り添うことが大事
SLOは導入すること自体が目的ではなく、サービスの信頼性を定量化し、プロダクトがその信頼性を適切なレベルに維持できるようにするための手段です。
SLOの導入や初期運用は、どうしてもSRE側が主体で動く場面が多くなります。ただ、理想を言えば将来的にはプロダクト主体で運用される状態が望ましいと思っています。
そのためには、プロダクト側に「SREの人たちが何かやっているもの」と距離を置かれないよう、導入の段階からできるだけ巻き込みつつ、負担をかけすぎない形で伴走することが大事です。
SREメンバーとしてできることは、例えば次のようなものがあります。
- 目的や前提の整理
- SLI/SLO実装のテンプレートやサンプルの用意
- 運用ルールのたたき台づくり（レビュー頻度、違反時の判断基準など）
- SLOに限らず、トイルを減らす仕組みづくりでプロダクトに貢献すること
プロダクトに寄り添い、少しずつ信頼を積み重ねていくことで、SLOを含む信頼性向上の取り組みがプロダクトの運用に自然に組み込まれていき、最終的にはプロダクト主体で自走できる状態に近づけるはずです。
３つ目：SLO違反はそんなに起きない（はず）
SLO導入直後は、まず仮の目標値を置いてみる段階なので、SLO違反が発生すること自体は珍しくありません。
一方で運用と調整を重ね、ユーザーの信頼性の閾値とSLOが近似してくると、SLO違反の頻度はだんだん落ち着いていくはずです。
これはSLOが「ユーザー影響として看過できない劣化を検知するライン」として設計されることが多いからです。
目標が適切で、日々の運用改善が回っている状態であれば、違反は頻発しない方が自然です。
また、SLO違反が起きるときは、その前段でインシデント級のエラーやユーザー影響がすでに発生しており、何かしらの対応が走っているケースも多いと思います。
その意味で「SLOが違反していない」ことは、基本的に良いニュースです。
ただし問題は、違反が起きないSLOほど「動きのない情報」になり、関心が薄れてメンテナンスされなくなることです。
そのため、以下のような棚卸しや見直しを定期的に行う必要があります。
- ユースケースの棚卸し（重要なユーザー行動が変わっていないか）
- SLIの妥当性確認（計測漏れ、仕様変更への追随）
- SLOの目標値の見直し
- SLOの運用ポリシーのレビュー
SLO運用で大事なのは、違反の有無を眺め続けることよりも、こうした棚卸しや見直しを継続できる仕組みを持つことです。定期的に点検できる場を用意して、SLOを腐らせず「生きた状態」のまま保つことが重要だと思います。
まとめ
本記事では、SLOを導入・運用していくうえで改めて気付いた心構えを3つ紹介しました。
どれもSLOに関するドキュメントを読んでいれば似たようなことは書いてあると思います。
ただ、今回自分としては知識としてではなく、知見として得られたことを残したく記事にしました。
今後も、いわゆる技術的な内容だけでなく、こういった現場で得た学びも共有していければと思います。