Alerting Principles

私たちは、単純な原則に基づいて、どのようにアラートを受けるかを管理します。アラートは、人間がアクションを実行する必要があるものです。それ以外は通知であり、それは私たちがコントロールできないものであり、私たちがそれらに影響を与える行動を取ることができないものです。通知は役に立ちますが、全ての通知が人を叩き起こすべきものではありません。

アラート優先度#

新しいアラート/通知を設定する場合は、上記のチャートを考慮して、ユーザーにアラートを送信する方法を確認します。たとえば、すぐに対応する必要がない場合は、優先度の高い新しいアラートを作成しないように注意してください。

優先度の例#

"プロダクションサービスがリクエストの75%で失敗し、自動化では解決できません。"_#

これは、High priority ページになり、解決するためにすぐに人間のアクションが必要になります。

"プロダクション・サーバーのディスク領域がいっぱいになり、48時間でいっぱいになると予想されます。ログのローテーションでは解決できません。"#

これはMedium priorityとなり、いずれ人間の行動が必要になりますが、直ちに今すぐというほどではありません。

"SSL証明書の有効期限が1週間後に迫っています。"#

これは、Low priorityになり、いずれ人間の行動が必要になりますが緊急性は低いです。

"デプロイが成功しました。"#

これはNotificationとなり、抑制されたイベントとして送信されます。これは、インシデントが発生した場合に有用な情報を提供しますが、人間に通知する必要はありません。

アラートの内容#

アラートには、問題を迅速に特定し、可能性のある修復手順を特定するのに十分な有用な情報が含まれていることを確認する必要があります。一般的なタイトルまたは説明を含むアラートは有用ではなく、混乱を引き起こす可能性があります。私たちは、すべてのアラートが従うべき、アラートの内容に関する一連のガイドラインを持っています。

タイトル/要約をわかりやすく簡潔にする。#

• 警告:何か問題があった。
• ディスクは prod-web-loadbalancer-af5462ce で 80% フルです。

アラートをトリガーしたメトリクスを、アラートの内容に含めるようにしましょう。#

• ディスクのディスク容量がいっぱいになっています。
• avg(last_1h):max:system.disk.in_use{env:prod-web-loadbalancer} by {host} > 0.8

アラートの内容には、実際どのような問題なのか、そしてなぜ問題なのかについての説明も含めましょう。#

• ディスクがいっぱいです。
• このホストのディスクの容量は80% です。いっぱいになりすぎると、新しいファイルが作成されず、現在のファイルが書き込まれないため、システムが不安定になることがあります。

問題を解決するための明確な手順、または手順書へのリンクを提供します。これらのいずれもないアラートは有用ではありません。#

• 何かを削除して問題を解決しましょう。
• ディスクスペースの問題を特定して解決するには、次の手順書を参照してください：https://example.com/runbook/disk . さらに、ログローテーションのしきい値でこの問題が再発しないようにできるかどうかを調べる必要があります。以下の手順書には、必要な手順が記載されています：https://example.com/runbook/log-rotate .

アラートのテスト#

新しいアラートと変更されたアラートをすべてテストするようにしてください。これは通常、新しいサービスのFailure Friday の一部として扱われますが、より迅速に必要な場合は手動でテストする必要があります。テストすべき事項は以下のとおりです：

• しきい値が適切に設定されていることをテストします。私たちは必要以上のアラートを望んでいません。
• 場合によっては、データがない条件でアラートを受信するテストをします。一般的に、データを受信しないことはしきい値を超えたのと同等です。
• メトリクスが正常に戻ったときにアラートが自動的に解決するかどうかをテストします。