それはアプリケーションの世界です。 意図的かどうかは別として、その結果の一つは、成功を測定する方法が変化することです。 今日の測定は、歩行者数ではなくダウンロード数とインストール数、平方フィートあたりのコストではなくマイクロ秒数と稼働率のパーセンテージで行われます。 つまり、パフォーマンスこそが重要であり、プラエトリアン ガードはパフォーマンスが維持されるようにするために導入されたインフラストラクチャです。
パフォーマンスを確保するには、パフォーマンスを(ほぼ)リアルタイムで把握する必要があります。 結局、壊れていることを知らなければ修理することはできません。 アプリケーションが壊れているかどうかを知るには、関わり、ビジネスを行っている顧客や従業員のアプリケーション エクスペリエンスを監視し、測定する必要があります。 しかし、研究によれば、必ずしもそうではないことが分かっています。 Copper Egg の調査によると、組織の半数以上 (54%) が、比較的小さなアプリの一部のみを監視しています。 正確には25%以下です。
確かに、パフォーマンスと可用性の監視と測定にはより注意を払う必要があります。 可用性の重要な要素はパフォーマンスであるという点で、これら 2 つは密接に関連しています。 パフォーマンスの悪いアプリは、使用済みのキャンディーの包み紙と同じくらいの注意で放棄され、呪われ、削除されます。 その点を証明するために多くの研究を引用することもできますが、すでにインフォグラフィックを見てレポートを読んだ99%の人々のために、引用はやめておきましょう。 パフォーマンスは非常に重要であり、それを「稼働時間」に含めるかどうかは運用ポリシーの問題であり、現実を反映するものではないとだけ言っておきます。
1 マイクロ秒の遅延は、生産性の低下、あるいは最終的には利益の損失という形で、企業に潜在的に損失をもたらします。 アプリケーションの世界では時間はお金であり、アプリケーションのパフォーマンスと可用性を測定および監視するニーズをサポートするアーキテクチャを共同で設計および実装するのは IT 全体の責任です。 つまり、実際に何を測定しているのか、その数値がパフォーマンスと可用性にどのように影響するのかを理解し、データの分析を通じて適切な是正措置を講じて、アプリケーション エクスペリエンスに対するユーザーの期待を満たすか、できればそれを上回ることができるようにする必要があります。
連絡しないでよ、兄弟
それは、単純な監視および測定手法から脱却することを意味します。 たとえば、 ping を使用してアプリケーションの稼働時間を判断しても、パフォーマンスの測定という点では価値がなく、可用性に関してもほとんど価値がありません。 仮想化からコンテナ化へとさらに進むと、共有システムの監視の価値は低下し続け、監視と測定はスタックの上部、つまりビジネスが現在依存しているアプリケーションまで強制的に行われるようになります。 マイクロサービスへの移行も、測定方法と測定対象に影響を与えます。
つまり、アプリが何をどのように監視および測定するか、またそのデータをシステムにフィードバックして必要に応じて調整できるようにする方法の両方を再評価する必要があります。 個々のシステムのパフォーマンスと可用性は重要ですが、「アプリ」が分散され、複数のサービスで構成されている場合は、 「アプリ」をそのすべての部分に基づいて測定する必要があります。
アプリケーションとアーキテクチャは進化しました。 パフォーマンスと可用性を監視および測定するための戦略も進化させる時期が来ています (おそらく過ぎています)。
測定対象(およびその理由)の詳細については、「測定と監視」をご覧ください。 アプリとスタック