学习资料： ITIL培训基地专家讲堂直播 300期视频回放

什么是SRE，如何从 0 建设 SRE 运维体系？

前短时间发了一篇文章讨论《如何构建IT监控管理体系？（一）IT监控管理流程设计》，其中给大家留了一个预告，说会写一篇《如何使用SRE的实践来落地ITIL4的“事态和监控管理实践”》。在这之前先给大家从监控的视角介绍下SRE以便于能够更好的利用SRE的实践思想落地ITIL4的“事态和监控管理实践”。

导入：SRE的来源

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

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

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

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

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

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

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

可用性

延迟

性能

效率

变更管理

监控和告警

应急响应

事件响应

准备工作

容量规划

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

SRE通常被定义为从事运维工作的软件工程师。SRE团队负责维护和建立其系统的服务水平指标（SLI）、目标（SLO）、协议（SLA）和错误预算，并确保满足这些指标。

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

SRE 的战略目标是：

使部署更加容易

提高或维持正常运行时间

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

设置SLI和SLO以及错误预算

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

消除手动操作任务

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

二、SLI和SLO

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

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

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

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

三、SLA关键业务价值

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

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

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）的关键部分。他们的目标是帮助识别和修复你系统中的任何潜在问题。

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

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

延迟（Latency）

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

流量（Traffic）

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

错误（Errors）

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

饱和度（Saturation）

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

利用率（Utilization）

虽然不是公认的“四大黄金指标”的一部分，但值得一提；利用率表明资源或系统有多忙。它以百分比表示，范围从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拉模型构建的时间序列数据库中记录实时指标。

图七 监控和告警

你可以配置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的概念，下篇文章给大家聊聊我的理解。

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

学习资料： ITIL培训基地专家讲堂直播 300期视频回放

什么是SRE，如何从 0 建设 SRE 运维体系？

前短时间发了一篇文章讨论《如何构建IT监控管理体系？（一）IT监控管理流程设计》，其中给大家留了一个预告，说会写一篇《如何使用SRE的实践来落地ITIL4的“事态和监控管理实践”》。在这之前先给大家从监控的视角介绍下SRE以便于能够更好的利用SRE的实践思想落地ITIL4的“事态和监控管理实践”。

导入：SRE的来源

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

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

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

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

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

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

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

可用性

延迟

性能

效率

变更管理

监控和告警

应急响应

事件响应

准备工作

容量规划

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

SRE通常被定义为从事运维工作的软件工程师。SRE团队负责维护和建立其系统的服务水平指标（SLI）、目标（SLO）、协议（SLA）和错误预算，并确保满足这些指标。

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

SRE 的战略目标是：

使部署更加容易

提高或维持正常运行时间

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

设置SLI和SLO以及错误预算

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

消除手动操作任务

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

二、SLI和SLO

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

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

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

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

三、SLA关键业务价值

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

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

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）的关键部分。他们的目标是帮助识别和修复你系统中的任何潜在问题。

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

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

延迟（Latency）

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

流量（Traffic）

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

错误（Errors）

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

饱和度（Saturation）

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

利用率（Utilization）

虽然不是公认的“四大黄金指标”的一部分，但值得一提；利用率表明资源或系统有多忙。它以百分比表示，范围从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拉模型构建的时间序列数据库中记录实时指标。

图七 监控和告警

你可以配置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的概念，下篇文章给大家聊聊我的理解。

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