用語の整理

まずはごっちゃになるSLI, SLO, SLAの整理から。
ちなみにSLは全部Service Level。

SLIはService Level Indicatorの略。Indicator: 指標
サービス品質をどうやって定量的に測るのかを決める。

SLIとして用いられる代表的なものは ↓

SLOはService Level Objectiveの略。Objective: 目標
「このサービス品質は維持したい」という基準値を決める。

例:

SLAはService Level Agreementの略。Agreement: 契約
「このサービス品質を守ります」という正式な契約内容を決める。
違反すると返金やペナルティが発生。

そのためSLAをSLOより厳しくするのは絶対NG。

SLOの設計原則

Google SRE本ではこう書かれています：

“SLOs should be based on user happiness, not engineer ambition.”
（SLOはエンジニアの理想ではなく、ユーザーが幸せでいられる範囲で設定すべき）

基本的には「ユーザーが満足しているなら現状値より少し緩めに設定」が定番のパターン。

SLOは実測値そのものではなく“目標”。

例えば現状が「90% 160ms, 95% 300ms」で、それに顧客が満足しているなら、SLOは「95% ≤ 350ms」のようにする（厳しくしすぎても緩すぎてもダメ）。

SLOが厳しいと常にSLO違反になってしまい、精神的に苦しい運用になる。
後述するエラーバジェットが枯渇し、リリースが凍結されたり改善活動が止まったりする。

SLOを超えて許容できる「失敗の量」

例: SLO：99.9% Availability

この場合、月間 0.1% = 約 43分まで障害が許容される。
これがエラーバジェット。

たとえば新機能をリリースしたい時、エラーバジェットが残っていればOKだが、障害が続きエラーバジェットを消費しきっていたら、リリース凍結して信頼性の改善に集中するなど。