SRE 运维体系 CTO 技术共享

Google 在 10 年前创造了 SRE 这个工种。SRE，Site Reliability Engineering 的缩写，其中 site 是指 Website，可以翻译为网站可靠性工程。几年前资深 Google SRE Chris Jones 等人联合撰写了《Google SRE: How Google runs production systems》，首次向外界解密了 Google 的生产环境以及整个 SRE 的方法论。那么如何从零搭建一套 SRE 体系呢？下面内容主要介绍了站点可靠性工程（SRE）以及如何在系统扩展时监控和保持系统快速可靠。

图 1 构建 SRE 架构思维导图

在云时代，客户体验是所有重要企业的新口号，即使命宣言。客户体验、可用性和可访问性是在端决定的，在这里站点应当始终可用 [24/7/365]。对用户来说，可靠性才是最重要的；一个未使用的应用程序对用户和企业毫无价值。

如今，每家公司都在努力推动科技变革。公司业务战略都围绕云功能构建。这对他们来说是一项重大的运维挑战。站点性能下降、客户体验的下降都将导致现金、收入和竞争力的损失，并导致传统运维无法应对可观察性的大问题（包括实时监控和告警）。

为什么存在站点可靠性工程（SRE）？敏捷运动提升了跨职能团队之间协作的重要性，这催生了 DevOps。

DevOps 是关于深入研究自己组织的具体问题和挑战的。它还与速度、效率和质量有关。从本质上讲，它是一种以实现组织的预期结果的文化、一种运动、一种价值观、原则、方法和实践。

这种速度也造成了一定的不稳定性，开发人员的行动速度比以往任何时候都快了，但却给运维团队带来了挑战。IT 运维团队没有能力应对这样的速度，这让他们遇到了瓶颈和严重的积压，导致生产中产生了不稳定的因素，结果使系统变得不可靠。因此，Google 提出了对 SRE 的要求：“一群能够将工程专业知识应用于运维问题的开发人员。”

SRE 是一种规范的 DevOps 方式。它是系统管理任务的一种思维方式，侧重于通过缩短交付周期和事件管理生命周期，并通过减少工作量来支持开发人员和运维人员来运维服务的原则。SRE 团队的日常任务包括：

• 可用性

• 延迟

• 性能

• 效率

• 变更管理

• 监控和告警

• 应急响应

• 事件响应

• 准备工作

• 容量规划

一、那么，什么是站点可靠性工程（SRE）？

SRE 团队的角色是在生产“关键任务系统”中运行应用程序，并执行任何必要的事情来保持站点正常运行。它通常被定义为从事运维工作的软件工程师。SRE 团队负责维护和建立其系统的服务水平指标（SLI）、目标（SLO）、协议（SLA）和错误预算，并确保满足这些指标。

他们预计将花费一定的时间进行运维工作（确保系统按期工作）并改进他们管理的系统。SRE 专注于编写软件来自动化流程并减少“脏活累活”的工作量。这个“脏活累活”就是目前还未实现系统自动化并且需要手动处理的工作。

SRE 的战略目标是：

• 使部署更加容易

• 提高或维持正常运行时间

• 针对应用性能去建设可视化能力

• 设置 SLI 和 SLO 以及错误预算

• 通过承担计算风险来提高速度

• 消除手动操作任务

• 降低故障成本以缩短新功能的周期时间

二、SLI 和 SLO

服务水平目标（SLO）只是 SRE 团队与产品所有者或业务线（LOB）之间的协议。指标在很大程度上取决于团队管理的系统的性质。服务水平指标（SLI）是为系统定义的量化指标，也称为“我们正在度量的内容”。

这些指标取决于所管理的系统。对于典型的 Web 应用程序，这些指标可能是可用性、请求延迟或错误率。但是，例如 Hyperledger Fabric 区块链应用程序可能会使用每秒背书和分类帐提交率来衡量网络的吞吐量。

SRE 团队最终将管理多个系统。跨各种应用程序定义一组标准的服务水平指标将帮助团队标准化整个堆栈的监控、日志记录和自动化。

SLO 是系统应该运行的“应该有多好”的目标值或范围。这些是之前定义的 SLI 的预期操作值。例如，区块链网络必须以不到 5 秒的端到端延迟来维持 50 到 100 个事务提交速率的事务吞吐量。当然这也有可能存在过度设计 SLI 和 SLO 的倾向。一开始就让它们保持简单是很重要的。随着你对系统的了解随着时间的推移而增长，你可以设定更严格的目标。

三、SLA 关键业务价值

