MTTR 不是“平均重启时间”

快速失败是当今速度的口头禅。 无论是 DevOps 还是业务，在数字经济中运营的前提都要求正常运行时间尽可能接近完美。

虽然这种哲学的理论是好的，但在实践中结果往往只是更多的失败。 由于没有集中精力寻找根本原因（MTTR）而只是注重确保可用性（正常运行时间），我们正在以前所未有的速度丢失宝贵的数据。 面对现实 - 当您只关心正常运行时间时，MTTR 就变成了平均重启时间，而不是平均解决时间。 如果没有解决方案（停机原因），您就无法防止它再次发生。

这种做法对企业是有害的。

你看，你丢的不是包裹，而是硬币。 而正如从交易中挪用零头以敛财数百万美元的经典犯罪手法告诉我们的那样，每一分钱都很重要。 组件、服务、服务器每秒钟若无法响应，您就会失去价值——无论是体验上的还是存在上的。 消费者不会容忍糟糕的性能或停机时间，商业分类账也不能容忍这两者。

如果您对吞吐量和带宽有所了解，您就会知道这两项计算的基础都是底层系统每秒可处理的数据包数。 这不仅适用于网络，也适用于与交易交互的每个组件。 应用程序。应用服务。 路由器。 开关。 数据库。 如果它有网络连接，它就会受到相同的计算和传递数据包能力的限制。

警告： 数学领先

当今的网络速度确保我们能够以每秒数百万个数据包的速度完成这一任务。 当然，商业交易主要通过 HTTP 交易（字面上的）网络进行，每个交易都会传递对开展业务至关重要的信息。 进行交易所需的数据包数量取决于所需的数据量。 平均每个数据包携带 1500 字节的数据（即 MTU）。 因此，如果携带代表交易的 JSON 有效负载的基于 HTTP 的消息需要 4500 字节（当然是加密后），那就大约需要三个数据包。 因此，我们可以大方地假设，一次典型的数字商业交易需要五个数据包。 10Gbps 网络每秒可以处理不到 15M 个数据包。 假设有足够的计算能力，那么你可以说这相当于 300 万笔交易。 我们假设每笔交易的价值都是一分钱的一小部分（三分之一）。 也就是每秒 100 万美元。

现在，实际上没有人以那样的速度或规模处理交易。 即使是 Visa（毫无疑问其数据处理速度超出大多数企业的要求）也声称其处理能力约为每秒 24,000 笔交易。 假设这些交易的价值相同（三分之一美分），那么每秒仍为 8,000 美元。

重点在于，由路由器、交换机、网络和应用服务基础设施、应用程序基础设施和组件组成的交易链出现故障是一件非常糟糕的事情™。 它的代价是昂贵的，因为一旦发生故障就意味着数据包无法被处理，它们所代表的金钱也无法被处理。 数字经济的每个部分都依赖于数据包的传递。

到目前为止，答案就在“快速失败”的口头禅中 - 只需启动 X 或 Y 或 Z 或任何失败的组件的新实例。 但该组件失败是有原因的，因此找出并解决该原因至关重要。 迅速地。 因为在故障和恢复之间仍然有宝贵的几秒钟，会损害商业价值。 如果一次失败，就很可能会再次失败。 又一次。

可见性： MTTR 的基础

这就是为什么可见性对于数字经济的成功如此重要。 因为可见性使得所有操作能够找到并补救故障的原因。 不幸的是，我们常常为了追求速度而牺牲可见性。 不是字面上的交易速度，而是价值实现时间。 我们急于更快、更频繁地将应用程序推向市场，因此我们并没有进行足够的投资来提高减少故障所需的可见性。

事实上，有人可能会认为 DevOps 的“快速失败”哲学是对这种失败的回应。 由于缺乏查找和解决故障原因的能力，DevOps 认为最好恢复可用性，而不是浪费时间。 随着企业采用多云方法部署应用，这种能力变得越来越难以实现。

2018 年，不到三分之一 (31%) 的受访者提到了多云的可视性挑战；而 2019 年，这一比例跃升至三分之一以上 (39%)，与性能和安全性并列成为多云面临的最大挑战。 可见性是总体“可观察性”的一个关键组成部分，它汇集了监控、分析和警报，可随时提供有关系统状态的宝贵见解。 在发生故障时，这一点尤为重要，因为系统状态分布在多个 IT 领域，这些领域可能会也可能不会实现信息共享，从而可以快速解决问题而不仅仅是重新启动。

服务网格通过分布式跟踪增加价值的能力是实现可见性的一个很好的例子。 但我们需要将其扩展至整个应用服务链，以扩展和保护在容器化世界中执行的应用。 其中包括在公共云中运行的分布式组件和应用，它们可能是执行链的一部分。 需要跨环境、基础设施和应用的可见性来查找和解决导致停机或性能不佳的问题。

可见性对于使组织能够重新衡量 MTT解决方案而不是 MTT重新启动的成功至关重要。