ベストプラクティス

アラートエスカレーションポリシーの最適化

アラートに対応するのは面倒ですが、事前に対応して IT アラートに関するフラストレーションを軽減する方法があります。 アラート戦略の開発による節約 ITオペレーション 開発チームは時間とお金を節約し、優先度の低いアラートからの通知を排除します。 ルーティングとエスカレーション チェーン、フィールド アラート、およびアラート戦略を経営陣に伝達する方法の詳細については、引き続きお読みください。 

重大度のアラート レベル

ほとんどのアラートには、警告、エラー、クリティカルの XNUMX つの重大度レベルがあり、通常は警告アラートが最も重大度が低くなります。 重大度レベルは組織によって異なりますが、ほとんどの内部アラートには、これら XNUMX つのレベルのバリエーションがあります。

警告: 警告は、注意すべき点があることを示しています。これは、現在は問題になる場合とそうでない場合がありますが、近い将来に間違いなくエラーになる可能性があります。 多くの場合、適切なプロアクティブな測定を行うことで、警告がさらにエスカレートする前に修正できます。

エラー: エラーは、何かが間違っているか、正しく動作していないことを示します。 これらは早急に修正する必要があり、調査する必要があります。

重大: 重大な問題は通常、何かが壊れており、すぐに注意を払う必要があることを意味し、重大な問題をできるだけ早く解決するための措置を講じる必要があります。

続きを読む: 異なるアラート重大度の意味

ルーティングとエスカレーション チェーン 

ルーティングとエスカレーション チェーン どのアラートをどのチームにルーティングする必要があるかを把握する目的に役立ちます。 また、これらのアラートの重大度とそれに対応する通知レベルも決定します。

最も単純なエスカレーション チェーンは、警告レベルのアラートを電子メールまたは Web 専用システムに送信することです。 テキストまたは電話で送信される警告レベルのアラートが多すぎると、アラート疲れやアラートに圧倒される可能性があります。 目標は、問題を確実に修復することですが、短時間の停止を許容できるシステムのために夜中に誰かを起こしてしまうなど、不必要なアクションを実行したくはありません。

エラーまたは重大なアラートには、SMS またはその他のライブ プッシュ ベースの通知システムが必要です。 チームの複数のメンバー間でエスカレートできます。 これは、誰がアラートを確認するかに依存し、その後エスカレーションが停止します。 エスカレーション チェーンを使用して、人々が通知を受ける方法をずらすことができます。 その他のオプションは、アラートの重大度に応じてチーム全体にスパムを送信する「万歳」アプローチです。

フィールディング アラート 

アラートが通知されると、問題のトラブルシューティングを担当する担当者は、顧客への影響に基づいてアラートの重大度を迅速に評価できる必要があります。 顧客への影響は、顧客と従業員の両方を調べます。 従業員が顧客に影響を与えないアラートに気を取られている場合、そのアラートの設定を調整する必要がある場合があります。 アラートを出して問題を解決するための一貫したプロセスが整っている必要があります。

アラートを確認することは、そのアラートのエスカレーションを停止するか、サポートを提供できる次のチームにすぐにエスカレートするために重要です。 問題が解決した後でも、問題の診断を続けることが重要です。 重要なステップは、アラートの有効性を改善するために何らかの方法でアラートを調整できるかどうかを検討することです。 「アラートは顧客向けですか?」という質問をするのがよいでしょう。 答えが「はい」の場合は、すぐに対応してください。 そうでない場合は、アラートが実際にどれほど緊急であるかを調べます。

アラートのトップレベルビューを示すアラートチェーン図。

アラート戦略を経営陣に伝える方法

より効率的なアラートシステムにより、企業はコストを節約し、ビジネスの他の領域に再割り当てすることができます。 ITチームは、アラートの疲労や優先作業からの不必要な気晴らしを回避することで、より多くの時間を解放することもできます。 節約された時間とお金を他の関連データとともに特定することは、警告戦略を経営陣に伝えるための最良の方法です。 数字は大いに役立ち、変更を加えることの戦略的価値を示しています。 チームメンバーの仕事を簡単にする場合は、チームメンバーの完全なサポートが得られる可能性があるため、これらのディスカッションにチームメンバーを含めることを忘れないでください。 

チームの現在のアラート慣行を詳しく調べるときは、完璧なシステムはないことに注意してください。 ただし、ITアラートのエスカレーションポリシーの改善に取り組んでいます LogicMonitorのガイダンス を改善するためのステップです ITインフラストラクチャの機能.

14 年 2020 月 2022 日に最初に公開されました。XNUMX 年 XNUMX 月に更新されました

著者
LogicMonitorチーム
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

私たちのブログを購読する

このような記事をあなたの受信箱に直接お届けします