モニタリングでAIがまだ離陸していないのはなぜですか?

LogicMonitor意見投稿

アルゴリズムによるIT運用(またはAIOps)は、複雑なエンタープライズ監視の状態を改善する大きな可能性を秘めています。 依存関係データ、負荷相関、異常検出、およびその他のシステムを追加すると、今日の監視システムの効率が大幅に向上します。 ただし、真の人工知能は、AIOpsの他の側面よりも貢献が少ない可能性があります。

AIは定義されていますか?

人工知能(AI)と、現代の運用チームとそのツールが扱う膨大な量のデータを使いこなすためのディープラーニングについては多くの話があります。 アナリストは、AI機能がどんなにマイナーであっても、製品の長所として、そしてそれらの欠如を短所として頻繁に宣伝していると報告しています。 しかし、AIの効果的な使用法は出現しておらず、ネットワーク運用で広く採用されていると主張しているようです。 サーバー監視。 何故なの?

問題の一部は、AIがソフトな定義であるということです。 MITの人工知能研究所の所長であるロドニーブルックスとして、 言う、「私たちがそれの一部を理解するたびに、それは魔法ではなくなります。 「ああ、それはただの計算だ」と私たちは言います。 したがって、定義上、AIに実際に到達することはありません。 LogicMonitorには、膨大な量のデータ間で数値相関を実行し、識別された奇妙なパターンと類似性を探す機能があります(たとえば、データベースのディスクレイテンシが増加した場合、類似したパターンを持つ他のメトリックを識別できます。Webサイトの要求?ネットワークの再送信? QAシステムからのデータベースクエリ?これにより、根本原因の候補を絞り込むことができます)。 AIのようなシステムは考えていません。 「ただ」 よく理解されている統計手法の適用。 しかし、20年前の運用担当者にとっては、間違いなくインテリジェンスのように思えます。

AIとしての機械学習

いくつかの技術は(少なくとも今のところ)AIとして広く認識されています。 機械学習もそのXNUMXつです。 機械学習は、「本当の」知性の領域であると考えられていたあらゆる種類の分野での適用性を見出しています。 チェスや囲碁で人間を打ち負かし、詩人が生み出したものと同じくらい良い交響曲や俳句を作曲することができます。 では、運用上のトラブルシューティングを行ってみませんか?
理由のXNUMXつは、教師あり機械学習はルールを学習して従う必要があるということです。 完成したゲームなど、一連のデータについてトレーニングする必要があります。 トレーニングセットからモデルを生成し、そのモデルを使用して、学習した内容を新しいゲームやコンポジションに適用できます。

正しい結果、間違った理由

Opsの世界での教師あり学習の問題のXNUMXつは、AIが抽出したルールがわからないことです。 正しい結果が得られている可能性がありますが、理由は間違っています。
私が知っているこれの最も楽しい例は 賢いハンス。 ハンスは算数ができる馬でした。 足し算、引き算、割り算。 馬に質問すると、大声で数えている人が正解に達したときを示します。 彼はこれを確実に、定期的に、そして繰り返し行うでしょう。 唯一の問題は、馬が数学の問題を解いておらず、正しい数字を聞いていないことでした。 彼は周りの人々を見ているだけで、彼らのボディーランゲージが適切な瞬間を示したとき、彼は足を踏み鳴らしました。 彼は事実上、数学パズルに答えを与えるように訓練されたニューラルネットでしたが、ハンスは予想された方法ではなく答えを抽出していました。 そして、実際にハンスの計算能力に頼りたくて、事前に答えを知らなかった場合に役立つ方法ではありません。

同様に、AI視覚認識システムは、ヒョウとチーター、オセロットを非常に正確に区別するようにトレーニングできます。 しかし、彼らはまた識別します ヒョウのソファ。 (ヒョウを防御するためにこれらのアルゴリズムに依存している場合、問題を想像することができます…)答えがわかっているときにAIの動作を確認できますが、答えがわからないときにAIに頼ると、何にでも依存することになります。トレーニングデータから適用可能と見なされるシステムの手がかり—そしてあなたはそれらが何であったかを知りません。 これは、デバイスのホスト名に「P」という文字が通常より多く出現しているため、デバイスが根本原因である可能性が高いと特定されている可能性があります。これは、トレーニングデータセットの未知のアーティファクトである可能性があります。

あなたが正しい答えを得れば、あなたの推論を説明できないことは問題ではないことを認めます。 プロのバイクレーサーは、トラクションを失って滑り出す前に、特定のコーナーをどれだけ速く周回できるかを正確に伝えることができます。 物理学者もそうだろう。 物理学者は自分の仕事を示し、摩擦係数、および横方向と縦方向のベクトルを説明できます。 サイクリストは彼がどのように知っているかを説明することはできません—しかし彼は知っています。

したがって、AIのプロセスに対する洞察の欠如は、必ずしも運用でのAIの使用を妨げるものではありません。 むしろ、AIはそのトレーニングセットによって制限されているという事実です。 AIは、芸術的で心地よい交響曲がどのように聞こえるかという現在の期待に一致するため、私たちが楽しむ交響曲を書くことができますが、創造性の限界を押し上げることはできず、規則に違反する交響曲を作成し、それらが引き起こす十分な感情的影響を生み出します 暴動 —その後すぐに上品な芸術と見なされました。

