すべてのダッシュボードが緑色です。サービスが停止しています。それを説明してください。

[JunshuO]

すべてのダッシュボードが緑色です。サービスが停止しています。それを説明してください。

監視スタックは世界最高水準です。オブザーバビリティプラットフォームは、毎分数百万のイベントを取り込みます。オンコールチームは経験豊富で勤勉です。しかし、どういうわけか、市民が福利厚生ポータルが機能していないことを報告するために電話をかけてきたとき、運用チームの誰もその兆候を検知できませんでした。これは誰もが認めたがらないほど頻繁に発生します。その理由と修正方法は次のとおりです。

---

監視システムは知っていた。ただ、自分が何を知っているのか分からなかっただけです。

とある州機関での木曜日の午後を想像してみてください。何千人もの住民がケースのステータスを確認し、文書を提出し、要請を開始するために使用する給付金適格性ポータルは、エラーを返し始めます。劇的ではありません。静かに。応答時間が上昇しています。いくつかのトランザクションが失敗しました。その後、さらに。

オペレーションセンターは、監視アラートからではなく、サービスデスクへの電話から最初の兆候を把握します。その後、別の電話や上司からのメールが続きました。インシデントが正式に宣言されるまでに 2 時間が経過し、ポータルはずっと劣化していました。

インシデント後のレビューでは、監視プラットフォームがその期間中に 4 つの個別のアラートにフラグを立てていたという不都合な真実が明らかになりました。データベースクエリのタイムアウト。メッセージキューのバックアップ。2 つのアプリケーションサーバーメモリの警告。あらゆる信号がそこにありました。どれも互いに接続されておらず、福利厚生ポータルに関連付けられておらず、個々には、一見するとサービスに影響を与えるインシデントには見えなかったため、優先応答をトリガーするものはありませんでした。

監視システムは完璧に機能していました。インフラを見守るだけでした。誰もサービスを監視するように指示していませんでした。

✦ ✦ ✦

問題点

インフラストラクチャメトリクスは、間違った都市の天気予報です

インフラストラクチャ中心の監視の根本的な問題は、間違ったものを測定していることではありません。CPU、メモリ、遅延、エラー率はすべて、本当に重要なシグナルです。問題は、それらが集合的に何を支えているかについてのモデルなしに、それらを切り離して測定することです。

メモリ使用率が 87% のサーバーはデータポイントです。そのサーバーが SNAP eligibility API のコンポーネントをホストしているのか、午前 3 時に実行されるバッチレポートジョブをホストしているのかは、コンテキストです。データポイントは、何かが昇格したことを示します。コンテキストは、誰かを起こすべきかどうかを示します。

インフラストラクチャのみの監視の 3 つの障害モード

アラート疲労 : すべてのシステムが独立してアラートを発報する場合、1 回のサービス中断により、監視ツール、チケット発行システム、ダッシュボード全体で数十のアラートが生成される可能性があります。運用チームは、当然のことながら、調査を行う前にアラートの洪水が収まるのを待つようになります。問題は、最も重要なアラートが洪水の真っ只中に到着することです。

false オールクリア : サービスが劣化している間にグリーンインフラストラクチャメトリクスを表示するダッシュボードは、仮定のものではありません。これらは、サービスの障害が依存関係の問題、つまり共有コンポーネント自体は問題ないように見えても、それに依存するアプリケーションに下流で問題を引き起こしている場合に発生します。インフラストラクチャの健全性とサービスの健全性は同じものではありません。

リアクティブディスカバリー : サービスモデルがない場合、インフラストラクチャアラートとそのサービスへの影響の関係は、運用チームがアクティブなインシデント中に手動で特定する必要があります。その際には、アーキテクチャ図を参照し、同僚に質問し、依存関係をリアルタイムで追跡します。これは調査時間であり、解決時間になる可能性があります。

解決策は、より多くの監視ではありません。これは別の種類の監視であり、それらの信号が影響するサービスのマップに対してインフラストラクチャ信号を測定するものです。このマップこそが、共通サービスデータモデルによって提供されるものです。

説明

シグナルから意味へ:CSDM がギャップを埋める方法

CSDM は、最下層にインフラストラクチャ構成アイテム、その上にテクニカルサービス、さらにその上にアプリケーションサービス、その上にビジネスアプリケーション、そして最上位にビジネス機能という構造でCMDBを編成します。各レイヤーはその上のレイヤーにマップされ、物理サーバーまたはコンテナから、最終的に実現するビジネス機能に至るまで、途切れることのないチェーンを作成します。

