摘要：自动化运维与管控在业界是一个非常普遍的话题，特别是在互联网圈子里面，近几年随着大数据技术的爆发、系统规模和复杂度的提升以及行业开始对ServiceMesh、FAAS等云原生技术体系的探索，自动化运维与管控在业界及公司内的重要性越发凸显，然而，自动化运维与管控的应用目前主要集中在各大公司的运维团队（包括大数据运维）、基础技术或研发体系支撑团队，占据研发人员大多数的业务产品技术团队对其重视程度有限，多数依赖基础技术产品/平台提供的自助工具并结合业务团队开发的常用工具集来开展日常系统维护。这里有个有趣的现象：如果某产品的客户是技术/研发类人员，则其自动化程度会高些，而若产品的客户是pd、运营、商家等非技术类人员则其系统自动化程度相对较低，究其原因这和产品研发团队支持的客户群体、问题量大小、产品稳定性、抽象程度有关，同时也和团队规模、团队文化及所处阶段有关。
我们站在安全生产的大背景下来看自动化运维管控，安全生产虽然带来了更严格的系统变更约束和更高的问题响应与处理的要求，但其本质还是要在保障系统风险可控的前提下提升产品研发效率并降低运维成本。这里的运维需要更广义的理解：一切的系统代码、配置或数据的变更管理（变更检查、执行、灰度、快速回滚等）、问题的及时感知、问题的快速定位与处理、业务或系统数据的监控、依赖的服务或资源的调度、甚至是问题的自助答疑排查等等。究其根本还是要从开发的思维角度来解决问题，那么，如何构建自动化运维管控体系并衡量其好坏，我们可以尝试从以下几个方面来分析下。
自动化运维管控体系的演进
过去几年，业界关于DevOps的讨论非常多，各大公司也有非常多的基于DevOps的实践落地，同时近几年随着大数据、AI概念的普及，AIOps成为当下研究和实践的热点方向，不管概念如何定义和演进，xxOps解决问题的核心思路基本遵循以下发展路径：
自动化体系从其解决问题的角度来看经历了以下三个发展阶段：
1）操作自动化：采用集成的脚本或web类工具来解决同一类问题。
2）场景自动化：基于自动化系统平台，能够结合当前系统上下文和外部环境并基于事先定义好的条件来做一系列的变更或分析需求。
3）数据驱动智能化：在场景自动化的基础上，结合严格定义的系统指标或业务指标（metrics），具备系统关键指标的实时采集、分析、计算能力，再基于特定的算法模型主动识别确定性问题并驱动问题的告警/预警、路由和解决执行。
本文主要阐述如何设计一个好的基于场景的自动化运维管控系统，并向数据驱动智能自动化体系升级。
待解决的核心问题
在阐述这个问题之前，我们先来看以下几个大家非常熟悉的场景：
1）业务要升级某个业务规则，小二需要在若干系统管理后台里做新规则配置，如业务规则应用的系统，风控管理的系统等等，经常出现某新人不熟悉完整流程漏了某个系统的配置，导致完整的线上业务流程中断，由于业务中断的原因有多种，如何快速定位到并彻底解决这类问题成为痛点。
2）现在大数据算法在业务中发挥着巨大的价值，除了常见的推荐搜索外，在订单路由和履行决策等场景也大量应用。当升级某个算法模型时，如何做到按照最小业务单元的控制粒度来执行灰度，在出现新模型召回率、准确率下跌时如何做到快速回滚并对受影响的订单快速定位、分析和修复。
3）在分布式系统架构中，通过异步消息解耦复杂系统之间的强依赖是非常常见和优雅的架构设计策略，特别是一个center/platform级别系统通常会向依赖它的上下游系统发出一些自身业务单据操作或其他实体事件的MQ信息做为业务执行的触发条件与依据。为了避免引入过于复杂的系统设计，大家普遍采取非事务一致性消息模式，当遇到消费者系统故障或消息系统故障等各种因素导致某些消费者（consumer）出现消息丢失的情形时，作为provider或consumer如何快速发现并补全这类丢失的消息。
4） 某算法引擎是个CPU计算密集型系统，但是由于VM资源隔离不干净经常出现同一台宿主机上的VM相互干扰导致st持续飙高，一旦出现这种现象就会导致算法引擎无法基于承诺的SAL给上游返回计算结果，从而影响业务行为。每次遇到这种情况，引擎的开发同学会第一时间分析是否为st飙高导致，一旦确认则通过kill jvm来粗暴快速的解决此次问题。此类case非常频繁，大多数通过客户反馈来驱动问题排查，在虚拟化资源隔离问题未彻底解决之前，作为上游的业务系统如何更高效、及时、主动的解决这类问题；
5）我们时常遇到线上突然告警，然后开发同学介入排查并执行预案（一般是几个配置变更）的场景，一般来说处理思路有如下几种：对上游做限流降级、对下游做依赖降级或启用备用方案、对某个变更做快速回滚。对于此类场景我们能否把其中有明确异常信号及处理流程的解决步骤流程化自动化，然后再去人工介入彻底解决呢？人的响应能力毕竟是有极限的，特别是非工作时段，如果能做到先“自动止血”尽可能降低影响面，然后再人工介入，业务上所受的影响会得到一定程度的降低。我们在业务上对异常的定义、识别、定位需要快速精准，要有备用解决方案，采用类似“熔断机制”的自主可控的处理思路来解决问题。
以上只是列举了几种一线业务系统开发运维时常见的场景，类似的场景还有很多，日常的业务系统答疑、临时需求解决、临时变更、各种依赖和基础环境不稳定时的异常问题跟进等事情占据了我们太多的时间，同时也带来更多的不安全性，如何系统性的解决这些问题呢？从上面的典型case来看，我们面临系统运维的效率问题和运维生产的安全性问题，我们需要给出一个具备以下5种特征的解决方案：
a) 指标精细透明：能够对系统各指标（系统、业务）进行精准、细致、体系化、实时的监控。
通常来讲，衡量一个系统的监控体系做的是否足够好在于我们能否基于这套指标监控体系讲清楚当前业务发生的行为以及行为（正常行为和异常行为）产生的原因，超出当前业务或系统体系则需结合上下游系统一起来诊断。因此，我们一般会从两个视角来定义应用系统关键指标：业务视角和系统视角，这两个视角密不可分（如接口调用量和业务单量）。我们将指标分为面向最终结果的指标和面向过程的指标，这些指标同样也需要精确无歧义的定义，只有这样我们才能做到既能直观了解到系统发生了什么，也能快速定位背后的原因。最后，指标数据采集和展现的实时性非常重要，关系到我们能否快速了解系统最新的行为。
b) 问题快速发现：能否及时主动的发现系统、业务异常。
基于设计良好的监控指标体系，我们能快速掌握当前业务及系统运行情况，结合我们对业务或系统的专业了解能很快识别出当前系统运行是否正常。如果我们把这些业务或系统可能发生的异常行为通过相关的指标值来表达，则可以基于监控大盘+告警系统做到快速、主动的感知具体异常行为的发生。更近一步，若能再融入大数据算法模型，把告警升级为预警则效果更好。
c) 预案自动执行：能够自动执行系统容灾或备份链路等系统预设的backup方案。
如果我们能用监控指标数据准确定义异常发生时的系统行为且能做到快速识别并有明确的异常处理系统化方案，则可以基于预设的异常条件与处理方案在异常发生时自动触发系统流程来解决异常或降低异常对系统影响面，为后续开发的介入创造主动性。
d) 变更安全可控：系统变更（业务规则、系统配置等）可灰度执行、数据影响可追溯、变更可快速回滚；
通过分析线上故障发现，很大比例的故障是在系统发生变更时产生，针对变更（包括但不限于系统配置项变更、数据订正、业务规则切换、发布等），我们一定要有快速回滚方案。同时为了控制变更对系统可能产生的影响，一定要有变更灰度执行或灰度生效的机制，对于较常用的变更操作，特别是针对某类场景的组合类变更一定要有工具化、流程化、系统化的解决方案，尽可能降低因人为操作而导致出错的概率。
e) 答疑高效支持：针对内部、外部的答疑（问题的定位、分析、排查）提供高效、自助的一站式解决方案；
开发团队每天都会花费大量精力应对系统内部或外部的问题咨询与答疑，即使如此仍难免未能支持好所有人的需求。如果对系统的异常行为有清晰的定义和系统化排查与解决方案，则会极大的降低团队内部排查问题的工作量；再进一步，如果我们把常见的问题抽象成通用的问题分析、处理平台并提供一站式解决方案提供我们的客户，则不仅将极大降低开发团队在线上咨询方面处理的投入度，提升客户满意度，更重要的是避免了排查和解决问题时大量的线上操作行为，提升了系统安全与稳定性。
如果能够很好地解决以上5类问题，不仅能支持好我们的客户，同时也能极大提升开发团队的研发效率，降低日常运维的成本，并增强了系统安全与可控性。再回到前述5个典型case，任一问题相信大家都有很好的解决方案，但若这些问题频频出现，就需要有系统化的整体解决方案了，而这绝不是一个小二工作台或工具平台能独自完成的事情。下面我们就来探讨如何设计一个完整的自动化运维管控体系。
自动化运维管控体系设计思路
下图是一个抽象的自动化运维管控系统的通用架构设计参考思路。
核心思路是把一切变更操作标准化、流程化、自助化、自动化，降低人工干预程度，提升操作效率。实现这张架构图并迭代演进是一个跨多个职能团队协作（Cross-Functional Autonomous Teams ）的工作，一切要以客户需求出发，进行持续的抽象和迭代。
我们来分解一下这里面的核心模块与其关键设计原则。
监控数据采集：监控大盘是观察系统的眼睛，一个系统的监控指标是否精细、完整和实时直接关系到这个系统的可运维性，监控指标又分为两大类：业务系统依赖的基础设施的运行时指标（系统类指标）和业务系统自身的业务指标（业务类指标，又分为业务结果数据数据和业务执行过程数据）。具体需要监控哪些数据主要从两个角度来梳理：系统类指标主要从可能会影响系统稳定的点来梳理哪些系统数据显性化有助于我们快速分析定位问题；业务类指标要从业务关心的目标结果数据以及影响这些目标结果达成的过程数据来梳理。目前集团内业务系统依赖的基础中间件、存储、VM等关键系统指标数据非常全面，所以我们的侧重点在业务类指标的梳理和完善上。又由于指标采集的工具、数据分析计算平台都很完备，做好系统数据的监控采集并不难。
异常自动识别：我们常从异常、失败的角度来做数据的埋点、采集和监控，很大一部分异常可以直接通过设定单维度监控预警阈值来进行识别，从而做到精准监控；部分异常需要结合上下文或上下游依赖的数据利用业务知识做二次分析判断，如监控到快递公司某条线路的包裹时效出现波动，由于快递网络包裹配送是一个多角色协同的场景，具体哪个环节出了问题还需要结合更细粒度的数据来分析，这里可能会引入一些算法模型。还有部分异常当前还做不到自动判断，需要人工干预。此外，目前还有一种高阶的做法是基于AI技术做异常预警，基于当前的数据可以预测异常即将发生。
Root Cause分析定位：这个领域基本上是模板驱动（Automated pattern discovery），前提是能够准确分析某类异常发生的根本原因且在对应的业务系统自动化体系里有现成的解决方案，否则就只能人工介入做决策。在依靠人工对异常问题处理的干预的同时，我们也能够沉淀更多的自动解决方案。
异常/变更处理：整个体系最重要的环节，包含预设的解决方案（系统具备的自动处理能力）、变更安全管控模块、对外核心处理能力的集成与驱动。
1） 预设的解决方案：通过业务知识的沉淀形成所谓的专家库，这些沉淀一方面来自于系统业务逻辑设计时制定的规则，另外一方面来自于日常对各种问题处理时的积累，它是一个不断迭代优化的过程。
2）变更安全管控模块：自动化体系建设确实能够提升解决问题的效率，但也使线上系统变更的成本变得更低了，为保证线上变更的安全性，需要对关键的变更做好权限控制，配置类变更需要做好版本控制和灰度发布，同时也要具备变更暂停和快速回滚的能力。对于大数量的变更或大量任务重试等还需要考虑限速限流的能力，避免把下游系统“打垮”，同时基于“重监控、轻管控”的原则，系统也要做好变更操作的关键记录便于事后追溯，有些变更带来的影响具备较长的延时性，这时记录信息能够起到非常关键的作用。
3）对外核心处理能力的集成与驱动：自动化管控系统不应涉及到太多的业务细节，它可能需要基于某个场景来协同多个系统单元来提供整体的自动化/自助化解决方案，但是每个系统单元的能力应该由各系统独自封装并以API的形式提供出来。自动化运维管控系统是目标驱动的，不关心API实现的细节，如：“我们需要修正某个包裹信息里面的业务规则并更新信息至下游合作伙伴系统”，业务运维管控系统里面对小二提供的是个一键修正的功能。在管控系统实现层面可能会分别依赖业务系统A、业务系统B提供的不同API，至于每个接口内部如何实现管控系统并不关心。业务系统需要保证每个独立API具备可重试和幂等的原则，并由管控系统来保证结果的最终执行，即使执行不成功原则上也不影响原有业务系统的数据和逻辑（由于非事物一致性）。基础系统也同样遵循这个原则，只不过当前阿里体系内部研发基础设施非常完备，基本上常用的中间件体系都有配套良好的运维控制系统，因此我们对这类系统的运维变更需求都是登录对应中间件管控平台操作，也有部分中间件产品对外开放了常用的API（基本都是RESTful 风格）供业务自动化运维管控系统来集成。
安全机制：这里的安全指系统或数据安全。在研发人员心中自动化管控系统的重要性通常低于其服务的业务系统的，因此在系统架构设计、代码质量、研发规范、安全等级等方面投入的精力和重视程度会打折扣。笔者曾见到一些系统的安全Bug在发布前置检查流程里面安全校验不通过则利用安全白名单机制绕开，这其实是不可取的，一个功能齐全的自动化运维管控系统对线上数据、业务变更的权限很大，可视作一个内部超级账号，即使内网很安全，我们也要避免意外发生。
通过以上分析我们发现一个好的自动化运维管控系统平台绝不仅仅是一个功能复杂的工具集，它应具备良好的系统化架构与设计，需要和业务系统密切配合又不关心业务处理的细节，基于（问题）场景为用户提供简单直接的解决方案。管控系统和业务系统最大的区别是管控系统需要为业务系统服务，帮助业务系统快速定位问题、解决问题，而不是替业务系统解决问题。一个极端的例子是管控系统里面包含大量直接操作业务系统库表的工具集并自定义组装业务变更的逻辑，这样一旦业务模型升级或逻辑发生变化时，该管控系统就失去了应用的意义。
如何衡量自动化运维管控系统做的好坏
衡量自动化运维管控系统应看其到底要解决那些问题，如前文所说：问题的快速发现、预案的自动执行、变更操作安全可控、日常答疑高效支持、系统指标精细透明等。其本质还是解决安全与效率的问题，因此可以从以下几个维度进行衡量。
1.由于系统变更导致的线上故障分是否有所收敛，是否有因为变更导致的故障，出现故障后是否有快速分析定位和修复问题的自动化机制等；
2.在满足所负责产品日常答疑需求的前提下观察团队在答疑支持上面的投入程度，这是一个持续建设的过程，知识库、自动化技术系统都需要持续完善；
3.开发人员在工作中被中断的频率是否下降，在重复性事务上花费的时间是否减少，关键产出是否提升等。
对于系统中哪些方面需要自动化，我的观点是 Automate Everything You Can ！然而,自动化不是银弹，它能保证问题的快速发现和响应，起到缓解问题的作用，但无法解决因为系统架构设计不合理带来的根本性问题。本文没有涉及研发阶段非常重要的持续集成等概念，更多的是站在现有问题体系下阐述如何做好系统的自动化运维管控。
自动化运维管控体系技术展望
1.随着业务复杂度的提升，数据规模持续增长，AIOps的价值会越来越明显，有些局部领域已经开始这方面的尝试与突破；
2.随着云计算的普及未来基于云的研发模式会成为普遍现象，且随着云原生技术的快速发展，未来在云上提供开箱即用的基础设施服务将使业务研发团队更加聚焦在业务系统的研发上，业务系统的自动化管控运维也会更加聚焦自身所服务的业务系统上。云原生基础技术将更加大众化，业务团队不会再享受到过去那种基础平台的贴身服务了，这也驱使业务研发团队更加重视自身系统的自动化运营管控体系建设。
文章来源：AlibabaTechQA
开发者社区整理