[总结]三年经验的运维策略

本人虽然只有工作三年，实际经手的系统却着实不少。抛开技术问题不谈，我想从策略的角度来总结，每次接触到新的组件的时候如何做才能把组件运行好。其中的经验来源于书本和博文的，最经典的当然就是google的两本《SRE:Google运维解密》和《Google SRE工作手册》，但书中的情景是基于google完善的基础架构，sre工作规范和培养制度的。实际工作中，我觉得很少有机会把这么成熟的组件和运维体系交付给我们。此时，更需要运维人员有智慧的分阶段的推动组件成熟化。其中的经验多数来源于我观察同事们工作后的总结，和曾经的行为规范。下面我根据一个新同学接触系统的过程，和组件本身成熟度两个维度来分析这个过程:

[新同学视角]接触组件

1. 建立依赖关系图

明白我们负责的系统依赖于哪些别的组件，这个阶段可以用draw.io

2. 建立三张Failure Modes表

通过1的图我们可以列举出系统中的所有组件,然后根据这些组件建立三张表:

• By Dependency
  这个表的意思是系统所依赖的另一个组件或系统如果有问题会怎么样，我们是否有应对的措施:

  Failure Mode ID	Component	Dependency	Possible Failure	Functional Impact	SLO Priority	Possible Cause(s)	Detection Point(s)	Detection Delay (seconds)	SOP
  	这个系统中的哪一个组件	依赖外部的哪一个系统或组件	失败后的表现，比如监控哪个指标下降	失败的影响	影响等级	可能的原因	检测方式

• By Components
  这个表的意思是组成系统的每个具体组件如果有问题会怎么样，具体表格可以参考上面

• By Functions
  对于整个系统，存在哪些功能，如果这个功能失效了会有什么影响。

[系统视角]系统的成熟度

在建立起了对于系统的基本认知后，我们需要对系统的成熟程度做一个基本的分类。以对短期和对长期发展有一个预期的目标。成熟度的划分：

初级阶段

这个阶段系统还有大量手工操作需要操作，运维方式通常为playbook或者多个shell脚本的组合。此时系统是极容易出问题的，我们应该根据上面的表格制定运维规范和完善运维体系，包含以下几个重要的方面：

• 1.1 事故预期SOP
  根据上面的表格，预估可能出现的问题，针对这些问题在测试环境搭建并实际测试，根据测试结果制定SOP。SOP的要求是明确事故检测方式，事故定位方法，事故恢复脚本。
• 1.2 监控系统搭建
  监控系统包括核心指标监控面板、报警渠道搭建、还有和7*24H值班团队一起制定报警升级方案，即无人可以响应的情况下的兜底人员或处理方式。
• 1.3 日志系统的配置
• 1.4 系统搭建脚本
  一般sre也是需要负责系统搭建的，但在这个阶段，系统本身也只是处于不断开发的初级阶段。开发人员交付的搭建方式也可能只是原始的手动搭建方式。可以通过python脚本自动化其中的一部分繁琐的手动流程，降低工作量。可以从[手册]效率工具得到一些启发。

中级阶段

本阶段是从手工转向自动化的重要阶段，其主要目的是将1.4 系统搭建体系自动化。方式是开发一个SRE专用平台来处理运维操作，这个根据团队架构师设计的方案每个公司可能不同，我目前所经历的是采用k8s-operator的方式。这个过程本身也有很多坑，本博客也会陆续更新更多的博文来尽量梳理清楚。

高级阶段

在中级阶段，我们已经通过自动化平台的建设完成了至少1.4的功能。由于在中级阶段积累了大量的api,这些api可能来源于公司内部的已有系统，比如报警系统，日志平台。因此我们有能力去做下面的工作来使得运维过程实现正向循环，即手动操作越来越少，自动化操作越来越多：

• 3.1 开发机器人，自动化检查报警，完成对报警的初级过滤，减少报警对运维人员的干扰
• 3.2 自动化执行SOP, 对于某些常规的固定操作，交给机器人来自动做。比如磁盘满了这种问题
• 3.3 用户查询接口，用户经常会需要运维人员去机器上检查一个什么问题。这种问题也应该通过接口的方式交给用户自己解决，减轻运维工作量。

尾声

从工作量的角度，整个过程一开始是最累人的，需要大量的人手去分担，才有可能让大家有空闲开发，进入下一个阶段。只要越过了(自动化工作时间〉人工介入工作时间)节点之后，后面的工作就会变得轻松和更有意义起来。从SRE的角度来看系统发展，一开始的时候SOP和报警爆炸是常见问题，因为没人知道在实际线上环境上线之后会出现什么意料之外的问题，会倾向于能上就上。SRE作为系统稳定的维护者，需要跟开发人员有一个好的沟通，了解每个报警背后的逻辑，不断优化报警和SOP, 尽可能的通过更少的人工介入来更准确的掌握线上情况。
另外，有两个问题还没有提到:

1. SLO/SLA的问题。我一直做内部平台，还没有接触过先制定SLO/SLA再制定运维计划的场景，所以就没什么谈论的资格。
2. 用户问产品使用问题，这个以前是很难搞的，非常浪费SRE的时间。可很多人不喜欢看文档，就会导致sre被问爆。现在的可能的解决方法是运用大语言模型，但这个方面我还没有实践过。