从70万字SRE神作提炼出的7千字精华文章

左手的ㄟ右手 2023-05-21 08:45 15阅读 0赞

最近在做一些运维架构转型的工作，某些思想其实是借鉴了SRE的理念，就和DevOps一样，SRE已经不是一个新鲜的词汇了，尤其是在互联网的行业，无论从组织架构，还是工作属性，都是将SRE，融入其中，成为了软件生命周期中重要的一环。

从DBAPlus看到了这篇文章，提炼的很好，对现实工作能起到些指导作用，特此转载，与君共勉，另外谢谢DBAPlus的慷慨授权。

作者介绍

**梁铭图，**新炬网络首席架构师，10年以上数据库运维、数据分析、数据库设计以及系统规划建设经验，在数据架构管理以及数据资产管理方面有深入研究。

读《SRE Google运维解密》是我首次比较系统地了解和学习Google内部SRE运作的指导思想、实践以及相关问题，最近又花了一些时间，仔细阅读了关于SRE的第二本书籍《SRE生存指南》。

![format_png][]

《SRE Google运维解密》与《SRE生存指南》

SRE首先是一套方法论，它从传统运维中与稳定性相关的工作内容提炼出来进行升华，构建了SRE的方法论体系。冗余和容灾、容量规划、系统自动保护、失败预案、监控能力、发布与变更管理、故障应急处理等构成了SRE领域的蓝图，并不断地快速迭代着。

方法论的落地实施离不开相关组织和个人，传统的运维工程师在SRE方法论的熏陶下在系统可用性方面的技能得到了极大的提高，其中一部分传统运维工程师“进化”成了技术含金量极高的SRE工程师，他们聚合在一起，构成了专职的SRE团队。

同样，方法论的落地还需要有一系列配套的技术产品和工具来支撑，与SRE相关的技术体系在近几年也得到迅速发展，特别是随着AI技术的发展、演进，两者结合产生了奇妙的“化学反应”，使系统可用性保障的效率和性能都获得了极大的提升。

书中的一些思路让我对Google SRE这个庞大的运维体系有了全新的认识，里面许多的内容令人印象深刻，例如“Mikey金字塔”、“监控是研究一个系统运维的基础”、“故障事后回顾”、“测试表明缺陷的存在，而不是不存在”等等观点，对长期从事于运维这个行当的人来说应该会有不少启发。

下文是我结合书中的理念和我们日常运维实践作出的一些解读，整理并供大家参考。

**Mikey金字塔**

Mikey金字塔是由美国数字服务公司的Mikey Dickerson设计的。层次结构是为了说明，当尝试提高系统可靠性时需要按部就班，在到达更高级别之前满足每个低别级的要求。

![format_png 1][]

Mikey金字塔

Mikey金字塔可以说是本书作者总结SRE运维体系的灵魂，自下而上分为监控、事故响应、事后回顾、测试与发布、容量规划、构建工具、用户体验等七层。每一层都建立在前一层的基础之上，每一层都被沟通这个基本要求所包围。

从这个框架内容，我个人认为SRE运维所遵守几个基本原则：

**1）以业务连续性为目标**

SRE的根本出发点和目标就是业务连续性。由于软件做不到100%完全可靠，一方面，我们基础设施做不到完美，各部分出故障是常态，这会影响到应用可用性；另一方面，我们的软件是人编写的，所以Bug不可避免，Bug出现也会引起异常停机。SRE做到的是尽可能快的发现和处理故障，并找到可能发生的故障，在预算范围内以有用的方式优化应用、基础设施，满足用户体验的需求。

**2）从技术到业务**

从监控、事故响应、事后回顾、测试与发布、容量规划、开发到用户体验这七层的递进，可以看出SRE运维不只是单纯的技术栈（主机、存储、基础软件设施等）的设备运维，SRE还逐步延伸业务运维领域，管理应用发布、业务需求以及用户对系统体验的总体期望。这种从技术栈到业务栈的递进，体现了SRE运维体系对传 统运维体系演进和拓展。

**3）高度自动化和工具化**

SRE本身是一个软件工程师以软件工程的方法解决运维问题的体系，因此就自身而言，SRE极度鄙视重复性的运维工作，更倾向于使用代码的方式去应对各种重复性的 运维操作。因此SRE运维体系是一个将自动化和工具化提高到战略高度的运维体系模型，正如书中所言：“SRE的诞生是因为软件工程师触及了运维。目标是将50%的时间用于编写代码，30%时间用于与人打交道、20%时间用于应对紧急情况。”

**4）预防与事故应对**

