AIOpsは、機械学習と人を組み合わせ、IT運用で技術的成果を実現するものです。この能力への期待が新たな競合を市場に送り込み続けています。AIOpsは、あらゆる主要なイベント管理プレーヤーにとって、メッセージングの中核となるコンポーネントとなっています。多くの企業が自社製品のブランドを変更し、AIOpsの機能を特に強調するようになりました。新興のイベント管理プレーヤーも登場し、AIOps市場に場を確保しようと試みています。ほぼ全ての観測可能なAPMベンダーが同じことを行い、自分たちが今、AIOpsツールとして選ばれていると主張しています。
AIOpsとは何か？
しかし、一歩下がってほんの少し現実を見てみましょう。AIOpsはツールではなく、一連の機能です。したがって、製品セットとしてのAIOpsを定義することは困難です。これは、自分のツールがDevOpsのツールとして選ばれていると主張するのと同じようなものです。業界をリードするアナリストでさえ、AIOpsの中核となるアプローチは何か、AIOpsの特定のヒューリスティックは何かについて、同様に意見の相違があります。このような意見の相違はあるものの、私たち実務家は、大多数のAIOpsソリューションを２つの中核的な陣営に分類して考えることができます。
オプションその１：アプリケーション監視
アプリケーション監視ツールは、最初の陣営を所有しています。この監視中心のアプローチは、メトリクス、KPI、ログなどを活用し、機械学習と傾向分析を使用して予測を行い、より早くスマートなアラートを出せるようにすることを目的としています。良い点は、全てを監視することで、根本的な原因に近づける可能性があることです。一方、デメリットは、監視を複製することになるか、これらのツールセットを活用するために現在のツールセットの大部分を削除して交換しなければならないことです。さらに、ネットワーク、ストレージ、アプリケーション、パフォーマンスモニタリングなど、全てを１つのツールで監視することは、特に「十分な」監視ツールを置き換える場合、コストがかかる可能性があります。
オプションその２：イベント管理
2つ目のアプローチは、イベント管理です。このソリューションのグループは、異なるモニタリングを統合することでドメインにとらわれない視点を維持し、単一の管理画面の結果に焦点を当てた集中型NOCの能力タイプに行き着くことになります。このアプローチでは、全ての異種情報を一元化することで、理想的にはより良い意思決定を行うことができると期待されています。しかし、ルールを更新するために一元化された場所を持つ必要があるため、能力のボトルネックになってしまう可能性があります。さらに、多くのベンダーがピーク時の使用量、１日の平均使用量、ノード数、イベントソース数などのデータに基づいて異なる料金指標を設定しているため、ソリューションのサイズ設定が難しい場合があります。
どちらのアプローチも抜け落ちているのは、「完璧な」根本原因を突き止めることができても、「さあ、どうする？」がないことです。どのように問題を解決するのか？これらのソリューションを使用するチームは、実際の銃撃戦に役立つ重要な質問をまだ残していることになります。どのサービスが影響を受けているのか？そのサービスの所有者は誰か？誰がそのサービスのために待機しているのか？どのような診断が必要なのか？どのような自動化が可能か？
これらの答えが見つからないと、サービスを復旧させるのに苦労することになります。
より良いAIOpsソリューション
PagerDutyは、ほとんどのAIOpsソリューションが無視しているリアルタイムの作業の問題を解決するために、この課題に取り組んでいます。私たちは、ノイズを減らし、根本原因を特定するためのコンテキストを作成し、労力を削減しサービスを回復するための自動化を促進します。PagerDutyを利用することで、チームはフルサービスのオーナーシップアプローチを活用し、ビルダーやイノベーターが競合他社よりも早くソリューションを市場に投入し、顧客のために価値を繰り返し提供できるよう支援します。PagerDutyは、お客様が既にお持ちのツール、チーム、機能を活用し、デジタルトランスフォーメーションに向けた幅広い戦略的優位性の構築をサポートしながら、戦術的な運用を迅速に実現するお手伝いをします。
自動化ファーストアプローチ
私たちの自動化ファーストのアプローチは、私たちのランブックオーケストレーションプラットフォームであるRundeckを第一レスポンダーとして活用することで、あなたのチームの働き方を変えることができます。Rundeckを使うことで、チームを動員することなく問題を解決できることがたくさんあります。この自動解決はMTTRを大幅に改善しますが、それと同じくらい重要なのは、各分野の専門家が本業に集中できるようにすることです。自動化が問題を即座に解決できない場合は、自動診断により、影響を受けるサービスと顧客への影響とSLAへの影響を第一レスポンダーが理解できるようにコンテキストを作成できます。そうすることで、ログ、スクリプト、手順から情報を収集し、自動化対応を推進するための指針とすることができます。これにより、全体の監査証跡が作成され、事後検証やITSM問題管理を改善し、将来、同様な問題が発生するのを避けられます。
私たちのプラットフォームは、大規模な組織や複数のチームがセルフサービスで管理できるように、API設定機能を活用しています。そのため、ルールの更新や設定の管理を中央のチームに依存するのではなく、管理者はリポジトリーやTerraformなどのツールを活用し、チームが必要とする更新を迅速に入手できるようにすることができます。中央のチームの力だけに頼って渋滞を起こすことを避けられます。
自動化を優先したデータ駆動型のセルフサービスアプローチにより、チームと機械学習が一体となって問題を解決し、根本原因を見つけるだけでなく、AIOpsの真の約束を実現できると信じています。このドメインにとらわれないアプローチでは、適切なタイミングで適切な情報を適切な担当者に提供することに集中できます。アクションを実用的なインテリジェンスに置き換えることで、ノイズやアラート疲れを減らし、第一レスポンダーが問題を解決できるようにし、労力を削減し、ビルダーやイノベーターがインシデントを追いかけるだけでなく、新機能を提供できるように変えられるのです。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：DevOps
