最初の警告は外部から届くこともある。.
ある顧客から、ある処理に通常より時間がかかっているとの報告があった。同様の事例が他にも確認されたため、技術部門が調査を開始した。.
痕跡とその指標は存在しますが、システムやアプリケーション、さまざまな情報源に分散している可能性があります。各チームが状況を把握するために情報を収集している間にも、その影響はすでに現れ始めています。.
「Technology Leadership」にとって、特に重要な兆候が一つあります： 顧客は組織よりも先にその問題に気づいた。.
顧客が警報となる時
不具合は、あるサービスで発生し、その操作を完了しようとするユーザーに気づかれる前に進行してしまうことがあります。.
顧客が最初にその問題を指摘した場合、テクノロジー部門は、影響がすでに現れてから調査を開始する。.
何が起きたのか？ どこで発生したのか？ どのサービスが関与したのか？ 通常とは異なる遅延はあるか？
回答に必要な情報は存在するかもしれない。問題は、その情報が分散したままであり、状況を把握するためにはそれを再構築しなければならない場合に生じる。.
操作が行われている様子を観察する
テクノロジーがシステムやサービスの挙動を継続的に監視できるようになると、状況は一変する。.
Telemetryは、システム、アプリケーション、インフラストラクチャから得られるトレースおよび関連メトリクスを自動的に収集、処理、相関分析します。.
オートマタはこのプロセスを継続的に実行し、実行状況や依存関係、エラー、レイテンシ、予期せぬ挙動などを分析するための運用上のコンテキストや有用なエビデンスを提供します。.
このように、可観測性は、苦情が寄せられた時点で始まるというものではない。.
テクノロジーにより、何が起きているのかを特定し、分析をどこに集中させるのが最も効果的かを判断するための、より明確な基盤が整っています。.
早期発見から理解の深化へ
可視性が高まることで、その目的は、単にすでに発生した問題をより迅速に調査することだけにとどまらなくなる。.
継続的な監視により、操業の進行中に逸脱や傾向を把握することができます。.
また、新たなトレースやメトリクスのソースが追加されるにつれて、カバー範囲を段階的に拡大し、システムやサービスに関するより包括的な全体像を提供できるようになります。.
それなら、質問も変わる。.
もはや単に “「何が起きたの？」”.
また、次第に “「この作戦は私たちに何を示しているのか、そしてどこに注目すべきなのか？」”
情報は、問題への対応だけでなく、行動を理解し、継続的な改善を推進するためにも活用できます。.
最も重要なところから始める
その行程では、最初からすべてのインフラを点検する必要はありません。.
Telemetryは、まず優先度の高いサービスに導入することができます。そこから、組織は利用可能な情報の価値を把握し、段階的に適用範囲を拡大していくことができます。.
変化は徐々に起こります： 何が起きたかをより深く理解し、改善の余地がある行動を特定し、その可視化を活用して運用から学びを得る。.
何かが起きていることに、誰が最初に気づくのでしょうか？
その質問は、技術的な運用における観察力について多くのことを明らかにしてくれるでしょう。.
対応が通常、顧客からの苦情から始まる場合、システム内部で起きていることと、技術部門がそれを把握できる時点との間には隔たりが生じている。.
Telemetryは、オートマトンによって実行される継続的な可観測性を通じて、そのギャップを縮めるのに役立ちます。.
Technology Leadershipにとって、変化とは単に情報をより多く得ることだけではありません。それは、 分散した情報を、技術的な運用を継続的に観察・理解するための能力へと転換する。.
なぜなら、顧客が「何かが起きている」と最初に気づく存在でなくなったとき、テクノロジーは極めて重要なものを手に入れるからだ： 理解し、行動するためのより大きな機会。.
