什么是 SRE？一文详解 SRE 运维体系

可观测性系统

在任何有必定规模的企业内部，一旦推行起来整个SRE的运维模式，那么对于可观测性系统的建设将变得尤其重要，而在整个可观测性系统中，一般咱们会分为以下三个方面：

• 指标监控：即各类指标监控，好比基础资源指标，服务性能指标，业务的调用指标。
• 日志：各类设备以及服务的运行日志监控。
• 调用链：业务层面的调用链分析，一般在分布式系统中帮助运营、开发以及运维人员快速识别总体调用的瓶颈点

一整套的可观测系统，它能确保你洞察系统，跟踪系统的健康状态、可用性以及系统内部发生的事情。

对于整个可观测系统的建设，须要注意以下两点：

• 肯定质量标准是什么，并确保系统持续逼近或保持在质量标准极限范围内
• 系统地关注这项工做—而不该该只是随机地查看一下系统

在整个企业级可观测系统中，我认为至少应该包括以下几个特征：

• 完备指标采集：能够对接企业内大部分的设备与技术栈相应的监控指标；同时，支持常见设备的监控指标体系，能够快速接入监控设备和指标，避免全部设备监控都是从头构建；对于日志数据的采集支持
• 海量设备支持：企业IT系统数量和规模愈来愈大，所以监控系统比之前须要监控海量设备监控。
• 监控数据存储和分析：监控数据是运维分析、运维自动化和智能化的基础，所以海量监控数据存储以及基于监控数据的可视化分析是一个监控系统的基本能力。
• 可观测系统是整个运维体系的基础，它须要提供整个运维体系的数据化支持。

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

故障响应

若是有什么东西出了故障，该如何提醒你们并作出回应？工具能够帮助解决这个问题，国为它能够定义提醒人类的规则。

故障响应是创建在使用可观测性系统构建的数据之上，并借助反馈循环，来帮助咱们增强对服务的监控。

故障响应一般包含以下几个动做:

• 关注: 不管是主动发现瓶颈点或异常点，仍是经过可观测性系统被动暴露瓶颈点，咱们都应该进行主动关注
• 交流: 及时将观察到风险点通知到相关方，并告知影响面以及相关的补救措施
• 恢复: 三方达成一致后，根据补救措施进行修复相关风险点和异常点

须要注意的是，若是在前期整个可观测性系统可以作好，一般故障应当始于一个简单的告警信息或一个报障电话，所以，一般状况下，可观测系统作的足够好仅能起到追溯和排查的做用，可是没法起到及时发现的做用，此时就须要依赖于各个观测数据进行计算和评估告警，以及时将相关的告警通知到相关人，以暴露风险点。

告警只是整个故障响应的第一个环节，解决的是故障如何发现的问题，而大多数的故障响应工做都是关于定义处理策略和提供培训的，以便人们在收到警报时知道该怎么作，一般这部分更多的是过去历史经验和运维经历的总结和沉淀，包括经验的一些抽象和工具化沉淀，以保证故障响应的效率和广泛化(即不依赖人为经验)。

而对于整个告警系统来讲，须要确保的是告警的有效性，不然，整个报警系统颇有可能沦落为垃圾数据制造机，告警有效性意味着须要知足以下两个需求：

• 告警及时性: 系统有问题须要及时经过告警信息告知运维处理人员及时处理告警;
• 告警准确性: 只要有告警信息系统必然出现问题(对于不少企业可能存在大量的无用告警，好比磁盘问题，mem等相关问题，固然这里涉及到了自动化、业务形态、告警阈值的问题);

在整个运维过程当中，咱们常常会发现有大量的可有可无的告警信息，让运维人员的注意力迷失在告警海洋当中，而一般非运维领域的领导会关注整个告警的响应程度，所以，抑制和消除无效的告警，让运维人员不被告警风暴所吞没，也是告警管理中重点建设的内容。

一般状况，在咱们的各个可观测系统构建完成后，能够经过整合到监控平台中的各类监控数据，应用趋势预测、短周期检测、间歇性恢复、基线判断、重复压缩等算法和手段实现告警压缩收敛，强化告警的有效性。

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

好比，经过基础资源的多个指标进行综合加权计算来总体评估该资源的利用率；经过一个应用关联的所有资源的资源利用率以及应用的运维架构总体建模分析来计算一个分值来总体评估该应用的健康程度。

这个过程若是作得成熟一些，能够根据内部已有的解决方案和告警进行闭环打通，一个简单的场景就是，当磁盘满时，告警会首先触发一次标准化的磁盘巡检，并进行相关的可丢弃数据的删除，若是依然没法解决该报警，下次可直接关联到一线运维进行人工干预，以后进行标准化经验总结。

故障复盘

故障复盘就是对于过去的一些服务异常和服务中断状况进行回顾和总结，以确保相同问题下次不会再出现。为了让你们团结协做，咱们但愿创建一种无指责、透明的过后文化。我的不该该惧怕事故，而是确信若是事故发生，团队将会响应和改进系统。

备注: 其实在国内的SRE文化中，通常只有对大型，对业务有重大影响的事故才会进行复盘，但实际上若是在时间和经历容许的状况下，对于通常的普通事故也应该在小范围进行复盘，正所谓大的故障都是从不断的小问题一点一点积累的。另外，其实对于运维相关的我的而言，咱们也应当及时的进行小故障复盘，以不断增强我的的故障处理和修复能力。

我认为SRE的一个关键共识正是认可了系统的不完美性，追求永不停机的系统是不现实的。基于不完美系统，咱们无可避免要面对和经历系统故障与失败。

