Category
インシデント＆アラート

メールアラートを改善したいですか？ もう一度考えてみましょう

監視システムは、稼働中のシステムをより効果的に管理するのに役立ちます。しかし、早期に問題を特定するためにチェックとしきい値を設定するのに多くの時間を費やしたとしても、アラート自体にはインシデント対応プロセスと同じくらいの意味しかありません。 PagerDutyがお客様の声を聞いてきた中で発見した最大の課題の1つは、どのお客様もメールアラートに悩まされているということです。 受信トレイがぐちゃぐちゃになって大切なものを見逃してしまいがちだと気づいていながらもなお、多くの監視システムとIT運用チームはメールアラートに依存しています。 メールアラートを改善しようとしていますか？ もう一度考えみてください。それでもまだこのまま使い続けようとお考えのあなたに、メールによるアラートをやめてしまった方がいい理由を5つお教えしましょう。

1. メールアラートは見過ごされやすぎる

「ねえ、友達が私にメールで送った最新の猫のビデオを見ましたか？」

受信トレイを常に見ていても、重大なアラートが他のアラートや仕事関連のメールに紛れてしまうのは日常茶飯事です。 このため、優れたオペレーションチームは、通常、少なくとも2つの通知チャネルを使用します。ひとつは、電話またはSMSメッセージです。 音でアラートを知らせることは間違いなく気づくのに役立ちます。

2. メールで誰かを確実にアサインすることはできません

「えーと、この件誰か対応してる？」

深刻なインシデントへの対応では時間が重要であり、チームの誰が対応に当たることになるのかで混乱している場合ではありません。アラートが複数の人にメールで送信されている場合、チームの誰が最初に応答するかを知る方法はありません。 他の誰かが既にそのメールを見て対応しているのか、自分はそのアラートに対応するのに最も相応しいのか、それとももっと経験豊富な人を待つべきだろうか。 優秀なオペレーションチームは、各インシデントが最適な担当者に自動的に割り当てられるようにします。 インシデント管理ツールとチケットシステムは、オンコールのエンジニアを自動的に割り当て、割り当てたエンジニアのステータスを追跡することにより、このワークフローを実行させます。

PagerDutyではオンコールのスケジュールに従い、すぐに対応に当たる人を決定してインシデントを割り当てます。

3. メールを集約またはバンドルすることはできません。

「これ、止められないのか？」

アラートの嵐が吹き荒れる。スタッフが対応を誤ると、すべての監視システムが毎分何度もアラートを送信します。膨大なアラートは受信トレイをたちまちあふれさせて、事実上使用できなくなります。 PagerDutyでは単一インシデントのアラートは1つに集約し、複数インシデントのアラートは、それぞれの最初の通知の後にまとめて通知します。したがって担当者が受け取るアラートは一度だけです。また、ダッシュボードにより現在進行中のインシデントの数とその出所を簡単に把握することもできます。

4. メールは状況を可視化してくれません

「現在のステータスはどうなってるんだ？」

メールでは、誰がインシデントに対処しているのか、経過時間、最新の状況の把握などは難しいです。この情報はチームだけでなく、経営幹部やその他のビジネス関係者にも重要です。あなたが対応している最中に、状況を知りたい人々に絶えず質問されるのも迷惑です。インシデントをPagerDutyのようなシステムに取り込むことで、管理者だけでなくチーム全員がアクセスできる単一のダッシュボードですべての情報を取得できます。 CEOやCTOがこれで問い合わせを控えてくれるとは限りませんが、少なくとも自分で情報を入手できる方法を伝えることはできます。

5. メールアラートでメトリクスを作成することはできません

「僕ら、うまくやれてる？」

優れたオペレーションチームは、パフォーマンスを継続的に測定、評価、改善するためにメトリクストラッキングを採用しています。全てのメトリクスをメールからトラッキングすることは非常に困難です。インシデントが発生した時刻、最初の人が気付いて応答するまでの時間、チームが解決するまでの時間などをトラッキングすることは、完了予想時刻を管理する上で大切になってきます。このデータを使用して作成したチームのパフォーマンスを示すダッシュボードと週ごとのレポートで、チームや企業内のコミュニケーションを容易にすることができます。

メールアラートの問題は、今まさにあなたが直面している課題かもしれませんが、それはあなただけの問題ではありません。

シンプルな 世界では、すべてのアラートは等しく発行され、インフラストラクチャは 完全に機能しているか、完全に壊れているかのどちらかで、その中間はありません。

しかし、実際には、世界はそれほど単純ではありません。インフラストラクチャがこれまで以上に多様で複雑な今日は特にそうです。

その複雑さに対処するには、監視とアラート管理に異なるアプローチが必要です。やって来るアラートに順番に応答するプロセスとして、またはすべてのアラートがアクションを必要とすると仮定して処理するよりもはるかに多くのことを要求されます。

この記事では、アラート管理に対する柔軟で微妙なアプローチが不可欠である理由と、その実装方法について説明します。

複雑化した現代のインフラ

柔軟なアラート管理プロセスが不可欠な理由を理解するために、現代のインフラストラクチャを複雑にする要因を検討してみましょう。次の点を考えてください。

階層化され相互依存しているインフラストラクチャ

以前はベアメタルのサーバとワークステーションがたくさんありました。今日、すべてがソフトウェアで定義される時代に、インフラストラクチャは物理マシンと仮想マシン、ソフトウェア定義のネットワーク、シンクライアント、断続的に接続されたセンサーなどからなる複雑なスタックであり、相互に絡み合っています。その結果、Docke化アプリケーションなどの1つのソースから発せられるアラートは、実際にはインフラの他の部分に根をもつ可能性があります（Dockerホストサーバが接続されているストレージアレイなど）。

