SRE心里话：要求100%服务可用性就是老板的无知

Posted 2023-05-25 龙渊秦五

不可能有 100% 的服务可用性，也没有必要做到 100% 的服务可用性。如何度量风险，如何制定 SLO，如何提升稳定性，如何权衡成本和产出

《SRE Google 运维解密》第3章讲了拥抱风险，一些关键的观点，在这里与大家分享，融入了我自己的一些理解，希望对你有些帮助。

服务可用性必须100%？其实完全没必要

一个服务客户的产品，不需要追求极端的可用性，因为实在是没有必要。比如一个论坛服务，用户使用智能手机来访问，手机本身有可能故障，手机的蜂窝网络可能出问题，如果用的 wifi 本地路由器可能出问题，小区宽带可能出问题，运营商的骨干网可能出问题，这些都不是论坛服务能够控制的。简单来说，用户在一个有着 99% 可靠性的智能手机上，是不能分辨出 99.99% 和 99.999% 的服务可靠性的区别的。

高可靠性带来高成本

99.99% 的可用性，每年不可用时长不能超过 53 分钟，如果是 99.999% 的可用性，每年不可用时长不能超过 5.3 分钟。多了一个 9，不可用时长只是缩减了 47.7 分钟，但是付出的成本可能是巨大的，需要衡量 ROI 是否值得。成本通常来自两个方面：

• 冗余物理服务器/计算资源的成本
• 机会成本

机会成本是说，我们把过多的人力投入到稳定性建设上了，导致投入到业务功能开发的人力就变少了，这个机会成本是很难估量的，但是很重要。

如何度量可用性

通常的做法是按照计划外停机时间来度量，比如：

可用性 = 系统正常运行时间 / (系统正常运行时间 + 系统计划外停机时间)

这个计划外停机时间，通常是指系统不可用的时间，比如系统崩溃了，或者系统的某个功能不可用了，或者系统的某个功能的性能下降了，都可以算作计划外停机时间。与计划外停机时间相对的，显然是计划内停机时间，偶尔通知用户，说凌晨3点我会做系统升级，计划停机3分钟，这个3分钟就是计划内停机时间，这3分钟内的不可用，不影响SLA。

但是，很多系统都是分布式的，尤其是 Google，一个服务，通常不会完全不可用，可能某个 region 不可用，但是其他 region 还可用，所以，大型互联网公司的服务通常是不会 100% 不可用的，可能会部分不可用，此时这个计划外停机时间就不好计算了。怎么办？使用请求数量来统计，可用性计算公式变成：

可用性 = 成功请求数 / 总的请求数

这是服务可用性的度量方法，一个大型互联网公司可能有几千个微服务，老板问技术团队，咱们今年的可用性如何？显然没法使用服务层面的数据，那就把众多微服务做个加权平均？也不那么说得通！那公司整体业务的 SLO 应该怎么算？一般是看业务指标，分享一下滴滴的做法，滴滴最核心的业务就是打车，核心就看打车的订单量，如果订单量下跌 10%，就开始计算不可用时长，这是整个公司最重要的可用性指标。这种指标称为北极星指标，我们现在创业就专门做了一个北极星指标的产品，对北极星指标做 VIP 级别的保障。详情可以了解这里。

谁来制定SLO？

在 Google，对于服务于终端用户的产品，通常有个产品技术团队，是这个服务的「商业所有者」，这个团队明确知道自己的商业目标，可以拍板 SLO。因为：SLO 最终是服务于商业目标的！

通常来讲，线上 70% 的故障是变更导致的，更好的 SLO 意味着线上变更的频率会降低，但是低频的变更，就意味着有些功能 feature 不能尽快发布给终端用户，终端用户的体验就会变差，竞争对手可能有更花哨好用的功能，我们无法及时跟进。那好，那就更快的变更，更快的变更通常意味着稳定性变差，所以就需要权衡了，这本质上是一个商业取舍，所以，需要商业所有者来拍板。而这个商业所有者，对于服务于终端用户的产品，通常就是产品团队，最终可能是这个业务的负责人最终拍板。

服务于内部的基础设施，比如 BigTable 这样的服务，没有终端用户，那谁来拍板？基础设施类服务，通常是服务于内部其他服务的，此时应该是 BigTable 的研发团队和上游服务所有者一起拍板，制定 SLO。

BigTable 可能同时服务两类上游服务，举例：一类上游服务是面向终端用户的，他们需要更低的延迟，另一类上游服务可能是离线任务，在 BigTable 里存储离线分析数据，他们需要更大的吞吐。低延迟的上游服务希望 BigTable 的请求队列（几乎总是）为空，这样系统可以立刻处理每个出现的请求。而离线分析的上游服务，需要更高的吞吐，希望 BigTable 繁忙，希望请求队列永远不为空。如果拿请求队列长度作为 SLO，就尴尬了...

所以，对于差异化要求比较大的基础设施，通常会拆分成不同的集群，提供不同维度的 SLO。

提升 SLO 的时候要注意 ROI

举个例子，假设某个服务每一个请求的价值是一样的：

• 可用性目标希望从 99.9% 提升至 99.99%
• 增加的可用性：0.09%
• 服务收入：100万美金
• 改进可用性后的价值：100万 * 0.09% = 900 美金

