自动化运维，先做规划还是先建场景？

随着自动化运维在企业落地的成功案例和场景越来越多，更多的企业都在探索适合自身的自动化运维规划。

而在开始进行自动化运维落地的时候，往往会面临一个选择：到底是先做规划再逐步建设，还是先取价值度高的场景再持续建设？

我们先来看看这两种方式的优缺点：

• 先做规划再逐步建设 先规划出未来的自动化运维蓝图，包括自身具备的功能模块、与周边系统的关联、数据流等，再逐步累加进行堆积。 这种方式的好处是整个建设更具备指导性和计划性，但缺点是无法持续的优化建设蓝图，找到适合自己企业落地的模式。
• 先取价值度高的场景再持续建设 先选取一些典型的场景，如应用发布、自动化巡检、补丁更新等场景，逐步建设，然后持续累加，在进行到一定阶段的时候探知到适合自己企业的目标和蓝图。 这种方式的好处是当前做的自动化运维建设是具备实际价值的，便于价值呈现后的后续建设，缺点是缺乏理论指导，需要后续持续构思适合自己的运维蓝图。

那我们在做自动化运维的时候，到底应该选择先做规划呢？还是选择先建场景呢？

我们两种都不选。

来看看一种新的建设思路：1+N

基于1+N的自动化运维建设思路

1+N模式，1是指基础技术平台，N是指运维SaaS应用。

组建团队牵头规划设计并负责基础技术平台的建设，具体的运维功能可以由各专业、各部门自行开发维护和发布，形成1十N的组织模式。

此模式具有如下特点：

• 发挥多方积极性，各取所长
• 快速形成比较完备的企业级能力
• 对平台的基础功能和核心框架要求高
• 要求各团队具有较强的运维开发能力
• 各部门能自己选取价值度最高的场景进行建设

目前嘉维蓝鲸的自动化运维解决方案，采取的就是1+N的建设思路，平台是基于腾讯的蓝鲸智云研发运营一体化平台。

三大典型场景案例介绍

接下来，笔者基于腾讯蓝鲸平台，以1+N的自动化运维建设思路，分享一下在企业的具体落地场景案例。

工单处理自动化

遇到的问题

用户在服务台上提交各类IT需求工单，审批后，需要各个运维人员去各个系统完成用户工单的请求响应，用户响应慢、IT运维工作重复效率低，且容易出错。

解决的方式

基于蓝鲸平台的强大API接入技术，实现与OA或ITSM工单集成，OA提起账号、文件服务器、邮件、业务系统等用户服务工单，完成流程后自动转到自动化运维平台上进行处理，而具体处理操作的执行，则由蓝鲸平台与各个IT对象对接的操作原子实现，操作原子可以是各类脚本、文件分发以及API代码的编排。

解决的成效

加速用户工单处理，提升用户体验和满意度；

减少IT运维重复工作，提高服务台工作效率和准确度。

架构图

应用发布自动化

遇到的问题

应用的更新与发布涉及到的技术对象和流程复杂，造成应用发布耗时长、容易出现步骤纰漏、运维工作量大等问题。

解决的方式

基于蓝鲸的流程引擎，把应用发布以及回滚的流程进行梳理，形成可编排的自动化运维流程，实现与开发的自动化联动，一键完成应用发布与部署。

如典型的应用发布流程为：

解决的成效

提升应用更新和发布的效率，加速企业Devops全流程落地。

架构图

资源交付自动化

遇到的问题

业务或测试用户需要频繁的向IT申请资源，IT需要快速交付整体的资源给到用户，包括计算资源、存储资源、网络资源、关联管理组件等，存在交付速度慢、交付后还需要深度修改、运维人员工作量大的问题。

解决的方式

通过蓝鲸的驱动能力与全套资源交付的各个对象对接，打通资源的各个组件，然后再进行流程编排，形成整体的资源交付。在我们做的案例里面，可以覆盖的例如F5、防火墙、网络设备、第三方系统等各类对象，做到真正意义上的跨系统调度与编排，用户只需要考虑场景和流程，而不用再关心技术上是否可行。

解决的成效

加速资源交付效率，提高业务敏捷性。

流程图

以上为笔者基于蓝鲸的自动化运维建设项目经验和场景设计思路的思考，欢迎大家探讨交流。