一个好的运维产品分层体系，是运维平台理解清晰与否的标志。
建设一个完整的运维平台，绝非一日之功，也非一两个平台所能覆盖，因此我非常喜欢用分层体系来归纳问题。无论是整体运维产品的规划体系，还是自动化体系，还是数据化体系，甚至说CMDB平台的资源体系，都可以用分层归纳总结。以下是我对运维产品整体分层体系的理解：
1.运营能力层
运营能力是体现IT运营价值，把IT的价值和业务场景紧密联系在一起，这些场景和之前谈的运营价值体系是一致的。在运维发展的不同阶段，IT系统的运营价值体现有所不同，IT运营的核心方法是有迭代式的思维。
对于很多企业来说，自动化提升效率是运维***个价值突破点，再往后，业务的高可用保证和成本控制，则是下一个价值方向；在之后，精细化运营的业务支撑则是更高的诉求，类似质量要求(质量的概念非常宽泛)。越往后，越凸显数据的价值，而非自动化工具的价值。因此我个人觉得在某一个阶段，自动化平台突破之后，自动化则不是主要瓶颈，而是数据化运营的能力。该能力在依赖平台的同时，更依赖的是运维团队的业务理解能力和经验总结。
这一层的能力都表现为一个具体的产品形式+运营方法，从而确保能够很好的闭环起来。
2.平台能力层
在一个完整的运维平台中，其能力是集成的，而非离散的--系统需要提供很好的集成能力，让系统得到收敛，避免系统被割裂成一个一个的执行单元，用户为此痛苦不堪；是场景化的，而非基于功能需求的--场景能够串联工具的能力；是基于角色的，而非基于单一用户的--运维的角色能过清晰定义场景需求，用户的需求往往是片面而不真实的需求；基于事务的，而非基于职能的--事务能过跨越职能组，让运维组织的自动化和数据能力流动起来。
平台能力是指基于底层平台构建起来的运维自动化/数据化(监控+分析)/安全的能力平台，这层能力实现了底层能力的组合与封装，屏蔽底层各个专业子平台的实现细节，是面向业务运维场景的，比如说应用交付/资源交付/业务交付/持续反馈等等。
3.通用能力层
通用能力层是基于基础设施之上封装的公共服务能力，这层架构的能力分成两部分：一部分是面向业务技术架构的，另一部分是面向运维服务架构的。图中列的服务只是其中的部分，这个也是我经常和交流者强调能力建设的核心，不能把这个问题留给下面资源能力层，也不能交给上层平台能力层。
对于线上技术架构来说，里面涉及到名字服务/负载均衡服务/分布式缓存/消息队列/分布式关系存储等等，运维需要对其技术实现的同学要求API直接调用的服务能力。
对于运维服务来说，提供了资源服务/作业服务/部署服务/F5管理/GSLB等等。这层的平台能力我一直理解成PAAS平台的核心，有了它们其实就可以实现端到端的能力调度。
该层服务能力平台可以很好的对上层平台进行积木式的支撑，同时可以对底层设施层能力做服务化能力交付，脱离了资源交付的范畴。
4.基础设施层
基础设施层是资源交付层，对于一个运维系统来说，应该屏蔽底层基础设施的交付能力，无论是IaaS，还是物理。特别对于一些IaaS云平台来说，更应该屏蔽IaaS底层实现的细节差异，通过api网关向上提供能力。国外早年有同类的产品，如RightScale，很好的实现了多云管理的能力。
基于这个思路，可以对其他系统或平台不断的进行分层分解，最终让平台的落地可执行性变得很强，而不是人云亦云的系统工具建设。
