[文章]解读《云计算运维平台参考框架及技术要求》

【摘要】

去年运维大会上，中国信息通信研究院提出了面向运维产品的评估标准——《云计算运维平台建设参考框架及技术要求》。在乱花渐欲迷人眼的运维产品市场，企业用户如何选择稳定、可靠的运维产品构建合适自己的解决方案？通过第三方机构客观的评估，给出了靠谱的办法。

本文阐述了作者对《云计算运维平台建设参考框架及技术要求》的个人理解。

【正文】

2017年11月在“全球运维大会（上海站）”上，发布了由中信息通信研究院、腾讯互娱运营部蓝鲸产品中心牵头，联合华为、高效运维社区、以及其他国内运维产品厂商等公司共同制定的，面向运维产品的《云计算运维平台建设参考框架及技术要求》。在这份标准中，包含了运维工具、产品或平台的最佳实践，并在标准中制定了运维解决方案的分级参考框架。无论企业选择自建运维管理平台或者采购优质的运维产品，都可以在这份标准中找到参考建议。

一、运维平台架构

在《云计算运维平台建设参考框架及技术要求》中，明确了最佳的运维平台应采用“四层架构设计”，包括IaaS管控层、原子平台层、集成平台层、运维场景层。

图1 运维参考框架

l  IaaS管控层：是指对IaaS资源的管理和控制，既能适配各类操作系统，还兼容虚拟机、容器、公有云、混合云等。在IaaS管控层的核心是提供各种类型的管道，如文件下发、命令执行、数据传输等。这里的通道可以理解为Agent、API\SDK、各通用协议等。

l  原子平台层：是指为满足通用运维场景的基础能力的封装。这层架构可以理解为，就是利用管控层的通道，将同类的运维操作或动作封装成各个功能模块。如CMDB模块、面向OS操作的“作业功能模块”、面向容器操作的“容器管理模块”。这些模块的所有功能都应该开放API，供上层架构进行灵活调用。

l  PaaS层：提供完整的前后台的开发框架，包括服务总线（ESB）、调度引擎、公共组件等模块。直白点说，就是让运维用户可以自主的、简单的、快速的创建和部署运维工具，且这些运维工具应由PaaS平台免运维托管。

l  运维场景层：PaaS层之上构建的运维工具，简单讲就是运维平台层功能模块的再封装，适配到不同企业的不同的运维场景。

上述四层架构参考框架中，把运维平台所需要的能力进行了极简的抽象。总结来说，下面的“IaaS管控层”和“原子平台层”代表运维平台对所有IT对象的纳管能力，上面的“PaaS层”和“运维场景层”代表运维平台对所有操作和流程的覆盖程度。从纳管能力和覆盖程度两个的角度，即可衡量一个运维平台或产品的成熟度。

二、IaaS管控层

IaaS管控层是整个运维框架的底层支撑体系，是上层运维场景与底层IaaS的连接器，为上层提供指令、文件、数据的通道。在《云计算运维平台建设参考框架及技术要求》中，IaaS管控层主要指的就是插入OS层面的Agent。Agent支持直连、代理等模式，并有且只有一个Agent。

图2 IaaS管控层

但是把IaaS管控层等同于Agent理解是不充分的，IaaS管控层还应该包括各IT对象的SDK/API和通用协议，比如公有云API、远程SQL语句、SNMP协议、IPMI协议等。虽然严格意义上来看，这些SDK/API和通用协议不属于运维平台的一部分，但确实是我们操作这些对象的有效手段，同样是自动化运维的通道。

所以从广义上理解这个IaaS管控层，就是利用一切可以利用方式，最大限度的对各门各类IT对象和应用进行纳管，不择手段。

三、原子平台层

在《云计算运维平台建设参考框架及技术要求》中定义“原子平台层”为“IaaS管控层”之上的管理与基础运维操作平台，具体包括运维操作对象管理的CMDB模块，运维执行脚本和文件传输的作业功能模块，对基础设施、应用程序、中间件等各类环境的运行状态进行数据采集和分析的运维数据模块，对容器的镜像生产、管理、资源调度的容器管理模块等其他满足运维操作的独立统一功能模块。

图3 原子平台层

《云计算运维平台建设参考框架及技术要求》中详细定义了上述原子平台层的各个模块应具备的功能，但这些模块是不够的，不能完全满足企业对运维的需求。比如面向数据库操作的“数据库管理模块”、面向存储设备的“统一存储管理模块”、面向公用云操作的“云管理模块”等都应该是企业需要建设的原子平台层模块。

“原子平台层”这层架构非常符合企业IT运维实际情况，基本没有哪家企业的IT运维是从0建设的，或多或少都已自建一些运维工具，比如发布工具、监控和日志工具、数据库管理工具等。这些已上线工具肯定希望可以继续发挥价值，就可以把它们规划到原子平台层中，开放出API对接到PaaS层，形成统一的运维平台。

四、PaaS层和运维场景层

PaaS层是开放的平台层，包括用于支持用户简单快速的创建、部署和托管运维工具的APaaS（Application Platform as a Service），以及提供完善前后台开发框架、服务总线、调度引擎、公共组件等模块的IpaaS（Integration Platform as a Service）。通俗讲，PaaS的主要作用就是对接原子平台层提供的API，再提供给上层运维工具调用，其中引入了ESB的概念。

运维场景层就是原子平台层功能模块的再拼装，实现基础运维、CI/CD、监控告警、任务编排、弹性伸缩、安全审计、ITIL以及移动运维等各类场景的自动化。

图4 PaaS层和运维场景层   

《云计算运维平台建设参考框架及技术要求》中并未对运维场景层进行严格的定义。这是符合企业运维实际情况的，不同企业有各自运维特点，关注点也各不相同，确实没有必要进行严格定义。然而运维场景就不能归纳总结了么，其实常见的运维场景可以归纳为两类需求：“执行操作无展示”和“执行操作有展示”

l  执行操作无展示：如应用更新发布、应用切换等，这些操作的特点是有清晰的操作步骤，按照流程一步一步做完即可。这一类运维场景可以通过将原子平台层的各个功能封装成操作原子，在利用调度引擎对原子进行编排，解决运维场景操作全流程的调度自动化。如果做成拖拽式编排设计，可极大提高效率。

l  执行操作有展示：如系统巡检需要出具报告、监控告警需要展示、以及各类可视化报表等。看起来这类运维场景差异性相对较大，但运维对可视化要求相对比较单一，多数为图标展示。可以考虑参考类似商业BI产品那样，拖拽式或轻量开发即可快速制作可视化报表。

五、总结

现在市场上没有一款运维产品可以即插即用的满足企业对运维的所有需求，《云计算运维平台建设参考框架及技术要求》为企业提供了一种方法论，指导企业建立完善的运维管理平台和选择优质的运维产品。通过对《云计算运维平台建设参考框架及技术要求》深度解读，企业构建运维平台应该着重考虑以下关键点：

l  PaaS层是运维平台建设的重点，特别是PaaS中的企业服务总线（ESB）起到了“承上接下”的作用，盘活了整个平台。

l  原子平台层是需要长期建设的，每个功能模块都需要开放API供上层PaaS调用。

l  原子平台层中丰富越多功能模块，整个运维平台生产力就越强大。这部分可以考虑采购或自建，目标就是越丰富越好。

l  运维场景层仍然是可以抽象的。