SRE首先是一套方法论，是从传统运维中与稳定性相关的工作内容提炼升华，构建SRE系统的方法论。冗余与容灾、容量规划、系统自动保护、故障预案、监控能力、发布与变更管理、故障应急处理等构成了SRE领域的蓝图，并不断快速迭代。方法论的实施离不开相关组织和个人。传统运维工程师在SRE方法论的影响下，在系统可用性方面的技能有了很大的提升。一些传统的运维工程师已经“进化”为技术含量高的High-levelSRE工程师，他们聚集在一起组成了一个全职的SRE团队。同样，方法论的实施也需要一系列配套的技术产品和工具来支撑。与SRE相关的技术体系近年来也发展迅速。尤其是随着AI技术的发展演进，两者的结合产生了奇妙的系统“化学反应”，大大提高了系统可用性保障的效率和性能。书中的一些思想让我对GoogleSRE这个庞大的运维体系有了新的认识。很多内容都让人印象深刻，比如“米奇金字塔”、“监控是研究一个系统运维的基础”、“故障后的回顾”、“测试表明缺陷存在，而不是不存在”等，对于长期从事运维业务的人来说，应该会有很大的启发。下面是我结合书中的思路和我们日常运维实践整理的一些解读，供大家参考。Mikey的金字塔Mikey的金字塔由USDigitalServices的MikeyDickerson设计。该层次结构旨在说明，在尝试提高系统可靠性时，需要遵循循序渐进的方法，在达到更高级别之前满足每个较低级别的要求。MikeyPyramidMikeyPyramid可以说是作者总结的SRE运维体系的灵魂。从下到上分为七层：监控、事件响应、事后回顾、测试发布、容量规划、构建工具、用户体验。每一层都建立在前一层之上，每一层都围绕着通信的基本要求。从这个框架的内容来看，我个人认为SRE运维遵循几个基本原则：1）业务连续性是目标SRE的根本出发点和目标是业务连续性。因为软件不可能100%完全可靠，一方面是我们的基础设施不完善，各个部分出现故障很正常，会影响应用的可用性；另一方面，我们的软件是人写的，bug是无法避免的，bug也会导致异常宕机。SRE所做的是尽快发现和处理故障，发现可能的故障，在预算内以有用的方式优化应用程序和基础设施，满足用户体验要求。2）从技术到业务，从监控、事件响应、事后回顾、测试发布、容量规划、开发到用户体验，可见SRE运维不仅仅是简单的技术栈（主机、存储、基础软件设施等），SRE也逐渐延伸到业务运维领域，管理应用发布、业务需求、用户对系统体验的整体期望。这种从技术栈到业务栈的进阶，体现了SRE运维体系向传统运维体系的演进和扩展。3）高度自动化和工具化的SRE本身就是软件工程师使用软件工程方法解决运维问题的系统。因此，SRE本身就很看不起重复的运维工作，更喜欢用代码来处理各种重复的运维操作。因此，SRE运维体系是将自动化、仪表化提升到战略层面的运维体系模型。正如书中所说：“SRE的诞生是因为软件工程师接触到了运维。目标是把50%的时间花在写代码上，花30%的时间和人打交道，花20%的时间应对突发事件”4）预防和事故响应虽然在米奇金字塔的七层模型中仍然存在监控、事件响度、事件审查等层次，但与目前传统的反应式运维体系有相似之处。但从整体上看，SRE整个运维体系都非常强调预防的重要性。通过事件审核、测试发布、容量规划、开发等层面的工作，不断优化应用，提高系统可靠性。“预防胜于治疗”这句话同样适用于IT系统建设和运维领域。5）平衡风险SRE运维体系首先决定了新业务需求和新软件版本的发布总会引入bug；同时，更长的开发周期和更严格的测试会发现并纠正错误，但也会延迟业务需求的实现和新版本发布的时间。需要在快速实施业务需求和因错误导致停机的风险之间取得平衡。SRE试图通过制定合理的SLO和错误预算，在系统风险和业务快速迭代之间实现可量化的平衡。监控第一层是监控，确保您深入了解系统，跟踪系统的健康状况、可用性以及系统内部发生的情况。有两个关键点需要监控：首先，您需要确定质量标准是什么，并确保系统持续接近或保持在质量标准范围内。其次，需要对这项工作有系统的关注——它不应该只是对系统的随机观察。监控不仅仅是一种工具，因为它还需要沟通。毫无疑问，系统监控是整个运维系统的基础，是最基础的运维工作。在自动化监测工具还没有完全普及的年代，人们已经用纸笔在电脑上记录读数和指标。随着IT规模的不断扩大，人们开始构建自动化监控系统。现在，我认为一个企业级的监控系统至少应该具备以下几个特点：1）完善的指标采集，可以对接企业内大部分设备和技术栈的相应监控指标；同时支持常用设备的监控指标体系，您可以快速访问监控设备和指标，避免所有设备监控从零开始。2）日志收集能力。除了传统的索引数据采集，监控工具还需要支持对当前越来越重要的日志数据进行通用的日志采集、切割、结构化、入库分析能力。3）海量设备支撑，企业IT系统的数量和规模越来越大，监控系统需要监控比以往海量的设备监控。4)监测数据存储与分析。监控数据是运维分析、运维自动化、智能化的基础。因此，海量监控数据的存储和基于监控数据的可视化分析是监控系统的基本能力。新居网络统一运维监控是整个运维系统的基础，需要为整个运维系统提供数据支撑。因此，企业级监控系统应该更加平台化。一方面，可以通过配置或者开发的方式，获取更多的运维指标；另一方面，也可以对接更专业的运维工具，整合开放多种运维数据，为更多运维场景提供数据服务。整体而言，监控为企业运维提供了数据基础，让我们可以将更多的数据用于事故应对和容量预测，而不是依赖过去的经验和头脑风暴来做决策。事件响应第二层是事件响应。如果出现问题，您如何提醒所有人并做出回应？工具可以通过定义提醒人类的规则来帮助解决这个问题。事件响应建立在使用监控构建的数据之上，并使用反馈循环来帮助我们加强对服务的监控。事件响应通常包括以下操作：注意，注意到有问题沟通，告诉别人哪里出了问题恢复，纠正错误事件响应通常从简单的警告消息或故障呼叫开始。因此，如何在监控系统的基础上实现更高效的告警和告警处理是故障响应和处理的重中之重。工具可以帮助解决这个问题，因为它可以定义提醒人类的规则。大多数事件响应都是关于定义处理策略和提供培训，以便人们知道在收到警报时该怎么做。在长期的运维工作中，我认为告警有效的意思是：告警及时性，如果系统出现问题，需要通过告警信息及时通知运维人员，及时处理告警。时间;报警的准确性，只要有报警信息系统，就难免会出现问题。这意味着误报与有问题但不报告是一样的。因为太多、频繁甚至误报，导致运维人员的注意力迷失在警报的海洋中。抑制和消除无效告警，让运维人员不被告警风暴吞噬，也是告警管理的重点建设内容。从日常运维实践来看，通过将各种监控数据集成到监控平台，应用趋势预测、短线检测、间歇恢复、基线判断、重复压缩等算法和方法，往往可以实现告警压缩收敛，强化告警。.效力。在告警压缩汇聚的同时，我们往往会针对一线用户场景，基于同一系统或设备的多个监控指标进行综合建模分析，汇总成一个健康分值，供一线运维使用。维修人员。系统基于健康度的分级系统评价体系，能够真实、直观地反映系统的运行状态，快速定界问题。系统健康指标最后，对于常见的告警信息，我们往往会连接一些可配置的自动处理动作，比如一些特殊的应急处理方式（某个文件系统快满了，清理无用文件）或者一些关键故障信息采集（在数据库中在发生死锁的地方，自动收集导致死锁的进程信息）供运维人员进一步分析确认。事后回顾的第三层是事后回顾。一旦发生服务中断，如何确保问题不再发生？为了让大家共同努力，我们希望建立一种无责备和透明的事后文化。个人不应该害怕发生事故，但要有信心，如果发生事故，团队会做出反应并改进系统。我认为SRE的一个关键共识是承认系统并不完美，追求永不停止的系统是不现实的。基于一个不完善的系统，我们将不可避免地面临和经历系统故障和故障。因此，对我们来说重要的不是找这个或那个人对这次失败负责，而是彻底审视这次失败和失败的根源是什么，如何避免同样的失败再次发生。系统可靠性是整个团队所追求的目标，从故障中快速恢复并从中吸取教训，每个人都乐于提出问题、应对停机并努力改进系统。事故是值得我们学习的，而不是害怕和羞愧的！在日常运维过程中，出现故障等事故，其实是我们回顾和学习的好机会。通过历史监控数据，分析事故根源，制定后续响应策略，并通过运维平台将这些响应策略编辑成标准化、可复用、自动化的运维应用场景，提供标准、快速的处理同样的问题在未来的解决方案中。这是事后追溯过程最真实的价值。此外，事件响应建立在使用监控构建的数据之上，并使用反馈循环来帮助我们加强对服务的监控。这告诉我们什么是重要的。因为如果我们没有收到警报，而是被告知该服务无法正常工作，那么我们就没有很好地监控。测试和发布第四层是测试和发布软件。这个级别是Mikey金字塔中第一个注重预防而不是事后治疗的级别。预防是指尝试限制发生的事件数量，并确保在发布新代码时基础架构和服务保持稳定。在《SRE Google运维解密》，我第一次接触到基于服务水平目标（SLO）的错误预算（ErrorBudget）。《SRE生存指南》本书通过测试和发布章节提供了更具体的案例。作为一个长期从事运维工作的人，内心最恐惧的或许就是应用新版本的发布。因为除了硬件和网络设备损坏这种自然灾害级别的概率事件外，新应用版本发布后的第二天通常是宕机和事故的高危期。以电信运营商行业为例，在一些系统稳定性特别高的日子，比如春节、国庆、奥运会等重大节日或者特殊时期，经常会出现所谓的堵网行为，其实质是拒绝非紧急BUG和业务功能上线，提高特殊时期的系统可靠性。正如书中所说，测试是一种在成本和风险之间找到适当平衡的活动。如果你冒太多风险，你可能会对系统故障感到厌倦；相反，如果你过于保守，你将无法以足够快的速度发布新事物，从而使企业无法在市场上生存。在错误预算比较大的情况下（即一段时间内因故障导致的系统宕机较少），可以适当减少测试资源，放宽系统上线的测试和条件，让业务可以在线上有更多功能以保持业务敏感度；当错误预算比较小的时候（即系统会因为故障而长时间关闭），需要增加测试资源，加紧对系统线上的测试，让潜在的风险可以更有效地对系统进行分析发布，避免系统停机，保持系统的稳定状态。敏感状态和稳定状态之间的平衡需要整个运维和开发团队共同分担。除了测试，应用发布也是通常由运维团队承担的职责。SRE的原则之一是将所有重复劳动编码和工具化；此外，应用发布的复杂度往往与系统的复杂度成正比。因此，应用系统中的大型企业往往开始基于自动化框架构建自动化的应用发布流程。新居网络基于自动化框架的应用发布使用自动化发布工具，我们可以构建一个管道来实现部署过程中的所有操作（如编译打包、测试发布、生产准备、告警屏蔽、服务停止、数据库执行、应用deployment、serviceRestart等）完全自动化，无需人工干预，解决以往人工发布存在的问题：整个过程需要人员参与，占用大量时间，效率低下。上线、更新、回滚速度慢且不规范，存在一定程度的管理混乱和人为失误运行概率增加容量规划第五层是容量规划。关于预测未来和发现系统的局限性。还进行了容量规划，以确保可以随着时间的推移改进和增强系统。规划的主要目标是管理风险和期望。对于容量规划，它涉及扩展整个企业的容量。关注的期望是人们在看到业务增长时期望服务如何响应。风险是花费时间和金钱在额外的基础设施上来处理这个问题。容量规划首先是对未来可预测性的分析判断，其预测的基础是海量运维数据。因此，除了有相应的架构和规划团队进行容量规划外，综合运维数据中心是系统容量规划的必备设施。容量趋势分析与预警将来自运维监控、流程管理等各种数据源的各种运维数据进行综合采集、整理、清洗、存储，并将这些运维数据从各种工具中打通整合、结构化为各种运维数据数据主题。使用这些数据主题的数据是用来帮助运维人员评估问题的，包括：当前容量是多少，当达到容量限制时，容量应该如何改变，容量规划和运维平台可以不仅提供必要的数据支持，还需要提供必要的数据可视化支持能力。运维数据可视化提供了一些必要的能力，保证运维人员可以更好的利用运维数据进行容量评估。运维数据可视化分析首先，运维平台需要具备强大的数据检索能力。运维平台存储了大量的运维数据。运维人员在尝试建立和验证探索性场景时，往往会反复搜索和查询特定数据。如果运维数据分析平台的数据查询很慢或者查询角度很少，运维人员创建场景需要很长时间甚至失败。因此运维人员可以通过该平台实现关键字、统计功能、单条件、多条件、模糊多维搜索功能，实现海量数据的秒级查询，更有效地帮助运维人员更方便地分析数据。其次，平台需要强大的数据可视化能力。人们常说“千言万语不如一张图”，运维人员往往会通过各个系统的运维数据进行统计分析，生成各种实时报表。)进行多维度、多角度的深入分析、预测和可视化，将自己分析的预测结果和经验表达和推广给他人。构建工具第六层是新工具和服务的开发。SRE不仅涉及运营，还涉及软件开发。SRE工程师将花费大约一半的时间来开发新工具和服务。其中一些工具将用于自动执行一些手动任务，而其他工具将用于改进Mikey金字塔的其余部分。通过编写代码将自己和他人从重复性工作中解放出来。如果我们不需要人类来完成任务，那么就编写不需要人类参与的代码。SRE发自内心的轻视重要工作，将从原来的人工加被动响应转变为更高效、自动化的运维体系。事实上，在我们负责运维的客户中，IT系统规模的增长速度已经远远超过运维团队规模的增长。例如，一些电信运营商很难在每天早上进行大规模业务运营之前对所有IT系统设备进行例行状态检查。为了解决这个矛盾，我们专门部署开发了我们的自动化监控和运维工具，把日常大量重复的机械操作交给了机器。你只需要定义相关的检测模板，机器就会按照我们定义了十年的规范进行各种检测操作。如果巡检结果有异常，运维人员手机上会出现告警信息，通知相关运维人员进行处理。基于新聚网络自动化运维框架构建自动化运维工具的优势在于：1）让机器来管理机器，将大量重复性、机械性的运维任务交给机器去执行，有效降低运维人力资源投入，让运维人员的精力可以释放出来，投入到更重要的领域。2)运维操作标准化，为众多复杂易错的人工操作实现了统一的运维操作入口，实现了运维操作的白屏，提高了运维操作的可管理性；带来人工误操作，避免“从删库到跑路”的悲剧。3）运维经验和能力的传承，运维自动化工具将众多原有运维团队积累的经验，以代码的形式总结成各种运维工具，实现自动化、白屏运维操作.运维团队的后来者可以有效地继承、复用和优化。这种编码的工作继承将个人能力转化为团队能力，减少了人员流动对工作的影响。自动化运维系统的构建必须基于运维场景。这些运维场景在企业内部反复迭代创建，是企业中最常用的运维场景。例如上述的自动巡检、软件安装部署、应用发布交付、资产管理、自动告警处理、故障分析、资源发放等。因此，自动化运维应该支持各类自动化作业配置能力，通过简单的脚本开发、场景配置、可视化定制流程，实现更多运维场景。用户体验最后一层是用户体验，就是保证用户有好的体验。与用户研究人员合作，确保良好的用户体验。这与SRE有两个关系。首先，我们需要支持我们支持的系统的用户体验。例如，确保您的应用程序响应迅速且可用，从而为用户提供一致的体验。其次，我们的工具需要提供出色的体验。出色的体验意味着我们构建和支持的服务的用户想要使用它们。用户体验的管理是SRE的最高境界，其实也是运维的最终目标。之前的层级，无论是监控、事件响应、审核、测试发布、容量规划、构建自动化工具，无非是为了提供更好的系统用户业务体验。因此，我们在运维过程中都非常注重系统的用户体验。例如，在实际运维工作中，我们经常可以获取应用日志、监控数据、业务测试等与业务相关的用户体验信息。在运维数据平台中，通过这些用户体验监控数据之间的关联和串联，再现了用户最终的业务调用环节以及各应用环节与性能数据的关系。最终，从业务用户体验数据出发，逐步实现系统运行状态数据与设备运行状态数据的链接，使运维系统达到以终端用户体验为中心的目标。这些用户体验信息对于运维团队掌握客户整体用户体验、监控系统可用性、针对性优化系统具有不可替代的作用。写在最后，SRE是典型的国外互联网公司如谷歌运维体系的建设理念。我认为不同于传统的以设备为中心的运维体系，SRE运维体系更强调以用户体验为核心，以自动化和运维数据为手段，实现应用业务的连续性保障。与其说是系统运维，不如说是系统运维更恰当。当然，不同的公司有自己不同的文化、制度和背景，SRE运维体系不能生搬硬套。但其中提到的很多思想和方法还是值得借鉴的。如果您有机会详细阅读本书，希望能分享您的感悟。笔者介绍新居网络首席架构师梁明图。拥有超过10年的数据库运维、数据分析、数据库设计、系统规划建设经验。在数据架构管理和数据资产管理方面有深入研究。
