一文讲清场景工程方法论及运维组织能力内化

随着业务支撑要求的变化，和技术架构的升级，运维管理建设模式跟之前也有了很大区别，场景上更注重主动工作、防范风险，而体系上更注重赋能组织、平台化、一体化。

因而，我们基于过去几年的大量客户实践，分享一些场景的工程落地，包括可观测、大规模发布、灾备应急、服务敏捷化等，并进一步分享如何把这些能力赋能给客户，把运维能力的产品化和组织赋能关联起来。

* 注：以下内容整理自：嘉为科技运维产品及解决方案负责人张敏于嘉为蓝鲸2022研运一体创新峰会的精彩分享——《从场景工程，到运维赋能》。

01. 运维的熵减：场景工程

1）熵减，降低运维体系的复杂性

熵是一个热力学概念，表示体系的混乱程度。熵增表示系统越来越混乱，熵减则表示系统归于有序。在没有外力作用的情况下，一切事物都是从有序向无序发展，最终形成熵死。而要使混乱往有序发展，就需要做熵减，通过不断做功，增加有效能量。

运维是一个复杂的体系，主要体现在两个方面。

一方面是管理体系带来的复杂性。不同的组织架构、工作流程、工具平台和技术路线、文化氛围等，都可能导致运维的低效和不完善，例如人员能力高低、流程复杂度不一、工具建设的烟囱化竖井化等。

另一方面则是技术对象变化带来的复杂性。例如云原生、微服务、国产化信创适配等，技术对象的更新迭代、规模发展及横纵的复杂性，都让运维这一保障性工作变得复杂。

如果没有有效的管理规划和技术规划，运维体系必然会走向混乱。我们需要不断有效做功，进行熵减，让运维体系归于有序。

2）有效做功：分级分域场景模型

怎么做熵减呢？

我们可以从经典运维原理（PPTR）出发，制定符合企业个性的管理体系，统一组织保障、流程管控、标准规范，然后选择匹配的工具平台和技术架构，设计满足企业需求的运维场景，最后逐步进行PDCA循环演进。

听起来很简单，但是在这个演进的过程中会遇到一个很大的问题，就是我们知道了如何做运维管理，也建设了很多工具系统，但是仍旧不知道现在运维的薄弱点。

问题出在从管理体系落地到工具系统的过程中间，我们要找准连接点。这个连接点即场景。

企业运维的场景非常多，可以大到做业务连续保障管理，也可以小到一个告警的丰富。如果没有对场景进行有效梳理，将会导致后续系统建设越发混乱。

基于过去几年的实践，我们总结出了一套分级分域的场景模型，能很好的解决这个问题。

L1：运维价值

最顶层，找到想要实现的运维价值，也即管理目标，例如业务连续性保障、IT服务满意度、IT运营等等；

L2：运维领域

找到价值目标以后，需要梳理运维领域，思考通过哪些运维领域的组合，能够实现此运维价值。例如要实现业务连续性保障这一价值，不能单单只做监控，而是需要有应急管理、灾备管理、故障管理，还有风险变更管控等等，通过多领域的组合配套，才能实现业务连续性保障的运维价值。

L3：运维活动

运维领域确定以后，就到运维活动。例如故障管理领域，对应需要做故障发现、故障定位、故障恢复、故障预防与改进等活动。

L4：运维操作

运维活动再往下是更细节的运维操作，例如告警源接入、多告警的标准化、如何进行告警收敛、告警分级、事件分派及对应处置，如何联动自动化做故障自愈、如何联动ITSM做事件委派，告警自动关闭等。

我们将管理目标拆解，逐层拆分后再进行工具落地。曾经在项目中遇到过有客户希望将监控指标放到CMDB里面去建设，这种情况就是没有梳理清楚场景。CMDB就应该聚焦在对象和配置，而IT对象的各种指标和状态应该放到监控里，最后将监控与CMDB做关联，这才是有效的做功。

3）一体化、平台化建设的必要性

