Red Hat Ansible Automation PlatformとLogicMonitor Edwin AIでAIOpsの可能性を解き放つ

障害が発生すると、最初のアラートは最初の兆候に過ぎません。より困難な作業はその後に続きます。関連するシグナルをグループ化し、症状と原因を区別し、影響を受けるサービスを特定し、次のアクションを実行しても安全かどうかを判断する必要があります。

この運用上の課題が、先日開催されたウェビナーのテーマとなりました。ウェビナーには、Red HatのAnsible担当プリンシパルプロダクトマネージャーであるSteve Fulmer氏、LogicMonitorのAI担当プロダクト責任者であるBharat Singh氏、そしてLogicMonitorのAI担当シニアセールスエンジニアであるCallum Brown氏が参加しました。セッションでは、LogicMonitorをインテリジェンスシステム、Red Hat Ansible Automation Platformをアクションシステムとする、AIOps自動化のための共同モデルに焦点が当てられました。

IBM watsonx.ai もこの連携において重要な役割を果たしており、関連するプレイブックが存在しない場合に自動化生成パスをサポートします。Edwin AI は、何が起こっているのか、そしてそのインシデントに対してどのようなアクションが適切かを判断するのに役立ちます。Ansible Automation Platform は、そのアクションの実行方法を制御します。

その前提はシンプルで、実用的です。AIOpsは、アラートの相関関係や根本原因の示唆にとどまる場合、その価値は限られます。IT運用チームは、レビュー、セキュリティ、監査可能性、および制御を維持しながら、シグナルからアクションに至るまでの道筋を必要としています。

インシデント対応に依然として時間がかかりすぎる理由

ITチームがシグナル不足に悩まされることは稀です。メトリクス、ログ、アラート、トポロジー、チケット、自動化履歴など、すべてが状況の一部を把握するのに役立ちます。インシデント発生時には、これらの情報は複数のツールに分散していることが多く、対応担当者は修復作業を開始する前に、状況を把握するために貴重な時間を費やすことになります。

その翻訳作業は、業務の遅延につながります。チームは、どの警告が関連しているか、どの依存関係が状態変化したか、どのサービスが影響を受けているか、どのチームがそれを担当しているか、そして既知の対応策が既に存在するかどうかを判断しなければなりません。調査に時間がかかればかかるほど、不必要なエスカレーション、重複作業、そして回避可能なダウンタイムが発生する可能性が高くなります。

AIOpsは、シグナルから意思決定までのプロセスを短縮する場合に最も効果を発揮します。Edwin AIは、イベントの重複排除、エンリッチメント、相関分析、インシデントトリアージ、根本原因分析、類似インシデント検出、影響分析、ランブック推奨などを通じて、このプロセスをサポートします。インシデント対応の遅延は、単一のポイントではなく、複数の引き継ぎ段階で発生するため、これらの機能が重要となります。

インテリジェンスには実行経路が必要だ

Edwin AIは、このモデルにおけるインテリジェンス層として位置づけられます。Edwin AIは、アラートの相関分析、根本原因の特定、ドメインをまたいだ関連問題のグループ化、トポロジーとCMDBコンテキストの関連付け、そして修復ワークフローの推奨または開始を行うように設計されています。

インシデント対応は手順に左右されます。チームが行動を起こす前に、何が故障したのか、何が影響を受けているのか、何が変更されたのか、どのサービスが問題の原因なのか、そしてどの対応経路が適切なのかを把握する必要があります。Edwin AIは、インシデントのコンテキストを1つのワークフローに統合し、AIエージェントを使用してトリアージ、診断、および修復計画を支援することで、調査時間を短縮します。

Red Hat Ansible Automation Platformは、異なる役割を担います。これは実行レイヤーであり、企業環境全体で一貫して自動化を実行できるように設計されています。Red Hatは、Ansible Automation Platformを、AI駆動型インテリジェンスを統制され、監査可能で、決定論的なアクションに変換する手段と説明しています。この枠組みは重要です。なぜなら、修復作業は、チームが本番システムを保護するために使用する制御を迂回すると、リスクを生み出すからです。

ウェビナーで説明された連携パターンでは、Edwin AIがインシデントを特定して分析し、その後、Ansible Automation Platformがポリシー、認証情報、ロールベースのアクセス、監査証跡を通じて承認された自動化を実行します。この方式のメリットは、ガバナンスをプロセスから排除することなく、2つのシステムを連携させることにあります。

Edwin AIとAnsibleの統合自動化プラットフォームのワークフローの実行方法

ワークフローは、優先順位付けと相関付けが行われたLogicMonitorアラートから始まります。これにより、対応者が解釈しなければならない個別の症状の数を減らすことができます。次に、Edwin AIがインシデントの状況を分析し、何が起こっているのか、何が重要と思われるのか、どの対応経路が適切かを判断します。

