如何打造一款高逼格的运维平台（详解二）

重要场景三：持续部署管理

第三个场景是持续部署管理，传统部署方式我们会遇到一些问题，包括：应用版本通过版本服务器多次人工传递，各应用的配置、维护脚本没有统一标准;通过表格人工维护各环境的参数差异，不同环境人工修改参数;应用的安装过程视变更人员经验，异常告警没有统一标准，回退方式不统一等。
为此，我们做了一个持续发布的标准，而且将这些标准借助这个平台可以实施，包括：统一版本传递路线，版本标准化;构建生产、测试、研发环境配置差异库，平台根据所在环境自动生存对应参数;标准化应用部署过程，多节点安装顺序自由编排，按照编排顺序进行安装;标准异常告警;故障时按照编排顺序逆向回退。
重要场景四：运行环境维护

第四个场景是是常用运维工具集成，包括我们常用的应用重启、健康检查、隔离、恢复工具，服务器的一些物理测试，以及自动装机后自动接入OpenStack或者是其它资源管理平台的自动对接，网络设备的健康检查，还有一些定期的安全检查，我们把这些工具集成在我们的云运维平台上。
重要场景五：画像场景

第五个场景是我们应用为维度的应用画像，通常我们一个应用可能有很多的元素，大家想知道这些元素会比较困难，例如这个应用的架构是什么样的，可能只有在一些应用的开发设计人员，或者是一些骨干的心中才能知道，也不一定特别的准确。
应用的参数可能有很多要到服务器查。应用版本、参数变迁、维护记录需要翻变更，应用各个层面的容量情况需要找各专业室查。应用的情况普遍说不清，要废很大的力气才知道是什么样。
我们在云运维平台里面，借助我们之前提到的各种产品管理工具，容量管理和高可用管理，我们放在一个视图的画像里面，根据变迁维护历史以及应用的容量、高可用信息，还可以计算出这个应用他的运维方面的成熟度。
云运维平台技术方案
在硬件资产层面我们通过一些snmp等工具获取状态及操作，虚拟资源层面我们目前借助openstack及其它管理平台提供的接口进行管理，操作系统之上我们通过自主开发的核心调度系统对linux及应用进行管理。

我们整个平台是使用权的一个部署，除了下面的缓存和MySQL其他所有的组件都是全容器的部署，前端使用apache、haproxy、keepalived;后端使用jboss、rabbitmq、ansible、zookeeper;数据存储采用mysql、redis、ceph等;另外我们还有一个安全服务模块，检查是否会有一些高危操作。