シンプルな 世界では、すべてのアラートは等しく発行され、インフラストラクチャは 完全に機能しているか、完全に壊れているかのどちらかで、その中間はありません。
しかし、実際には、世界はそれほど単純ではありません。インフラストラクチャがこれまで以上に多様で複雑な今日は特にそうです。
その複雑さに対処するには、監視とアラート管理に異なるアプローチが必要です。やって来るアラートに順番に応答するプロセスとして、またはすべてのアラートがアクションを必要とすると仮定して処理するよりもはるかに多くのことを要求されます。
この記事では、アラート管理に対する柔軟で微妙なアプローチが不可欠である理由と、その実装方法について説明します。
複雑化した現代のインフラ
柔軟なアラート管理プロセスが不可欠な理由を理解するために、現代のインフラストラクチャを複雑にする要因を検討してみましょう。次の点を考えてください。
階層化され相互依存しているインフラストラクチャ
以前はベアメタルのサーバとワークステーションがたくさんありました。今日、すべてがソフトウェアで定義される時代に、インフラストラクチャは物理マシンと仮想マシン、ソフトウェア定義のネットワーク、シンクライアント、断続的に接続されたセンサーなどからなる複雑なスタックであり、相互に絡み合っています。その結果、Docke化アプリケーションなどの1つのソースから発せられるアラートは、実際にはインフラの他の部分に根をもつ可能性があります（Dockerホストサーバが接続されているストレージアレイなど）。
いくつかの問題はより深刻
これは、インシデント管理の経験がある人にとっては自明のことです。それでも、今日の問題の範囲がどれくらい広がっているのか、アラートの重大度をすばやく解釈することがどれほど難しいのかを強調しておきましょう。たとえば、ストレージサーバが応答を停止したことを知らせるアラートは、一見すると非常に深刻に思えるかもしれません。ただし、サーバが自動フェイルオーバーを備えたスケールアウトされたストレージクラスタの一部である場合、ダウンタイムは実際には最優先事項ではありません。データが失われる可能性は低く、チームがすぐに問題に対応しなくともビジネス継続性は中断されません。さらに、一部のアラートは警告としては機能しますが、すぐに対処可能ではありません。その情報は、インフラストラクチャ全体のレベルでの異常検出のために保持する必要がありますが、アラートの嵐に疲れてしまわないために、人間の反応のトリガーにならないよう抑止する必要があります。
リアルタイム応答の重要性
今日の常時稼働の世界では、ユーザーはサービスの失敗をリアルタイムで知ることができます。したがって、アラート管理プロセスはリアルタイムでも発生する必要があります。あなたの会社に連絡する前に、SNSのような公開の場所に書き込む傾向があるという事実は、リアルタイム解決をより緊急事項にします。反応的ではなく積極的に行動する、顧客が怒りのツイートをするまでアラート対処を待つことは望ましくありません。
アプリケーションパフォーマンスの問題
アプリケーションが実行されていることを単に確認するだけでは不十分です。ユーザーはパフォーマンスの低下に対してほとんど忍耐力を持たないため、パフォーマンスを最善にする必要があります。たとえば、Webサイトの速度が遅い場合、顧客は10秒待たずに別のサイトに移動します。アラートの観点からこれが意味することは、アプリケーションが完全に応答を停止したときに通知されるだけでは不十分だということです。稼働の監視は重要ですが、パフォーマンスの低下に関するアラートも受け取る必要があります。さらに、無応答アラートと区別できる必要があります。
アラートを微妙に調整
最新のアラート管理の課題は以上のようなものですが、ではどのように解決できるでしょうか。 答えはアラート管理プロセスを非常に柔軟に、より機敏にすることです。次のような戦略を採用します。
優先順位の高いアラートを目立つようにする
最も重大なアラートに迅速に対応するには、それが簡単に見分けられる必要があります。優先度の高いアラートと優先度の低いアラートがダッシュボード上で混在していると、双方を見分けるのは困難です。監視ソフトが優先度の高いアラートをマークすればはるかに簡単になります。
役に立たない警告を抑止する
役に立たないアラートを排除することで、ダッシュボードの視認性を向上させることができます。新しいユーザーアカウントの作成など、優先度の低いイベントのアラートを抑制することなどです。このようなアラートを完全に無効にするのではなく抑止する利点は、緊急の時は紛らわされず、かつ必要に応じて表示させることができるからです。
微妙なアラートの報告と抑制
抑制は必ずしも命題ではありません。特定の状況では特定の種類のアラートをいくつか抑制できますが、他の状況では抑制しないことを選択できます。
たとえば、就業時間内にスタッフがアカウントを作成しているときにはアカウント作成に関連するアラートを抑制し、時間外に行った場合はアラートを表示する、ということができます。または、再起動が一定時間内に3回以上行われない限り、サーバの再起動に関する警告を抑制したい場合もあります。
また、重複した対策やコミュニケーションを防ぐため、関連するアラート間の関連付けを作成することも重要です。
重要なイベントを見逃さずにアラートノイズを最小限に抑えるには、抑止、関連アラートのグループ化、通知閾値のカスタマイズなどを実行し、アラートの重要度をより洗練された方法で判定する必要があります。
アラートによって送信先を変える
すべてのアラートをチームの全員に送るのは非効率的です。異なるタイプのアラートは、各人のスキルとスケジュールに応じて異なるメンバーに送る必要があります。対応する者が異なるということは、アラートの柔軟な割り当てが重要だということです。次の1時間インシデント管理にあたるエキスパートは、その後は非番になるかもしれません。
最初から適切な人にアラートを送信するようにしておくことで、問題を判定してスタッフに割り当てるために必要な手作業の多くを省くことができます。
システムダウンだけではない監視
前述のように、アラート管理の成功は今日、障害だけでなくパフォーマンスの低下を検出することを意味します。このため、システムが容量の限界に近づいたとき（ネットワーク負荷が80％を超える場合や、アプリケーションのCPUタイムが閾値に達したが、まだそれを超えていない場合）にアラートを生成するように監視ソフトウェアを設定することが重要です。
もちろん、これらのアラートに重大な障害と同じ優先順位を付ける必要はありません。障害インシデントは、直ちに知り直ちに処理することがより重要になります。しかし、何かが完全に壊れるまで待ちたいとも思いません。代わりに、アラート処理を最適化して、パフォーマンスの問題がシステムダウンに発展する前に処理できるようにします。
DevOps時代には、インフラストラクチャはアジャイルです。アラート管理プロセスもそうあるべきです。すべてのアラートが同等の重要性を有すると仮定したり、すべてのアラートを報告したりレビューしたりする必要があるとした時代は終わりました。圧倒されることなく現在の複雑で変化の激しいインフラストラクチャを監視するには、アラートに対する最適化されたアプローチが必要です。アラートを重要度に応じて識別し解釈するIT組織の能力が試されます。
カテゴリー ：インシデント＆アラート
