从0构建 SRE 运维体系

前言：该文章为 19 年 Ernese Norelus 发表在 medium 上的 Building SRE from Scratch，现在看来也依然不会觉得过时，一起再来回顾一下。

首先从一张构建 SRE 体系图开始，从为什么构建 SRE、SRE 目标以及如何实现 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 团队最终将管理多个系统。跨各种应用程序定义一组标准的 SLI 将帮助团队标准化整个堆栈的监控、日志记录和自动化。

SLO 是系统应该运行的目标值或范围 “它应该有多好。” 这些是之前定义的 SLI 的预期操作值。例如，区块链网络必须维持 50 到 100 个交易提交率的交易吞吐量，端到端延迟小于 5 秒。

可能存在过度设计 SLI 和 SLO 的倾向。一开始就让它们保持简单是很重要的。随着您对系统的了解随着时间的推移而增长，您可以设定更严格的目标。

SLA 关键业务价值

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

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

99.9% 是三个 9 的正常运行时间允许每天 100 万 44 秒的停机时间。该停机时间分别为每周、每月和每年 10.1m、43.8m 和 8.78 小时的停机时间，如上表所示。

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

减少工作量并控制 SRE 团队的工作量

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

也就是，真正让 SRE 团队能够有一半的时间来去改进系统或者工具，来整体减少这种手工的、无聊的、琐碎的工作。当然了，在国内不论是组织架构还是人员要求，都很难能够做到这一点。

错误预算

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

可用性=（良好事件数 / 事件总数）* 100
错误预算= (100 - 可用性) = 失败的请求 / (成功的请求 + 失败的请求)

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

错误预算是 SLO 的另一个示例，其中每个服务都受制于其带有惩罚条款的 SLA。它衡量您有多少空间来满足其他 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。

促进事后分析

当您在组织中构建 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。

了解如何使用错误预算和风险分析等基本工具来指导必要的决策，以平衡您对可靠性的投入与对应用程序功能或其他业务优先级的投入。

详细阐述了监控分布式系统的四个黄金指标。