尽管Mikey金字塔七层模型中仍然有监控、事件响度和事件回顾等层次，与当前传统应对型运维体系有近似的地方。但是从整体上，SRE整个运维体系非常强调预防的重要性。通过事件回顾、测试与发布、容量规划、开发等层次的工作来持续优化应用，提升系统的可靠性。“预防胜于治疗”这句话，在IT系统建设和运维 领域同样适用。

**5）平衡风险**

SRE运维体系首先认定新业务需求和新软件版本的发布无论如何总会引入bug；与此同时，较长的开发周期与更严密的测试会发现并修正bug，但是亦会延迟业务需求实现以及新版本发布的时间。快速实现业务需求与由于bug引起宕机的风险之间需要得到平衡。SRE通过制定合理的SLO以及错误预算，尝试在系统风险与业务快速迭代之间实现可量化的平衡。

**监控**

第一层是监控，它确保你洞察系统，跟踪系统的健康状态、可用性以及系统内部发生的事情。监控两个关键点：首先，需要确定质量标准是什么，并确保系统持续逼近或保持在质量标准极限范围内。其次，需要系统地关注这项工作—而不应该只是随机地查看一下系统。监控不仅仅是工具，因为它也需要沟通。

毫无疑问，系统监控是整个运维体系的基础，它是最基本的运维工作。在自动化监控工具没有完全普及的年代，人们已经用纸笔记录着计算机上读数和指标。随着IT规模的不断扩展，人们开始建设自动化的监控系统。如今，一个企业级的监控系统我认为至少应该包括如下几个特征：

1）完备指标采集，可以对接企业内大部分的设备与技术栈相应的监控指标；同时，支持常见设备的监控指标体系，可以快速接入监控设备和指标，避免所有设备监控都是从头构建。

2）日志采集能力，除了传统的指标数据采集外，针对于目前显得越来越重要的日志数据，监控工具也需要支持常见日志采集、切割、结构化以及入库分析能力。

3）海量设备支持，企业IT系统数量和规模越来越大，因此监控系统比以前需要监控海量设备监控。

4）监控数据存储和分析，监控数据是运维分析、运维自动化和智能化的基础，因此海量监控数据存储以及基于监控数据的可视化分析是一个监控系统的基本能力。

![format_png 2][]

新炬网络统一运维监控

监控是整个运维体系的基础，它需要提供整个运维体系的数据化支持。因此，一个企业级的监控系统更应该是平台化的。一方面可以通过配置或者开发实现更多运维指标的接入；另一方面，亦可对接更多的专业运维工具，整合并打通多元的运维数据，为更多运维场景提供数据服务。从整体上，监控为企业运维提供了一个数据基础，让我们对事故响应以及容量预测等方面更多使用数据而非凭借以往经验和拍脑袋做出决策。

**事故响应**

第二层是事故响应。如果有什么东西出了故障，该如何提醒大家并做出回应？工具可以帮助解决这个问题，国为它可以定义提醒人类的规则。事故响应是建立在使用监控构建的数据之上，并借助反馈循环，来帮助我们加强对服务的监控。

事故响应通常包括以下几个动作：

*  关注，注意到有些东西不对劲
 *  交流，告诉别人哪些东西不对劲
 *  恢复，纠正不对劲的东西

事故响应往往始于简单的一句告警信息或一个报障电话。因此，在监控系统的基础上如何实现更有效率的告警和告警处理是故障响应和处理的重中之重。工具可以帮助解决这个问题，因为它可以定义提醒人类的规则。而大多数的事故响应都是关于定义处理策略和提供培训的，以便人们在收到警报时知道该怎么做。

在长期的运维工作中，我认为有效的告警意味着：告警及时性，系统有问题需要及时通过告警信息告知运维处理人员及时处理告警；告警准确性，只要有告警信息系统必然出现问题。这意味着，错误报警等同于有问题但没有报出来。因为过多过频繁甚至误报的告警，让运维人员的注意力迷失告警海洋当中。抑制和消除无效的告警，让运维人员不被告警风暴所吞没，也是告警管理中重点建设的内容。

从日常运维实践中，我们往往可以通过整合到监控平台中的各种监控数据，应用趋势预测、短周期检测、间歇性恢复、基线判断、重复压缩等算法和手段实现告警压缩收敛，强化告警的有效性。

![format_png 3][]

告警压缩与收敛

同时，面向一线使用人员的场景，我们又往往根据综合同一个系统或设备的多个监控指标进行综合性建模和分析，汇总成一个健康度的分值，给予一线运维人员系统的基于健康度的系统分层评价体系，真实、直观反映系统运行状态，实现问题快速定界。

![format_png 4][]

系统健康度指标