モニタリングに関するAIインサイト

IT運用では、優れた運用慣行により、ほとんどの問題が固有のものであることが求められます。 以前の問題は、再発しないように対処する必要がありました。または、少なくとも、状況を明確に警告するように監視を構成する必要がありました。 これらの条件のいずれも当てはまらない場合でも、インシデントは未解決であると見なされます。 したがって、問題がほとんど固有のものである場合、トレーニングセットはそれらをカバーしておらず、AIからの洞察がひどく洞察に満ちているか役立つ可能性は低いです。 実際、賢馬ハンスに納税申告書の計算を依頼するなど、気を散らすものやガチョウの追跡である可能性があります。 (もちろん、いくつかの既知の問題は再発します。確かにAIはそのような問題のコンテキストを提供するのに役立つため、経験の浅いスタッフは、経験の豊富なスタッフが持つ可能性のあるより大きなコンテキストに依存することなく、問題を解決できます。)

これを回避する1つの方法は、顧客のさまざまな運用データのセット全体で情報をマイニングすることです。 クォーラム構成を根本原因とするZookeeperに問題があり、それを解決したという事実は、問題が再発することはないはずですが、その知識はZookeeperを実行している他の企業にとって役立つ可能性があることを意味します。 もちろん、ここにはデータのプライバシーだけでなく、データのラベル付けやトレーニングにも問題があります。 zookeeperノードをタグ#zookeeperと#prodでz34.prodとして識別し、タグ#quorumと#liveでnXNUMX.lax.us.westを呼び出す場合、トレーニングレッスンを可能にするために共通性を確立するにはどうすればよいですか。適用されましたか?

テクノロジーは確かに監視システムに付加価値をもたらすことができます。時間の共通性、および(理想的には)システムのトポロジと依存関係の知識に基づいて、さまざまなシステムからのアラートをXNUMXつのインシデントにまとめることができます。 これにより、アラートの過負荷が軽減され、根本原因の検出が簡素化されます。 ただし、これがAIであるかどうかは議論の余地があります。 (依存関係は負荷に応じて変化する可能性があるため、依存関係を「知る」という理想的な状態は、少なくとも個々のトランザクションレベルでは不可能な場合があることに注意してください。データがキャッシュされるかどうか、新しいコードがデプロイされるとき、または新しいときはいつでもノードまたはコンテナが追加/削除されます。また、インシデントの原因となる依存関係の変更が監視システムによって認識されない場合があるため(通信メカニズム自体がインシデントによって中断される可能性があるため)、監視によって一部のアラートが古いデータに基づくインシデント。Googleチームとして それを置く 「Googleのインフラストラクチャでは継続的なリファクタリングが安定しているため、複雑な依存関係階層を維持しているチームはほとんどありません。」)

全体像AIOps

厳密なAIよりも広い範囲でAIOpsを見ると、監視が大幅に改善される可能性があります。 AIOpsは、時間の経過に伴うパフォーマンスの不一致や異常を指摘するのに適しています。 AIOpsは、リリースによって引き起こされた問題(たとえば、2つのデータベース要求を受け取るために使用されていたページのレンダリング)に警告を発することができます。現在は10が必要です。開発の敏捷性が高まるにつれて、監視の重要な役割。 もちろん、「これは以前とは異なります」を特定することは、実際にはAIではありません。依存関係とフローデータによって通知されるシステムで大規模に行われる統計処理です。 AIOpsの価値は、トポロジ、リリースに関する情報、および依存関係データを使用して、最も可能性の高い(根本原因のような)データ変更を推測できることです。 また、機械学習を適用して、人間の管理者が重要と見なすものについてトレーニングすることもできます。 与えられたAIは現在、人間の意思決定に取って代わるのに非常に適しています。 XNUMX秒もかからない (車の位置の特定、顔の認識)–複雑なデータセンターの監視にはそのようなタスクは多くありません。 ただし、アラートを意味のないもの、または他の問題の症状として識別することは、MLが行うタスクのXNUMXつです。 できる 人間の作業負荷を軽減するためのトレーニングを受ける。

これは、LogicMonitorが計画している方向です。パフォーマンスデータ、コストデータ、パフォーマンスアラート、リリースデータ、トポロジ、依存関係を組み合わせて意味のある通知を生成し、機械学習を使用して、そのセットをさらに実用的な通知に減らします。そしておそらく自動化された)解決。
頻繁に電話をかけていた元ネットワークおよびシステム管理者と言えば、監視とアラート応答の最前線にいる人々の生活を楽にするほど、すべての人にとってより良いものになります。 そしてもちろん、それがLogicMonitorの焦点です。

スティーブ·フランシス

創業者

スティーブはLogicMonitorの創設者です。

LogicBlogを購読して、LogicMonitorの最新の開発に関する最新情報を入手し、ITエキスパートとエンジニアのワールドクラスのチーム、およびITプロフェッショナルが愛する製品。

LogicBlogの他の記事

アンペアロボット 影

お店の話をしましょう。

STARTED GET