SLO
Service Level Objective
障害を起こしても許容される頻度の目標値
正常に動作していなくてもユーザが重大な混乱に陥らないと保証する目標値
SLIを満たしたイベント / 全イベント
この割合の満たすべき目標値がSLO
参考
目標値である
契約上の合意ではない
自由に変更や更新できる
この目標値を上回っている場合、ユーザはサービスの状態に満足する
この目標値を下回っている場合、ユーザはサービスの状態に満足しない
SLOが高ければ良いというわけでもない
自分の担当する部分が信頼性が高くても、依存する他のサービスの信頼性が低ければユーザから見れば信頼性がないことに変わりはない
e.g. ユーザの自宅のネットが弱い
高すぎると、失敗できる機会が少なくなる
学習できる機会が減る
実験できない
カオスエンジニアリングできない
短時間で機能のリリースができない
これは問題だねmrsekut.icon
サービスが期待される動作を実行していないこと
緊急かどうかは関係ない
APIが十分な速さでレスポンしなかったら障害と言える
問題になるのは、詳細が頻繁に発生したり、長く続いた場合のみ
SLOが多すぎても問題
意思決定する難しさが増す
どうやって決めるか？
過去のパフォーマンスを参考にする
例
「1ヶ月間のリクエスト成功率が99.9%以上であること」
「95%以上のリクエストが300ms以内に完了する」
SLOは単なるデータである
もっかいよもうmrsekut.icon