NetOps 关注 SRE，重点关注 MTTR，实现可用性

站点可靠性工程师 (SRE) 是一个相对较新的角色 - 通常在工程或运营领域 - 专注于维护站点可靠性（这并不奇怪）。 这通常意味着applications的可用性，但也包括性能。 这是有道理的，因为如今大多数最终用户都认为无响应的应用程序不可用。

仔细阅读Catchpoint 的 2018 年 SRE 报告，我被比较服务水平指标和 SRE 指标的图表所震撼。 通常，当您将“可用性”视为顶级服务级别指标时，您也会将“正常运行时间”或“停机时间”视为指标。 但本次调查中的 SRE 并非如此。 

当被问及哪些服务水平指标对他们的服务最重要时，84% 的受访者表示“最终用户可用性”是第一位的。 延迟位居第二，占 61%，错误率位居第三，占 60%。 性能（报告中描述为最终用户响应时间）占据了令人印象深刻的 58% 的答案。

现在请注意用来定义成功的指标。 在基础设施和运营领域，我们更习惯于看到“正常运行时间”等指标和“5 个 9”等朗朗上口的短语。

SRE 倾向于根据事故发生率和 MTTR 来衡量成功。 鉴于同一报告指出 41% 的 SRE 在成为 SRE 之前曾担任“DevOps 工程师”的角色，所以这应该不足为奇。 DevOps 本身更关心 MTTR 而不是计算正常运行时间，因为它假设会有停机时间。 关键在于快速解决它以尽量减少它，而不是浪费时间试图避免它。

不过，精明的读者会注意到，通过最小化 MTTR，您可以最大限度地减少停机时间。 解决速度更快，停机时间更少。

两者之间的细微差别在于，人类倾向于根据所要测量的内容进行优化。 如果按代码行数来衡量，那么您将会编写很多代码行 – 无论您是否需要它们。 如果您对安全事件进行衡量，您将锁定一切并对任何可能导致违规的更改大喊“不”。 如果您根据正常运行时间来衡量人员，则运营将专注于保持系统正常运行和可用，而不是设计和检测可减少 MTTR 的系统和applications。

这是 DevOps 的‘文化’方面之一——我们处理运营的方式的改变——需要延续到 NetOps 中。 如果我们继续优化正常运行时间，我们就会错失实施警报和可观察性（如监控和强大的日志记录）的机会，从而减少平均解决时间并实现最小化停机时间的目标。

挖掘日志（即使是集中式日志）并不是了解问题本质并解决问题的有效方法。 如果您发现系统或服务正在降级或突然出现故障，那么对影响可用性的关键变量（例如整个数据路径（网络、基础设施、应用）的容量、连接性和性能）进行实时监控和警报将不可避免地减少解决问题所需的时间。

NetOps 需要在生产流程的可靠性方面采用这种方法，因为它是处理不可避免的故障的更好的方法，并且与 DevOps 的方法保持一致。 毕竟，我们只达到 5 个 9 是有原因的，不是吗？ 因为我们认识到，无论我们多么努力，都会失败，完美是不可能的。

从正常运行时间/停机时间转变为平均修复时间 (MTTR) 作为成功的衡量标准，可以鼓励跨团队协作以及在整个生产流程中使用可观察性工具。 在调查中，监控和警报工具位列 SRE 的“必备工具”之首，这是有原因的。 可观察性（目的是对错误/事件发出警报）加上协作是一个更好的方案，可以确保每个人——NetOps、DevOps 和 App Dev——都能实现保持应用程序快速且可用的目标。