云管平台和自动化平台的关系、边界是什么？银行云管平台建设应采用怎样的路径？

■ 来自社区交流，供大家参考

银行云管平台的建设路径探讨？

银行云管平台的建设路径探讨：云管平台和自动化平台的关系、边界，哪些放到云管平台实现，哪些放到自动化平台实现。

现状：一般金融企业都是在已经完成基于ITIL的流程体系和技术体系后，建设云管平台的。流程体系实现的流程审批功能，技术体系以自动化平台、堡垒机、监控体系为核心实现日常变更和运维。

问题：云管平台与以上二者之间的关系是什么？资源发放的流程审批，在流程平台中实现，还是云管平台中实现？ 自动化变更，本质是调用API或脚本，云管平台和自动化平台都具备这一能力。哪些服务放到云管平台实现，哪些放到自动化实现？

@caikai  系统架构师  KYLERC：

不同企业由于各自业务属性/企业文化/流程/职能分工/历史遗留/高层重视程度/利益关系等各种各样的问题，导致对于云管的定位和具体应用场景差别很大，云管到底应该如何去做，不可一概而论，而要根据公司的实际情况具体分析。我这边提供一些思路，供大家参考选择。

首先，云管本质上，是一个服务提供平台。将业务部门会用到的IT设备或资源，通过标准化的服务目录，以服务的方式提供给出来。在异构资源与业务需求之间起到承上启下的作用（业务人员不懂基础架构，但是他需要申请，使用资源。所以需要提供业务人员看得懂的资源申请方式和内容，帮助他快速合理的进行资源申请，同时还要为具体运维人员进行资源交付时提供必要的信息）。

其次，用户可能会申请任何种类的资源，IT基础架构团队也会使用各种各样的技术和平台来保障架构的正常，稳定运行。所以就要求云管跟各种各样的设备或平台进行对接，以便实现统一管理，提供更多的服务和更高程度的自动化。

云管的价值就是提供了一套新的管理框架，一种新的服务交付理念和新的资源管理模式，然后不断对接平台和设备，保证能提供更多的能力，然后把能力输出为服务提供出来，满足业务，IT基础架构，管理人员，开发的不同诉求。

所以，云管的核心其实是: 搭建管理框架，对接平台，输出能力（单个能力，或能力编排），提供服务。

在这个过程中，完成标准制定，规范制定，加强资源和流程管控，解决传统条状+竖井状管理过程中面临的部分问题，更快更高校的完成日常工作。

再具体落地中：

1.做好云管的定位，明确价值和边界，获得领导支持。

2.做好规划，分阶段实施，稳步推进，小范围纳管。

3.先出效果，实现IT内部自动化及资源管理。

4.按场景提供功能，扩大用户范围，慢慢培养用户习惯。

问题1：云管平台与以上二者之间的关系是什么？

回答：传统的ITSM+线下手工交付存在很多问题，效率低，响应慢，信息不一致，管理不方便，体验不好。云管平台利用自助线上（服务目录）申请，线上审批，线上自动化交付，线上资源可视化管理的思路，可以有效解决这些问题。在云管这个管理框架中，天生具备服务管理，流程管理，自动化的能力。所以如果说关系，那就是包含关系。

问题2：资源发放的流程审批，在流程平台中实现，还是云管平台中实现？

回答：首先合格的云管肯定具备完善的流程定义功能。也可以对接OA，itsm等平台提供的审批功能（对接需要考虑的问题是，云管服务目录与OA或itsm申请单如何联动。云管发起流程，在OA或itsm中审批；还是在OA，itsm中发起+审批，云管只是自动化创建）。到底如何做取决于公司高层意愿以及OA，itsm在公司内部的实际应用范围和程度。这一块牵扯的利益太多，阻力会很大。

建议先从云管纳管资源（要确认纳管范围），梳理存量资源入手，企业IT资源通过这些年的发展肯定存在很多资源是否再用，责任人是谁，用的怎么样，等等的问题。先通过云管平台，把这些信息梳理清楚。这个是前期最能体现云管价值的地方。

然后给用户提供线上资源可视化查看或操作的功能。这样每个人名下有多少资源用户也比较清楚。

再通过云管提供部分资源申请类的功能和入口。

慢慢的改变用户习惯。

问题3：自动化变更，本质是调用API或脚本，云管平台和自动化平台都具备这一能力。哪些服务放到云管平台实现，哪些放到自动化实现？

回答：

1.长远看，云管必须要具备自动化+原子化（脚本，API或其他形式）编排+任务计划+多通道（ansible，saltstack，ssh，agent，terraform等）对接+堡垒机集成能力，才能适应复杂的企业内部IT环境，以及多云多混合异构基础设施的运维和管理诉求。

2.具体怎么做，要想好云管在公司内部的定位以价值。可以通过对接先有自动化平台完善云管的自动化能力，交由云管整合自动化，提供更多的场景功能。

@asdf-asdf  研究学者 cloudstone：

自动化和云管平台本身都是管理平台 ，一个定义业务交付，一个定义持续运维。

但目前情况是两个平台趋于整合，在vm时代运维和交付是一个事情。

@lewoli  系统架构师 Yunify.com：

业务交付慢慢会转向DevOps，PaaS平台，云管继续去管理运维，资源服务申请。两者的融合在之前通过脚本进行交付的阶段可以合一，但在基于DevOps的容器应用交付时，建议拆开。业务交付由应用团队负责，运维由系统运维团队负责。Kubernetes成为两者之间的分割界面。

@dawey  系统运维工程师 光大证券：

我们的做法是：资源审批、变更、创建放在云管平台，监控目前两边都有，后续计划是逐步归口到智能化运维平台（可能就是自动化平台），CMDB在智能化运维平台中，云平台数据通过kafka采集到CMDB。

@Steven99 软件架构设计师：

云管建设路径是向混合云，多云管理发展，跟自动化平台是两个概念。

云管也会涉及自动化流程，但云管重在云资源管理。

目前趋势是平台整合，但需要明确整合目标，然后寻找方法方案。

不要拘泥于技术实现细节，先搞清楚基本概念就容易理解，不会迷失于细节之中。

@邓毓  系统工程师 江西农信：

个人觉得云管平台不要做的太大，把什么运维流程、自动化、监控都放到云管里面去，没必要，在外围把这些平台和系统建设好后，云管平台集成即可，云管平台专注做资源的服务和全生命周期管理即可，不需要涉及过多无法很好胜任的角色，专业的产品做专业的事，而且尽量都“平台”化，像流程“平台”、监控“平台”、自动化运维“平台”，而不是放在云管平台中的小“系统”，以上是个人见解，我们实际也是这么做的。

@匿名：

个人的理解，ITIL关注的是流程，自动化平台更关注的是自动化运维和监控。运管平台侧重于资源的管理，包括资源纳管，治理和生命周期管理，在混合云中，还有一个多云管理的任务。目前大部分的IT都建立了ITIL和自动化运维的情况下，运管是作为自动化之上的管理平台，协同工作。ITIL只负责流程，按照不同的企业流程，在自动化运维和运管中插入控制点。

如果环境比较单一规模比较小，自动化平台和云平台合并，也不是不可以的。

您对这个问题怎么看？欢迎点击阅读原文到该话题讨论页面，分享您的观点

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场