便利だけど煩わしい？ 「よくある4つのITアラート」への対応方法：「リソース」「パフォーマンス」「可用性」「セキュリティインシデント」

TechTargetは「ITアラートへの対応方法」に関する記事を公開した。ITアラートは、サーバの障害や混雑したネットワークの状況を知らせてくれる。ITアラートが表示されたら、ITの管理者はすぐに行動を起こす必要がある。

[Rob Bastiaansen，TechTarget]

　TechTargetは2024年3月27日（米国時間）、「ITアラートへの対応方法」に関する記事を公開した。

よくある4つのITアラートへの対応（提供：TechTarget）

　IT環境の管理者（以下、管理者）がITアラートから把握できる情報は、実際に起こっている現象のほんの一部だ。水面下にはもっと大きなものが潜んでいる可能性がある。

　管理者が、データセンターで稼働しているITインフラを実際に見たり触ったりする機会はほとんどないだろう。だが、それらのコンポーネントを通じて管理者は、サーバ障害やディスクリソース不足、ネットワークの混雑など、外部からは確認できない問題に悩まされる可能性がある。

　何か問題が起きて、ユーザーが必要なリソースにアクセスできなくなったら、サービスデスクに連絡が来るだろう。しかし、そのときになって初めて問題に気付くようでは事態は手遅れになっている可能性がある。組織は、傾向分析を使用して、問題が発生したとき（または問題が発生する前）にそれを検出できるアラートを設定する必要がある。こうしたアラートを電子メール、テキストメッセージ、またはそれ以外の方法で管理者に送信することで、問題が発生する前（もしくは制御不能になる前）に対応できるようになる。

4つの一般的なITアラートへの対応方法

　ITアラートが指し示す問題は多くの場合、「リソース」「パフォーマンス」「可用性」「セキュリティインシデント」の4つに分類される。管理者はこれらのアラートを起点に根本的な原因を見つけなければならない。

1．リソースのトラブル

　例えば運用チームが主要なITインフラのリソースが不足していることを知ったとする。ワークロードが仮想化されていればリソースを増やすのは簡単だ。しかし、ここで運用チームが気を付けるべきなのは、単にリソースを増やすことではなくリソース不足の原因を探ることだ。通常、ITインフラのリソースは、数週間または数カ月にわたって安定的に使われるため、突然不足することはない。そのため急激に使用量が増加した場合は、アラートを発したITインフラをしっかりと確認し、その原因を調査することが重要だ。

　ITインフラの確認項目は幾つかある。例えば「ITインフラに最近パッチが適応（もしくはアップグレード）されていないかどうか」などだ。そうした作業の際に、管理者がアップグレード用のプログラムをサーバに置き忘れているかもしれない。ただ、こうした単純な理由であっても、リソース不足の問題は意外に深刻だ。無計画に問題を修正すると、クラウドリソースのコストはもちろん、バックアップやその他のディザスタリカバリー機能などにも影響する可能性があるからだ。

　リソースのトラブルで重要なのはトレンド（傾向）を見ることだ。使用量の増加率が一定で、スパイク（急激な変動）がほとんどないのであれば恐らくそれは正常な動作だ。こうした場合はリソースを増やすことが解決策となる。だが、こうした傾向を調べず、不足のたびにリソースを増やして対処するようになると、その動きは誰にも止められなくなる。反射的にリソースを増やすだけでも一時的に問題解決はできるが、そうした対応では、突然発生するリソース不足の問題を解決できない。

2．低迷するパフォーマンス

　アプリケーションの応答に非常に時間がかかっている（と思われる）場合、それは「一般的な障害アラート」と見なせる。これは追跡するのが困難な問題の一つだ。アプリケーションはさまざまなITインフラを使っているため、問題の原因はさまざまな場所に存在するかもしれないからだ。

　解決するには、アプリケーションがユーザーに届くまでの過程で関係する全ての要素を理解し、全体像を把握することが重要だ。ただ、このやり方は非常に時間がかかる。

　そこで有効なのが「瞬間的なパフォーマンス統計」を利用することだ。このデータだけで根本原因が明らかになるわけではないが、どこに注意すればいいのかが明確になり、問題解決に近づくことができる。例えば履歴データと組み合わせることで、問題の原因が明らかになることもある。

3．可用性の問題

　ハードウェアやその他のシステムが突然故障することはめったにない。そのため、何かが故障したときは、その原因を突き止めることが重要だ。

　サービス復旧を最優先にするあまり、原因究明をせず、ITインフラの再起動などを実施することがある。するとその作業で「失敗した理由」に関するデータが失われる可能性がある。（もちろん復元を優先するのは正しい動きだが）その前に、可能な限り全てのデータをキャプチャーする必要がある。これは、「エラーコードやダンプ画面の写真を撮る」といった簡単なことでも構わない。全てのエラーはログファイルに取り込まれるべきだが、必ずしも「そうしなければエラーが特定できない」というわけではない。

　別の観点では「ITインフラの変更」も注意する必要がある。ITインフラに変更を加える（機器の入れ替えや設定の変更、パッチ適応などをする）ことで可用性の問題が発生することはよくあるが、変更しないことで影響が出る場合がある。特にDNS、動的ホスト設定プロトコル、鍵管理サービスなどのアラートは、特に注意しなくても動作的には問題ないことが多く、忘れがちだ。適切な再起動やパッチ適用、メンテナンスが実施されないと、これらの重要なサービスにメモリリークが発生したりクラッシュしたりする可能性がある。例えばMicrosoftの鍵管理サーバが失われると、環境内の全てのMicrosoft製品に影響が出る。

　この種の問題を追跡するのは非常に難しい。だからこそ、管理者はアプリケーションの流れを理解することに長けていなければならない。

4．セキュリティインシデント

　管理者にとって、セキュリティインシデントへの懸念はますます深刻なものになっている。セキュリティの問題は、その他の問題にもつながる可能性がある。例えばサービス拒否攻撃（DoS攻撃）はリソースやパフォーマンスの問題を引き起こすかもしれないし、場合によっては可用性が失われる可能性もある。

　こうした懸念を拭い去るには、セキュリティ侵害のアラートを受け取れる新しいITインフラを使えるようにしなければならない。多くのベンダーは、IDS/IPS（不正侵入検知システム／不正侵入防止システム）のツールを提供している。「VMware NSX」などセキュリティとネットワークが統合されたサービスは、ファイアウォールをIDS/IPSと連携させることでマルウェアの侵入を防止し、ネットワーク上の不審な行動を検出可能だ。こうした、ネットワークの検知と対応機能は「何が起きているのか、どのように対応すべきなのか」を洞察するための総合的なアプローチを提供してくれる。

ITアラートの長所と短所

　ITにおける“アラート”は、便利であると同時に煩わしいものだ。アラートが多過ぎると、IT担当者は警告を無視するようになる。かといって、アラートが少な過ぎると、問題が小さいうちに対応する機会をIT担当者が逃してしまう可能性がある。

　アラートには、何か大きなことの始まりを知らせるもの（つまり、早急な対応が必要なもの）もあれば、「週明けを待って対応すれば十分」といったレベルのものもある。この違いを見分けるには、自社で使用されているツールを知り、自社のIT環境を深いレベルで理解しなければならない。