これは、カオスの監視から自律的な運用に移行するためのフィールドガイドと考えてください。
「私たちは完全なオブザーバビリティを持っています」と運用責任者は言いましたが、4 時間かけて 800 件のアラートを手動で関連付けて、生産のメルトダウンを引き起こしている 1 つのデータベース クエリを見つける直前に言いました。
聞き覚えがありますか？あなたは一人ではありません。ほとんどの IT チームは、何をすべきかわからないほど多くの監視データを抱えています。ダッシュボードは美しいです。アラートは容赦ありません。そして、ノイズのどこかに、実際に重要な信号があります―誰かがそれを見つける時間があれば。
ここで重要なのは、オブザーバビリティは常にゴールラインではなく、スタートラインであるはずだったということです。本当の目的地は、はるかに強力で、より安らかなものが本当の目的地です。
ダッシュボードのパラドックス
すべての患者が自分のモニターを持っている病院を想像してみてください。心拍数、血圧、酸素レベル、すべてが常にビープ音を鳴らします。ここで、フロア全体に看護師が 1 人しかおらず、患者がささくれや心停止の有無に関係なく、すべての機械が同じ音量でビープ音を鳴らしていると想像してください。
これは、多くの組織にとって最新のIT運用です。オブザーバビリティツールは、インフラストラクチャ、アプリケーション、クラウドプラットフォーム、ネットワークからテレメトリを収集し、異常を検出するという、設計どおりの機能を果たします。問題はデータそのものではなく、コンテキストのないデータが単なるノイズであることです。
「オブザーバビリティは何が起こったのかを教えてくれます。なぜそれが重要なのか、誰がそれを所有しているのか、それに対して何をすべきかは教えてくれません。」
「何かがおかしいことに気付いた」と「何が壊れているのか、何が影響するのか、どのように修正すればよいのかを正確に知っている」との間のギャップは、チームが何時間も、時には心を失うところです。
実際に欠けているもの：サービスマップ
これは、毎週運用センターで繰り広げられるシナリオです。データベースクラスターがレイテンシのスパイクをスローし始めます。監視プラットフォームは 47 件のアラートを発します。エンジニアがページングされます。彼らは手動でトレースを開始します：どのサービスがそのデータベースにヒットするか？これらのうち、カスタマー向けのものはどれですか？スパイクは 1 つの不正なクエリによるものですか、それともより広範なインフラストラクチャの問題によるものですか？ダウンストリームサービスのいずれかが既にデグレードされていますか？
これらの質問はすべて、オブザーバビリティ ツールの外、つまり人々の頭の中、ウィキ ページ、長年にわたって蓄積された部族の知識の中に存在する知識を必要とします。そして、その知識を知っているエンジニアが休暇中だと、あなたは困ります。
これが問題です。これは、Common Service Data Model (CSDM) のようなサービスアーキテクチャモデルが解決する問題です。CSDM は、インフラストラクチャをコンポーネントのフラットなリストとして扱うのではなく、インフラストラクチャコンポーネントがテクニカルサービスをどのようにサポートするか、テクニカルサービスがビジネスアプリケーションをどのように強化するか、およびそれらのアプリケーションが実際のビジネス価値をどのように提供するかなど、それらの間の関係をマッピングします。
データベースの異常が適切なサービスアーキテクチャのシステムに発生したときに、プラットフォームは「データベースのスパイク」を単に認識するわけではありません。以下のように表示されます。「このデータベースは、優先度 1 の SLA でプラットフォームチームが所有する 3 つの顧客向けアプリケーションの依存関係である注文処理サービスをサポートしています。」このコンテキストによって、アラートのルーティング方法から解決の速さ、適切な人が午前 2 時に起きるかどうかに至るまで、すべてが変わります。
AI が実際にその地位を獲得している場所
IT 運用における AI は多くの誇大宣伝を受けています。しかし、マーケティングを除いて、それが実際にうまくやっているのは、人間が真似できない規模のパターン認識です。
システムは何百万ものイベントを生成します。歴史的に、これらのイベントの一部は機能停止に先行していました。よく訓練されたモデルは、機能停止が起きる前に、これらの前駆体パターンを認識して表面化する方法を学習できます。これにより、チームは事後対応ではなく積極的に行動できるようになります。
キャッチは？AI が作業するには、構造化されたコンテキスト化されたデータが必要です。12 個の切断されたツールからのテレメトリの生の消防ホースは、機械学習モデルにとってほとんど役に立ちません。しかしテレメトリサービスリレーションシップで強化、つまり、このメトリクスがこのチームが所有するこのサービスに属し、これらのビジネス機能に影響を与えることを知っていることは、AI が実際に推論できる構造化された入力の種類です。
実際の例： ある大手小売業者は、インベントリサービスの CPU のわずかな増加とデータベース接続プールの使用量の増加など、非常に特殊なシグナルの組み合わせが、チェックアウトの完全停止より確実に約 12 分先行していることに気づきました。人間はこれらの点をつなげたことはありませんでした。18 か月分の履歴データでトレーニングされた AI モデルがフラグを立てました。修正スクリプトを自動化しました。次にパターンが現れたとき、1人の顧客が気付く前に自己修復しました。
成熟度ジャーニー（いいえ、ステップをスキップすることはできません）
誰も聞きたくない部分は、壊れた基盤の上に自律的な運用をボルトで固定することはできないということです。旅は本当に連続的です。確固たるオブザーバビリティとクリーンなサービスモデルなしに AI 主導の自動化にすぐに飛び込もうとする組織は、非常にコストのかかる自動化がすぐに間違ったことをしてしまうことになります。
結合組織としての ServiceNow
オブザーバビリティが感覚系であり、AIが脳であるならば、信号を適切な場所にルーティングし、チームやツール間でアクションを調整する神経系である必要があります。このような ServiceNow が果たす役割はますます大きくなっています。
これは、インシデントが作成され、CMDB コンテキストで強化され、AI によって関連付けられ、適切な所有者にルーティングされ、自動化されたワークフローまたは人間主導のワークフローによって解決されるプラットフォームです。また、承認、監査証跡、変更コントロールなどのガバナンスが存在する場所でもあり、自動化が実際に機能すると、ビジネスが信頼する範囲内で機能します。
そのガバナンスの部分は、人々が予想している以上に重要です。自律運用の恐怖は常に「自動化によって事態が悪化したらどうなるか」ということです。適切に設計されたシステムは、アクションを起こす前にサービスの依存関係を理解すること（例えば、トリガーを引く前に、共有コンポーネントの再起動が他の5つのサービスに影響を及ぼさないか確認すること）で、これに対処します。
リアルで正直なタイムライン
有意義な自律性を実現するには、数か月ではなく数年かかります。ステージ 1 と 2 （堅牢なオブザーバビリティと信頼できるサービスアーキテクチャ）だけでも、大企業では特に CMDB が長年の技術的負債を蓄積している場合、12 〜 18 か月の作業になる可能性があります。
しかし、その見返りはあらゆる段階で複合的に増大します。観測可能性の向上により、平均検出時間が短縮されます。クリーンなサービスモデルにより、インシデントルーティングが改善され、「誤ったチームへの通知による負担を軽減します。」AI 主導の相関関係により、800 のアラートの嵐が 12 の実行可能なイベントに削減されます。自動化は午前 2 時のサービス再起動チケットを処理するため、誰も行う必要はありません。
そこに到達したチームは、インシデントをより迅速に解決できるだけではありません。彼らはそれらを防ぎ始めます。それが本当の変化です：消火するチームから防火帯を建設するチームへ。
あなた自身のオブザーバビリティのジャーニーについてご意見はございますか？CMDB 修復プロジェクトを経験して生き延びた方は特に、コメント欄にぜひお寄せください。
この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/from-observability-to-autonomy-from-drowning-in-...。
免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。
This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-blog/from-observability-to-autonomy-from-drowning-in-...。
