SREやDevOpsチームでのアラート疲れの5つのよくある原因

この Blog Post は 5 Common Sources of Alert Fatigue for SRE and DevOps Teams の意訳です。

オンコールSREの経験があるのであれば、アラート疲れに詳しいはずです。アラート疲れとは、システム全体の多数のサービスやツールからアラートに対応した後に忍び寄る燃え尽きた感情です。この現象は疲れだけでなく、他の作業に集中するためのあなたの能力すら制限します。それが、単に「確認」ボタンをクリックするような作業だとしても。調査によると、人々は短いコンテキスト切り替えで生産時間の最大40％を失います。終わりのない対応を引き起こすアラートの多くは、緊急でも重要でもないため、人間のアクションを必要としません。それでは、どこから来たのでしょう？

稼働システムで注意が必要な実際の問題からオンコールのDevOpsまたはSREチームの注意をそらし、アラート疲れを引き起こす5つのノイズソースを以下に示します。

無関係なアラート

未使用のサービス、廃止されたプロジェクト、および他のチームによってアクティブに対応されている問題は、迷惑になるほど十分に広まっているノイズの原因ですが、そのソースでアラートをオフにする面倒な作業を行う価値は必ずしもありません。これらの通知は、本番システムのあらゆる種類のツールから送信され、すぐに確認される傾向がありますが、通常は根本的にアクション可能な問題はないため、ほとんど無視されます。

低優先度の アラート

一部のノイズメーカーは、いずれ対処する必要があるかもしれないものの、現在の優先度リストでは低い問題を示しています。これらのアラートを設定したままにしておくと、最終的に問題の根本原因を調査したり対処したりするための便利なリマインダーになる可能性がありますが、短期的にはおそらく付加価値はありません。

フラッピングアラート

フラッピング問題に対応することは、もぐらたたきのように感じられます。これらのアラートはシステムの問題が拡大していることを示す良い指標ですが、問題を解決しようとしているときに気を散らす原因になる可能性があり、SREが対応しなくなったり、盲目的に受け入れたりしてしまいます。。フラッピング通知の山の中に無関係な問題が紛れて見失う可能性もあります。チームが重要な問題に気付けなくなる恐れがあります。

重複アラート

フラッピングアラートと似ていますが、根本的な運用上の問題よりは冗長な監視構成の症状であるため、アラートの重複はアラート疲れの別の原因になる可能性があります。最初のアラートで問題に気付いているので、追加のアラートによる通知によりフラストレーションが増える可能性があります。

相関アラート

相関アラートは最も困難ですが、おそらく最も認識すべき重要なノイズ源です。問題の根本原因に到達するのは、システム全体にわたって問題に影響するすべてのコンテキストをより速く捉えることであり、このコンテキストを逃すと調査とトラブルシューティングが時間の無駄となり、ウサギの穴に落ちてしまう恐れがあります。

過去1日または1週間のチームの履歴をさっとスクロールして、それぞれについて考えます。これらのカテゴリーのどれに当てはまるのですか？このような騒がしいページは気を散らし、フラストレーションを引き起こし、実際の問題を隠します。現代の運用システムの複雑さが増すにつれて、アラートのボリュームは増加する一方です。

適切なソリューションでアラート疲れを解消

New Relic AIのようなAIOpsプラットフォームを実装すると、システム全体でアラートノイズに取り組み、インシデントを関連付けて優先順位を付けるための継続的に改善された合理化されたシステムを作成できます。機械学習駆動のフィルターとロジックの多くのレイヤーがNew Relic AIを強化します。相関エンジンにより、これらすべてのノイズ源を探します。また、より関連性の高いアラートを継続的に提供するように適応し、アラート疲労れを軽減し、チームが重要な問題に集中できるようにします。New Relic AI（現在はプライベートベータ版）の詳細を今すぐご覧ください。