作者嘉为蓝鲸·2022-11-24 11:18

其它·广州嘉为科技有限公司

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

字数 5505阅读 632评论 0赞 0

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

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

![](https://pic2.zhimg.com/80/v2-fb504eaa7ed61edca9e7e3c64d7bffcd_720w.webp)

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

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

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

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

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

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

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

![](https://pic1.zhimg.com/80/v2-513524832f9c57d084a631a79fb7246c_720w.webp)

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

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

** 怎么做熵减呢？**

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

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

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

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

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

![](https://pic1.zhimg.com/80/v2-ca903eec850e1b0db534aa7216cca81c_720w.webp)

** L1：运维价值**

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

** L2：运维领域**

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

** L3：运维活动**

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

** L4：运维操作**

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

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

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

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

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

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

![](https://pic1.zhimg.com/80/v2-71e76760585caa80abde22e18719cf64_720w.webp)

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

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

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

** 起点，是管理（M）**

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

** 其次，是场景（S）**

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

** 再次，是能力（C）**

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

** 最后，形成产品（P）**

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

![](https://pic3.zhimg.com/80/v2-41cfd9298e70720ea8847ae9db2bbc1a_720w.webp)

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

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

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

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

![](https://pic2.zhimg.com/80/v2-6a27d19b423ce4d7dee732752a2f61a9_720w.webp)

![](https://pic4.zhimg.com/80/v2-2ff11d09aa7ce31946a55e9742961e7f_720w.webp)

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

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

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

![](https://pic1.zhimg.com/80/v2-83fb1876fe1817109c540fd762de5de8_720w.webp)

![](https://pic1.zhimg.com/80/v2-0184b98a6d0dbe1952b940ab0d04f0d4_720w.webp)

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

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

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

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

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

![](https://pic4.zhimg.com/80/v2-31c93109b0ca577e20bc2f785330a783_720w.webp)

## 02. 运维组织能力内化的三个步骤

组织能力提升对于运维来说特别重要。运维组织的能力不能仅仅依托于内部几个老专家，技术对象的复杂、管理要求的复杂、外部数字化转型加内部技术架构变化等因素，都需要我们将运维作为一个体系去思考。

如何系统性建设我们的运维能力呢？我们跟随一个大的股份制银行客户经过近五年的组织打造，抽象了三个步骤

### 1）第一步：激活组织

运维组织激活其实是一件很困难的事情，运维本身干的活特别苦逼，某种程度上讲往往也是比较被动的。

激活组织的起点，从让运维人员有成就感开始，而成就感则来源于持续的自我提升。建设侧重点要从如何快速处理故障转向如何减少故障，围绕服务连续性和主动管理，持续建设运维能力。

让组织的成员看到有奔头，看到有改变，这样才能激活人更大的创造力和求变的能力。

![](https://pic3.zhimg.com/80/v2-72b47021b8827a01c8e76bda79b95402_720w.webp)

### 2）第二步：可持续建设+可扩展建设

企业IT运维建设最大的浪费，是历史投资无法被保护的浪费。所以，我们需要采取可持续+可扩展的建设模式。

* 可持续是指，建设的系统有延续性；
* 可扩展是指，沉淀能力应对未来变化。

我们可以采用能力+场景的抽象架构，也就是PaaS化的架构，抽象和解耦能力沉淀于底层，在上层去构建场景和工具，适配多环境多对象。同时不同的场景工具之间联动作业，形成真正的管理闭环，满足现在和未来的需要。

![](https://pic2.zhimg.com/80/v2-b081b25f03e3a18a2e45ef96d12d69d5_720w.webp)

### 3）第三步：提升生产力，改变生产关系

* 生产力，指的是运维团队的人员能够快速去满足运维和业务支撑所需要的能力；
* 生产关系，是指运维和业务的关系，不再偏于被动，而是更加主动去提供甚至运营辅助等服务。

具体怎么落地？关键点在于 给不同类型的运维人员，找到发挥价值的位置。

团队中工作多年的运维专家，对运维的管理、联动和执行理解非常深刻，适合转型做运维规划；团队中有编码基础、脚本基础的运维工程师，可以转型运维开发，基于平台提供的开发框架、低代码、原子能力等，快速组装工具系统，由此实现运维体系的自生长。

![](https://pic3.zhimg.com/80/v2-5a3bef15ba3edf97b28c9fd5d8cba65a_720w.webp)

通过这三个步骤，就能够让整个运维团队，实现 从活力到能力，最后提升生产力 的转变。

## 03. 与客户共赢

长期深耕行业，以客户为中心，加上我们对管理经验和工程产品的抽象，形成了目前嘉为1+7的运维产品体系。

基于腾讯蓝鲸PaaS平台沉淀共性能力，可持续可扩展地进行运维体系建设；嘉为自研的配置管理、可观测产品、IT服务管理、自动化运维、多云管理、数据与智能中心、数据运营中心等，一体化联动。

同时，我们也会秉持MSCP方法论，从管理实践、行业场景、架构设计到工具工程去进行长期的产品战略规划，持续输出价值，与客户共赢。

![](https://pic3.zhimg.com/80/v2-f230896594b953e502709b2c3aa95326_720w.webp)

最后，我们希望与客户一起共赢，客户可以用新的运维模式更好支撑业务，嘉为则用新的方法以及对应的工具体系，帮助客户进一步提升运维价值，与客户一起改变运维行业，一起走得更远。

运维场景嘉为蓝鲸运维系统

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

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

添加新评论0 条评论

作者其他文章

相关文章

相关问题