アラートの原則

私たちは アラートは人間によるアクションが必要 というシンプルな原則に基づいて、受け取るアラートを管理します。それ以外の私たちで制御できないものは通知であり、それに対するアクションもありません。通知は便利ですが、いかなる状況でも人々を目覚めさせてはいけません。

アラートの優先度#

高優先度アラート

深夜に人を叩き起こすものは すぐに人が対応できるもの であるべきです。そうでなければ、人々を呼び出さないようアラートを調整する必要があります。

新しいアラート/通知を設定する場合は、誰に通知したいかを考えてください。たとえば、即時対応が必要ない場合は、高優先アラートを鳴らさないよう注意してください。

優先度Highで、すぐに人手による対応が必要です。

High Urgency

優先度Mediumで、すぐにではないが人手による対応が必要になります。。

Medium Urgency

これは優先度Lowで、近いうちに人手による対応が必要になります。

Low Urgency

これはNotificationで、イベントは抑制されて送信されるべきです。これはインシデント発生時に役立つ情報ですが、人間に知らせる必要はありません。

Notification

アラートには問題を迅速に特定できる文脈と、復旧できる可能性がある手順を含むべきです。アラートに一般的なタイトルまたは説明文を使うと返って混乱を招く可能性があります。私たちにはアラートの内容に関する一連のガイドラインがあり、全てのアラートがそれに従うべきです。

✘ ディスク空き容量が枯渇しています
✓ avg(last_1h):max:system.disk.in_use{env:prod-web-loadbalancer} by {host} > 0.8

✘ 削除して直してください
✓ 手順書 (https://example.com/runbook/disk) を参考にして、ディスクの空き容量を確保してください。再発防止のために、手順書 (https://example.com/runbook/log-rotate) に従って、ログローテーションのしきい値の設定が十分か調査してください。

テストは重要です

テストしていなアラートは、アラートが無いのと同じです。いざというときにアラートが動作するかわかりません。アラートが実際に動作するかをテストするのは、正常なサービス運用にとって重要で、リリースの計画やデプロイのデプロイ作業に含めるべきです。

追加されたアラートは必ずテストしてください。これは新しいサービスのFailure Fridayによってカバーされますが、より迅速にする場合は手動でテストしてください。テストすべきものは