yuru sre 14

https://yuru-sre.connpass.com/event/376206/

Transcript

2. 私の好きな過去のゆるSREセッション
3. 私の好きな過去のゆるSREセッション
4. おばあさんに聞いた SREの知恵 @maru (X: @maruloop)
5. 普段の登壇では… • 2025/09 • Platform Engineering Kaigi • 2025/11 • Observability Conference Tokyo • 2026/01 • SRE Kaigi 考えてること(原液) →自分のチームで試行錯誤 → 後から振り返って整理する << ここを普段は話す
6. 普段の登壇では… • 2025/09 • Platform Engineering Kaigi • 2025/11 • Observability Conference Tokyo • 2026/01 • SRE Kaigi 考えてること(原液) << 今日はここを話す！ →自分のチームで試行錯誤 → 後から振り返って整理する << ここを普段は話す
7. おばあさんに聞いた SREの知恵 @maru (X: @maruloop)
8. Googleでは、SLO違反によってエラーバジェットが枯渇した時 リリース停止というポリシーで運用しているんですか？ そのポリシー強すぎませんか？
9. Googleでは、SLO違反によってエラーバジェットが枯渇した時 リリース停止というポリシーで運用しているんですか？ そのポリシー強すぎませんか？ エラーバジェットポリシーの厳しさは、 それを導入することによって軽くなる 他のリリースゲートに重さに依存するんじゃ
10. エラーバジェットのポリシーは 減らされるリリースゲートの重さと釣り合う 例えば、既存のリリースチェックリストが100000項目あるとして そのチェックが完全になくなるなら、エラーバジェットポリシーがリリース禁止でも釣り合う。 逆に、今リリースチェックリストのような”リリースゲート”が存在せずに、 新たにゲートとしてエラーバジェットを追加するのは、色々調整が必要！
11. レイテンシーのSLOを最近違反しがちです。 しきい値が厳しすぎるようなので、チームで議論して 200msから400msに変更してもいいですよね？
12. レイテンシーのSLOを最近違反しがちです。 しきい値が厳しすぎるようなので、チームで議論して 200msから400msに変更してもいいですよね？ レイテンシーのSLOは、しきい値のレイテンシーだけでなく パーセントタイルを調整することも検討するんじゃ。 それぞれの調整の意味が違うから、 ちゃんとチームで議論する際に認識合わせからやるんじゃよ。
13. 調整するのは、パーセントタイル？しきい値？ 「99%ileで200ms以下」を成功とみなす ↓↓↓ 調整はどっちが良い？ • 「99%ileで400ms以下」を成功とみなす • 「90%ileで200ms以下」を成功とみなす
14. 調整するのは、パーセントタイル？しきい値？ 「99%ileで200ms以下」を成功とみなす ↓↓↓ 調整はどっちが良い？ • 「99%ileで400ms以下」を成功とみなす • 「90%ileで200ms以下」を成功とみなす 教科書的には、必要性に応じて2つ持ちましょう。 でも、それぞれの意味を理解しよう。
15. パーセントタイル？しきい値？ パーセントタイルの考え方としては、 「ユーザーの期待を満たすのに、何回API callが必要か？」を考えると議論がしやすい。 「ある1つの画面を表示したいケース」 • 並列で呼ぶAPI callが1回必要であれば • 99%ileで400msの場合、1%(1-0.99)の確率で400ms以上かかる • 100人中1人が400ms 以上 • 90%ileで200msの場合、10%(1-0.9)の確率で200ms以上かかる • 100人中10人が200ms以上 • 並列で呼ぶAPI callが10回必要であれば • 99%ileで400msの場合、9%(1-0.99^10)の確率で400ms以上かかる • =100人中9人で400ms 以上 • 90%ileで200msの場合、65%(1-0.9^10)の確率で200ms以上かかる • 100人中65人で200ms 以上
16. 深夜や早朝の低QPS時間帯で、エラー率のアラートの誤検知がひどいです。 とりあえず、低QPS時は無視するクエリにしたんですけど、 こんなことしちゃっていいんでしょうか？
17. 深夜や早朝の低QPS時間帯で、エラー率のアラートの誤検知がひどいです。 とりあえず、低QPS時は無視するクエリにしたんですけど、 こんなことしちゃっていいんでしょうか？ なぜそれを誤検知だと考えられるんじゃ？ きっと君の中に「観測されたエラー」と「真のエラー」が存在するんだね？
18. 深夜や早朝の低QPS時間帯で、エラー率のアラートの誤検知がひどいです。 とりあえず、低QPS時は無視するクエリにしたんですけど、 こんなことしちゃっていいんでしょうか？ なぜそれを誤検知だと考えられるんじゃ？ きっと君の中に「観測されたエラー」と「真のエラー」が存在するんだね？ つまり、低QPS時間帯に観測されたエラーは、上振れ/下振れの可能性が高く エンジニアが電話を受けてわざわざ対処するほどでもないということだね。
19. 深夜や早朝の低QPS時間帯で、エラー率のアラートの誤検知がひどいです。 とりあえず、低QPS時は無視するクエリにしたんですけど、 こんなことしちゃっていいんでしょうか？ なぜそれを誤検知だと考えられるんじゃ？ きっと君の中に「観測されたエラー」と「真のエラー」が存在するんだね？ つまり、低QPS時間帯に観測されたエラーは、上振れ/下振れの可能性が高く エンジニアが電話を受けてわざわざ対処するほどでもないということだね。 であれば、Wilson Scoreを使うと良いのじゃ。
20. Wilson Score 「このエラー率は本当に閾値を超えたと言えるほど確かなのか？」を確認するもの。 上限「サンプル数が少ないため、 エラー率は最大で b% 程度まで悪化している可能性がある」 下限「サンプル数が少ないため、 エラー率が a% 程度以上である可能性を否定できない」 < アラートはこちらにかけたい n: サンプル数、z: 信頼レベル(98%信頼区間2.33, 95%信頼区間1.99)、p: エラー率
21. コード的にすると X = エラー数、z=信頼レベル(98%で2.33)、n=サンプル数 ((2.0 * x + z * z - (z * m.sqrt(z*z - 1.0 / n + 4.0 * x * (1.0 - p) + (4.0 * p - 2.0)) + 1.0)) / (2.0 * (n + z * z)))
22. PromQLクエリにすると ((2.0 * sum(increase(requests_total{status="500"}[1m])) + 2.33 * 2.33 - (2.33 * sqrt(2.33*2.33 - 1.0 / sum(increase(requests_total[1m])) + 4.0 * sum(increase(requests_total{status="500"}[1m])) * (1.0 - (sum(increase(requests_total{status="500"}[1m])) / sum(increase(requests_total[1m])))) + (4.0 * (sum(increase(requests_total{status="500"}[1m])) / sum(increase(requests_total[1m]))) - 2.0)) + 1.0)) / (2.0 * (sum(increase(requests_total[1m])) + 2.33 * 2.33))) * on (_your_label_) sum(increase(requests_total{status="500"}[1m])) > bool 0
23. 何をやってるか？ • サンプル数が低い時は、観測されたエラー率より低い確率になる • Lim_{n-> }にすると、観測されたエラーに漸近する 観測されたエラー率 = x/n Wilson score(下限)
24. 障害対応を改善したいと思うんですけど、 どこから手をつけたらいいんでしょうか？
25. 障害対応を改善したいと思うんですけど、 どこから手をつけたらいいんでしょうか？ まず、ポストモーテムに「幸運だったこと」の項目を追加するんじゃ。 「幸運」を当たり前にするために頑張れると良いのう。
26. 障害対応を改善したいと思うんですけど、 どこから手をつけたらいいんでしょうか？ まず、ポストモーテムに「幸運だったこと」の項目を追加するんじゃ。 「幸運」を当たり前にするために頑張れると良いのう。 他にも、分析する際にMTTRを使わないことが重要じゃ。 もっと細かくMTTDやMTTIやMTTAごとに分析してみるんじゃ。
27. それぞれの区間で平均と分散を集計するんじゃ • 発生からシステムの検知(Detection)まで • Time to Detect(TTD) • 発生から人間の認知(Acknowledge)まで • Time to Ack • 発生から原因判明(Identify)まで • Time to Identify • 発生からサービス復旧(Service Recovery)まで • Time to (Service) Recovery • 発生から次の障害発生(Between failure)まで • Time between Failures
28. それぞれの区間で平均と分散を集計するんじゃ • 発生からシステムの検知(Detection)まで • Time to Detect(TTD) • ➔ TTDの分散が大きければ、アラートやメトリクスを改善する。その成果は分散の変化で計測できる。 • 発生から人間の認知(Acknowledge)まで • Time to Ack • ➔TTAの分散が大きければ、オンコール体制の整備が効果的。 • 発生から原因判明(Identify)まで • Time to Identify • 発生からサービス復旧(Service Recovery)まで • Time to (Service) Recovery • 発生から次の障害発生(Between failure)まで • Time between Failures
29. MTBF(平均故障間隔)って、どうやって考えればいいの？ 再発防止策をちゃんとやってるから、 同じ障害はほとんど起きないよ？
30. MTBF(平均故障間隔)って、どうやって考えればいいの？ 再発防止策をちゃんとやってるから、 同じ障害はほとんど起きないよ？ 障害のグルーピングがあんまり上手くいってないようじゃな。 原因別だけでなく、影響別やチーム境界別など、 様々なグルーピング方法が可能じゃ。
31. 障害のグルーピング 平均故障間隔(MTBF)を計算しようとすると、再発防止策してるから再発しないはずじゃ・・・？となる。 障害を適当に分類して集計するところから始めてみよう。 • 原因別 • 設定ミス、オペレーションミス、実装ミス、仕様漏れ、外部サービス影響、etc • 組織ごと • 開発組織A、開発組織B、etc • マイクロサービスごと • マイクロサービスA、マイクロサービスB、etc • デプロイ頻度ごとのマイクロサービスごと • 月1デプロイのマイクロサービス群、週1デプロイのマイクロサービス群、etc
32. グルーピングしても初回の障害が多すぎて、 MTBFをとりあえず埋めることもできないよ〜
33. グルーピングしても初回の障害が多すぎて、 MTBFをとりあえず埋めることもできないよ〜 初回を正しく計算することはできないけど、 とりあえずベイズで事前確率を設定すれば、表自体は埋まるわよ
34. おわり！ おわり！