| 某银行卡组织十年前以ITIL（Information Technology Infrastructure Library，信息技术基础架构库）为基础构建了流程平台，变更、事件、问题、服务等流程通过这个平台进行流转。在五年前从开放平台转化为云运维平台，在这个过程中，建立了IaaS（Infrastructure as a Service，设施即服务）虚拟化资源平台，同时他们也跟业界一样构建了CMDB（Configuration Management Database，配置管理数据库），用于统一管理运维数据。但是在运转一段时间以后，发现还有很多需求要实现，主要体现在以下3个方面。
|
|
|
| （1）软硬件节点数目不断增加，日常运维迫切需要一个适应各种运维场景的高效自动化平台，减少重复劳动。
|
|
|
| （2）运维人员的经验需要在一个平台沉淀，形成一个智能化场景库，将运维服务或能力复用，从而提高整体的运维质量和运维效率。
|
|
|
| （3）在传统流程化运维的基础上，注入智能化场景，将运维工作从依靠人工判断、流程决策，逐步转为依靠机器智能分析判断。
|
|
|
| 所以基于这三方面需要，建设了一个云计算环境下面向规模化运维的平台，如下图所示。
|
|
|
|
|
|
|
|
|
| 互联网业务在公司发展特别快，还会有一些营销活动，需要运维能够快速地响应。
|
|
|
|
|
| 最近几年频繁使用一些开源架构和新兴技术，对运维技术增加了要求。
|
|
|
|
|
|
|
|
|
| 出于这些方面考虑，运维平台的愿景（如下图所示）是运维的质量以及可运维设备的数量不因运维人员的数量或者是技能的变化改变，从而实现运维的数量和质量都可控的目的。
|
|
|
|
|
|
|
| 这个运维平台产品（如下图所示），主要有4方面功能。
|
|
|
|
|
|
|
| 第一，是资源统一调度，可以将资源整合，通过资源平台提供的API包括，包括Openstack、数据库管理平台、容器管理平台、分布式存储管理平台、网络管理平台、安全管理平台，将常用的运维操作，都整合在这个运维平台中，将运维流程尽量的简化，实现自助化运维。
|
|
|
| 第二，借助运维平台实现自动化管理，减少手工操作，实现数据的自动收集、自动应用安装、自动配置和更新、自动数据分析、自动扩展、自动备份恢复、自动故障处理等。
|
|
|
| 第三，多维可视化，让各个角色在平台上都有一个独立的视角，以角色重定义运维。如网络管理视图，系统管理视图、监控视图、报表视图等。统一报表系统，统一全局数据并提供可自定义多维报表。
|
|
|
| 最后一点就是实现高性能，希望这个运维平台可以满足万级节点的并发收集、执行。
|
|
|
| 云运维平台场景规划如下图所示。下面是一个核心的调动模块。包括执行、采集以及和其他流程的对接，中间是运维平台主要要做的事情，叫做运维OS，全生命周期管理使得应用系统从上线到下线都可以通过这个平台自动实施。
|
|
|
|
|
|
|
| 运行环境管理和运维工具给实际的运维人员提供一个比较便利的操作环境，包括备份比对，作业编排以及参数管理等。
|
|
|
|
|
| （1）生命周期管理。在以前的部署过程中，通常是这样的，开发人员写一个是需求文档通过内部流程给运维接口人员，由他来协调各资源管理员分配资源，形成部署方案，最后将这个部署方案通过人工构建变更的方式实施。这里面存在两个问题，一是传递过程中可能有偏差，第二是传递周期比较长。借助云运维平台实现参数级别的电子化传递，以及自动化的部署。也就是用户在平台上面选择需要的组件，以及资源需求，由管理员分配、确认实际的部署资源。最后由平台进行一个自动化的部署，并在部署过程中自动进行各项规范标准的实施。这样可以大大减少偏差，提高效率。
|
|
|
| （2）运行环境管理。包括资源类的CPU、内存、IP、端口、访问关系等，以及运维人员关注的定时任务、备份策略、自启动项目等。通过云运维平台对运行环境进行管理，替代原有Excel表格，并进行自动化设置。
|
|
|
| （3）持续部署管理。传统部署方式会遇到一些问题，包括：应用版本通过版本服务器多次人工传递，各应用的配置、维护脚本没有统一标准；通过表格人工维护各环境的参数差异，不同环境人工修改参数；安装过程的异常告警没有统一标准，回退方式不统一等。为此，做了一个持续发布的标准，而且将这些标准借助这个平台实施，包括：统一版本传递路线，版本标准化；构建生产、测试、研发环境配置差异库，平台根据所在环境自动生成对应参数；标准化应用部署过程，多节点安装顺序自由编排，按照编排顺序进行安装；标准异常告警；故障时按照编排顺序逆向回退。
|
|
|
| （4）运维工具集成。包括常用的应用重启、健康检查、隔离、恢复工具、服务器的一些物理测试，以及自动装机后自动接入OpenStack或者是其他资源管理平台的自动对接，网络设备的健康检查，还有一些定期的安全检查，把这些工具集成在云运维平台上。
|
|
|
| 云运维平台技术方案。在硬件资产层面通过SNMP类工具获取状态及操作，虚拟资源层面借助OpenStack及其他管理平台提供的接口进行管理，操作系统之上通过自主开发的核心调度系统对Linux及应用进行管理。
|
|
|
| 整个平台是使用权的一个部署，除了下面的缓存和MySQL其他所有的组件都是全容器的部署，前端使用Apache、Haproxy、Keepalived；后端使用Jboss、Rabbitmq、Ansible、ZooKeeper；数据存储采用MySQL、Redis、Ceph等；另外还有一个安全服务模块，用于检查是否会有一些高危操作。
|
|
|
| 下图表现了一个具体的业务流程，左边是这个云运维平台的界面，一个运维请求会被封装为一个消息会放到消息队列里面，Schedule模块接收到消息后按照调度算法，自动分配给Ansible节点，Ansible节点通过SSH到服务器上执行，并将执行结果异步返回给消息队列。
|
|
|
|
|
|
|
| Schedule的调度算法与Ansible分布式架构。schedule的调度算法考虑到生产环境存在很多的分区，会根据请求者的IP自动生成一个所属区域的Tag，Schedule在发现这些消息以后，会针对Tag以及目标机器数据进行拆分，把这个消息详细拆分为几个消息，Ansible去订阅处理自己的消息。在Ansible上进行一个改造，所有任务均有唯一的id，处理完成后返回消息，从而实现多任务的并发异步执行。
|
|
|
| 数据可视化。在数据可视化方面，通过采集器采集信息，通过同步器同步其他平台信息，存储在核心数据库，通过阈值库产生对比告警，通过分析函数库进行性能分析，并产生一些运维需要的报表进行可视化管理。
|
|
|