この階層は、生のテレメトリではできないこと、つまり、すべてのインフラストラクチャ信号にサービスアドレスを与えることを行います。データベースクエリーの速度が低下すると、CSDM は、そのデータベースがどのテクニカルサービスに属しているか、そのテクニカルサービスに依存しているアプリケーションサービスはどれか、それらのアプリケーションサービスを通じてユーザー向け機能を提供するビジネスアプリケーションはどれか、どのビジネス機能（福利厚生の適格性、ケース管理、ドキュメント送信など）がリスクにさらされているかを運用プラットフォームに通知します。

信号は変わりませんでした。意味が完全に変わりました。

これが監視レイヤーでどのように表示されるか

CSDM 関係をイベント管理および観測可能性プラットフォームと統合すると、インフラストラクチャのみの監視では提供できない 3 つの特定の機能が明らかになります。

分離されたアラートではなく相関サービスイベント。 木曜日の午後のシナリオ:接続されていない 4 つの別々のアラートも、サービスアーキテクチャが導入されていれば異なって見えます。データベースタイムアウト、メッセージキューのバックアップ、およびメモリの警告はすべて、同じ福利厚生ポータルアプリケーションサービスをサポートする構成アイテムまでトレースされます。イベント管理は、それらを単一のサービスイベントにグループ化し、適切な優先度で分類され、影響を受けるサービスが明確に特定され、適切なチームにルーティングされます。4 つのアラートが 1 つのインシデントになります。

ポータルの劣化は、最初の市民が電話をかける前に表示されます。

意味のある方法で集計されるサービス健全性インジケーター。 アプリケーションサービスは、サーバー、データベース、キュー、ダウンストリーム API などの複数のコンポーネントに依存します。サービス健全性モニタリングは、これらすべてのコンポーネントのシグナルを、サービス自体の単一の健全性ステータスに集約します。わずかな変動が発生しているコンポーネントは誤報を引き起こしません。複数のコンポーネントにわたる劣化のパターンは、首尾一貫したストーリーを物語っています。運用チームは、個々のメトリクスを監視するのをやめ、サービスが健全であるかどうかという重要な点に注目し始めます。

ビジネス用語での影響分析。 インシデントが宣言されたとき、リーダーシップからの最初の質問は「どのサーバーが影響を受けているか」ではありません。それは「今、人々ができないことは何ですか?」です。CSDM を使用すると、運用チームは、推測ではなく、既にビルドされているサービス依存関係マップを読み取ることによって、その質問に正確かつ即座に回答できます。インシデントのコミュニケーションは、「データベースパフォーマンスの問題を調査中です」ではなく、「ドキュメント送信サービスが劣化しており、推定 3,200 のアクティブセッションに影響を及ぼしています」になります。

「インフラストラクチャの監視により、マシンの何が問題になっているかがわかります。サービス中心の監視により、それを使用するユーザーにとって何が問題なのかがわかります。どちらも重要です。しかし、本当に重要な理由で行動を起こさせるのは、サービス中心の監視だけです。」

ソリューション

モニタリングを有意義なものにするモデルの構築

インフラストラクチャ中心の監視からサービス中心の運用の可視化への移行は、テクノロジープロジェクトというよりも、アーキテクチャの分野です。ツール (ServiceNow イベント管理、オブザーバビリティプラットフォーム統合、サービスヘルスダッシュボード) の準備は整っています。最初に考慮すべきは、これらのツールが使用するサービスモデルです。

つまり、CMDB について 3 つのことが真実であることを確認するということです。

まず、構成アイテムがテクニカルサービスに関連付けられています。 サービスをサポートするすべてのサーバー、コンテナ、データベース、およびネットワークデバイスは、それが属するテクニカルサービスにリンクする必要があります。これは、他のすべてが流れ込む基本的な関係です。それがなければ、インフラストラクチャ信号は住所を持たない事実として孤立したままになります。

次に、テクニカルサービスはアプリケーションサービスに関連付けられています。 アプリケーション配信をサポートする共有プラットフォームとインフラストラクチャ層 (メッセージングキュー、データベースクラスター、認証プラットフォーム) は、それらに依存するアプリケーションサービスとの明示的な関係を持つテクニカルサービスとしてモデル化する必要があります。この関係により、コンポーネント間のアラート相関と爆発半径のアセスメントが可能になります。

