執筆者：SRE シラト
・SRE ２年生になりました！！！
・DevOpsの文化浸透を目指してます！
・最近、散歩ポケモンGOを始めました。
対象読者
・SLO/エラーバジェットの導入検討している、運用を行っている人
はじめに
SLO/エラーバジェットの運用ハードルが高いと感じていませんか？
私自身、運用を開始しても形骸化しないかとても不安でした。
数ヶ月前からCoolmicで運用を開始しましたので、意識したこと、所感についてお話しいたします！
※ SLO/エラーバジェットの説明やアーキテクチャのご紹介はありません
運用で意識したこと
1. プロダクトチーム全体を巻き込む
例えば、SREが単独でSLOを設定して運用を開始したらどうなるでしょうか？
👮♀️SRE「最近、TOPページの表示速度遅いから改修した方がいいかも！」
🧑💻他チーム「対応します！（まだ遅くないから大丈夫だな）」
個人、チーム間で、デッドラインの認識が異なると何もアクションしなくなり形骸化が加速してしまいます。
重要なのは、
『チーム全員で顧客目線の信頼性を定義、可視化して、共通認識にする』
ことだと思います。当たり前のことかもしれませんが、他のチームも巻き込むことはとても大切なのに、忘れがちだったりします。
2. エラーバジェットが枯渇しても復旧対応を必須にしない
調べてみると大きく２つの事例がありました。
①新機能開発を止めて復旧作業を優先する
②エラーバジェットが枯渇したらチーム全体に共有して、復旧作業を優先するべきか判断する
以下の理由から②での運用を開始しました。
設定したSLOが正しいとは限らない
SLO/エラーバジェットは、顧客目線で設定した運営側の数値でしかありません。
あくまで仮説で設定した数値なので、必ず復旧作業をする必要があるかというと、いささか疑問を感じました。
重要なのは、
『エラーバジェットが枯渇したから復旧作業をする』
のではなく
『顧客からの信頼度が下がるから復旧作業をする』
ことだと思います。 エラーバジェットが枯渇したら一度立ち止まって、判断するフェーズがあってもいいかと思いました。
3. ダッシュボードをいい感じにする
ダッシュボードがかっこいいとやる気でませんか？
完全に個人的な気持ちの問題なので、論理的な視点もなにもありません！
所感
1. 推測するな、計測せよ
実際、可視化してみるだけでも「あれ、このページって他のページと比較すると表示速度が遅いんですね」という声が上がりました。
可視化されていないと「気が付いたらパフォーマンスが悪化していた・・・。」という状態になりかねません。
2. 判断コストを削減できる
エラーバジェット運用を行う最大のメリットかと思います。
パフォーマンス改善するべき？バグ修正するべき？の判断においては、かなり需要な指標ですね！
3. 数値を見る文化に助けられた
少し話が脱線しますが、Coolmicには、朝会で売上数値などを確認する文化があります。
朝会で、エラーバジェットの枯渇状況を確認するので、毎日問題がないか確認することになります。
そのため、SREが関与せず、エラーバジェットが枯渇しそうになると、タスク化されます。
改めていい文化になったと感じました！
おわりに
運用の正解はないと思うので、定期的に運用を見直そうと思います。
正直もっと早く導入すればよかったと反省しつつ、判断コストが削減できるのはいいですね！