可用性提升一个 9，收益是 900 美金，如果提升一个 9 的成本低于 900 美金，就是划算的，如果高于 900 美金，就是不划算的。

SLO和错误预算构建过程

• 产品管理层定义一个 SLO，确定一项服务在每个季度预计的正常运行时间
• 实际在线时间是通过一个中立的第三方来测算的：我们的监控系统
• 这两个数字之间的差值就是这个季度中剩余的不可靠性预算
• 只要测算出的正常在线时间高于 SLO，也就是说，只要仍然有剩余的错误预算，就可以发布新的版本

扩展阅读

• 快猫星云可观测性产品，专注故障定位止损、稳定性治理
• 夜莺专业版，提供增强监控的能力，提供可观测性专家经验
• 告警事件统一OnCall中心，解决告警降噪、排班、认领、升级、协同的需求

SRE网站可靠性工程师

SRE网站可靠性工程师

SRE需要做什么？

一般:

• 故障模式，尤其是SPOF(单点故障)。消除SPOFs是你作为SRE最大的挑战和乐趣。
• 基础设施组件，从应用程序到硬件(服务器、交换机、路由器、互联网连接、防火墙、isp、互联网路由(BGP)、IPS系统等)。

应用程序级别:

• 应用程序负载测试、内存泄漏和断点。

服务器级别:

• 高可用性和系统故障转移。如何使系统优雅地失败，而不会丢失事务并从最终用户的角度保持有状态。
• 备份系统。
• 硬盘的可靠性和故障转移(包括RAID功能)。在数据中心级别，应该考虑灾难恢复(确保故障转移到不同的位置)。

安全与管理:

• 了解不同类型的网络安全攻击。
• sla——把最好的留到最后，sla(service level agreements服务水平协议)是SRE工作中最重要的方面之一。设置、监视和执行sla将占用大量工作。

SRE核心组件

SRE的以下5个理念可以通过事实数据和洞察力带来更好的客户体验。可观察性和实用的度量标准是现SRE促进服务弹性和基础设施正常运行的最佳方法——满足客户的期望。

1)可用性

SRE工程师将负责制定和满足服务水平的目标、协议和指标(SLOs、sla和SLIs)。基于底层应用程序和基础设施的成熟度，以及整个团队的结构和可靠性实践的支持，SREs可以评估合理的指标，以量化客户的正常运行时间和可用性。什么样的可用性水平是合理的，可以假定您可以持续地维护，以及什么会让客户和潜在客户满意，从而带来更多的业务?

2)性能

当然，如果站点可靠性工程师要对服务可用性负责，那么他们也要对性能负责。在某种意义上，性能是看待可用性的另一种方式。在工程团队看来，经历了某种程度的延迟或另一种类型的性能下降的客户，很可能正在经历停机。如果服务不是高性能和可用的，那么它几乎是不可用的。SREs负责为这些生产系统带来见解和行动，以确保开发人员和IT团队快速修复问题，改善客户体验，并使应用程序和基础设施随着时间的推移更具弹性。

3)监控

为了确保性能和可用性，SREs需要知道在其应用程序和基础设施中监视和警告什么。可观察的服务大大提高了开发和发布团队的效率，这自然会提高面向客户的服务的正常运行时间和性能。SREs同时使用白盒和黑箱监控，以及仪表板和其他可视化工具来确保开发，组织中任何地方的IT和安全团队都能更好地了解他们的应用程序和基础设施的健康状况。

4)事件反应

SREs的随叫随到管理和事件响应，通常在不同的组织之间是不同的。虽然站点可靠性工程师并不总是需要随叫随到，但他们至少应该对事件后的评审做出贡献，并在高水平上了解事件响应过程。系统可靠性在很大程度上取决于DevOps和IT团队在处理生产中的事故和中断时的效率。站点可靠性工程师需要对他们的事件响应团队的成功负责——这通常意味着他们需要成为随叫随到过程的一部分。

5)协作沟通

SREs需要确保开发人员和IT运营团队拥有他们需要的资源，以了解他们的系统，知道什么地方出了问题，并快速响应问题。通过事件后的协作评审过程、有用的度量标准和指示板，以及对组织的CI/CD过程的全面改进，站点可靠性工程师在DevOps和IT效率方面有很大的优势。

google招聘SRE的要求

最低学历:

• 计算机科学学士学位，软件/系统工程相关技术领域，或同等的实践经验。
• 至少使用以下语言之一进行编程:C、c++、Java、Python或Go。
• 熟悉算法和数据结构。

优先条件:

• 具有设计、分析和故障排除大型分布式系统的专业知识。
• 具有调试、优化代码和自动化日常任务的能力。
• 系统解决问题的方法，加上有效的沟通技巧和驱动力。
• 了解Unix/Linux操作系统。

参考

Google’s SRE Book
Google’s Site Reliability Workbook PDF
Google Cloud Platform Podcast
Splunk’s Beginner’s Guide to Observability
SRE, Golden Signals and Happier Customers (webinar)
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (book)
The Complete Guide to Post-Incident Reviews
Reducing MTTD for High-Severity Incidents (guide)
The Unicorn Project (book)