今日干货分享：SRE运维体系的构建和工作职责划分。本文将从可观测性系统、故障响应、故障复盘、测试与发布、容量规划以及用户体验多个维度理透SRE运维体系。

可观测性系统

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

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

一整套的可观测系统，它能确保你洞察系统，跟踪系统的健康状态、可用性以及系统内部发生的事情。对于整个可观测系统的建设，需要注意如下两点：

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

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

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

可观测系统是整个运维体系的基础，它需要提供整个运维体系的数据化支持。

故障响应

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

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

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

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

而对于整个告警系统来说，需要确保的是告警的有效性，否则，整个报警系统很有可能沦落为垃圾数据制造机，告警有效性意味着需要满足如下两个需求：

• 告警及时性：系统有问题需要及时通过告警信息告知运维处理人员及时处理告警；
• 告警准确性：只要有告警信息系统必然出现问题（对于很多企业可能存在大量的无用告警，比如磁盘问题，mem等相关问题，当然这里涉及到了自动化、业务形态、告警阈值的问题）。

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

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

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

故障复盘

故障复盘就是对于过去的一些服务异常和服务中断情况进行回顾和总结，以确保相同问题下次不会再出现。为了让大家团结协作，我们希望建立一种无指责、透明的事后文化。个人不应该害怕事故，而是确信如果事故发生，团队将会响应和改进系统。

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

测试与发布

测试与发布对于整个稳定性和可靠性的主要出于一个预防的作用，预防是指尝试限制发生的事故数量，并确保在发布新代码时基础架构和服务能够保持稳定。除了测试外，应用发布也是一项运维团队通常要承担的责任。SRE的一个原则是将一切可以重复性劳动代码化和工具化；此外，应用发布的复杂程度往往与系统的复杂程度成正比。因此在应用系统上规模企业，往往已经着手基于自动化框架构建自动化的应用发布过程。

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

容量规划

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

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

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

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

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

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

自动化工具开发

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

自动化运维框架：

自动化运维工具的优势和必要性：

• 提高效率：由程序自动化操作，有效地降低运维人力资源的投入，也让运维人员的精力得以释放并投向更为重要的领域。
• 操作的标准化：将原来许多复杂、易错的手工操作实现统一运维操作入口，实现运维操作白屏化，提升运维操作的可管理性；同时，减少由于运维人员情绪带来手工误操作，避免“从删库到跑路”这样的悲剧的发生。
• 运维经验能力的传承：运维自动化工具将原来许多运维团队积累的经验以代码方式总结为各种运维工具，实现自动化和白屏化的运维操作。运维团队的后来者，可以有效地继承、重复使用并优化它们。这种代码化的工作传承，将个人能力转变为团队能力，并减少人员流动带来对工作的影响。

用户体验

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

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

文章部分素材来源：分布式实验室