作者：Ernese Norelus 和 Erhan Saygi

从头开始构建 SRE。站点可靠性简介… |作者：厄内斯·诺雷勒斯 |中等 (medium.com)

在云时代，客户体验是任何严肃企业的新口头禅，是使命宣言。客户体验、可用性和可访问性在边缘确定，网站应始终可用 [24/7/365]。毕竟，可靠性对用户来说很重要;未使用的应用对用户和业务没有任何价值。

如今，每家公司都是推动变革的技术公司。公司围绕云功能构建其整个业务战略。这对他们来说是一项重大的运营挑战。性能和客户体验的任何下降都将导致金钱、收入和机会的损失，并导致传统运营[作案手法]无法应对可观察性的大问题，包括实时监控和警报。

为什么存在站点可靠性工程 （SRE）？敏捷运动促进了跨职能团队之间协作工作的重要性，这催生了DevOps。DevOps 是关于深入了解您自己组织的特定问题和挑战。它还涉及实现速度、效率和质量。从本质上讲，它是一种文化、一种运动、一种价值观、原则、方法和实践的哲学，以实现组织的期望结果。这种速度造成了一些不稳定，开发人员比以往任何时候都更快地移动，并为运营团队带来了挑战。IT 运营团队无法应对这种速度，这给他们带来了重大瓶颈和积压，无法应对速度，导致生产中不受控制的不稳定，系统变得不可靠。因此，需要谷歌创建的SRE：“一群可以将工程专业知识应用于运营问题的开发人员。*

SRE 是执行 DevOps 的一种规范性方法。它是系统管理任务的一种思维方式，侧重于通过减少交付和事件管理生命周期时间和减少工作量来支持开发人员和运营来运营服务的原则。SRE 团队的日常任务包括：
– 可用性
– 延迟
– 性能
– 效率
– 变更管理
– 监视和警报 – 应急响应 – 事件响应

– 准备

– 容量规划

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

SRE 团队的作用是在生产“任务关键型系统”中操作应用程序，并采取一切必要措施保持站点正常运行。它通常被定义为执行操作工作的软件工程师。SRE 团队负责维护和建立其系统的服务级别指标 （SLI）、目标 （SLO）、协议 （SLA） 和错误预算，并确保满足这些要求。他们应该花一定的时间做运营工作（确保系统按预期工作），并改进他们管理的系统。SRE 专注于编写软件以自动化流程并减少工作量。辛劳被认为是系统上的手动活动，任何当前未自动化的活动。

SRE 的战略目标是：
– 使部署更容易
– 提高或保持正常运行时间 – 建立对应用程序性能
的可见性 – 设置 SLI 和 SLO 以及错误预算 – 通过承担计算的风险
来提高速度 – 消除辛劳

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

具有后果和 SLI 的 SLO

服务级别目标 （SLO） 只是 SRE 团队与产品所有者或业务线 （LOB） 之间的协议。指标在很大程度上取决于团队所管理系统的性质。服务水平指标（SLI）是为系统定义的定量度量，也称为“我们正在测量的内容”。指标取决于所管理的系统。对于典型的 Web 应用程序，这些指标可能是可用性、请求延迟或错误率。但是，例如，Hyperledger Fabric Blockchain应用程序可能会使用每秒的背书和账本提交率来衡量网络的吞吐量。

SRE 团队最终将管理多个系统。跨各种应用程序定义一组标准的 SLI 将有助于团队标准化整个堆栈的监视、日志记录和自动化。

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

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

SLA 关键业务价值

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

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

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

例如，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 的另一个示例，其中每个服务都受其 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 违规的项目列表 – TTD（检测时间）- TTR（解决时间）- 频率/年（每年的错误频率）- 用户（受影响用户的百分比）
– 坏/年（每年坏分钟数，也等同于错误预算）

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 Blockchain节点中提取指标。

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

促进事后分析

当您在组织中构建 SRE 功能时，一个重要但经常被遗忘的方面是事后分析，“事后分析应该是无可指责的。它可以被定义为组织从所犯的错误中吸取教训的机会。事后分析应在事件解决后尽快合理进行。在复杂的企业 IT 环境中，组件和应用程序最终会失败。失败可能是由于部署错误、最新版本中引入的软件错误或仅仅是硬件故障造成的。记录事件的根本原因以及应用并在开发和 SRE 团队中传播的短期和长期修复对于保留在企业中获得的知识非常重要。事件的结果可以用作对其他系统的预防性修复，也可以作为将来类似事件的参考点。实施良好，事后分析应该易于访问，并保留为将来访问的存储库。

您如何获得可靠的服务？

SRE 团队的作用是操作应用程序并采取任何必要的措施来保持系统正常运行。以下是 SRE 通过各个阶段执行日常活动的一些策略和可能的工具：阶段 1：开发
– 流水线 – 负载和规模咨询
第 2 阶段：试点
– 监控
– 随叫随到 + 无可指责的事后分析- 整合 + 可搜索日志记录

– 与产品经理
一起审查 SLI / SLO – 基础架构即代码
第 3 阶段：生产

– 金丝雀部署 + 自动回滚 – 加载和扩展实施
– 应用程序性能监控

– 混沌工程

结论

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

合著者

Erhan Saygi，IBM区块链实验室架构师

归 因

特别感谢来自 Marketing and Communications IBM Garage 的 Amy Xin 在发布前校对了初稿。另外，感谢 IBM Garage Singapore Engagement Manager 团队：Yvette Lin和 Jenny Goh 的审阅。Chun-Yin Wong，软件客户端架构师，Kok Wai Ong，技术销售。

引用

对 SRE 感到好奇，请参阅下面的链接，您可以在其中找到许多有关如何掌握核心概念的读物，这些概念可以快速采用，而无需花费数月时间试图找出“正确的做事方式”：

• 寻求 SRE
• 所以你想成为一名 SRE？
• 站点可靠性工程
• 站点可靠性工作簿
• 如何监控 SRE 黄金信号
• 收集指标的四个黄金信号
• 站点可靠性工程的构建块
• SRE：可观测性：指标命名空间和结构
• 展示站点可靠性工程 （SRE） 的价值
• 用谷歌的 4 个黄金信号定义网络性能
• 在云应用程序管理方面，请从黄金信号开始
• 云原生应用中 API 运行状况和性能的 4 个黄金信号
• AWS re：Invent 2018：在高速增长期间在 Coinbase 从头开始构建 SRE （DEV315-S）