こんにちは。フィックスポイントの冨です。

昨年にアラートメッセージの判断を自動化する”AlertHub”をリリースして以降、様々なプロジェクト、インフラでのシステム監視の実情をお伺いする機会がありました。
毎日、恐ろしい数のメッセージを捌いておられる現場や、オンコールのローテーションを少人数で組んでいて、何とか対応しているなど、それぞれの現場ごとに、なかなかご苦労されている様子を垣間見ている気分になります。

システム運用のツラい側面の１つとしてアラート対応があります。特にうるさ過ぎるアラートにはイライラしがちですし、さらには誤報と分かった瞬間の脱力感は経験した者でないと分からないでしょう。アラートを受け取るとアドレナリンが分泌されますし、問題対応を頻繁に繰り返していると、アラート疲れを起こして燃え尽きてしまいます。

極端にアラート発生件数が多い場合には、運用しているアプリケーションの品質に問題がある事が疑わしく、ログ情報を元にして改善を試みる必要があります。ある程度、順調に稼働しているシステムのアラートの改善については、いくつかの観点から見直しが必要です。極力、送出数を限定する事と、どのようなトラブルが発生していて、どのようなユーザー影響が出ているかを過不足なく伝える工夫が必要となります。

(1) 至急にアクションが必要な状況なのかを判断する
サービス提供に問題が発生し、エンジニアを叩き起こしてでも対応が必要な局面でのみアラートを送信すべきです。言い換えれば、システムに何らかの問題が生じたものの一時対応の自動化で復旧した場合や、一時的な負荷増大で自然に復旧した場合など、後からの対応で十分な場合にはアラートを送るべきではありません。発生記録を残しておいて、後で振り返れば良いものです。

(2) 見ても対応しなかったアラートは削除する。
システムから警告のメッセージを受信したものの、特にアクションを起こさなかったものについては、(1) 同様に「アラート」では無いと考えて、送信設定をスキップします。もちろんソフトウェア改善のための基礎資料としての価値がある場合には、それらのメッセージを記録保存することは、何ら問題ではありません。

(3) メトリックからのアラート設定を閾値だけでなく、変化率も考慮する。
極端な場合では、ディスクを毎日0.1%ずつ使うような場合で、ある日、利用率が閾値の90％を超えた場合。翌日の見込みが90.1%なので、緊急で何かをしなければ危険というわけでもありません。
1日で利用率が20%から60%に急上昇した場合、閾値からはかなり離れていますが、この増加率のまま放置すると翌日のディスクフル障害のリスクは非常に高い可能性があるとみるべきでしょう。
メトリックの変化傾向を考慮し、アラート発生基準をチューニングする必要があります。

その他、アラート発生時の手順書を整備する。各メトリックの変化とユーザー影響との関連性を明確にする。など、いろいろとストレス軽減の取り組みの余地はあると思います。
やみくもに全部に人力で対応しようとすると無理が出ますので、アラート送出の基準の見直しを積み重ねて、適切な質・量を保てるように工夫してください。