バジェットを計算しアラートを試す

目標

「可用性99.9%」は契約書に書くのは簡単ですが、それが1か月で何分かを知っている人はまれです。そして、大半のアラートは、SLOとは何の関係もありません。

このラボは、数字を自分で求め、その数字でアラートを書き直し、そのアラートが本当に鳴るかをテストします。

開始

cp -r /opt/lab/slo/* .
python3 budget.py 99.9
promtool check rules rules.yml
promtool test rules test.yml

ファイル

ファイル	役割
`budget.py`	エラーバジェットとバーンレートの計算。修正しません
`rules.yml`	アラートルール。ここを修正します
`test.yml`	ルールのユニットテスト。ここも修正します

時系列の表記

test.ymlの0+90x20は、0から始めて1分ごとに90ずつ20回増やすという意味です。つまり毎分90件です。

ステップ

エラーバジェット → 01-budget.txt
バーンレート → 02-burn.md
今のアラートの問題 → 03-why-bad.md
バーンレートで書き直す → rules.yml
鳴るかをテスト → test.yml
静かかもテスト → test.yml
2つのウィンドウ → 07-window.md
まとめ → 08-notes.md

参考

ステップ4・5・6は、採点ツールがpromtoolを直接実行して確認します。

99.9%は1か月で何分か

99.9、99.95、99.99の3つの、1か月のエラーバジェットを求めて、01-budget.txtに残してください。

python3 budget.py 99.9のように使います。

数字を覚えることが目的ではなく、桁の感覚をつかむことが目的です。99.9%と99.99%は表記が1桁違うだけですが、許容時間は10倍違います。

契約書に99.99%と書く前に、それが1か月で何分かを知っておく必要があります。

今の速度ならいつ尽きるか

バーンレート1、6、14.4のそれぞれについて、バジェットがいつ尽きるかを求めて02-burn.mdに書き、14.4という数字がどこから来るかを説明してください。

python3 budget.py 99.9 --burn 14.4。

バーンレートは、エラー率が許容値の何倍かです。1倍なら、ちょうど1か月でバジェットを使い切ります(設計どおり)。

14.4は、次のように出ます。1時間に1か月分のバジェットの2%を消費する速度です。0.02 × 30일 × 24시간 = 14.4(韓国語は順に日と時間という意味です)。ここまでなら、今すぐ起こす必要があるという意味です。

今のアラートがなぜ役に立たないのか

rules.ymlの現在のルールを読み、なぜSLOと無関係かを03-why-bad.mdに書いてください。静かであるべきなのに鳴る場合と、鳴るべきなのに静かな場合を、それぞれ挙げてください。

今のルールは「5分間のエラー率が1%超過」です。SLO(0.1%を許容)とは何の関係もありません。

考えてみてください。エラー率0.5%が1か月間ずっと続いたらどうなるでしょうか(バジェットを5倍超過しているのに、静かです)。逆に、明け方に1.2%が5分間跳ねたらどうでしょうか(バジェットはほとんど減っていないのに、人を起こします)。

アラート疲れは、アラートが多いからではなく、役に立たないアラートが多いから生まれます。

バーンレートで書き直す

rules.ymlを修正して、バーンレート基準のアラートに変えてください。promtool check rules rules.ymlが通る必要があります。

しきい値は14.4 × (1 - SLO)です。SLOが99.9%なら14.4 * 0.001。

expr: |
  (sum(rate(http_requests_total{status=~"5.."}[5m]))
   / sum(rate(http_requests_total[5m]))) > (14.4 * 0.001)

アラート名も変えてください。今は「エラー率が高い」ではなく、「バジェットを速く消費している」です。名前が対応方法を決めます。

アラートが本当に鳴るかをテストする

test.ymlを修正して、promtool test rules test.ymlが通るようにしてください。新しいアラート名とコメントに合わせる必要があります。

このラボで最も価値のあるステップです。アラートルールにユニットテストを付ける人はまれです。そのため、肝心の障害のときに鳴らないアラートがよくあります。

input_seriesの0+90x20は、1分ごとに90ずつ20回増やすという意味です。エラーを0+10x20にすれば、10%のエラー率なので、どの基準でも鳴ります。

採点ツールがpromtool test rulesを直接実行します。

鳴ってはいけないときに静かかもテストする

test.ymlに、アラートが鳴ってはいけないケースを1つ追加してください。バジェットの範囲内で動いている正常な状態です。

exp_alerts: []で、「アラートが1つもないべき」を表現します。

エラー率を0.05%くらい(例: 0+1x20対0+2000x20)にすれば、SLOの範囲内です。

鳴るべきときに鳴るかだけをテストするのは、半分です。静かであるべきときに静かかもテストして初めて、アラート疲れを防げます。

速いウィンドウと遅いウィンドウ

なぜウィンドウ(window)が1つでは足りないかを07-window.mdに書き、2つのウィンドウを使う構成を提案してください。

短いウィンドウ(5分)だけを使うと、一瞬跳ねただけで起こされます。長いウィンドウ(1時間)だけを使うと、速く燃えていることに遅れて気づきます。

そのため、普通は2つをandで結びます。短いウィンドウと長いウィンドウが両方しきい値を超えたときだけ鳴ります。そうすれば、瞬間的な跳ねは除かれ、本物の消費は早く捕まります。

そして、重大度を分けます。速い消費(14.4倍)は即時ページ、遅い消費(6倍以下)はチケットにします。

まとめる

08-notes.mdに3行以上。バーンレートとは何か、アラートルールをテストすべき理由、バジェットが尽きたらチームが何をすることにしたか。

本文に번 레이트、시험、예산(韓国語の語で、順に「バーンレート」「テスト」「バジェット」という意味です)が入っている必要があります。最後の項目が難しいです。バジェットの消費に対する対応が決まっていなければ、SLOは飾りです。