中国领先的IT技术网站
|
|

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

一个好的运维产品分层体系,是运维平台理解清晰与否的标志。无论是整体运维产品的规划体系,还是自动化体系,还是数据化体系,甚至说CMDB平台的资源体系,都可以用分层归纳总结。本文是作者对运维产品整体分层体系的理解。

作者:老王来源:互联网运维杂谈|2015-12-15 17:21

【沙龙】51CTO诚邀您9月23号和多位技术大咖一起聊智能CDN的优化之路,抓紧时间哦!


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

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

1.运营能力层

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

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

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

2.平台能力层

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

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

3.通用能力层

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

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

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

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

4.基础设施层

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

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

【编辑推荐】

  1. 运维自动化与标准规范化:解析、设计及实现
  2. 详解数据中心的运维自动化和DevOps
  3. 运维高手十分钟写了一个内存监控系统
  4. 百度运维专家:我在大数据项目中踩过的那些坑
  5. IT运维人员之痛 如何通过自动化进行系统化解决?
【责任编辑:火凤凰 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

Java编程思想 第4版

本书共22章,包括操作符、控制执行流程、访问权限控制、复用类、多态、接口、通过异常处理错误、字符串、泛型、数组、容器深入研究、Java I...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
× 学习达标赢Beats耳机