第 3 に、アプリケーションサービスはビジネスアプリケーションと機能に関連付けられています。 これは、運用イベントをビジネス言語に変換する接続であり、監視アラートを技術的な異常ではなくサービス中断として表現できるようにします。また、この関係性は、アクティブなインシデント中に誰も手動で全体像を組み立てることなく、どの機能が危険にさらされているかをリーダーシップに伝える関係でもあります。

ガバナンスの前提条件

サービスモデルが維持されていない場合、これらはいずれも機能しません。サービス関係は、環境の変化、新しい展開による依存関係の追加、廃止されたシステムによって孤立した関係が残されたり、チームの再編成によって所有権が変動するなど、変化していきます。定期的なデータ認定、明確なサービスオーナーシップの説明責任、自動化された CMDB ヘルスモニタリングにより、モデルの信頼性が長期にわたって維持されます。誰も更新していない昨年の正確なサービスモデルは負債であり、資産ではありません。運用チームはそれを信頼し、誤解を招くでしょう。

---

サマリー

あの木曜日の午後に戻る

私たちのオープニングシナリオの代理店は優れた監視を行っていました。そこになかったのは、監視を監視対象のサービスに接続するサービスモデルでした。4 つのアラートが発報されましたが、どれも接続されておらず、市民が報告するまでその影響は目に見えない形で蓄積されました。

CSDM を導入すると、その午後は異なって見えます。4 つのアラートは、福利厚生ポータルにリンクされた 1 つのサービスイベントに関連付けられます。このイベントは、1 人の市民から電話がかかってくる前に、優先度 1 に分類されます。適切なチームには、既にチケットに含まれているサービスコンテキストが通知されます。ポータルは 20 分で復元されます。リーダーシップへのインシデントレポートには、どのサービスが影響を受けたか、どのくらいの期間、どのくらいのセッション数が影響を受けたかが記載されており、これらはすべてサービスモデルから自動的にプルされます。

同じ監視ツール。同じ運用チーム。ある時点で、誰かがインフラストラクチャ信号をサービスインテリジェンスに変換するマップを構築する作業を行ったため、まったく異なる結果になりました。

信号は常にそこにありました。意味を示すモデルを構築します。

---

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/every-dashboard-is-green-the-service-is-down-exp...。

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-blog/every-dashboard-is-green-the-service-is-down-exp...。

[JunshuO]

すべてのダッシュボードが緑色です。サービスが停止しています。それを説明してください。

監視スタックは世界最高水準です。オブザーバビリティプラットフォームは、毎分数百万のイベントを取り込みます。オンコールチームは経験豊富で勤勉です。しかし、どういうわけか、市民が福利厚生ポータルが機能していないことを報告するために電話をかけてきたとき、運用チームの誰もその兆候を検知できませんでした。これは誰もが認めたがらないほど頻繁に発生します。その理由と修正方法は次のとおりです。

---

監視システムは知っていた。ただ、自分が何を知っているのか分からなかっただけです。

とある州機関での木曜日の午後を想像してみてください。何千人もの住民がケースのステータスを確認し、文書を提出し、要請を開始するために使用する給付金適格性ポータルは、エラーを返し始めます。劇的ではありません。静かに。応答時間が上昇しています。いくつかのトランザクションが失敗しました。その後、さらに。

オペレーションセンターは、監視アラートからではなく、サービスデスクへの電話から最初の兆候を把握します。その後、別の電話や上司からのメールが続きました。インシデントが正式に宣言されるまでに 2 時間が経過し、ポータルはずっと劣化していました。

インシデント後のレビューでは、監視プラットフォームがその期間中に 4 つの個別のアラートにフラグを立てていたという不都合な真実が明らかになりました。データベースクエリのタイムアウト。メッセージキューのバックアップ。2 つのアプリケーションサーバーメモリの警告。あらゆる信号がそこにありました。どれも互いに接続されておらず、福利厚生ポータルに関連付けられておらず、個々には、一見するとサービスに影響を与えるインシデントには見えなかったため、優先応答をトリガーするものはありませんでした。

監視システムは完璧に機能していました。インフラを見守るだけでした。誰もサービスを監視するように指示していませんでした。

✦ ✦ ✦

問題点

インフラストラクチャメトリクスは、間違った都市の天気予報です

インフラストラクチャ中心の監視の根本的な問題は、間違ったものを測定していることではありません。CPU、メモリ、遅延、エラー率はすべて、本当に重要なシグナルです。問題は、それらが集合的に何を支えているかについてのモデルなしに、それらを切り離して測定することです。

