站点可靠性工程师（SRE）是一个相对较新的岗位，通常隶属于工程或运维团队，主要负责维护站点可靠性。站点可靠性通常是指应用的可用性，但也包括性能。这并不难理解，因为如今大多数最终用户会将无响应的应用视为不可用。
在阅读Catchpoint 的《2018 年 SRE 报告》时，对比服务级别指标与 SRE 度量指标的图表引起了我的注意。通常，当“可用性”作为顶层服务级别指标时，也会看到以“正常运行时间”或“停机时间”作为度量指标。但本次调查中的 SRE 并非如此。
当被问及哪些服务级别指标对其服务最重要时，84%的受访者以压倒性多数将“最终用户可用性”列为首位。延迟以61%的占比位居第二，错误率以60%紧随其后，位居第三。性能（报告中称为最终用户响应时间）也获得了58%的受访者选择。
现在，请注意用于定义成功的指标。在基础设施和运维领域，我们更常见到“正常运行时间”等指标，以及“五个 9”之类的常用说法。
相比之下，SRE往往以事件发生率和平均修复时间（MTTR）来衡量成功。同一份报告指出，41%的SRE在成为SRE之前担任“DevOps工程师”，因此这并不令人意外。DevOps本身更关注MTTR，而不是计算正常运行时间，因为其前提是停机必然会发生。关键在于快速解决问题，尽量缩短停机时间，而不是浪费时间试图完全避免停机。
不过，敏锐的读者会注意到，缩短平均修复时间（MTTR）也就意味着减少停机时间。解决得越快，停机时间就越短。
两者之间的细微差别在于，人们往往会针对考核指标进行优化。如果考核指标是代码行数，就会编写大量代码，无论是否确有必要。如果考核指标是安全事件，就会封锁一切，并对任何可能增加安全漏洞风险的变更坚决说“不”。如果以正常运行时间考核员工，运维团队就会专注于维持系统正常运行和可用，却不会着力设计系统和应用的架构并为其配置监测机制，以缩短平均修复时间（MTTR）。
这是DevOps需要延伸到NetOps的“文化”理念之一，即改变我们处理运维工作的方式。如果继续以正常运行时间为优化目标，就会错失部署告警和可观测性功能（如监控和完善的日志记录）的机会，而这些功能有助于缩短平均解决时间，实现尽量减少停机时间的目标。
逐一翻查日志，即使是集中式日志，也无法高效定位并解决问题的根源。如果能够及时发现性能下降或突然发生故障的系统或服务，并对整个数据路径（网络、基础设施、应用）中影响可用性的关键变量（如容量、连接和性能）进行实时监控和告警，就能缩短问题解决时间。
NetOps需要在生产管道的可靠性方面采用这种方法，因为总体而言，它能更好地应对不可避免的故障，而且也与DevOps团队的做法一致。毕竟，我们只以5个9为目标是有原因的，不是吗？因为我们认识到，无论多么努力，故障总会发生，而完美是不可能的。
从以正常运行时间和停机时间衡量成功，转向采用平均修复时间（MTTR）这一指标，有助于促进跨团队协作，并在整个生产流水线中使用可观测性工具。调查显示，监控和告警工具位居SRE“必备工具”之首，这是有原因的。可观测性（旨在针对错误和事件发出告警）与协作相结合，更有助于确保NetOps、DevOps和应用开发团队都能实现目标，让应用始终保持快速和可用。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。