运维自动化的多维解读
1 基于应用变更场景的维度划分
我们曾经探讨过，所有运维的价值导向最终都是面向业务、面向用户，所以自然而然就需要从业务的维度进行划分。而运维是有很多种场景的，但从业务的角度来说，核心的业务场景一般就包括如下5种：业务上线、业务下线、业务扩容、业务缩容和应用升级。下面将以其中一种场景为例，将整个流程穿起来看看，以此识别流程的节点到底对接了哪些系统？针对其他的业务场景，我们也可以用同类的方法进行分析。首先预设业务的架构如图1-2所示。
图1-2 业务架构示例图
(1)业务上线。表示上线一个完整的应用。从无到有部署整个业务上线，具体的流程如图1-3所示。
仔细看图1-3中所示的流程，我们会发现该流程涉及多个系统，每个系统所完成的职能又都有不同，这里只是大概地描述了一下。但一旦将这个流程清晰地梳理出来，我们就能知道真正地将一个应用全部上线到底有多复杂了。但看完图1-3又会觉得其实比较简单了，因为从业务上线的流程来看，我们只需要一个上层的流程调度引擎再加上对应的执行器，执行器通过API和底层的各个系统对接即可。这也是为什么之前在框架图(图1-2)中，要求各个专业系统一定要向上提供API，并且要求这个API的风格必须是一致的。
图1-3 业务上线流程
最复杂的业务上线流程梳理完成之后，业务下线其实很简单，它是上线过程的逆过程，上线负责装，下线负责拆。
业务上线之后，随着用户活跃度的上升，业务的容量逐渐会出现不足的情况，此时就需要进行业务扩容。业务扩容其实很简单，当某类节点出现不足的时候，就对它进行扩容。业务扩容所要做的
变更，其实都是业务上线的子流程。比如说如果Web层容量不够，那就申请机器，安装组件、下发应用包，进行自动化测试。这个时候需要注意的是：在业务上线的过程中，我们把很多的配置信息都下放到CMDB中了，因此我们在选择扩容的时候，就要从CMDB中把信息读取出来，以指导变更。
应用升级，目前持续集成所讲的自动化都集中在这块。简单来讲，就是升级程序包、升级配置、执行额外的指令等，一般来说逃脱不了这几种模式。读者可能会问，如果正如你所说的这么简单，那么是不是将SSH封装成一个UI就可以了。当然不是，这个时候还需要你以对运维的理解，在底层进行一些标准化的工作，否则你提供的就只是一个工具，而完全没有运维的思路，比如说程序运行属主、运行路径、监控的策略等。另外建设应用发布平台的目的就是要让测试和生产环境的运维变得更可控。
以上几个运维场景的自动化是否要一次性全部做完呢？当然不是，它们也是有先后和主次之分的。对于以上的运维场景，我在当前所负责的游戏运维中做过统计，数据如图1-4所示。
图1-4 持续部署的数量
(2)持续部署的数量，一个月2000次左右。
(3)其他场景的分布情况。一个月上线一次、下线两次、扩容一次左右。
有了这个数据，我们在建设一个自动化系统的时候，就能意识到应该先做什么后做什么。当然，不同的企业有不同的实际情况，还是应该找到核心痛点，而不是一上来就建设完整的业务变更系统，那样不仅见效不快，且容易让项目收益不大，从而遇到很大的阻力。
基于系统层次的维度划分
首先来看下系统层次的维度划分，如图1-5所示。
图1-5 基于系统层次的维度划分
给出如图1-5所示的分层体系图，其实就是为了让大家更好地识别系统的职责和范围，下层干上层的活，或者上层干下层的活都是越界，越界将带来耦合的问题。举个例子，系统服务层由Puppet(或者Chef)配置管理，但网上的很多资料都说Puppet可以用来做发布，也就是说可以做应用服务层的事情。后来我看过几家用Puppet来做应用服务层发布的公司，最后都走不下去，因为应用包的需求变化太大，只靠Puppet编写factor的模式来适应所有的场景，基本上是不可能的，所以说Puppet适合的是系统服务层配置管理。以上所举的例子就是一种越界!
基于与业务程序耦合紧密程度的维度划分
基于与业务程序耦合紧密程度的维度划分，这点非常重要，这个划分其实是确定系统建设的Owner，从而避免让运维团队承担过多的系统建设职能，否则将会导致运维能力提升缓慢。那么应该如何判断与业务程序耦合的紧密程度呢？我的准则非常简单，线上程序直接调用的就是紧耦合，或者由研发主导的公共服务，类似于API/SDK类的后端服务，应该由测试来主导系统建设；有些服务与程序不是直接关联的，或者是由运维牵头建设的，则由运维来主导，例如LVS、DNS服务等。
有这样一种情况，在很多应用程序中，DNS和LVS服务也存在于程序调用链中，怎么办？在我的方案中，绝对不允许内部服务走DNS和LVS。我们都知道DNS和LVS的服务对于服务异常的处理(DNS无状态、LVS是七层能力弱)，远远达不到线上服务的要求，所以要坚决拒绝。如果真的有人要使用DNS和LVS，那么第一告诉他们业务的风险；第二，发生故障的时候，需要让研发参与处理。另外这也是系统的边界没划分清楚的问题，是让运维组件去承担业务上应该具备的容灾容错功能，这会令后面的运维系统建设增加很多不必要的功能。
面向服务的自动化能力划分
运维最终是需要对外提供服务的，这些服务能力应该由很多底层的自动化平台来承载，个人对其能力划分如下，其实细分到每一层都将发现自动化无处不在，而服务化的能力其实是自动化平台的核心能力，能力划分具体如图1-6所示。
图1-6 自动化平台
1. 运营能力层
运营能力可体现IT运营价值，把IT的运营价值和业务场景紧密联系在一起，这些场景和之前所谈的运营价值体系(质量、成本、效率和安全)是一致的。在运维发展的不同阶段，IT系统的运营价值体现会有所不同，IT运营的核心方法是要有迭代式的思维。
对于很多企业来说，自动化提升效率是运维的第一个价值突破点；再往后，业务的高可用保证和成本控制，则是下一个价值方向；再之后，精细化运营的业务支撑则是更高的诉求，类似于质量要求(质量的概念非常宽泛)。越往后，越能凸显数据的价值，而非自动化工具的价值。因此我个人觉得在某一个阶段，自动化平台突破之后，主要的瓶颈将不是效率，而是数据化IT运营的能力。该能力在依赖平台的同时，更依赖于运维团队的业务理解能力和经验总结。数据化运营能力是精细化的运营能力，是面向产品的，从底层的基础设施质量、到应用的访问体验、再到产品发布后的用户满意度，等等。
这一层的能力表现为一个具体的产品形式＋运营方法，从而可以确保能够很好地闭环起来。举个例子来说：基于资源容量管理的成本优化能力，首先需要一个贴合面向应用的容量分析模型，现实中一般是通过应用所消耗的资源(CPU、内存、I/O、网络等)进行分析运算；其次是需要通过IT运营分析产品来呈现应用的容量水平(当前、历史等)；基于可视化的数据呈现，建立相应的容量管理机制。这里又分为如下三点：
(1)建立标准。低负载需要提升资源使用容量、高负载则需要扩容资源(降低资源使用容量)。
(2)明确责任人和职责。确定容量管理的负责人，可以按照应用的粒度进行划分，同时还要明确这部分的管理要求，对于大规模服务来说，可以 借用考核的工具来进行驱动。
(3)结果驱动。通过定时的结果可视化来驱动容量管理的持续优化。
2. 平台能力层
一个完整的运维平台应具有以下特点：
其能力是集成的，而非离散的——平台需要提供很好的集成能力，让系统得到收敛，避免将系统分割成单个的执行单元，用户也会为此痛苦不堪。
其能力是场景化的，而非基于功能需求的——场景能够串联工具。
其能力是基于角色的，而非基于单一用户的——运维的角色能够清晰地定义场景需求，用户的需求往往是片面而不真实的需求。
其能力是基于事务的，而非基于职能的——事务能够跨越职能组，让运维组织的自动化和数据能力流动起来。
平台能力是指基于底层平台构建起来的具有的运维自动化/数据化(监控＋分析)/安全的能力，这层能力实现了底层能力的组合与封装，屏蔽了底层各个专业子平台的实现细节，是面向业务运维场景的，比如说应用交付、资源交付、业务交付、持续反馈等。
3. 通用能力层
通用能力层是基于基础设施之上封装的公共服务能力，这层架构的能力可分成两个部分：一部分是面向业务技术架构的，另一部分是面向运维服务架构的。图1-6中所列的服务只是其中的一部分，这个也是我经常和交流者强调的能力建设的核心，不能把这个问题留给下面的资源能力层，也不能交给上层的平台能力层。
对于线上技术架构来说，通用能力层将会涉及名字服务、负载均衡服务、分布式缓存、消息队列、分布式关系存储等，运维需要对其技术实现的工作人员要求API直接调用的服务能力。
对于运维服务来说，通用能力层提供了资源服务、作业服务、部署服务、F5管理、GSLB等。这层的平台能力我一直将其理解成是PaaS平台的核心，有了它们其实就可以实现端到端的能力调度。
该层服务能力平台可以很好地对上层平台进行积木式的支撑，同时还可以对底层设施层能力做服务化能力交付，脱离了资源交付的范畴。
4. 基础设施层
基础设施层是资源交付层，对于一个运维系统来说，应该屏蔽底层基础设施的交付能力，无论是IaaS，还是物理层基础设施。尤其是对于一些IaaS云平台来说，更应该屏蔽IaaS底层实现的细节差异，通过API服务向上提供能力。国外早年就有了同类的产品，如RightScale，它很好地实现了多云管理的能力。