メモリ使用率が 87% のサーバーはデータポイントです。そのサーバーが SNAP eligibility API のコンポーネントをホストしているのか、午前 3 時に実行されるバッチレポートジョブをホストしているのかは、コンテキストです。データポイントは、何かが昇格したことを示します。コンテキストは、誰かを起こすべきかどうかを示します。

インフラストラクチャのみの監視の 3 つの障害モード

アラート疲労 : すべてのシステムが独立してアラートを発報する場合、1 回のサービス中断により、監視ツール、チケット発行システム、ダッシュボード全体で数十のアラートが生成される可能性があります。運用チームは、当然のことながら、調査を行う前にアラートの洪水が収まるのを待つようになります。問題は、最も重要なアラートが洪水の真っ只中に到着することです。

false オールクリア : サービスが劣化している間にグリーンインフラストラクチャメトリクスを表示するダッシュボードは、仮定のものではありません。これらは、サービスの障害が依存関係の問題、つまり共有コンポーネント自体は問題ないように見えても、それに依存するアプリケーションに下流で問題を引き起こしている場合に発生します。インフラストラクチャの健全性とサービスの健全性は同じものではありません。

リアクティブディスカバリー : サービスモデルがない場合、インフラストラクチャアラートとそのサービスへの影響の関係は、運用チームがアクティブなインシデント中に手動で特定する必要があります。その際には、アーキテクチャ図を参照し、同僚に質問し、依存関係をリアルタイムで追跡します。これは調査時間であり、解決時間になる可能性があります。

解決策は、より多くの監視ではありません。これは別の種類の監視であり、それらの信号が影響するサービスのマップに対してインフラストラクチャ信号を測定するものです。このマップこそが、共通サービスデータモデルによって提供されるものです。

説明

シグナルから意味へ:CSDM がギャップを埋める方法

CSDM は、最下層にインフラストラクチャ構成アイテム、その上にテクニカルサービス、さらにその上にアプリケーションサービス、その上にビジネスアプリケーション、そして最上位にビジネス機能という構造でCMDBを編成します。各レイヤーはその上のレイヤーにマップされ、物理サーバーまたはコンテナから、最終的に実現するビジネス機能に至るまで、途切れることのないチェーンを作成します。

この階層は、生のテレメトリではできないこと、つまり、すべてのインフラストラクチャ信号にサービスアドレスを与えることを行います。データベースクエリーの速度が低下すると、CSDM は、そのデータベースがどのテクニカルサービスに属しているか、そのテクニカルサービスに依存しているアプリケーションサービスはどれか、それらのアプリケーションサービスを通じてユーザー向け機能を提供するビジネスアプリケーションはどれか、どのビジネス機能（福利厚生の適格性、ケース管理、ドキュメント送信など）がリスクにさらされているかを運用プラットフォームに通知します。

信号は変わりませんでした。意味が完全に変わりました。

これが監視レイヤーでどのように表示されるか

CSDM 関係をイベント管理および観測可能性プラットフォームと統合すると、インフラストラクチャのみの監視では提供できない 3 つの特定の機能が明らかになります。

分離されたアラートではなく相関サービスイベント。 木曜日の午後のシナリオ:接続されていない 4 つの別々のアラートも、サービスアーキテクチャが導入されていれば異なって見えます。データベースタイムアウト、メッセージキューのバックアップ、およびメモリの警告はすべて、同じ福利厚生ポータルアプリケーションサービスをサポートする構成アイテムまでトレースされます。イベント管理は、それらを単一のサービスイベントにグループ化し、適切な優先度で分類され、影響を受けるサービスが明確に特定され、適切なチームにルーティングされます。4 つのアラートが 1 つのインシデントになります。

ポータルの劣化は、最初の市民が電話をかける前に表示されます。

意味のある方法で集計されるサービス健全性インジケーター。 アプリケーションサービスは、サーバー、データベース、キュー、ダウンストリーム API などの複数のコンポーネントに依存します。サービス健全性モニタリングは、これらすべてのコンポーネントのシグナルを、サービス自体の単一の健全性ステータスに集約します。わずかな変動が発生しているコンポーネントは誤報を引き起こしません。複数のコンポーネントにわたる劣化のパターンは、首尾一貫したストーリーを物語っています。運用チームは、個々のメトリクスを監視するのをやめ、サービスが健全であるかどうかという重要な点に注目し始めます。

