希望并非战略：站点可靠性工程 (SRE) 的七大原则

站点可靠性工程（又称“SRE”），是一种将运营问题视为软件问题的方法。它最初由 Google 工程师 Ben Treynor Sloss 于 2003 年首次命名并阐述。作为一门学科，SRE 旨在维护特定系统的可用性、性能和效率。

站点可靠性工程 (SRE) 可能很难确定。它是一种方法或学科，而不是一套规定性的任务，并且它根据特定组织的需求而采取不同的形式。幸运的是，站点可靠性工程的七项原则可以帮助指导 SRE 团队取得成功。

大多数软件开发都专注于创建——包括开发运维 (DevOps)，这是一个关联但独立的领域，更关注产品的整个生命周期，但系统上线远非工作的终点。在 Google 的 SRE 指南序言中，作者指出“系统总成本的 40% - 90% 是在系统诞生后产生的”。SRE 重点关注系统上线后的情况，旨在最大限度确保产品的可用性。

SRE 最关键的要素是系统可靠性和运行时间。如果系统无法正常运行，即使是全球最卓越的服务也无法普惠用户。因此，SRE 专注于最大限度减少停机并创建可靠的系统。

SRE 团队还会通过严格管理软件和安全更新，确保产品的所有元素维持最新状态。标准和法规可能会发生变化，工程团队应负责持续进行合规管理。

SRE 实践也可以节省资金。SRE 的许多核心原则都与效率有关，效率可以显著节省成本和工作量，包括通过自动化和资源管理。

SRE 的七大原则包括：

• 接纳风险
• 服务级别目标
• 消除低效劳作
• 监控
• 自动化
• 发布工程
• 简易性

虽然 SRE 高度关注管理和限制停机时间，但这种趋势并不意味着目标是让服务保持完美、100% 可用的服务可靠性。事实上，SRE 的关键支柱之一是，100% 的可靠性不仅不现实，甚至不一定是首选结果。

在 SRE 中，风险被视为一个连续体，当可靠性接近 100% 时，降低风险的难度和成本会呈指数级增长。尝试将可靠性从 99.99% 提升至 99.999% 比从将其从 80% 提升至 99% 要困难得多。接近 100% 所需的资源会降低开发团队执行其他任务的能力，例如创新新功能和更新。相反，团队会设置误差量来表示相应的失败次数。

另一个反对追求绝对可靠性的理由是：超过特定阈值后，用户通常无法感知可靠性的提升——尽管这一结论看似违背常理。它不仅成本高昂，而且收效甚少。理想的情况是，制定并实现目标，但不要过分超标。

相反，SRE 利用可用性指标来衡量停机风险的可接受度。根据一项指标，99.99% 的可靠性意味着仅允许全年累计 52.6 分钟的停机时间。更复杂的指标则会考虑某个位置或某个服务的元素发生停机但其他元素仍正常运行的可能性。

SRE 团队必须评估每项服务并确定可接受的不可靠程度。允许的停机时间有多长？由多种根本原因引发的各类故障是否会对用户体验产生不同的影响？超过这一限值，需要投入多少成本（包括人力和资金）？平衡点在哪里？

选择目标并衡量其成效和原因，对于 SRE 团队至关重要。服务级别目标 (SLO) 是一个具体且可衡量的目标，代表 SRE 团队设定的质量等级。这类 SLO 可采用各种形式的指标，但可用性、查询率、错误率和响应时间均为常见指标。

这些目标可利用服务级别指标 (SLI) 来衡量，同时也是延迟等性能的原始测量值。因此在这种情况下，SLI 对应延迟指标，SLO 则要求该指标始终低于特定阈值。反之，SLO 可作为服务级别协议 (SLA) 的组成部分，同时充当提供商和用户之间的合同，并对 SLO 以及不满足此类协议的后果作出规定。

选择服务级别目标 (SLO) 可能很棘手。理想情况下，应围绕对用户最重要的内容来构建 SLO。例如，对于云游戏服务，SLO 可能会围绕低延迟展开，但对于会计服务来说，延迟并不是那么重要。

理想情况下，站点可靠性工程师会使用相对较少的 SLO 来专注于实现这些目标；正确完成主要任务至关重要。设定现实的目标也很重要；正如我们之前讨论的，完美既不是一个现实目标，也不是一个理想目标。

SRE 的创建者特意将“低效劳作”定义为与工作存在交集但本质不同的劳动类别。低效劳作指的是线性扩展的手动工作任务，这些任务通常是需手动操作且存在重复性，因此往往可以借助自动化技术来完成。

必须反复进行的工作可归类为低效劳作；理想情况下，单项任务则只需一到两次复核即可完成。无法改进产品的工作也属于低效劳作。“如果您的服务在完成任务后仍处于相同状态，那么这项任务就是‘低效劳作’，” Google 的 Vivek Rau 写道。错误修复、功能完善和优化并不属于低效劳作，但手动下载指标则可纳入这一范畴。事件响应可能包括工程师和运营团队之间的大量协调工作，但它并不是低效劳作，因此应在产品发布前规划好事件管理策略。

还有认知负荷。您是否有过这样的经历：您经常使用一种基本食谱，但每次都要查找配料和用量？这就是认知负荷：一遍又一遍地重新学习某种事物会浪费时间和精力。相反，SRE 提倡创建更多的指南和标准，因此无需一直记住或重新学习方法和任务。

