1.4 运维自动化的多维解读

1.4.1 基于应用变更场景的维度划分

我们曾经探讨过，所有运维的价值导向最终都是面向业务、面向用户，所以自然而然就需要从业务的维度进行划分。而运维是有很多种场景的，但从业务的角度来说，核心的业务场景一般就包括如下5种：业务上线、业务下线、业务扩容、业务缩容和应用升级。下面将以其中一种场景为例，将整个流程穿起来看看，以此识别流程的节点到底对接了哪些系统？针对其他的业务场景，我们也可以用同类的方法进行分析。首先预设业务的架构如图1-2所示。

（1）业务上线。表示上线一个完整的应用。从无到有部署整个业务上线，具体的流程如图1-3所示。

仔细看图1-3中所示的流程，我们会发现该流程涉及多个系统，每个系统所完成的职能又都有不同，这里只是大概地描述了一下。但一旦将这个流程清晰地梳理出来，我们就能知道真正地将一个应用全部上线到底有多复杂了。但看完图1-3又会觉得其实比较简单了，因为从业务上线的流程来看，我们只需要一个上层的流程调度引擎再加上对应的执行器，执行器通过API和底层的各个系统对接即可。这也是为什么之前在框架图（图1-2）中，要求各个专业系统一定要向上提供API，并且要求这个API的风格必须是一致的。

最复杂的业务上线流程梳理完成之后，业务下线其实很简单，它是上线过程的逆过程，上线负责装，下线负责拆。

业务上线之后，随着用户活跃度的上升，业务的容量逐渐会出现不足的情况，此时就需要进行业务扩容。业务扩容其实很简单，当某类节点出现不足的时候，就对它进行扩容。业务扩容所要做的变更，其实都是业务上线的子流程。比如说如果Web层容量不够，那就申请机器，安装组件、下发应用包，进行自动化测试。这个时候需要注意的是：在业务上线的过程中，我们把很多的配置信息都下放到CMDB中了，因此我们在选择扩容的时候，就要从CMDB中把信息读取出来，以指导变更。

应用升级，目前持续集成所讲的自动化都集中在这块。简单来讲，就是升级程序包、升级配置、执行额外的指令等，一般来说逃脱不了这几种模式。读者可能会问，如果正如你所说的这么简单，那么是不是将SSH封装成一个UI就可以了。当然不是，这个时候还需要你以对运维的理解，在底层进行一些标准化的工作，否则你提供的就只是一个工具，而完全没有运维的思路，比如说程序运行属主、运行路径、监控的策略等。另外建设应用发布平台的目的就是要让测试和生产环境的运维变得更可控。

以上几个运维场景的自动化是否要一次性全部做完呢？当然不是，它们也是有先后和主次之分的。对于以上的运维场景，我在当前所负责的游戏运维中做过统计，数据如图1-4所示。

（2）持续部署的数量，一个月2000次左右。

（3）其他场景的分布情况。一个月上线一次、下线两次、扩容一次左右。

有了这个数据，我们在建设一个自动化系统的时候，就能意识到应该先做什么后做什么。当然，不同的企业有不同的实际情况，还是应该找到核心痛点，而不是一上来就建设完整的业务变更系统，那样不仅见效不快，且容易让项目收益不大，从而遇到很大的阻力。