因此咱们重要的并不是找到为这个故障责任的这我的或者那我的，而是更应该创根问底地复盘这个故障和失败的根本缘由是什么，以及如何避免再次出现相同的故障。系统可靠性是整个团队共同奋斗的方向，从失败中快速恢复并吸收教训，每一个人放心地提出问题，应对停机，并努力改进系统。

备注: 一般不少企业内部在故障复盘过程当中，相关人员可能将故障和失败的根因追溯 不经意间 当作了故障定责和一系列的惩罚措施，经过一些惩戒措施来强行约定故障的发生，这种方式每每是很是不可取的，试想每一个人都不想出现事故，要么是认知以外，要么是规则缺陷，永远没有一我的明知会有故障而恰恰去制造故障的。

须要牢记的是: 故障是咱们能够从中学习的东西，而不是让人惧怕和羞耻的事情！

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

测试与发布

测试与发布对于整个稳定性和可靠性的主要出于一个预防的做用，预防是指尝试限制发生的事故数量，并确保在发布新代码时基础架构和服务可以保持稳定。

做为一个长期从事运维工做的人，可能心里中最为恐惧的莫过于新应用版本发布。由于除了硬件和网络设备损坏这个属于天灾级别的几率事件外，新应用版本发布的次日一般是停机与事故的高危期。因此，对于一些量级较大的产品一般会在节假日以及重要活动前夕进行封网操做，以免新版本上线而致使的业务bug出现。

而测试是在成本和风险之间找到适当的平衡活动。若是过于冒险，大家可能就会疲于应付系统失败；反过来讲，若是你太保守，你就不能足够快地发布新东西，让企业在市场上生存下来。

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

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

经过自动化发布工具，咱们能够构建流水线实现部署的过程当中全部的操做（如编译打包、测试发布、生产准备、告警屏蔽、服务中止、数据库执行、应用部署、服务重启等）所有自动化。

容量规划

容量规划是关于预测将来和发现系统极限的，容量规划也是为了确保系统能够随着时间的推移获得完善和加强。

规划的主要目标是管理风险和指望，对于容量规划，涉及到将容量扩展到整个业务；所关注的指望是人们在看到业务增加时指望服务如何响应。风险是在额外的基础设施上花费时间和金钱来处理这个问题。

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

容量趋势预警和分析将综合地从各类运维监控、流程管理等数据源中收集、整理、清洗并结构化地存储各类运维数据，将这些来自于各类工具的运维数据打通融合而且构建各类数据主题。

应用这些数据主题的数据用于帮助运维人员对问题进行评估，包括：

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

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

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

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

自动化工具开发

SRE不只涉及运营，还涉及软件开发，固然这部分指的是和运维以及SRE领域相关的工具和平台开发。在Google的SRE体系中，SRE工程师将花费大约一半的时间来开发新的工具和服务，这些工具的一部分用于自动化一些手动任务，而其余部分用于来不断填补和修复整个SRE体系内部的其余系统。

经过编写代码把本身和其余人从重复的工做中解放出来，若是咱们不须要人类来完成任务，那么就编写代码，这样人类就不须要参与其中了。

SRE从心里上鄙视重复性的工做，将从原有的人工加被动响应，转变为更高效、更为自动化的运维体系。

自动化运维框架：

自动化运维工具的优点和必要性:

• 提升效率: 由程序自动化操做，有效地下降运维人力资源的投入，也让运维人员的精力得以释放并投向更为重要的领域。
• 操做的标准化: 将原来许多复杂、易错的手工操做实现统一运维操做入口，实现运维操做白屏化，提高运维操做的可管理性；

  同时，减小因为运维人员情绪带来手工误操做，避免“从删库到跑路”这样的悲剧的发生。

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

构建自动化运维体系就必须以运维场景为基础，这些运维场景是在本企业内反复迭代和打造，是企业中最经常使用的运维场景。

好比常见的运维场景：软件安装部署、应用发布交付、资产管理、告警自动处理、故障分析、资源申请、自动化巡检等等。所以，整个自动化运维体系建设时也应支持多种不一样类型的自动化做业配置能力，经过简单的脚本开发、场景配置和可视化定制流程实现更多运维场景的实现。

用户体验

用户体验这一层要说的是，做为SRE来说，从用户的角度来保证业务的稳定性和可用性才是最终目标。这个才传统意义上的运维人员是不会关注这一点的，由于你们一般只会考虑到我底层运维的系统或底层资源是否稳定，但实际上整个业务的稳定才是SRE须要关心的问题，而业务的稳定性和可用性一般须要站在用户的角度来模拟和衡量总体的可用性和可靠性。

在前面提到的全部SRE相关的工做范畴，不管是监控、事故响应、回顾、测试与发布、容量规划以及构建自动化工具，无非都是为了提供更好的系统用户业务体验而服务的。所以，咱们在运维的过程当中无不须要注意关注系统的用户体验。

而在实际运维工做中，咱们每每能够经过应用日志、监控数据、业务拔测等业务相关的用户体验信息。在运维数据平台中，经过这些用户体验监测数据之间的关联和串联，重现用户的最终业务调用链路以及各应用环节对性能数据的关系。最终造成从业务用户体验数据入手，逐步实现系统运行状态数据、设备运行状态数据链路的打通，让运维体系实现以最终用户体验为中心的目标。

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

其实，SRE运维体系更为强调以用户的体验为核心，以自动化和运维数据为手段，实现应用业务连续性保障，从这个点出发，咱们会发现和以往的传统运维仍是有很大的区别的，咱们再也不仅仅是单纯的安装和部署工程师，咱们须要经过一系列的技术手段来不断保障上层业务的稳定性和可靠性。

_来自：BGBiao的SRE人生
连接：https://bgbiao.top/post/sre运...