从2004年起，嘉为就开始面向企业提供IT运维服务，并于2016年正式发布嘉为蓝鲸自动化运维解决方案。经过多年的实践，我们落地了很多运维场景，也愈发认识到一体化和平台化建设的重要性。

一体化，指的是管理一体、流程一体、工具一体，最后形态是以一体化运维工具系统支撑企业的运维场景。以自动化发布为例，运维团队通过开源的或者自研的工具就可以完成编排发布。但是当遇到发布规模变大，或者即有传统发布又有容器发布的复杂情况，或是需要编排多种发布策略的时候，就会发现搞不定了，因为这涉及到多种工具体系的联动。底层需要依赖CMDB、需要作业Agent管控、需要可以联动容器调动K8S，上层需要封装多种发布策略的逻辑，最终才能形成适应各种情况的自动化发布。这就是落地的一体化形态，如果我们建设单个领域能力的时候没有考虑到联动，就会形成烟囱。

而平台化，指的是可持续发展。运维场景会随着技术对象和管理要求的变化而不断发展，怎么保证现有建设的能力体系和工具平台能够满足这种发展呢？我们通过PaaS模式做平台化建设，来满足可持续发展的需要。

4）场景到工程的设计方法：MSCP

有了管理目标、梳理好了场景以后，我们是否就可以进行工程落地了呢？并不是。

经过我们多年的实践，我们总结出了一套从场景到工程的设计方法：管理（M）、场景（S）、能力（C）、产品（P）。

起点，是管理（M）

我们希望达到的管理目标、配套的制度规范、对应的组织岗位能力体系、工作流程、工程落地、度量改进，这是一个不断做功的过程。

其次，是场景（S）

如ITOM、ITSM等经典的运维场景。

再次，是能力（C）

场景到产品中间很重要的一步，是要将能力进行抽象和解耦。我们推荐的最好的解耦方式，就是PaaS。将可复用的能力沉淀为原子，通过API方式调用原子能力和联动第三方能力；同时提供开发框架等，便于进行自定义扩展。

最后，形成产品（P）

基于PaaS自定义开发形成产品，实现可持续的延展。

如下是我们做的两个客户案例，通过MSCP方法指导，最终实现从管理到产品的软件落地：

第一个案例，是大规模发布的场景，应该算是国内除了BAT这几家互联网公司以外，企业级发布规模最大的一个场景了。

客户有业务系统100+、主机节点5万+、K8S集群的主机节点5千+，需要实现高质量、高安全、高效率的统一发布。

最后产品落地，纳管主机实例5W+，容器实例11W+，制定应用发布管理规范，实现对软件交付全流程统一管控；实现CI CD CO全流程贯通、提升发布质量和效率。

第二个案例，是一家大型银行，ITSM替换的场景。

客户的业务系统有200+、主机节点3千+，用户数特别多，需要替换掉之前4大的传统巨石型ITSM管理系统，并且满足ISO标准。

最后产品落地，服务内部运维用户1000+，业务用户10000+，制定关键运维管理活动流程规范，满足ISO20000合规，实现事件管理闭环，提升问题处置效率80%，有效的变更管控，减少变更事故风险。

场景到工程的设计方法MSCP，是我们实践的总结，希望能够给企业的运维建设带来一些思考。

5）数字化运维场景活动蓝图

谈了方法，我们来看下嘉为对数字化运维场景活动的定义。

最上层，是我们运维的本质和价值：用户和业务支撑。下方，是ITSM、ITOM和ITOA活动。其中最重要的是1+4个域：观测域、配置域、作业域、服务域，以及生态域。而对当前AIOps的能力和实践，我们的看法是，这是一个技术补充，仍然回归到运维管理层面，也就是我们定义的AIOps in Ops。

采用PaaS平台技术架构打造生态，实现观测、配置、作业、服务整体协同的一体化。通过ITOA不断持续运营改进，从而把我们的管理体系、对应场景、对应能力、对应工程产品完整落地到IT运维系统，提升组织能力。