当客户对所提供的服务不满意，未能按照相关协议交付时，服务水平协议（SLA）就会发挥作用；它可能是一个系统的可靠性。SLA 是产品与其最终用户之间的协议，是与客户就服务可靠性签订的合同，简单表述为“SLA = SLO + consequences”。SRE 团队可能不参与定义 SLA 的过程，但是他们需要确保满足 SLO。

SLA 通常包含一段时间内服务正常运行时间的计算。

图二 用 9 展示 SRE

99.9%是三个 9 的正常运行时间，允许每天有 1.44s 的停机时间。如上表所示，每周、每月和每年的停机时间分别为 10.1 分钟、43.8 分钟和 8.78 小时。

例如，SLA 可以保证电信线路 99.9%的正常运行时间；因此，服务只能减少 0.1%的停机时间，超过这一时间将被视为违反 SLA，后果将是罚款。

四、减轻工作负担并控制 SRE 团队的工作量

SRE 团队中总会存在一些手动、乏味的事情需要执行。在你的日常工作中，无论你是软件开发人员还是架构师，你都需要完成自己不喜欢的这类任务。这些通常是手动的、无聊的和重复的任务也可能会导致错误。SRE 团队也必须执行类似的任务。这是 SRE 可以使用他们的开发技能并尽可能消除手动流程的一个实例。让 SRE 花费多达 50%的时间来改进他们管理的系统是一种很好的做法。

五、错误预算

错误预算是 SRE 团队用来平衡服务可靠性的工具，计算如下：

Availability = (Number of good events / Total events) * 100Error budget = (100 — Availability) = failed requests / (successful requests + failed requests)

误差预算是 100 减去服务的 SLO。99.99%的 SLO 服务有 0.01%的误差预算。

错误预算是 SLO 的另一个例子，其中每个服务都受其带有惩罚条款的服务级别协议的约束。它衡量你有多少空间来满足你的另一个 SLO。

例如，如果你有一个服务级别指示器，它显示 99.99%的交易必须在 5 秒内提交记账，则只有 0.01%的交易可以超过 5 秒。一个主要版本发布后，你可能会意识到系统运行开始缓慢，突然耗尽你所有的错误预算。

请记住，变更是中断的最重要原因，发布是变更的主要来源。如果你一直超出你的误差预算，你将需要重新审视你的一些 SLO 和过程。

你是否在单个版本中引入了太多更改？请保持简单，并将你的版本分成更小的需求变更。

SLO 是否过于严格？你可能需要协商并放宽 SLO。

你的发布过程中是否有任何导致问题的手动步骤？尝试引入自动化和测试。

系统的架构是否容错？硬件故障、网络包丢失、上游或下游应用程序可能会出现异常行为。你的系统架构应该能够容忍这些故障。

开发团队是否解决了技术债问题？在急于发布新功能时，技术债常常被忽视。

你的监控和告警是否抓住了主要指标？不断增长的队列规模、网络速度变慢、潜在客户变更过多等都可能导致下游事件。

你是否定期监控日志并保持其清洁？你的日志中可能存在不会立即导致问题的警告。但是，再加上其他基础设施问题，这些告警可能会导致重大事故。

六、监控分布式系统的四个黄金指标

SRE 的四个黄金指标是构建成功的监控和告警系统的一些基本原则和最佳实践。它们是大型生产应用程序的服务级别目标（SLO）的关键部分。他们的目标是帮助识别和修复你系统中的任何潜在问题。

他们主动解决你的基础架构问题，每当你的运维团队需要快速了解问题，并需要近乎实时地跟踪所有服务的延迟、流量、错误和饱和度时。

让我们简要描述每个指标，然后看看如何利用四个关键指标来监控你的系统：

• 延迟

延迟是信息发送方和接收方之间的时间延迟，以毫秒（ms）为单位。而原因往往是由于数据包丢失网络拥塞和网络抖动造成的，称为“数据包延迟差异”延迟对客户体验有直接影响，转化为成功请求的延迟和失败请求的延迟。

• 流量

流量是系统工作量带来的压力。它通过每秒查询数（QPS）或每秒事务数（TPS）来衡量。企业通过数量来衡量这一点：关键绩效指标（KPI）是在给定时间来到站点的人数。这与商业价值有直接关系。

• 错误

错误是根据整个系统中发生的错误来衡量的。被认为是服务错误率的重要指标！有两类错误：显式错误，如失败的 HTTP 请求（500 个错误代码，例如）；隐含错误是成功的响应，但内容错误或响应时间长。

• 饱和度