いくつかの問題はより深刻

これは、インシデント管理の経験がある人にとっては自明のことです。それでも、今日の問題の範囲がどれくらい広がっているのか、アラートの重大度をすばやく解釈することがどれほど難しいのかを強調しておきましょう。たとえば、ストレージサーバが応答を停止したことを知らせるアラートは、一見すると非常に深刻に思えるかもしれません。ただし、サーバが自動フェイルオーバーを備えたスケールアウトされたストレージクラスタの一部である場合、ダウンタイムは実際には最優先事項ではありません。データが失われる可能性は低く、チームがすぐに問題に対応しなくともビジネス継続性は中断されません。さらに、一部のアラートは警告としては機能しますが、すぐに対処可能ではありません。その情報は、インフラストラクチャ全体のレベルでの異常検出のために保持する必要がありますが、アラートの嵐に疲れてしまわないために、人間の反応のトリガーにならないよう抑止する必要があります。

リアルタイム応答の重要性

今日の常時稼働の世界では、ユーザーはサービスの失敗をリアルタイムで知ることができます。したがって、アラート管理プロセスはリアルタイムでも発生する必要があります。あなたの会社に連絡する前に、SNSのような公開の場所に書き込む傾向があるという事実は、リアルタイム解決をより緊急事項にします。反応的ではなく積極的に行動する、顧客が怒りのツイートをするまでアラート対処を待つことは望ましくありません。

アプリケーションパフォーマンスの問題

アプリケーションが実行されていることを単に確認するだけでは不十分です。ユーザーはパフォーマンスの低下に対してほとんど忍耐力を持たないため、パフォーマンスを最善にする必要があります。たとえば、Webサイトの速度が遅い場合、顧客は10秒待たずに別のサイトに移動します。アラートの観点からこれが意味することは、アプリケーションが完全に応答を停止したときに通知されるだけでは不十分だということです。稼働の監視は重要ですが、パフォーマンスの低下に関するアラートも受け取る必要があります。さらに、無応答アラートと区別できる必要があります。

アラートを微妙に調整

最新のアラート管理の課題は以上のようなものですが、ではどのように解決できるでしょうか。 答えはアラート管理プロセスを非常に柔軟に、より機敏にすることです。次のような戦略を採用します。

優先順位の高いアラートを目立つようにする

最も重大なアラートに迅速に対応するには、それが簡単に見分けられる必要があります。優先度の高いアラートと優先度の低いアラートがダッシュボード上で混在していると、双方を見分けるのは困難です。監視ソフトが優先度の高いアラートをマークすればはるかに簡単になります。

役に立たない警告を抑止する

役に立たないアラートを排除することで、ダッシュボードの視認性を向上させることができます。新しいユーザーアカウントの作成など、優先度の低いイベントのアラートを抑制することなどです。このようなアラートを完全に無効にするのではなく抑止する利点は、緊急の時は紛らわされず、かつ必要に応じて表示させることができるからです。

微妙なアラートの報告と抑制

抑制は必ずしも命題ではありません。特定の状況では特定の種類のアラートをいくつか抑制できますが、他の状況では抑制しないことを選択できます。

たとえば、就業時間内にスタッフがアカウントを作成しているときにはアカウント作成に関連するアラートを抑制し、時間外に行った場合はアラートを表示する、ということができます。または、再起動が一定時間内に3回以上行われない限り、サーバの再起動に関する警告を抑制したい場合もあります。

また、重複した対策やコミュニケーションを防ぐため、関連するアラート間の関連付けを作成することも重要です。

重要なイベントを見逃さずにアラートノイズを最小限に抑えるには、抑止、関連アラートのグループ化、通知閾値のカスタマイズなどを実行し、アラートの重要度をより洗練された方法で判定する必要があります。

アラートによって送信先を変える

すべてのアラートをチームの全員に送るのは非効率的です。異なるタイプのアラートは、各人のスキルとスケジュールに応じて異なるメンバーに送る必要があります。対応する者が異なるということは、アラートの柔軟な割り当てが重要だということです。次の1時間インシデント管理にあたるエキスパートは、その後は非番になるかもしれません。

最初から適切な人にアラートを送信するようにしておくことで、問題を判定してスタッフに割り当てるために必要な手作業の多くを省くことができます。

システムダウンだけではない監視

前述のように、アラート管理の成功は今日、障害だけでなくパフォーマンスの低下を検出することを意味します。このため、システムが容量の限界に近づいたとき（ネットワーク負荷が80％を超える場合や、アプリケーションのCPUタイムが閾値に達したが、まだそれを超えていない場合）にアラートを生成するように監視ソフトウェアを設定することが重要です。

もちろん、これらのアラートに重大な障害と同じ優先順位を付ける必要はありません。障害インシデントは、直ちに知り直ちに処理することがより重要になります。しかし、何かが完全に壊れるまで待ちたいとも思いません。代わりに、アラート処理を最適化して、パフォーマンスの問題がシステムダウンに発展する前に処理できるようにします。

DevOps時代には、インフラストラクチャはアジャイルです。アラート管理プロセスもそうあるべきです。すべてのアラートが同等の重要性を有すると仮定したり、すべてのアラートを報告したりレビューしたりする必要があるとした時代は終わりました。圧倒されることなく現在の複雑で変化の激しいインフラストラクチャを監視するには、アラートに対する最適化されたアプローチが必要です。アラートを重要度に応じて識別し解釈するIT組織の能力が試されます。