1.4.4 面向服务的自动化能力划分

运维最终是需要对外提供服务的，这些服务能力应该由很多底层的自动化平台来承载，个人对其能力划分如下，其实细分到每一层都将发现自动化无处不在，而服务化的能力其实是自动化平台的核心能力，能力划分具体如图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，它很好地实现了多云管理的能力。