写在前面
前短时间发了一篇文章讨论《如何构建IT监控管理体系？（一）IT监控管理流程设计》，其中给大家留了一个预告，说会写一篇《如何使用SRE的实践来落地ITIL4的“事态和监控管理实践”》。在这之前先给大家从监控的视角介绍下SRE以便于能够更好的利用SRE的实践思想落地ITIL4的“事态和监控管理实践”。
导入：SRE的来源
十多年前，Google创造了一种名为SRE（Site Reliability Engineering）的工作职位。SRE是Site Reliability Engineering的缩写，其中的"site"指的是网站，可翻译为网站可靠性工程。几年前，资深Google SRE Chris Jones等人联合撰写了一本名为《Google SRE: How Google runs production systems》的书籍，首次向外界揭示了Google的生产环境和整个SRE的方法论。接下来，我们将主要介绍站点可靠性工程（SRE），以及在系统扩展时如何监控和保持系统的高速可靠性。下面的图表清楚地概括了SRE架构的整体思想和关键方法论。
在云时代，客户体验是所有重要企业的新口号，即使命宣言。客户体验、可用性和可访问性是在用户端决定的，在这里站点应当始终可用 [24*7*365]。对用户来说，可靠性才是最重要的；一个未使用的应用程序对用户和企业毫无价值。
如今，每家公司都在努力推动科技变革。公司业务战略都围绕云功能构建。这对他们来说是一项重大的运维挑战。站点性能下降、客户体验的下降都将导致现金、收入和竞争力的损失，并导致传统运维无法应对可观测性的大问题（包括实时监控和告警）。
为什么存在站点可靠性工程（SRE）？敏捷运动提升了跨职能团队之间协作的重要性，这催生了DevOps。
DevOps是一种专注于深入了解组织固有问题和挑战的方法论。它与协调速度、效率和质量息息相关。从本质上说，DevOps是一种文化，一种运动，一种价值观，一种基于原则、方法和实践的方式，目的是实现组织期望的结果。
这种速度也造成了一定的不稳定性，开发人员的行动速度比以往任何时候都快了，但却给运维团队带来了挑战。IT运维团队没有能力应对这样的速度，这让他们遇到了瓶颈和严重的积压，导致生产中产生了不稳定的因素，结果使系统变得不可靠。因此，Google提出了对SRE的要求：“一群能够将软件工程专业知识 应用于 运维问题 的开发人员。”
SRE是一种规范的DevOps方式，是DevOps在google的落地实践。DevOps是SRE的普适版本。SRE是系统管理任务的一种思维方式，侧重于通过缩短交付周期和事件管理生命周期，并通过减少工作量来支持开发人员和运维人员来运维服务的原则。SRE团队的日常任务包括：
可用性
延迟
性能
效率
变更管理
监控和告警
应急响应
事件响应
准备工作
容量规划
一、那么，什么是站点可靠性工程（SRE）？
SRE（Site Reliability Engineering）一般被定义为从事运维工作的软件工程师。SRE团队负责维护和建立系统的服务水平指标（Service Level Indicators，SLI）、目标（Service Level Objectives，SLO）、协议（Service Level Agreements，SLA）和错误预算，并确保系统能够符合这些指标。
作为IT工程师，他们计划投入一段时间来进行运维工作，确保系统按时运行并改进他们负责管理的系统。SRE专注于编写软件来自动化流程，减少手动处理的繁琐工作，即目前还未实现系统自动化的任务。
SRE 的战略目标是：
使部署更加容易
提高或维持正常运行时间
针对应用性能去建设可视化能力
设置SLI和SLO以及错误预算
通过承担被计算过风险来提高速度
消除手动操作任务
降低故障成本以缩短新功能的周期时间
二、SLI和SLO
服务水平目标（SLO）是SRE团队与产品所有者或业务线（LOB）之间的协议，旨在确保服务水平指标（SLI）的达成。SLI是系统的定义和度量指标，用于量化我们正在关注的内容，根据团队管理的系统的性质来确定具体指标。
这些指标取决于所管理的系统。对于典型的Web应用程序，这些指标可能是可用性、请求延迟或错误率。但是，例如类似区块链应用程序可能会使用每秒分类帐提交率来衡量网络的吞吐量。
SRE团队最终将管理多个系统。跨各种应用程序定义一组标准的服务水平指标将帮助团队标准化整个堆栈的监控、日志记录和自动化。
SLO指的是系统应该达到的目标值或范围，以确保系统性能达到预期操作值。例如，对于区块链网络而言，其事务吞吐量需要保持在每秒50到100个事务提交速率，并且端到端延迟应保持在5秒以下。然而，需要注意过度设计SLI和SLO的风险。在最初阶段，保持简洁而简单的目标非常重要。随着对系统的了解和经验的积累，可以逐渐设定更严格的目标。
三、SLA关键业务价值
当客户对所提供的服务不满意，未能按照相关协议交付时，服务水平协议（SLA）就会发挥作用；它可能是一个系统的可靠性。SLA是产品与其最终用户之间的协议，是与客户就服务可靠性签订的合同，简单表述为“SLA = SLO + 后果（consequences）”。SRE团队可能不参与定义SLA的过程，但是他们需要确保满足SLO。
SLA通常包含一段时间内服务正常运行时间的计算。
根据所提供的表格数据，我们可以推断99.9%的运行时间中只允许有1.44秒的停机时间。具体而言，每周的停机时间约为10.1分钟，每月的停机时间约为43.8分钟，每年的停机时间则约为8.78小时。
根据服务级别协议（SLA），电信线路的正常运行时间可以达到99.9%，因此，服务停机时间只能减少至最多0.1%。超过这个允许的停机时间将被认定为SLA违约，相应的处罚将会实施。
四、减轻工作负担并控制SRE团队的工作量
SRE团队中总会存在一些手动、乏味的事情需要执行。在你的日常工作中，无论你是软件开发人员还是架构师，你都需要完成自己不喜欢的这类任务。这些通常是手动的、无聊的和重复的任务也可能会导致错误。SRE团队也必须执行类似的任务。这是SRE可以使用他们的开发技能并尽可能消除手动流程的一个实例。让SRE花费多达50%的时间来改进他们管理的系统是一种很好的做法。
五、错误预算
错误预算是SRE团队用来平衡服务可靠性的工具，计算如下：
If I am an IT engineer, I would express this text in a more professional manner: The availability of a system can be calculated by dividing the number of successful events by the total number of events, and then multiplying the result by 100. Meanwhile, the error budget of a system can be determined by subtracting the availability from 100, where the number of failed requests is divided by the sum of successful and failed requests.
误差预算是100减去服务的SLO。99.99%的SLO服务有0.01%的误差预算。
错误预算是服务级别目标 (SLO) 的另一个示例，其中每个服务都受其具有惩罚条款的服务级别协议的限制。它衡量您满足另一个SLO 的可用空间。
作为IT工程师，你可能会遇到这样的情况：如果你有一个服务级别指标，它要求99.99%的交易必须在5秒内提交记账，那么只有0.01%的交易可以超过这个时间限制。在主要版本发布后，你可能会注意到系统开始运行缓慢，并且突然消耗了你所设置的错误预算的全部。
请记住，变更是中断的最重要原因，发布是变更的主要来源。如果你一直超出你的误差预算，你将需要重新审视你的一些SLO和过程：
- 你是否在单个版本中引入了太多更改？
请保持简单，并将你的版本分成更小的需求变更。
- SLO是否过于严格？
你可能需要协商并放宽SLO。 - 你的发布过程中是否有任何导致问题的手动步骤？
尝试引入自动化和测试。 - 系统的架构是否容错？
硬件故障、网络包丢失、上游或下游应用程序可能会出现异常行为。
你的系统架构应该能够容忍这些故障。 - 开发团队是否解决了技术债问题？
在急于发布新功能时，技术债常常被忽视。 - 你的监控和告警是否抓住了主要指标？
不断增长的队列规模、网络速度变慢、潜在客户变更过多等都可能导致下游事件。 - 你是否定期监控日志并保持其清洁？
你的日志中可能存在不会立即导致问题的警告。
但是，再加上其他基础设施问题，这些告警可能会导致重大事故。
六、监控分布式系统的四个黄金指标
SRE的四个黄金指标是构建成功的监控和告警系统的一些基本原则和最佳实践。它们是大型生产应用程序的服务级别目标（SLO）的关键部分。他们的目标是帮助识别和修复你系统中的任何潜在问题。
他们以主动解决基础架构问题的方式来帮助运维团队快速了解和跟踪服务的延迟、流量、错误和饱和度，以便保证服务的顺畅运行。
让我们简要描述每个指标，然后看看如何利用四个关键指标来监控你的系统：
延迟（Latency）
延迟是指在信息传输中，发送方和接收方之间存在的时间延迟，单位为毫秒（ms）。这种延迟通常是由数据包丢失、网络拥塞和网络抖动等原因导致的，被称为“数据包延迟差异”。延迟直接影响客户体验，包括成功和失败请求的延迟。作为IT工程师，我们需要关注并解决延迟问题，以确保客户获得良好的体验。
流量（Traffic）
流量是系统工作负载带来的压力，可通过每秒查询数（QPS）或每秒事务数（TPS）进行衡量。企业以数量来衡量这一点，即关键绩效指标（KPI）是在给定时间内访问站点的人数。这一指标直接与商业价值相关。
错误（Errors）
错误是用于衡量整个系统中发生错误的指标。它是服务错误率的一个关键指标。错误可以分为两类：显式错误，例如HTTP请求失败（如500错误代码）；还有隐含错误，即响应成功了，但内容错误或响应时间过长。
饱和度（Saturation）
饱和度是指服务过载程度的度量标准，它主要关注系统资源的利用率和整体容量。通常用于衡量CPU利用率、内存使用、磁盘容量和每秒操作数等资源。仪表盘和监控警报是IT工程师们在容量饱和之前主动调整容量的理想工具，它们能帮助工程师密切关注这些资源。
利用率（Utilization）
虽然不是公认的“四大黄金指标”的一部分，但值得一提；利用率表明资源或系统有多忙。它以百分比表示，范围从0到100%。
我们一致认为这些指标至关重要且必须得到监控。那么我们应该如何着手？为了简化问题，我们可以首先创建一个基本的矩阵，考虑一些最基本和传统的资源，如CPU、磁盘、网络和RAM。
黄金指标的优势在于它能够发出告警、排除故障以及调整和规划容量：
告警可以通知你出现问题。
故障排除可以帮助找到并解决问题，分析根本原因。
调整和规划容量可以帮助随着时间的推移使用正确的指标、日志和从监控系统收集的跟踪来改善问题。
七、风险分析
风险分析定义如下：可能导致违反SLO的项目列表。
TDD：检测时间（time-to-detect）
TTR：修复时间（time-to-resolve）
Freq/Yr：每年的错误频率（frequency of error per year）
Users：受影响的用户
Bad/Yr：每年有异常的分钟数，相当于错误预算
作为一名IT工程师，我们通过使用错误预算来管理可接受的风险级别和风险，并根据需要做出明智的决策。我们会注意控制风险在何时需要结合服务级别指标（SLI）和服务级别目标（SLO）进行更改。同时，如果需要，我们的SRE团队还可以控制发布周期。
风险计算公式为 Risk = TTD * TTR * (Freq / Yr) * (% of users)，其中 TTD 表示故障检修时间（Time To Detect），TTR 表示故障修复时间（Time To Repair），Freq 表示故障发生频率，Yr 表示一年的时间。如果故障检修时间 TTD 为零，则风险计算公式简化为 Risk = TTR * (Freq / Yr) * (% of users)。
八、监控和告警
监控是观察系统运行方式的一种好方法，告警是系统崩溃或即将崩溃时可以触发的事件。因此，SRE团队必须构建可靠且有意义的监控系统。我们可以使用一些工具来构建良好的监控系统。Prometheus是一个开源应用程序，用于事件监控和告警。它在使用HTTP拉模型构建的时间序列数据库中记录实时指标。
你可以配置Grafana来构建可视化和仪表板来查询Prometheus。
九、促进事后分析
当你在组织中构建SRE角色时，一个重要但经常被遗忘的方面是事后分析，“事后分析是无可指责的”。它可以被定义为一个组织从它所犯的错误中吸取教训的机会。故障解决后应尽快进行事后分析以及复盘。在复杂的企业IT环境中，组件和应用程序最终会失败，可能是由于部署错误，最近版本中引入的软件bug或仅仅是硬件故障。
将事件的根本原因和短期和长期修复方案一同归档，并在开发和SRE团队中广泛传播，这在企业的知识传承中具有重要意义。故障的发现可以用于预防其他系统的类似问题，也可以作为未来类似事件的参考。如果事后分析得当，这些分析结果应被记录，以便建立内部知识库，方便日后查询。
十、如何获取一个可靠的服务？
作为一位IT工程师，您的职责是维护和管理应用程序（业务系统），通过执行必要的操作来确保业务系统的正常运行。以下是您在业务系统研发、日常运维和发布上线不同阶段可能采取的一些策略和工具，以支持您的工作：
阶段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的概念。我们还介绍了利用错误预算和风险分析等基本工具来引导决策，平衡对可靠性的投入与应用程序功能或其他业务优先级的投入。最后，我们详细阐述了监控分布式系统的四个重要指标。
相关阅读
更多课程及服务
最近开课计划：
- ITIL4 全系列在线课程 | 随到随学
- ITIL4 Foundation 直播特训认证课程 | 5月20、21日 线上
- ITIL4 高级直通车--一次拿下高级MP+SL证书 | 5月13日、14日（DPI）
如果您想借助于外部专家的经验和力量，对IT部门的业务进行重新梳理和设计，推荐您点击下列链接使用：
