作者陆一丁，中国银行卡组织运维架构师。主要的。前言大家在做运维的时候一般都会经历这样一个过程：首先，我们会规范操作。这个阶段是提升运维质量的阶段。标准化实施之后，由于数量的增加，或者一些运维场景的增加，我们会逐步进行一些工具化和自动化，现阶段我们的运维效率会有所提升。但是，很多工具和自动化脚本会让我们的管理过程变得更加困难。随着人员的变动或者一些工具在维护过程中的失误，我们自动化运维工具的受众并不稳定。这时候我们就需要一个平台来积累我们的运维工具和一些运维过程中的经验，并利用这个平台来实现我们的智能运维，所以我们从运维人员的需求和经验出发开展运维平台产品化建设。银行卡机构云运维平台概述下面给大家介绍一下我们IT系统的建设。大约十年前，我们构建了一个基于ITIL的流程平台。变更、事件、问题、服务和其他流程流经该平台。五年前，我们从开放平台转型为云运维平台。在这个过程中，我还建立了一个IaaS虚拟化资源平台。同时我们也像业界一样搭建了CMDB来统一管理运维数据。但是运行之后发现还有很多需求需要实现，主要是三个方面：软硬件??节点数量不断增加，日常运维急需一个高效的自动化平台来适应丰富的运维场景，减少重复劳动。需求是在一个平台上积累运维人员的经验，形成智能场景库，对运维服务或能力进行复用，从而提高运维的整体质量和效率。三是在传统的流程??化运维基础上注入智能化场景，逐步将运维工作从依赖人工判断和流程决策转向依赖机器智能分析判断。因此，基于这三个需求，我们构建了一个在云计算环境下进行大规模运维的平台。云运维平台主要解决以下痛点：互联网业务在我公司开展很快，会有一些营销活动，需要运维快速响应。我们的硬件数量呈指数级增长。近年来，开源架构的一些新兴技术被频繁使用，对运维技术提出了更高的要求。运维工具分散，缺乏统一管理。我们的运维数据没有统一的展示。第六是我们的人力增长目前比较缓慢，在审计过程中会出现一些劳动保障问题。基于这些考虑，我们运维平台的愿景是，运维的质量和可运维的设备数量不会因为我们运维人员的数量或技能的变化而改变，从而实现我们运维的数量和质量。质量达到可控水平。银行卡机构云运维平台是一款怎样的产品？接下来介绍一下我们的运维平台产品，主要包括四个方面：第一是资源的统一调度。我们可以整合资源。包括，包括Openstack，数据库管理平台，容器管理平台，分布式存储管理平台，网络管理平台，安全管理平台，把我们常用的运维操作集成到我们的运维平台中，把我们的运维集成到尽可能简化维护流程，实现自助运维。第二，我们希望通过我们的运维平台，尽可能实现自动化管理，减少我们的人工操作，实现数据自动采集、应用自动安装、自动配置更新、数据自动分析、自动扩容、自动备份和恢复、自动掌声处理等。三是多维度可视化，让每个角色对平台都有独立的视角，以角色重新定义运维。如网络管理视图、系统管理视图、监控视图、报表视图等。统一报表系统，统一全局数据，提供可定制的多维度报表。最后一个是实现高性能。我们希望我们的运维平台能够满足上万节点的并发采集和执行。云运维平台搭建场景这是我们运维平台的场景规划图，下面是我们的核心动员模块之一。包括执行、收集以及与其他进程的连接。中间部分是我们运维平台主要要做的事情。我们称之为运维OS。图表管理实现自动拓扑和自定义报表，全生命周期管理是通过我们的平台实现应用系统从线上到线下的自动化实现。运行环境管理和运维工具，为实际运维人员提供更方便的运行环境，包括备份对比、作业安排、参数管理等。对于容量管理，我们希望通过我们的平台汇总监控的数据，控制容量。高可用管理对我们各层级的各种应用系统和组件的可用性进行统一管理、可用性监控和自动化可用性演练。关键场景一：生命周期管理首先是生命周期管理。在之前我们身边的部署过程中，一般都是这样的。开发人员写好需求文档，通过内部流程发送给运维联系人，由他协调各资源管理员分配资源，形成部署方案，最后通过人工构建和变更实施部署方案。这里有两个问题。一是传输过程中可能会出现偏差，二是周期比较长。我们希望通过我们的云运维平台，实现参数层级的电子化传输和自动化部署。即用户在我们的平台上选择需要的组件和资源需求，我们的管理员分配和确认实际部署的资源。最后，平台进行自动化部署，在部署过程中自动执行各种规范和标准。重要场景??二：运行环境管理第二个场景是我们的运行环境管理，包括资源CPU、内存、IP、端口、访问关系等，还有我们运维人员关心的问题，比如定时任务、备份策略、自启动项目等。我们通过云运维平台管理运行环境，替换原有的excel表格，进行自动化设置。重要场景??3：持续部署管理第三个场景是持续部署管理。我们在传统的部署方式中会遇到一些问题，包括：应用版本通过版本服务器多次手动传输，每个应用的配置和维护脚本没有统一的标准；表手动维护各环境参数差异，不同环境手动修改参数；应用的安装过程取决于换机者的经验，异常告警没有统一标准，回滚方式也不统一。为此，我们做了一个持续发布的标准，这些标准可以借助这个平台来实现，包括：统一的版本发布路线，版本标准化；构建生产、测试??、研发环境配置差异库，平台根据环境自动生存响应。参数;标准化应用部署流程，自由安排多节点安装顺序，按安排顺序安装；标准异常报警；失败时按排列顺序反向回退。重要场景??四：运行环境维护第四个场景是常用运维工具的集成，包括我们常用的应用重启，健康检查，隔离，恢复工具，服务器的一些物理测试，自动接入OpenStack或者我们集成这些工具进入我们的云运维平台，用于其他资源管理平台的自动对接，网络设备的健康检查，以及一些定期的安全检查。重要场景??五：画像场景第五个场景是我们的应用程序作为一个维度的应用程序画像。通常，我们的一个应用程序可能有很多元素。每个人都很难知道这些要素。例如，这个应用程序的架构是什么？可能只有一些应用开发者和设计者，或者一些骨干心里知道，不一定特别准确。服务器上可能有很多应用程序参数需要检查。应用版本、参数变更、维护记录等需要查改，应用各层级容量需要专业部门核查。申请情况一般很难说清楚，需要费一番功夫才能知道到底是什么样的。在云运维平台中，借助我们前面提到的各种产品管理工具，容量管理和高可用管理，我们将它们放在一个视图镜像中，根据历史、应用容量、高可用信息进行维护。变化，也可以计算这个应用运维的成熟度。云运维平台技术方案在硬件资产层面，我们使用snmp等工具来获取状态和操作。在虚拟资源层面，我们目前使用openstack等管理平台提供的接口进行管理。在操作系统上，我们使用自主研发的核心调度系统管理linux和应用。我们整个平台是一个使用权的部署。除了下面的缓存和MySQL，其他组件全部部署在全容器中。前端使用apache、haproxy、keepalived；后端使用jboss、rabbitmq、ansible、zookeeper；数据存储采用mysql、redis、ceph等；此外，我们还有一个安全服务模块，用于检查是否会有一些高危操作。业务流程技术上图是我们具体的业务流程。左边是我们云运维平台的界面。一个运维请求会被封装成一个消息，放入消息队列中。schedule模块收到消息后，会按照调度算法，自动分配给ansible节点，ansible节点通过ssh在服务器上执行，并将执行结果异步返回给消息队列。schedule的调度算法和ansible分布式架构schedule的调度算法是我们考虑到我们的生产环境有很多partition，我们会根据region的IP自动生成一个tag。schedule找到这些消息后，它会针对Splityourtag和targetmachinedata。我们将其详细拆分为几条消息，ansible订阅处理自己的消息。我们在ansible上进行改造。所有任务都有唯一的id，处理完成后返回消息，实现多个任务的并发异步执行。数据可视化在数据可视化方面，我们通过collector收集信息，通过synchronizer同步其他平台信息，存入核心数据库，通过阈值库生成对比告警，通过分析函数库进行性能分析，生成一些我们的操作和维护信息。所需报告的可视化管理。银行卡组织云运维平台成果展示了我们平台的建设成果。我们平台的一些部分已经完全构建，我们正在开发一些其他功能。这是我们实际推出的一个平台。大概有几千个我们首先看到这个信息中心有一个机房，我们看到一些机柜，配置每个机柜对应哪些服务器。这个switch/F5-physicalserver-virtualserver自动拓扑页面是我们这里根据snmp抓取交换机和F5信息，通过anbible抓取物理机信息，通过openstack抓取虚拟机信息，自动生成拓扑图以上消息。数据同步可以自定义定时抓取数据。这是一个实际的备份管理功能，我们可以使用我们的平台选择相应的服务器，通过平台进行自定时即时备份。自助启动项管理。自助定时任务管理。