最后，对于常见告警信息，我们也往往会对接一些配置化的自动化处理动作，例如，一些特殊的应急处理手段（某个文件系统快满了，清理掉当中没有价值的文件）或者一些关键故障信息采集（出现死锁的数据库里面，自动采集引起死锁的进程信息）作供运维人员进一步分析和确认使用。

**事后回顾**

第三层是事后回顾。一旦发生服务中断，那么如何确保问题不会再次发生？为了让大家团结协作，我们希望建立一种无指责、透明的事后文化。个人不应该害怕事故，而是确信如果事故发生，团队将会响应和改进系统。

我认为SRE的一个关键共识正是承认了系统的不完美性，追求永不停机的系统是不现实的。基于不完美系统，我们无可避免要面对和经历系统故障与失败。所以我们重要的并非找到为这个故障责任的这个人或者那个人，而是更应该创根问底地复盘这个故障和失败的根本原因是什么，以及如何避免再次出现相同的故障。系统可靠性是整个团队共同奋斗的方向，从失败中快速恢复并吸取教训，每个人放心地提出问题，应对停机，并努力改进系统。

事故是我们可以从中学习的东西，而不是让人害怕和羞耻的事情！

在日常运维过程中，出现故障等事故对于我们而言其实是一个很好的复盘学习机会。通过历史监控数据，分析事故其中的根本原因，制定后续应对策略，并且通过运维平台将这些应对策略编辑成标准化、可重用、自动化的运维应用场景，为后续相同问题的处理提供标准且快捷的解决方案。这正是事后回顾这个过程最真实的价值体现。

此外，事故响应建立在使用监控构建的数据之上，并借助反馈循环，来帮助我们加强对服务的监控。这向我们展示了什么是重要的。因为如果没有得到警报，而是有人告诉我们服务没有正常工作，那么我们的监控就是不到位的。

**测试与发布**

第四层是测试和发布软件。这个层级是Mikey金字塔中第一个专注于预防而不是事后处理的层级。预防是指尝试限制发生的事故数量，并确保在发布新代码时基础架构和服务能够保持稳定。

在《SRE Google运维解密》，我首次接触了基于服务水平目标（SLO）而制定的错误预算（Error Budget）。《SRE生存指南》本书则是通过测试与发布这个章节提供了一个更为具像化的案例。

作为一个长期从事运维工作的人，可能内心中最为恐惧的莫过于新应用版本发布。因为除了硬件和网络设备损坏这个属于天灾级别的概率事件外，新应用版本发布的第二天通常是停机与事故的高危期。以电信运营商行业为例，在一些系统稳定性要求特别高的日子如春节、国庆、奥运会等重大节日或者特别时期，往往有所谓封网的行为，其实质就是通过拒绝非紧急Bug和业务功能上线来提升一段特殊时期内的系统可靠性。正如书中所说，测试是在成本和风险之间找到适当的平衡活动。如果过于冒险，你们可能就会疲于应付系统失败；反过来说，如果你太保守，你就不能足够快地发布新东西，让企业在市场上生存下来。

在错误预算比较多（即在一段时间内故障导致系统停机时长较少）的情况下，可以适当减少测试资源并放宽系统上线的测试和条件，让业务可以有更多的功能上线，以保持业务的敏态；在错误预算比较少（即在一段时间内故障导致系统停机时长较多）的情况下，则要增加测试资源并收紧系统上线的测试，让系统的潜在风险得到更多有效的释放，避免系统停机保持系统的稳态。这种敏态与稳态之间的平衡，需要整个运维与开发团队来共同承担。

除了测试外，应用发布也是一项运维团队通常要承担的责任。SRE的一个原则是将一切可以重复性劳动代码化和工具化；此外，应用发布的复杂程度往往与系统的复杂程度成正比。因此在应用系统上规模企业，往往已经着手基于自动化框架构建自动化的应用发布过程。

![format_png 5][]

新炬网络基于自动化框架的应用发布

通过自动化发布工具，我们可以构建流水线实现部署的过程中所有的操作（如编译打包、测试发布、生产准备、告警屏蔽、服务停止、数据库执行、应用部署、服务重启等）全部自动化，无需人工手工干预解决以往手工发布存在问题：

*  整个过程都需要人员参与，占用大量的时间，效率低下
 *  上线、更新、回滚速度慢
 *  规范化低，存在一定的管理混乱，人为误操作的机率增大

**容量规划**

第五层是容量规划。关于预测未来和发现系统极限的。容量规划也是为了确保系统可以随着时间的推移得到完善和增强。规划的主要目标是管理风险和期望。对于容量规划，涉及到将容量扩展到整个业务。所关注的期望是人们在看到业务增长时期望服务如何响应。风险是在额外的基础设施上花费时间和金钱来处理这个问题。

