BLOG
ファーストデータ、ファーストモニタリング

ビッグデータはもう古い。 今日、データを効果的に活用するための鍵は、ファーストデータです。

大量の監視情報の収集と分析を伴う従来のインシデント管理ではもはや十分ではありません。 また、監視データの収集だけでなく それをリアルタイムで実行する「ファーストモニタリング」が必要とされています。

ここでは、ファーストモニタリングが意味することを検証し、インシデント管理チームがこのアプローチを実装して大きなメリットを実現する方法について説明します。

ファーストデータの定義

ファーストモニタリングの概念を理解するためには、ビッグデータの世界で最も新しいイノベーションの1つであるファーストデータを理解する必要があります。

非常に簡単に言えば、ファーストデータは高速にビッグデータを処理することです。 ビッグデータとは、伝統的に大量の情報を保存して後で分析することを意味しますが、ファーストデータとは、大量の情報をできるだけ速く、理想的にはリアルタイムでデータ分析を実行することを意味します。 その目標は、できるだけ実用的で関連性のあるデータを分析することです。

ソースから分析プラットフォームにデータをストリームするのは、ファーストデータを活用する上で重要な部分です。 これが、Apache Sparkのようなビッグデータツールが近年普及している理由です。 ストリームデータの収集とインメモリ処理をサポートすることにより、Sparkは非ストリーミングやハードディスクによるデータ解析プラットフォームよりもはるかに高速で大量の情報を取り込み、分析できます。

ファーストデータとインシデント管理

インシデント管理はデータ分析とは異なる分野ですが、インシデント管理者はファーストデータへの移行トレンドから多くのことを学ぶことができます。 インフラストラクチャの監視とインシデント管理の世界では、大量の監視とアラートのデータをリアルタイムで分析してレスポンスを向上させることが、これまで以上に重要になっています。

伝統的なインシデント管理から迅速なインシデント管理まで

ファーストデータとファーストモニタリングのつながりは偶然ではありません。多くの点で、インシデント管理の進化はデータ分析の進化を反映しています。

約10年前までは、インフラストラクチャのデータは比較的小さくて済んでいました。ほとんどの組織では、それほど多くのデータを生成しなかったため、ペタバイトクラスのデータを分析する必要はありませんでした。同様に多くの組織は、大規模で多様なインフラストラクチャをサポートできる監視ソリューションを必要としませんでした。代わりに、サーバやワークステーションからなる比較的小さくて複雑ではないネットワークをトラックするためのベーシックな監視システムで済んでいました。

そして、2000年代半ばには、データとインフラストラクチャの両方が大幅に拡大し始めました。すべてをデジタル化することで、組織は大量の情報収集を開始し、ビッグデータを生み出しました。その一方で、モバイルデバイスの普及、仮想化の台頭、さらにますます強くなるコンピューティングパワーの必要性は、インフラストラクチャをはるかに大きく複雑にしました。この新しい状況には大規模なモニタリングが必要でした。

そして、ここ数年の間に、もうひとつの変化が起こっています。情報が絶えず変化している時代には、ほんの数時間の分析の遅れでもデータの価値が損なわれます。同様に、最新ではない情報を監視することに基づいてインシデント管理を実行することにより、管理者はインシデントを迅速に処理して対応することができなくなります。

したがって、ファーストデータとファーストモニタリングには異なるツールセットが必要な場合がありますが、両方の動機と原則は同じです。インシデント管理チームがインフラストラクチャとアプリケーションをできるだけスムーズに稼動させようとファーストモニタリングに専念するのは、データアナリストの仕事とよく似ています。

ファーストモニタリングの促進

情報の収集と迅速な対応は簡単に聞こえるかもしれませんが、実際にはどのようにしてファーストモニタリングを行うことができるでしょうか。主なガイドラインは次のとおりです。

• データ収集を一元化する: 迅速に情報を監視するためには、すべての監視データを中央のインターフェイスに転送する必要があります。これにより、異なるダッシュボードや監視システムを切り替える必要がなくなり、時間と精神的なエネルギーを無駄にするだけでなく、根本原因を理解することが非常に困難になります。
• 利用可能なすべての情報を収集する: 伝統的なインシデント管理は、マシンのデータとアラートの収集だけに集中する傾向があります。その情報は、迅速な監視を行うために必要なものの一部を提供しますが、可能な限り迅速にインシデントに対応するためには、可視性と洞察力を可能な限り広げるべきです。たとえば、チケットやサポートコールから人間が生成したデータを収集することを無視してはいけません。これは、PagerDutyのカスタムイベントトランスフォーマーなどの機能を活用して、従来はインシデント管理ワークフローの一部ではないソーシャルメディアチャネルなどのソースからデータを収集することも意味します。
• ノイズを最小限に抑える: 大量のアラートを受け取っても、アクションを必要とするのはそのうちの一部だけです。 したがって、警告の数が最小限になるようにノイズをカットし、対応不要なものを抑止することは絶対に重要です。重複するアラートは自動的に排除されるべきであり、解決が必要な単一の問題に関連する症状をグループ化するのは簡単なはずです。これにより、注意を必要とするアラートの瞬時識別が容易になり、リアルタイムで適切な応答ワークフローが開始されます。
• データを解釈しやすくする: 大量の監視データを収集し、中央の場所に格納することで、そのデータをすぐに価値に変えることができます。 しかし、ダッシュボード上の情報を分析する負荷を軽減するには、さまざまなソースからのデータを一貫した形式に正規化する必要があります。 そうすれば、さまざまなベンダーのすべてのスキーマを暗記する必要はありません。 これを実現するには、さまざまな形で情報を取得し、フィールドを普遍的なものに標準化し、即座に実行可能でわかりやすい洞察を与えるインシデント管理ソリューションが必要です。

これらのプラクティスはすべて、重大な事故の際にインシデント管理者が必要とする手動分析の量を最小限に抑えます。 また、アラート収集とアクションの間隔を最小限に抑え、インシデント管理スタッフがインシデントに素早く反応し、ファーストモニタリングをリアルタイムレスポンスに変えて正常稼働時間を向上させます。