IT インシデントのアラートとは?

監視の自動化

課題を迅速かつ効果的に特定する最善の方法は、監視の自動化です。

データベースの応答が通常より遅いですか? ユーザーのアプリの読み込み時間が平均より遅くなっていますか? 不可欠なシステムがダウンしていますか? 技術者の 1 人から赤い旗の可能性があるリクエストがありましたか? このような問題が自動的に監視されて、問題が発生した際に通知されるようにする必要があります。

スマート アラートのしきい値の設定

すべてのアラートに対して即時の対応が必要ですか? ほとんどの企業では不要なので、合理的なアラートのしきい値を設定する必要があります。

夜中に開発者をたたき起こす価値があるか朝まで待てる内容なのかを見分けることが、素早く対応できる満足度の高い開発者と、新しい仕事を探して週末を過ごすアラートに疲弊したチームとの相違点となり得ます。

アラートの重複排除

アラートによる疲弊に関するある研究によると、病院の臨床医は重複するアラートを受信するたびにアラートに対する注意力が 30% 低下することがわかりました。この研究結果はおそらく、開発者にとっても同じになる可能性が高くなります。同じアラートを何度も確認すると、そのアラートに対する注意力は低下します。ここでのベスト プラクティスがアラートの重複を排除してリマインダーを最小限に抑えることになるのは、そのためです。

優先度および重大度レベルの設定

明らかに、アラートの中には他のアラートよりも重要なものがあります。Web サイトの停止はまず間違いなく、使用頻度の低い機能の速度が短時間に低下していることよりも優先されるでしょう。悪意のあるハッキングは十中八九、アプリ内で正しくレンダリングされない画像よりも優先度が高いでしょう。

システムによって、アラートの優先順位と重大度が認識されるだけでなく、インシデントを解決する責任者にその優先順位が明確に伝わる必要があります。ここでのベスト プラクティスは、視覚的、聴覚的、感覚的な指示を利用して、チームが次に焦点を当てるべき内容を迅速かつ明確に示すことです。

実用的なアラートの設定

間違いを把握することは良いことであり、次に実行する内容を把握することは、より良いことです。そのため、アラートが実用的でない場合は実用的にする必要があります。

DevOps チームが航空業界から学べることの 1 つです。飛行中にパイロットの計器盤にアラートが表示されると、実用的なチェックリストも一緒に表示されます。このような詳細をアラート システムに組み込むと、診断時間が短縮されて開発者がプロセスを通じて素早く行動できるようになります。

これは特に、開発者が真夜中に目がかすんでいる状態で起き上がって、最高の状態とはいえないときに役に立ちます。

適切なアラート テクノロジーの選択

これらのベスト プラクティスに従った IT アラート システムを開発することは、アラートに前もって戦略的に取り組むことを意味します。また、このために適切なテクノロジーを選択することでもあります。ベンダーを選ぶときは、以下の実現を目指すことをおすすめします。

複数のアラート通知チャンネル

アラートに関しては、チャンネルとしてメールが選択されることがよくあります。しかし、実際には必ずしもメールが最適解というわけではありません。緊急アラートの場合は、SMS、モバイル プッシュ通知、または音声通話さえも必要な場合があります。さまざまな方法でアラートを通知できるシステムを見つけてください。

情報が豊富なアラート

実用的なアラートは、詳細なアラートです。短いテキスト メッセージでは不十分な場合があるということです。厳密な文字制限に注意して、グラフ、ログ、ランブック、チェックリストを添付してアラートにコンテキストを追加し、開発者が次に実行する内容を伝えられるテクノロジーを見つけてください。

アラート アクションのカスタマイズ

ほとんどのアラート テクノロジーでは、アラートにメモを追加したりアラートを一掃したりできます。しかし、場合によっては、その間に段階がある場合があります。詳細な調査のためのアラートのエスカレーション、サービス チケットの作成、サーバーの再起動などがあります。アラートのオープンやクローズに留まらないより多くを実現できる技術ソリューションを見つけてください。

アクションの自動化

アラートによっては、次に実行する内容が複雑で、経験豊富な開発者のインサイトが必要な場合があります。それ以外の場合は、その後の方法は明確です。

診断テストや是正措置など次のステップが明確なアラートの場合は、事前定義された基準を満たすアラートに応じてそれらの応答を自動的にトリガーするシステムが必要になります。

たとえば、データベースの速度が遅い場合は、アラート システムがバックアップ データベースに自動的に切り替わるように設定するとよいでしょう。課題 A を修正するための最初の手順が常にサーバーの再起動である場合は、サーバーを再起動して結果を監視するようにアラート システムを設定して、真夜中にアラートを送信せずに済むようにします。

アラートのカスタマイズと分類

アラートを受信したら、チームはそれらを整理して追加情報をタグ付けし、フィルタリングできる必要があります。

アラートのライフサイクルの追跡

インシデントの事後分析では、アラートを受信した時間、受信した担当者、確認した時間、講じた措置を把握する必要があります。選択したテクノロジーによって、これらの詳細を自動的に追跡できるようにします。これにより、うまくいっていることとうまくいっていないことを把握し、KPI を改善し、過去のインシデントを文書化することが容易になります。そのため、オンコール チームがそれらから学習して、今後のインシデントのために習得した内容を参照できるようになります。

アラート ポリシーと通知ポリシー

ここでのベスト プラクティスが、アラートにインテリジェントなしきい値を設定してぐっすり眠っている開発者を軽微な課題のために起こさないようにすることであれば、コンテンツとタイミングに基づいてアラートを抑制、遅延、効率よく処理できるテクノロジーが必要です。

監視のためのリアルタイム モニタリング

アラート システムが稼働していることを常に把握するにはどうしたらよいでしょうか?

解決策としては、技術チームが適切なテクノロジーを使用して独自の監視システムを採用することです。当社では、Opsgenie で Heartbeats というツールを利用して実現しています。このツールは、監視ツールがアクティブで接続されていることと、カスタマイズしたタスクが予定どおりに完了していることを継続的に確認します。信号がダウンすると、即座にアラートが送信されます。