容量规划首先是对未来预测性的分析与判断，其预测的基础正是海量的运维数据。因此，容量规划除了有相应的架构和规划团队外，一个全面的运维数据中心是实现系统容量规划的必须设施。

![format_png 6][]

容量趋势分析和预警

他将综合地从各种运维监控、流程管理等数据源中收集、整理、清洗并结构化地存储各种运维数据，将这些来自于各种工具的运维数据打通融合并且构建各种数据主题。应用这些数据主题的数据用于帮助运维人员对问题进行评估，包括：

*  当前的容量是多少
 *  何时达到容量极限
 *  应该如何更改容量
 *  执行容量规划

运维平台除了可以提供必要的数据支持外，还需要提供必要的数据可视化支持能力。运维数据可视化提供了一些必要的能力保障运维人员可以更好地利用其中的运维数据评估容量。

![format_png 7][]

运维数据可视化分析

首先，运维平台需要有极强的数据检索能力。运维平台存储着海量的运维数据，运维人员为了尝试建立和验证一个探索性场景的时候，往往多次反复检索和查询特定数据。如果运维数据分析平台的数据查询很慢或者查询角度很少的情况下，运维人员建立场景的时间就会拖得很长甚至进行不下去。因此，运维人员可通过平台可以实现关键字、统计函数、单条件、多条件、模糊多维度查找功能，以及实现海量数据秒级查询，才能更有效帮助运维人员更便捷分析数据。

其二，平台需要强大的数据可视化能力。人们常说“千言万语不及一图”，运维人员经常会通过各系统的运维数据进行统计分析并生成各类实时报表，对各类运维数据 （如应用日志、交易日志、系统日志）进行多维度、多角度深入分析、预测及可视化展现，将他们分析的预测结果和经验向他人表达和推广。

**构建工具**

第六层是开发新工具和服务。SRE不仅涉及运营，还涉及软件开发。SRE工程师将花费大约一半的时间来开发新的工具和服务。这些工具中的一部分将用于自动化一些手工任务，而其他工具将用于改进Mikey金字塔的其余部分。通过编写代码把自己和其他人从重复的工作中解放出来。如果我们不需要人类来完成任务， 那么就编写代码，这样人类就不需要参与其中了。

SRE从内心上鄙视重复性的工作，将从原有的人工加被动响应，转变为更高效、更为自动化的运维体系。事实上，在我们负责运维的客户中，IT系统规模的增速已经远远超越由于运维团队规模的增长。例如,一些电信运营商企业连每天早上大规模营业前对所有IT系统的设备进行一次常规状态检查都难以维持。为解决这个矛盾，专门部署并开发了我们的自动化监控和运维工具，将这些每天重复性的大量机械性操作交由机器实现。只需要定义好相关的巡检模板，机器就会十年如一日地按照我们定义的规范进行各种巡检操作。如巡检结果中出现任何异常，运维人员的手机就会出现该问题的告警短信，通知相关运维人员处理。

![format_png 8][]

新炬网络自动化运维框架

构建自动化运维工具，其优势在于：

1）让机器管理机器，将大量重复、机械的运维工作交给机器执行，有效地降低运维人力资源的投入，也让运维人员的精力得以释放并投向更为重要的领域。

2）运维操作的标准化，将原来许多复杂、易错的手工操作实现统一运维操作入口，实现运维操作白屏化，提升运维操作的可管理性；同时，减少由于运维人员情绪带来手工误操作，避免“从删库到跑路”这样的悲剧的发生。

3） 运维经验能力的传承，运维自动化工具将原来许多运维团队积累的经验以代码方式总结为各种运维工具，实现自动化和白屏化的运维操作。运维团队的后来者，可以有效地继承、重复使用并优化它们。这种代码化的工作传承，将个人能力转变为团队能力，并减少人员流动带来对工作的影响。

构建自动化运维体系就必须以运维场景为基础，这些运维场景是在本企业内反复迭代和打造，是企业中最常用的运维场景。例如上文提到的自动化巡检、软件安装部署、应用发布交付、资产管理、告警自动处理、故障分析、资源开通等。所以，自动化运维应支持多种不同类型的自动化作业配置能力，通过简单的脚本开发、场景配置和可视化定制流程实现更多运维场景的实现。

**用户体验**

最后一层是用户体验，即确保用户获得良好的体验。与用户研究人员合作，以及确保良好的用户体验。这与SRE有两种关系。首先，我们需要支持我们所支持的系统的用户体验。例如，确保应用程序具有响应性和可用性，可以让用户获得一致的体验。其次，我们的工具需要提供良好的体验。良好的体验意味着我们构建和支持的服务的用户愿意使用它们。

