正確でも有害なアラートがある
一言でいうと
アラートの成功基準は「問題を検知したか」ではなく、「人が今すぐ何かをしなければならないか」です。この基準を通らないアラートは、正確でも有害です。
なぜ必要なのか
事故が起きるたびにルールを1つずつ追加していくと、2年後にはルールが300個になり、Slackには1日400件が積み上がります。オンコールは夜に3回起こされ、3回とも何もせずにまた眠ります。1日400件のうち実際の対応につながったものが4件なら、適合率は1%です。
この状態で人が学習する最適な戦略は、「とりあえず無視して、あとで確認する」です。それが合理的であるがゆえに、より危険です。アラートをもう1つ追加して解決する問題ではありません。
どう動くのか
原則は1つです。ユーザーが体験する症状にだけ、ページを設定します。CPU 90%は症状ではありません。CPUが90%でも応答時間が正常なら何も起きていないのと同じで、CPUが40%なのに応答に5秒かかるなら深刻な事故です。原因の指標にページを設定すると、どちらのケースも外します。
ページを設定するもの: 可用性、レイテンシ(しきい値を超えた割合)、スループットの急減、鮮度、正確性。設定しないもの: CPU、メモリ、ディスクIOPS、Podの再起動回数、スレッドプールの使用率、GC時間、レプリカ数。例外は2つだけです。元に戻せず、事前のリードタイムが必要なもの(ディスクの空き、証明書の期限切れ、クォータの枯渇)と、観測体制そのものの故障(up == 0 or absent(up))です。このアラートがなければ、ほかのアラートが静かに死にます。
しきい値も説明できなければなりません。「エラー率が5%を超えたらアラート」の5%は、どこから来たのでしょうか。たいていは、どこからも来ていません。説明できないしきい値は、事故が起きるたびに少しずつ上がっていきます。
for:は、式が真の状態がその時間だけ連続して続いて初めて発火し、途中で一度でも偽になるとタイマーが0に戻ります。そのため「誤検知が多いからforを30分に延ばそう」はアンチパターンです。検知が30分遅れ、事故が25分で終わればアラートはまったく鳴りません。正しい順序は、①長いウィンドウのrateで平滑化する、②短いウィンドウのANDで進行中であることを確認する、③forは最後に2–5分だけ、です。
現場での姿
ルーティングは3段階です。ページ(今すぐ起きる必要がある)、チケット(業務時間内)、ダッシュボード(アラートを作らない)。4段階目はありません。「とりあえずSlackチャンネルにだけ送ろう」という折衷案は最悪です。誰も責任を持たず、誰も止めません。
グルーピングで最もよくある間違いは、group_byにinstanceを入れることです。Podの数だけアラートが届きます。そしてseverity=pageなのにrunbook_urlがなければ、CIがビルドを失敗させるべきです。明け方3時に起こされた人は、創造力を発揮できる状態ではありません。ただし、リンクだけがあって中身が空のランブックは、リンクがないよりも悪いものです。
目標値は数字で決めておきます。12時間シフトあたりのページは平均2件以下、ページが対応につながった割合は70%以上です。この2つの数字を超えたら、アラートを追加するのではなく削除するときです。3か月連続で対応につながらなかったページは降格するか削除し、サイレンスが30日以上続いているアラートは削除します。サイレンスは、アラートが間違っていることを示す最も正直なシグナルです。
アラート1件に何が書かれているべきか
明け方3時に起こされた人が画面で読むのは、アラートのタイトルの1行です。その1行と本文が次の行動を生み出す必要があるので、アラートには決まった項目を入れます。
- 何が問題なのかを、ユーザーの言葉で書きます。「決済APIのエラー率12%」であり、「hikari_pending > 0」ではありません。
- どれだけ悪いのかを書きます。現在の値としきい値を併記します。12%なのか51%なのかで、対応が変わります。
- いつからなのかを書きます。たった今始まったものと、40分続いているものは、別の状況です。
- どこなのかを書きます。サービス、環境、そして必要なだけの範囲です。ただしPod名まで入れると、前に述べたとおり、アラートがPodの数だけ分かれます。
- 次に何をするかを書きます。ランブックへのリンクと、ダッシュボードへ直接飛ぶリンクです。
ここにもう1つ勧めたいのは、「このアラートは鳴ったが、何の対応も必要なかった」と記録する方法です。オンコールがその場でワンクリックで記録できれば、数週間後にどのアラートがノイズかがデータで出ます。振り返りで記憶に頼って議論するよりも、はるかに早く結論が出ます。
アラートを作るときに必ず一緒に決めておくべきものは、それを消す条件です。ルールを追加するときに「3か月間、対応につながらなければ削除する」を一緒に書いておけば、ルールが300個になることは最初から起きません。ルールは増やすのは簡単で消すのは難しいので、消す根拠は作るときに一緒に作っておく必要があります。
最後に、アラート自体をテストしなければなりません。ルールを書いたら、その条件を意図的に作って実際に発火するか、そして状況が終わったときに解消されるかを確認します。解消されないアラートは、発火しないアラートと同じくらい悪いものです。一度鳴ったあとに永遠に赤いまま残っていると、次に本当に同じことが起きたとき、誰も気づきません。
次のラボですること
症状と原因を分類し、アラートルールに必須フィールドを埋め、ルーティングと抑制とグルーピングを定義し、ランブックを実際に埋めたうえで、最後に欠陥のあるルールをCIで見つけるチェッカーを自分で作ります。