别来找我，兄弟

这是一个应用世界。 不管有意还是无意，其后果之一就是我们衡量成功的方式发生了改变。 如今的测量单位是下载量和安装量，而不是人流量；是微秒和正常运行时间百分比，而不是每平方英尺的成本。 这意味着性能为王，而禁卫军就是为确保性能得以维持而设立的基础设施。

确保性能意味着您可以（近乎）实时地查看性能。 毕竟，如果您不知道它坏了，您就无法修复它。 要知道它是否有问题，您需要监控和衡量与您交往和有业务往来的客户和员工的应用体验。 然而研究表明事实并非一定如此。 根据Copper Egg 的研究，超过一半（54%）的组织仅监控其应用程序中的一小部分。 准确地说是25％或更少。

可以肯定的是，我们需要更加警惕地监控和衡量性能和可用性。 两者密切相关，因为可用性的一个关键组成部分是性能。 性能不佳的应用程序会被抛弃、诅咒和删除，就像使用过的糖果包装纸一样。 我们可以引用许多研究来证明这一点，但为了 99% 已经看过信息图表和阅读过报告的人的利益，我们还是不要这样做了。 可以说，性能至关重要，我们是否将其纳入“正常运行时间”是一个运营政策问题，而不是现实的反映。

每微秒的延迟都有可能给企业带来金钱损失，要么是生产力损失，要么最终是利润损失。  在这个应用游戏中，时间就是金钱，并且需要 IT 作为一个整体来协作设计和实施支持衡量和监控应用性能和可用性需求的架构。 这意味着了解我们实际测量的内容以及这些数字如何影响性能和可用性，以便通过分析数据，我们可以采取适当的纠正措施，满足或超越用户对应用体验的期望。

别来找我，兄弟

这意味着要超越简单的监测和测量技术。 例如，使用ping来确定应用的正常运行时间，对于衡量性能没有任何价值，对于可用性也没有什么帮助。 随着我们从虚拟化进一步进入容器化，共享系统的监控价值将继续降低，并迫使监控和测量向上游发展，转向业务现在所依赖的应用。 向微服务的转变也会对我们的测量方式和测量内容产生影响。

这意味着重新评估应用程序的监控和测量内容和方式，以及如何将数据反馈到系统中以便在必要时进行调整。 单个系统的性能和可用性很重要，但是当“应用程序”是分布式的并且由多个服务组成时，就需要开始根据其所有部分来衡量“应用程序”。

applications和架构已经发展。 现在（或许已经）是时候制定监控和衡量其性能和可用性的策略了。

您可以在“ 中阅读更多有关测量的内容（以及原因）的信息测量和监测： 应用程序和堆栈”