工作以来一直在做运维平台相关的研发工作，最近计划总结下对运维体系建设的思考，总结出一个通用模型，后续持续迭代，欢迎一起探讨交流。运维的工作主要有三个方向，稳定性、效率、成本，本篇是第一篇，稳定性篇。
下面开始正文
运维工作的核心目标是保障线上业务可以稳定的运行，降低故障发生次数，缩短故障发生时间。因此稳定性方向的建设工作，我们可以从故障的整个生命周期角度入手，来展开保障稳定性的工作。故障的生命周期有预防、发现、定位、止损、复盘五个阶段。下面我们就从这几个阶段逐个介绍我们可以做哪些工作。
首先我们可以对故障进行分类，有哪些原因会导致故障，从本质上看，所有的故障都是因为变化引起的，有一个不可避免的变化因素“时间”，从变化的角度分析，有计划内变化和计划外变化两大类，由此可以梳理出故障分类的脑图。
预防阶段我们需要做的工作是降低故障的发生次数，可以从计划内变化和计划外变化两个方面考虑。
从每年对故障记录的总结分析上看，引起故障最多的就是主动变化类的变更，大部分都是因为操作不规范导致的。所以故障预防阶段，我们可以重点从规范变更流程入手。首先需要建立规范制度，之后将规范集成到平台中，最后还需要有评价体系，将变更操作规范程度通过分数量化出来。高分的表扬，低分的督促改进。
全公司拉齐规范流程，对于因为违反规范流程而导致的故障，事后要进行重点总结复盘。变更规范可以有下面几条，仅供参考
变更平台一方面可以提高我们的软件功能交付效率，另一方面，也可以起到规范变更流程的作用，上一小节介绍的流程规范内置到变更平台中，可以保证不了解规范的新人，也会遵循变更规范，减少由于变更不规范而引发故障的次数。
待变更平台建设完成后，我们可以从变更平台拿到每个业务线的操作数据，根据变更规范要求，对操作进行打分，起始分数是满分，哪点没遵守就扣一些分，扣分规则可以和业务通过协商达成一致。最后以业务线的维度对分数排名定期通晒，从上到下推动变更规范落地。
对于计划外的变化，我们可以在容量和程序健壮性两个方面做一些工作
我们可以建立完善的压测机制，定期对服务进行压测，提前发现服务的性能瓶颈，及时扩容优化，保障服务稳定运行。
故障发生时及时发现，是降低故障时长的重要一环，要想及时发现故障，就需要对线上业务做全方位的监控。在监控领域有三个支柱，Logging、Metrics、Tracing，其中 Logging 和 Tracing 都是比较细粒度的数据，Metrics 是一种聚合类的时序数据，可以观察服务的状态和趋势，很合适作为判断服务是否异常的依据。所以在故障发现这个层面，我们可以重点在 Metrics 方向做建设。
首先我们对常见的线上业务的数据流模型进行分析，以此来总结一套监控数据体系。
上图是一个线上业务常见的数据流模型，要想做到及时发现线上问题，每一个节点都需要进行数据采集和监控
根据上面的数据流模型我们可以梳理出下面的监控采集场景。
我们把采集数据的场景分为五层，不同的层面由不同角色的人来推动监控数据的采集建设。
监控数据采集完成后，就可以对数据做异常检测了，所有时序数据的异常从本质上可以总结为下面五类
我们可以针对这五种情况，开发我们自己的异常检测引擎，异常检测引擎的建设可以分为两个阶段
第一个阶段，可以实现基于固定阈值的异常检测函数，根据历史经验配置一个固定的阈值，固定阈值检测的优点是易于落地，缺点是需要依赖人的经验，有时候需要不断调试才可以找到一个合适的值，不同的业务需要不同的配置，同一个业务隔一段时间可能还要对阈值进行调整，这样带来了一定的人力成本消耗。
第二个阶段，在人力充足的情况下，我们可以引入基于机器学习的异常检测算法，动态的计算出一个阈值。我们只需要关注对这些指标进行监控，而无需关心它的上下限阈值。一方面可以节省配置告警策略的人力成本，另一方面也降低了对人的经验的依赖。引入智能异常检测算法的工作主要是将已经成熟的算法，工程化落地到我们自己的监控平台。
告警通知我们需要关注下面几点
从数据驱动的思路入手，我们可以统计下面几个指标，一方面体现我们的工作成果，另一个方面也可以推动故障发现机制落地。
平台侧可以统计
业务侧可以用下面的指标给业务打分
首先我们要对故障进行定义，只有影响到线上业务稳定运行的，才算是故障。故障定位的目标不是要找到故障的根因，只要定位到可以做止损动作的决策点就可以了。为了更高效的定位，我们可以从下面两个方面入手
建设平台的目的是可以将信息聚合到一起，辅助大家快速发现到可以止损的决策点，故障定位的目的是确认故障影响范围，以及故障属于哪种类型，之后根据故障类型执行相应的预案。我们可以从空间和时间维度去思考如何加速故障定位的过程。
我们要快速了解故障的边界，确定到底影响了哪些服务，影响范围越明确，越容易找到问题。基于这个目标。我们可以从模块、场景再到业务三个层次去建设每个层次的成功率。要做这件事情的前提是我们已经把每个模块的核心接口的请求数，错误数都采集到了，之后每个模块可以计算出一个整体的成功率，再由多个模块计算出所属场景的成功率，最后计算出整个业务的成功率。如下图所示
通过这样一个整体的成功率大盘，可以快速将问题收敛到一个或几个模块中。滴滴内部把这样的产品叫做灭火图。当定位到模块级别之后，下面要分析出问题的模块是由于什么原因出问题了根据上文中的故障原因分类可知，如果是成功率下跌，要么是自身出问题了，要么是下游出问题了。如果是自身出问题，直接查看模块自身监控大盘。
如果是依赖的下游出问题，要想知道是哪个下游，我们需要提前梳理和下游的依赖关系，首先看一下出问题的模块会有哪些依赖，关于模块依赖关系的梳理，可以通过构建 trace 平台，自动生成依赖关系。如果公司没有 trace 平台的话，那看到这篇文章的你可以考虑搭建一套 trace 平台了，现在比较流行的有 jaeger、skywalking、tempo。但 trace 平台的落地需要一段时间，这个时候，可以推动运维同学和模块负责人一起手动梳理模块的依赖，将模块自身的容量、每个依赖调用的请求量，成功率，分位值延迟都配置成图表，配置到一个监控大盘，从模块成功率图表可以直接跳转到模块的监控大盘中。这样模块依赖的哪个下游出问题了，也就一眼能看到了，如下图所示。
从空间层面，通过灭火图+监控大盘，可以从 业务-》场景-》模块-》依赖 定位到某个模块的某个功能故障点。
当 trace 平台搭建完成之后，我们还可以继续向下追踪，以时间和模块为依据，继续下钻到报错接口的请求链路
再根据 traceid，联动日志平台，继续追踪到详细的日志
我们可以观察下故障发生时刻最近一段时间，都发生了哪些事件，包括告警事件，变更事件，运营事件。离故障发生时刻比较近的事件，很可能是导致故障发生的原因。通过将事件以时间线的方式展示出来，可以辅助我们判断是否是网络故障、变更操作导致的故障。
最后整个定位流程可以总结为下面一张图
平台侧可以统计每个故障从故障发现到故障定位之间消耗的时间，看长期的变化趋势，可以量化我们在故障定位方面的工作成果。
业务侧可以用下面的指标给业务打分
上文中，我们已经梳理出了线上服务出现故障的分类，那针对每一类故障原因，我们可以梳理出对应的预案执行流程，之后再建设预案自动化平台，将预案流程自动化，梳理内容见下图。
所以对于每一个业务，负责该业务运维的同学可以和业务研发一起建立下面七种预案流程。
为了推动预案机制的落地，我们可以建立止损预案健康分体系，从预案建设覆盖度和定期演练次数，进行打分，列出排名，推动预案落地及演练。
关于复盘我们要想清楚为什么要复盘，之后再根据我们复盘的目标，总结出一个复盘模板，并持续优化迭代。
首先我们思考下，为什么要复盘，我理解主要有以下几点
基于上面复盘的目的，我们可以整理出下面的复盘模板
