忘记正常运行时间。 较低的 MTTR 是 IT 的新“5 个 9”

停电的代价是昂贵的。 它们最终是攻击还是软件或硬件故障的结果并不重要。 由于现代数字经济对 API 和网络应用的依赖性越来越强，每分钟停机成本正在增加。

对于某些人来说，这些成本是惊人的。 据估计，亚马逊 2013 年的 40 分钟停机时间给他们造成了 264 万美元的损失。 对于那些不愿意计算的人来说，这就是每秒1100 美元。 如果你认为这很可怕，那么想想谷歌，同年该公司 5 分钟的宕机时间每分钟就造成 10.9 万美元的损失 （或每秒 1816.67 美元） ，总计高达 545,000 美元。 持续 5 分钟。 从技术上讲，如果这就是他们所遭受的一切，那么这就是 IT 所要实现的引以为豪的“5 个 9”的目标。

停电多久发生一次？ 显然，太频繁了。 如果你从未见过这个，请看一下pingdom 的实时中断地图。 它是根据从全球 700,000 多名用户收集的数据构建的。 这张令人着迷的地图显示了过去一小时内全球各地发生的停电情况。 描绘停电的明亮闪光是一个很好的点缀；真正地引起了用户的注意。

也就是说，这是一个不受欢迎的人。

数字经济加剧了这一问题。 今年早些时候，亚马逊的 S3 中断导致大量客户的应用程序和网站陷入瘫痪。 但是，如果您不想将这个问题归咎于公共云提供商，快速浏览一下builtwith.com网站就会很快消除这种想法。 如果考虑到对其他人的正常运行时间的依赖，利用 CDN 和 API 的网站百分比可能高得惊人。 很难找到一个不依赖至少一个外部 API 或服务的站点，这增加了停机的可能性，因为如果该外部服务停机，您也会停机。

基本上，IT 确定了“5 个 9”，因为不可能实现 100% 的可用性。 如今，由于经济向数字化领域的转变，每秒成本正在飞涨，关键在于尽量减少停机时间。 换句话说，设定要求较低的平均解决时间 (MTTR) 的目标与试图消除停机时间同样重要 - 甚至更为重要。

Puppet Labs 的《 2016 年 DevOps 状况报告》中“高绩效组织”的关键衡量标准之一是 MTTR，其定义为发生服务事故（例如计划外中断或服务受损）时恢复服务所需的时间。 绩效最高的组织（根据报告的评估）需要不到一小时，而绩效中低的组织则需要“不到一天”。 报告指出：“换句话说，高绩效企业的 MTTR 比低绩效企业快 24 倍。”

您会注意到，问题不是“是否”存在服务事故。 这是当发生服务事故时的情况。 假设事件会发生，因此关键是尽量缩短解决时间。 IHS 2016 年的一项调查报告显示，“调查受访者平均每月经历 5 次停机事件，每月停机时间为 27 小时”，这给中型企业造成了平均 1 美元的损失，而大型企业则损失高达 6,000 万美元。

如果我们假设墨菲定律仍然适用，那么答案就是尽量减少 MTTR，以减少与不可避免的停机相关的时间（和成本）。

这意味着可见性至关重要，也意味着监控。 大量的监控。 但不仅仅是网站、网络应用程序或 API——我们需要监控整个堆栈。 从网络到应用服务再到应用本身。 并不是每个人都会这样做，而且即使他们这样做，似乎也并不一致。

考虑一下 2017 年xMatters|Atlassian DevOps 成熟度调查，其中 50% 的受访者表示他们“等待运营宣布重大事件”后才会做出回应。 令人担忧的是，有 1/3 的公司“从客户那里了解到服务中断的情况”。

在数字经济中，每分每秒都至关重要。 这不仅是因为它要花钱，而且还会对未来的收入产生负面影响。 品牌价值和客户信任度的下降会导致购买量和用户减少，并最终导致增长停滞。 这不是组织应该走的方向。

监控是检测导致停机的问题的第一步。 但仅靠监控并不能帮助提高平均修复时间 (MTTR)。 沟通可以。 尽快通知相关利益相关者并向他们提供解决问题所需的信息将有助于更快地解决问题。 这意味着共享（DevOps 的四大关键支柱之一）是提高 MTTR 的关键。 即使您尚未在公司层面接受 DevOps 的其他方面，您也应该考虑将共享提升为顶级举措。 无论是通过 ChatOps还是电子邮件、移动应用程序或动态更新的 wiki 页面，通过监控收集的信息必须在整个组织内广泛共享。

交换机或服务器出现故障可能看起来无害，但如果不加以处理，可能会导致关键应用程序所依赖的一半服务瘫痪。 在Viavi 开展的 2017 年网络状况研究中，65% 的网络和系统管理员认为“确定问题是由网络、系统还是应用程序引起的”是解决应用问题时面临的首要挑战。 更高的可视性和全栈监控是应对这一挑战的方法之一，确保负责查找根本原因的人员掌握尽可能多的有关数据路径中所有组件的状态和健康状况的信息。

可视性是 IT 未来的关键。 没有它，我们就无法达到在停电发生之前纠正停电所需的自动化水平。 如果没有可见性，我们就无法有效地减少平均修复时间 (MTTR)。 没有它，我们确实无法保持业务以可持续的速度增长。

可视性和安全性一样，应该是推动 IT 发展的战略堆栈中的头等公民。 因为中断会发生，所以可见性使得组织能够快速有效地恢复，并尽可能减少对其品牌和底线的损害。