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