そこから、ワークフローはAnsible APIを介してAnsible Automation Platformに接続し、既存のプレイブックを検出して使用します。承認済みのプレイブックが存在する場合、Ansible Automation Platformは、RBAC、監査証跡、Ansible Vault、ポリシー適用、人的承認などのエンタープライズレベルの制御機能を使用して、そのプレイブックを実行できます。

関連するプレイブックが存在しない場合、Ansible自動化コーディングアシスタントとIBM watsonx.aiは、提案されたAnsible自動化の生成を支援します。生成された自動化には運用リスクが伴うため、生成されたコンテンツは本番環境で使用する前に、レビュー、テスト、承認のプロセスを経る必要があります。

このワークフローは、ITSMシステムとの同期、問題の修復、およびクローズドループ学習へのフィードバックも可能です。解決済みのインシデントは、時間の経過とともに、将来の診断、ルーティング、および自動化の適用範囲を向上させることができます。

ガバナンスによってAI支援アクションが利用可能になる

AIによる修復は、もっともらしい推奨事項だけでは不十分です。本番環境には、実行されるアクションのリスクに見合った認証情報の境界、承認経路、ポリシーの適用、および監査履歴が必要です。

Ansible Automation Platformは、その作業のための統制された実行レイヤーを提供します。オペレーターは、Web UIを使用して、ロールベースのインターフェースを介して自動化の設定、起動、および監視を行うことができます。サードパーティシステムは、トークンベースの認証を使用してAPIを介して統合できます。イベント駆動型Ansibleは、外部イベントソースから自動化をトリガーできます。MCPを使用すると、AIモデルがAnsible Automation Platformにクエリを実行し、定義された範囲内で自動化を起動できます。

最後の境界線は重要です。AIは解決策の可能性を特定するのに役立ちますが、実行段階では組織の統制モデルを尊重する必要があります。より安全なパターンは、提案されたアクションが統制された自動化プロセスに移行し、リスクに応じて承認と監査可能性が維持されるというものです。

LogicMonitor Envisionによるイベント駆動型自動化

このウェビナーでは、LogicMonitor EnvisionとRed Hat Ansible Automation Platformを使用したイベント駆動型パターンについても解説しました。LogicMonitor Envisionはアラートを捕捉し、LogicMonitor.integration Content CollectionはWebhookを介してイベントを送信します。

イベント駆動型Ansibleは、イベントを検知し、Ansibleルールブックに基づいて評価を行い、定義された条件が満たされた場合にプレイブックまたはジョブテンプレートを呼び出します。このワークフローにより、ハイブリッドクラウドインフラストラクチャ全体にわたる問題を修復したり、チケットの拡充や自動的な情報収集といったリスクの低いアクションをトリガーしたりすることができます。

これにより、チームは実践的な出発点を得ることができます。初期段階のワークフローでは、インシデントの状況把握、適切なチームへの通知、対応担当者がインシデントに参加する前の診断情報の収集などが可能です。より成熟したワークフローでは、サービスの再起動、バックアップ、ロールバック、ドリフト対応、コンプライアンス対応、証明書管理などを処理できます。

チームが始められる場所

最も安全な出発点は、多くの場合、本番システムに影響を与える前にインシデントの状況を把握するワークフローを構築することです。チームは、チケット作成の自動化、トポロジーや所有者データによるアラートの強化、インシデント概要の添付、適切な担当者への通知、エスカレーション前の診断情報の収集などを行うことができます。

そこから、チームは対応手順が明確でロールバックの手順も明確なレスポンスワークフローを追加できます。一般的な例としては、証明書管理、サービス再起動、しきい値に基づくアクション、バックアップトリガー、構成チェック、および繰り返し発生するインシデントに対する既知の修復手順などが挙げられます。

ビジネスケースは現実的な視点に立つべきです。測定可能な成果としては、インシデント解決の迅速化、エスカレーション件数の減少、時間外労働の削減、SLA遵守率の向上、そしてチーム間のより一貫した業務遂行が挙げられます。

ループを閉じる

このウェビナーで最も重要な点は、AIOpsには制御されたアクションへの道筋が必要だということです。Edwin AIは、チームが複雑な環境全体で何が起こっているかを理解するのに役立ちます。Ansible Automation Platformは、チームがその理解に基づいて行動するための統制された方法を提供します。AIを活用した自動化は、提案されたワークフローが使用前にレビューされ承認されることを前提として、カバレッジの拡大に役立ちます。

この組み合わせにより、IT運用部門は自己修復型の運用に近づくことができ、しかも、自動化を本番環境で安全に運用するために必要な制御機能をチームに放棄させる必要もありません。