ビジネス用語での影響分析。 インシデントが宣言されたとき、リーダーシップからの最初の質問は「どのサーバーが影響を受けているか」ではありません。それは「今、人々ができないことは何ですか?」です。CSDM を使用すると、運用チームは、推測ではなく、既にビルドされているサービス依存関係マップを読み取ることによって、その質問に正確かつ即座に回答できます。インシデントのコミュニケーションは、「データベースパフォーマンスの問題を調査中です」ではなく、「ドキュメント送信サービスが劣化しており、推定 3,200 のアクティブセッションに影響を及ぼしています」になります。

「インフラストラクチャの監視により、マシンの何が問題になっているかがわかります。サービス中心の監視により、それを使用するユーザーにとって何が問題なのかがわかります。どちらも重要です。しかし、本当に重要な理由で行動を起こさせるのは、サービス中心の監視だけです。」

ソリューション

モニタリングを有意義なものにするモデルの構築

インフラストラクチャ中心の監視からサービス中心の運用の可視化への移行は、テクノロジープロジェクトというよりも、アーキテクチャの分野です。ツール (ServiceNow イベント管理、オブザーバビリティプラットフォーム統合、サービスヘルスダッシュボード) の準備は整っています。最初に考慮すべきは、これらのツールが使用するサービスモデルです。

つまり、CMDB について 3 つのことが真実であることを確認するということです。

まず、構成アイテムがテクニカルサービスに関連付けられています。 サービスをサポートするすべてのサーバー、コンテナ、データベース、およびネットワークデバイスは、それが属するテクニカルサービスにリンクする必要があります。これは、他のすべてが流れ込む基本的な関係です。それがなければ、インフラストラクチャ信号は住所を持たない事実として孤立したままになります。

次に、テクニカルサービスはアプリケーションサービスに関連付けられています。 アプリケーション配信をサポートする共有プラットフォームとインフラストラクチャ層 (メッセージングキュー、データベースクラスター、認証プラットフォーム) は、それらに依存するアプリケーションサービスとの明示的な関係を持つテクニカルサービスとしてモデル化する必要があります。この関係により、コンポーネント間のアラート相関と爆発半径のアセスメントが可能になります。

第 3 に、アプリケーションサービスはビジネスアプリケーションと機能に関連付けられています。 これは、運用イベントをビジネス言語に変換する接続であり、監視アラートを技術的な異常ではなくサービス中断として表現できるようにします。また、この関係性は、アクティブなインシデント中に誰も手動で全体像を組み立てることなく、どの機能が危険にさらされているかをリーダーシップに伝える関係でもあります。

ガバナンスの前提条件

サービスモデルが維持されていない場合、これらはいずれも機能しません。サービス関係は、環境の変化、新しい展開による依存関係の追加、廃止されたシステムによって孤立した関係が残されたり、チームの再編成によって所有権が変動するなど、変化していきます。定期的なデータ認定、明確なサービスオーナーシップの説明責任、自動化された CMDB ヘルスモニタリングにより、モデルの信頼性が長期にわたって維持されます。誰も更新していない昨年の正確なサービスモデルは負債であり、資産ではありません。運用チームはそれを信頼し、誤解を招くでしょう。

---

サマリー

あの木曜日の午後に戻る

私たちのオープニングシナリオの代理店は優れた監視を行っていました。そこになかったのは、監視を監視対象のサービスに接続するサービスモデルでした。4 つのアラートが発報されましたが、どれも接続されておらず、市民が報告するまでその影響は目に見えない形で蓄積されました。

CSDM を導入すると、その午後は異なって見えます。4 つのアラートは、福利厚生ポータルにリンクされた 1 つのサービスイベントに関連付けられます。このイベントは、1 人の市民から電話がかかってくる前に、優先度 1 に分類されます。適切なチームには、既にチケットに含まれているサービスコンテキストが通知されます。ポータルは 20 分で復元されます。リーダーシップへのインシデントレポートには、どのサービスが影響を受けたか、どのくらいの期間、どのくらいのセッション数が影響を受けたかが記載されており、これらはすべてサービスモデルから自動的にプルされます。

同じ監視ツール。同じ運用チーム。ある時点で、誰かがインフラストラクチャ信号をサービスインテリジェンスに変換するマップを構築する作業を行ったため、まったく異なる結果になりました。

信号は常にそこにありました。意味を示すモデルを構築します。