BLOG
アクショナブルインテリジェンスに "アクション "を入れる

投稿:2022年8月4日   |    更新:2022年8月4日

AIOpsは、機械学習と人を組み合わせ、IT運用における技術的成果を実現します。この能力の約束は、新たな競合を市場に送り込み続けています。AIOpsは、すべての主要なイベント管理プレーヤーにとって、メッセージングの中核となるコンポーネントとなっています。多くの企業が自社製品のブランドを変更し、AIOpsの機能を特に強調するようになりました。新興のイベント管理プレーヤーも登場し、AIOpsのスペースを確保しようと試みています。ほぼすべての観測可能なAPMベンダーが同じことを行い、自分たちが今、AIOpsツールとして選ばれていることを主張しています。

AIOpsとは何か?

しかし、一歩下がってほんの少し現実を見てみましょう。AIOpsはツールではなく、一連の機能です。したがって、製品セットとしてのAIOpsを定義することは困難です。これは、自分のツールがDevOpsの選択ツールであると主張するのと同じようなものです。業界をリードするアナリストでさえ、AIOpsの中核となるアプローチは何か、AIOpsの特定のヒューリスティックは何かについて、同様に意見の相違があります。このような意見の相違はあるものの、私たち実務家は、大多数のAIOpsソリューションを2つの中核的な陣営に分類して考えることができます。

オプション #1: アプリケーション監視

アプリケーション監視ツールは、最初の陣営を所有しています。この監視中心のアプローチは、メトリクス、KPI、ログなどを活用し、機械学習と傾向分析を使用して予測を行い、より早くスマートなアラートを出せるようにすることを目的としています。良い点は、すべてを監視することで、根本的な原因に近づける可能性があることです。一方、デメリットは、監視を複製することになるか、これらのツールセットを活用するために現在のツールセットの大部分を削除して交換しなければならないことです。さらに、ネットワーク、ストレージ、アプリケーション、パフォーマンス・モニタリングなど、すべてを1つのツールで監視することは、特に「十分な」監視ツールを置き換える場合、コストがかかる可能性があります。

選択肢その2:イベントマネジメント

2つ目のアプローチは、イベント管理です。このソリューションのグループは、異なるモニタリングを統合することによってドメインにとらわれない視点を維持し、単眼鏡の結果に焦点を当てた集中型NOCの能力タイプに行き着くことになります。このアプローチでは、すべての異種情報を一元化することで、理想的にはより良い意思決定を行うことができると期待されています。しかし、ルールを更新するために一元化された場所を持つ必要があるため、能力のボトルネックになってしまう可能性があります。さらに、多くのベンダーがピーク時の使用量、1日の平均使用量、ノード数、イベントソース数などのデータに基づいて異なる料金指標を設定しているため、ソリューションのサイズ設定が難しい場合があります。

どちらのアプローチも抜け落ちているのは、「完璧な」根本原因を突き止めることができても、「さあ、どうする?どのように問題を解決するのか?これらのソリューションを使用するチームは、実際の銃撃戦に役立つ重要な質問をまだ残していることになります。どのサービスが影響を受けているのか?そのサービスの所有者は誰か?誰がそのサービスのために待機しているのか?どのような診断が必要なのか?どのような自動化が可能か?

これらの答えが見つからないと、サービスを復旧させるのに苦労することになります。

より良いAIOpsソリューション

PagerDutyは、ほとんどのAIOpsソリューションが無視しているリアルタイムの作業問題を解決するために、この課題に取り組んでいます。私たちは、ノイズを減らし、根本原因を特定するためのコンテキストを作成し、労力を削減しサービスを回復するための自動化を促進します。PagerDutyを利用することで、チームはフルサービスのオーナーシップアプローチを活用し、建設業者や革新者が競合他社よりも早くソリューションを市場に投入し、顧客のために価値を繰り返し提供できるよう支援します。PagerDutyは、お客様が既にお持ちのツール、チーム、機能を活用し、デジタルトランスフォーメーションに向けた幅広い戦略的優位性の構築をサポートしながら、戦術的な運用を迅速に実現するお手伝いをします。

自動化ファーストアプローチ

私たちの自動化ファーストのアプローチは、私たちのランブックオーケストレーションプラットフォームである Rundeck をファーストレスポンダとして活用することで、あなたのチームの働き方を変えることができます。Rundeck を使うことで、チームを動員することなく問題を解決できることが多くあります。この自動解決は MTTR を大幅に改善しますが、それと同じくらい重要なのは、主題専門家が本業に集中できるようにすることです。自動化が問題を即座に解決できない場合は、自動診断により、最初の対応者が影響を受けるサービス、顧客への影響、SLAへの影響を理解できるようにコンテキストを作成することができます。そうすることで、ログ、スクリプト、手順から情報を収集し、自動化対応を推進するための指針とすることができます。これにより、包括的な監査証跡が作成され、事後検証やITSM問題管理を改善し、将来的な問題を回避することができます。

当社のプラットフォームは、大規模な組織や複数のチームがセルフサービスで管理できるように、API設定機能を活用しています。そのため、ルールの更新や設定の管理を中央のチームに依存するのではなく、管理者はリポジトリやTerraformなどのツールを活用し、中央のみの機能による閉塞感なしに、チームが必要とする更新を迅速に入手できるようにすることができます。

自動化を優先し、データ駆動型のセルフサービス・アプローチにより、チームと機械学習が一体となって問題を解決し、根本原因を見つけるだけでなく、AIOpsの真の約束を実現できると信じています。このドメインにとらわれないアプローチでは、適切なタイミングで適切な情報を適切な担当者に提供することに集中することができます。アクションを実用的なインテリジェンスに置き換えることで、ノイズやアラート疲労を減らし、初動対応者が問題を解決できるようにし、労力を削減し、構築者や革新者がインシデントを追いかけるだけでなく新しい機能を提供できるようにすることができるのです。

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

book-markカテゴリー :DevOps
book-markタグ: