运维人要理清运维产品的能力分层体系

2015-12-16 10:38:15 来源：互联网运维杂谈抢沙发

2015-12-16 10:38:15 来源：互联网运维杂谈

摘要：一个好的运维产品分层体系，是运维平台理解清晰与否的标志。无论是整体运维产品的规划体系，还是自动化体系，还是数据化体系，甚至说CMDB平台的资源体系，都可以用分层归纳总结。
关键词：运维

　　一个好的运维产品分层体系，是运维平台理解清晰与否的标志。

　　建设一个完整的运维平台，绝非一日之功，也非一两个平台所能覆盖，因此我非常喜欢用分层体系来归纳问题。无论是整体运维产品的规划体系，还是自动化体系，还是数据化体系，甚至说CMDB平台的资源体系，都可以用分层归纳总结。以下是我对运维产品整体分层体系的理解：

　　1.运营能力层

　　运营能力是体现IT运营价值，把IT的价值和业务场景紧密联系在一起，这些场景和之前谈的运营价值体系是一致的。在运维发展的不同阶段，IT系统的运营价值体现有所不同，IT运营的核心方法是有迭代式的思维。

　　对于很多企业来说，自动化提升效率是运维第一个价值突破点，再往后，业务的高可用保证和成本控制，则是下一个价值方向；在之后，精细化运营的业务支撑则是更高的诉求，类似质量要求(质量的概念非常宽泛)。越往后，越凸显数据的价值，而非自动化工具的价值。因此我个人觉得在某一个阶段，自动化平台突破之后，自动化则不是主要瓶颈，而是数据化运营的能力。该能力在依赖平台的同时，更依赖的是运维团队的业务理解能力和经验总结。

　　这一层的能力都表现为一个具体的产品形式+运营方法，从而确保能够很好的闭环起来。

　　2.平台能力层

　　在一个完整的运维平台中，其能力是集成的，而非离散的--系统需要提供很好的集成能力，让系统得到收敛，避免系统被割裂成一个一个的执行单元，用户为此痛苦不堪；是场景化的，而非基于功能需求的--场景能够串联工具的能力；是基于角色的，而非基于单一用户的--运维的角色能过清晰定义场景需求，用户的需求往往是片面而不真实的需求；基于事务的，而非基于职能的--事务能过跨越职能组，让运维组织的自动化和数据能力流动起来。

　　平台能力是指基于底层平台构建起来的运维自动化/数据化(监控+分析)/安全的能力平台，这层能力实现了底层能力的组合与封装，屏蔽底层各个专业子平台的实现细节，是面向业务运维场景的，比如说应用交付/资源交付/业务交付/持续反馈等等。

　　3.通用能力层

　　通用能力层是基于基础设施之上封装的公共服务能力，这层架构的能力分成两部分：一部分是面向业务技术架构的，另一部分是面向运维服务架构的。图中列的服务只是其中的部分，这个也是我经常和交流者强调能力建设的核心，不能把这个问题留给下面资源能力层，也不能交给上层平台能力层。

　　对于线上技术架构来说，里面涉及到名字服务/负载均衡服务/分布式缓存/消息队列/分布式关系存储等等，运维需要对其技术实现的同学要求API直接调用的服务能力。

　　对于运维服务来说，提供了资源服务/作业服务/部署服务/F5管理/GSLB等等。这层的平台能力我一直理解成PAAS平台的核心，有了它们其实就可以实现端到端的能力调度。

　　该层服务能力平台可以很好的对上层平台进行积木式的支撑，同时可以对底层设施层能力做服务化能力交付，脱离了资源交付的范畴。

　　4.基础设施层

　　基础设施层是资源交付层，对于一个运维系统来说，应该屏蔽底层基础设施的交付能力，无论是IaaS，还是物理。特别对于一些IaaS云平台来说，更应该屏蔽IaaS底层实现的细节差异，通过api网关向上提供能力。国外早年有同类的产品，如RightScale，很好的实现了多云管理的能力。

　　基于这个思路，可以对其他系统或平台不断的进行分层分解，最终让平台的落地可执行性变得很强，而不是人云亦云的系统工具建设。

第三十四届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训

责编：pingxiaoli

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。