用户体验的管理是SRE的最高层次实现，它实际上正是运维的最终目标。此前的层次，无论是监控、事故响应、回顾、测试与发布、容量规划以及构建自动化工具，无非都是为了提供更好的系统用户业务体验而服务的。因此，我们在运维的过程中无不需要注意关注系统的用户体验。例如，在实际运维工作中，我们往往可以通过应用日志、监控数据、业务拔测等业务相关的用户体验信息。在运维数据平台中，通过这些用户体验监测数据之间的关联和串联，重现用户的最终业务调用链路以及各应用环节对性能数据的关系。最终形成从业务用户体验数据入手，逐步实现系统运行状态数据、设备运行状态数据链路的打通，让运维体系实现以最终用户体验为 中心的目标。

这些用户体验的信息，对于运维团队掌握客户整体的用户体验情况、系统可用性的监测以及系统针对性的优化提供着无可替代的作用。

**写在最后**

SRE是Google这类典型国外互联网企业的运维体系建设理念。我认为与传统以设备为中心的运维体系不同，SRE运维体系更为强调以用户的体验为核心，以自动化和运维数据为手段，实现应用业务连续性保障。与其说是系统运维，不如说是系统运营体系或会更为适当。

当然，不同的企业会有其自身不同的文化、制度和背景，SRE这套运维体系不能生搬硬套。但是里面提到的很多理念和方法，还是很值得我们借鉴的。如果大家有机会详细阅读本书，亦希望能分享一下你们的见解。

**近期热文：**

《[从数据误删到全量恢复的惊险记录][Link 1]》

《[DevOps的重要时刻][DevOps]》

《[last\_load\_time和last\_active\_time的选择][last_load_time_last_active_time]》

《[truncate分区表的操作，会导致全局索引失效？][truncate]》

《[NUMBER长度的误解][NUMBER]》

《[decode函数再挖掘][decode]》

《[《decode函数的妙用》网友的两个问题解答][decode 1]》

《[decode函数的妙用][decode 2]》

《[虚拟内存详解][Link 2]》

《[7号球衣的故事：重要的不是号码，而是穿着它的人][7]》

《[插入"&"特殊字符的几种思考][Link 3]》

《[connect by超乎你想象][connect by]》

《[公众号600篇文章分类和索引][600]》

[format_png]: /images/20230521/6b6757603b54490d93d9bf131e0dda3c.png
[format_png 1]: /images/20230521/993ee9362b944baf94fdda022f89ad73.png
[format_png 2]: /images/20230521/08e57bf840944cc893941eff9be01a1d.png
[format_png 3]: /images/20230521/22c724d0ce1b4af1ae381a85a1aa19d0.png
[format_png 4]: /images/20230521/446132a7b5bf44f69cb494b7fb798ecc.png
[format_png 5]: /images/20230521/4c80e09b27ea449dad30b3cc61c5c19a.png
[format_png 6]: /images/20230521/344089155ce54013ab570f21fa5c1be0.png
[format_png 7]: /images/20230521/d366aa56fe0c4162880da3bb883d1c60.png
[format_png 8]: /images/20230521/e483376c2f7743fbb778459c854cb159.png
[Link 1]: https://blog.csdn.net/bisal/article/details/105697127
[DevOps]: https://blog.csdn.net/bisal/article/details/105591694
[last_load_time_last_active_time]: https://blog.csdn.net/bisal/article/details/105630136
[truncate]: https://blog.csdn.net/bisal/article/details/105570845
[NUMBER]: https://blog.csdn.net/bisal/article/details/105548618
[decode]: https://blog.csdn.net/bisal/article/details/105671807
[decode 1]: https://blog.csdn.net/bisal/article/details/105445417
[decode 2]: https://blog.csdn.net/bisal/article/details/105424100
[Link 2]: https://blog.csdn.net/bisal/article/details/105383561
[7]: https://blog.csdn.net/bisal/article/details/105283168
[Link 3]: http://mp.weixin.qq.com/s?__biz=MzI2NzM1OTM4OA%3D%3D&chksm=ea815f05ddf6d613a8fd4f4454278476e27e37675d810d3aa4e74a8e0c8d06b6e168ea9c8ecb&idx=1&mid=2247490294&scene=21&sn=46ac00aeef5cae9c81dcd234c9766853#wechat_redirect
[connect by]: https://blog.csdn.net/bisal/article/details/105236326
[600]: https://blog.csdn.net/bisal/article/details/104548761