站点可靠性工程最重要的部分之一是监控：使用工具不断测量、分析和改进核心功能和系统性能。这些核心功能通常包括所谓的监控“四个黄金指标”：

延迟：最基本的定义是，完成请求需要多长时间？请注意，具体时长取决于请求成功与否；有时，错误消息可能需要更长的时间来处理。

流量：服务的负载或需求有多大？具体单位会有所不同：也许是页面浏览量、交易量或 HTTP 请求。

错误：错误通常按速率来衡量，可能包括获取不正确的数据、获取数据的速度低于 SLA 规定速度，或根本无法获取。

饱和度：从本质上讲，饱和度是衡量一项服务接近其容量上限的程度。了解饱和度非常重要，因为当接近 100% 饱和度时，部分服务会逐渐出现故障、速度迟缓或产生更多错误。

许多监控工具均可收集数据、设置基准、调试和分析问题、提供实用的可观测性仪表板，并提醒 SRE 关注潜在的中断或其他问题。解决事件后提供可靠的事后分析报告也很重要，该报告可用于阐释事件的背景、根本原因和触发因素、影响、解决方案以及未来的经验教训。详细且客观的事后分析对于避免重复犯错大有帮助。

与现代科技的诸多要素一样，将自动化纳入工作流的目的是帮助工程师摆脱无附加值的重复性任务。有了更多的空闲时间，工程师就能处理自动化无法完成的任务：创建、构思、大规模指导等。

自动化对于实现以下目标极具价值：

一致性：重复性手动任务的弊端不仅在于枯燥乏味，而且会占用更有价值的行动的时间。如果这些任务（例如用户帐户创建）由自动化工具完成，几乎可以杜绝错误和不一致。新员工的做事方式可能与老员工不同；用户可能会意外地在错误的字段中输入值，而自动化流程（通常）不会。

可扩展性：可扩展性是自动化的一个主要长期优势。让我们以之前的用户帐户创建示例为例。如果帐户创建量呈指数级增长，那么负责帐户设置的员工的工作量也会呈指数级增长，从而使该员工无法从事其他可能更有价值的工作。自动化系统不会出现这个问题。

速度：某些任务（如查找和修复代码中的错误），会耗费大量的人力时间成本。自动化软件系统能够监控大量数据，并且通常可以通过高级模式识别和其他工具比人类更快速地检测错误，从而快速完成修复，而无需任何人工干预。

当然，任何自动化流程都潜藏着危险。其中包括：

前期成本：必须先创建自动化，然后才能部署。这可能需要大量的时间、精力，甚至硬件成本。在考虑自动化的价值时，必须兼顾创建自动化所付出的努力和自动化启动后实际节省的资源。

维护：自动化任务看似能够永续运行，但情况往往并非如此。自动化代码必须及时更新，并与其他代码和系统更新保持同步。如果添加新功能，则需要通过人工干预更新自动化代码，以融入新操作或防止出错。

人工智能为 SRE 提供一些令人兴奋的全新可能性，最明显的是在自动化领域。从理论上讲，前期成本和维护都可以通过新的 AI 模型进行调节。尽管如此，AI 也带来了新的潜在痛点：最明显的是幻觉、安全和隐私。

发布工程是软件工程的一个子学科，重点关注发布软件的必要步骤。这些步骤包括版本控制、计划发布、持续或定期构建，以及发布指标的选择和收集等流程。在 SRE 中，发布工程从一开始就已内置而非事后补充，其目的是避免最后一刻才仓促分配发布工程任务。

作为一门学科，发布工程涉及多项关键原则。其中包括：

自动化和自助服务：理想情况下，许多发布流程可以自动化，并且只需极少甚至几乎不需要工程师互动。这确保了快速且稳定的发布。

速度：在发布工程中，快速且频繁的发布是首选理念。通过快速推出版本，甚至可能每小时发布一次，版本之间的变化会减少。这种速度使测试和故障排除变得更加容易。

封闭式构建：构建过程应完全独立于构建机器本身，并采用主流编译器、库和工具。“如果两个人尝试通过不同机器的源代码存储库以相同的版本号构建同一产品，我们期望得到相同的结果，” Google 的 Dinah McNutt 写道。

标准和政策：出于安全考虑，对某些任务进行检查至关重要，包括部署、源代码变更、新版本发布和构建配置变更。

站点可靠性工程的大部分工作均围绕简易性展开。Google 的 Max Luebbe 写道，软件“本质上处于动态且不稳定的状态”。考虑到这一点，简易性是最大限度减少潜在问题并控制固有不稳定性的关键所在。

为此，站点可靠性工程提倡开展各种任务，以简化和明确项目。

1. 仔细选择要包含的功能很有帮助，但简单地删除所有不会显著增加产品实用性的功能也同样有帮助。功能越多就越复杂。
2. 较小、较频繁的版本发布使调试和故障排除更加容易。具有数十个新功能的新版本可能会引入可能极难追踪的错误。那么具有一项新功能的版本呢？任何潜在问题都只能来自一个地方。
3. 同样，组织也倾向于增加 API 的复杂性，具体为借助多个端点、微服务等方式。但我们应避免这种情况。API 越简单，设置越快，所需文档也越少，同时还可减少整合时间和成本。