饱和度定义了服务的过载程度。它衡量系统利用率，强调服务的资源和整体容量。这通常适用于 CPU 利用率、内存使用、磁盘容量和每秒操作数等资源。仪表板和监控警报是帮助你密切关注这些资源并帮助你在容量饱和之前主动调整容量的理想工具。

• 利用率

虽然不是公认的“四大黄金指标”的一部分，但值得一提；利用率表明资源或系统有多忙。它以百分比表示，范围从 0 到 100%。

图三 黄金信号

我们都同意这些指标很重要，必须加以监控。那么如何开始？为简单起见，让我们创建一个非常基本的矩阵，首先考虑非常基本和传统的资源，例如 CPU、磁盘、网络和 RAM。

黄金指标的优势在于它能够发出告警、排除故障以及调整和容量规划：

• 告警可以通知你出现问题。

• 故障排除可以帮助找到并解决问题，分析根本原因。

• 调整和容量规划可以帮助随着时间的推移使用正确的指标、日志和从监控系统收集的跟踪来改善问题。

图四 黄金信号之网络和延迟

图五 黄金信号之错误和饱和

七、风险分析

风险分析定义如下：可能导致违反 SLO 的项目列表。

• TDD：检测时间（time-to-detect）

• TTR：修复时间（time-to-resolve）

• Freq/Yr：每年的错误频率（frequency of error per year）

• Users：受影响的用户

• Bad/Yr：每年有异常的分钟数，相当于错误预算

SRE 通过使用错误预算来控制可接受的风险级别和风险并做出明智的决策，从而以可控的方式接受风险关于何时应结合 SLI 和 SLO 进行更改。如果需要，SRE 团队可以控制发布周期。

Risk = TTD * TTR * (Freq /Yr) * (% of users)If TTD = 0,Risk = TTR * (Freq /Yr) * (% of users)

图六 风险分析和度量

八、监控和告警

监控是观察系统运行方式的一种好方法，告警是系统崩溃或即将崩溃时可以触发的事件。因此，SRE 团队必须构建可靠且有意义的监控系统。我们可以使用一些工具来构建良好的监控系统。Prometheus 是一个开源应用程序，用于事件监控和告警。它在使用 HTTP 拉模型构建的时间序列数据库中记录实时指标。例如，Prometheus 可以配置为从 Hyperledger Fabric 区块链节点提取指标。

图七 监控和告警

你可以配置 Grafana 来构建可视化和仪表板来查询 Prometheus。

图八 使用“四个黄金信号”监控服务的示例 Grafana 仪表板

九、促进事后分析

当你在组织中构建 SRE 角色时，一个重要但经常被遗忘的方面是事后分析，“事后分析是无可指责的”。它可以被定义为一个组织从它所犯的错误中吸取教训的机会。故障解决后应尽快进行事后分析以及复盘。在复杂的企业 IT 环境中，组件和应用程序最终会失败，这些失败可能是由于部署错误，最近版本中引入的软件 bug 或仅仅是硬件故障。

将事件的根本原因和短长期修复方案一起归档，并在开发和 SRE 团队中进行传播，这对于知识在企业的传承显得很重要。故障的发现可以用作其他系统的预防性修复，也可以作为未来类似事件的参考点。事后分析如果做得好，这些分析应该被记录，并用于建设内部知识库，便于以后查询。

十、如何获取一个可靠的服务？

SRE 团队的角色是运维应用程序并通过执行必要的操作来保持系统正常运行。以下是 SRE 在各个阶段执行日常活动的一些策略和工具：

阶段 1：Development

• 流水线（Pipelining）

• 负载和容量考量（load and scale）

阶段 2：Pilot

• 监控（Monitoring）

• 轮值和无指责的事后分析（On-call + blameless postmortems）

• 聚合和可检索的日志系统（Consolidated + searchable logging）

• 和产品负责人定期审查 SLI/SLO

• 基础设施即代码（Infrastructure as code）

阶段 3：Production

• 灰度部署和自动回滚（Canary deployment + automated rollbacks）

• 负载和扩展执行（Load and scale implementation）

• 应用性能监控（APM）

• 混沌引擎（Chaos engineering）

十一、结论

所以，可靠运行是什么意思？这篇博文试图涵盖构建成功 SRE 团队所需的基本概念和技术。讨论了如何通过改进的指标、日志、跟踪和仪表板关注可观察性来主动识别和补救事件以及什么是 SLO、SLI 和 SLA。了解如何使用错误预算和风险分析等基本工具来指导必要的决策，以平衡你对可靠性的投入与对应用程序功能或其他业务优先级的投入。最后文中详细阐述了监控分布式系统的四个黄金指标。