【设想】如何打造一个高逼格的云运维平台？

前言

大家做运维普遍经历这样的过程：



首先我们会把操作做一个标准化，这个阶段是运维质量的提升的阶段。

在标准化实施完以后，由于数目的增加，或者是一些运维场景的增多，我们会逐步的进行一些工具化和自动化，这个阶段我们的运维的效率得到提升。

但是众多的工具以及自动化脚本，会让我们的管理过程中比较困难，随着人员的变动或者是一些工具维护过程中的差错，我们的自动化运维工具的受众群体不太稳定。

这个时候我们就需要一个平台将我们的运维工具以及运维过程中的一些经验进行沉淀，借助这个平台实现我们的智能化运维，于是我们从运维人员的需求和体验出发出发进行了一个运维平台产品化的构建。

银行卡组织云运维平台的概况

我给大家介绍一下我们IT体系建设的情况，差不多十年前我们以ITIL为基础构建了流程平台，变更、事件、问题、服务等流程通过这个平台进行流转。

在五年前我们从开放平台转化为云运维平台，在这个过程中，我也建立了IaaS虚拟化资源平台，同时我们也跟业界一样构建了CMDB，用于同意管理运维数据。

但是在运转下来以后，我们发现还有很多需求需要实现，主要三个方面：

软硬件节点数目不断增加，日常运维迫切需要一个适应各种运维场景的高效自动化平台，减少重复劳动。

需求是将运维人员的经验需要在一个平台沉淀，形成一个智能化场景库，将运维服务或能力的复用，从而提高整体运维质量和运维效率。

第三个需求是在传统的流程化运维的基础上，注入智能化场景，将运维工作从依靠人工判断、流程决策，逐步转为依靠机器智能分析判断。

所以基于这三方面需要，我们建设了一个云计算环境下面向规模化运维的平台。



云运维平台主要解决的是以下几个痛点:

互联网业务在我所在的公司开展特别快，还会有一些营销活动，这样就需要运维有一个快速的响应。

我们的硬件数目有了一个几何级的增长。

最近几年频繁的使用一些开源架构新兴技术，对运维技术增加了要求。

运维工具散乱，缺乏同同一管理。

我们运维数据没有一个同一的的展示

第六个是我们的人力增长目前比较缓慢，我们在审计过程中会有一些人工安全性方面的问题。



出于这些方面考虑，我们运维平台的愿景，是运维的质量以及可运维设备的数量不因我们的运维人员的数量或者是技能的变化改变，从而实现我们的运维的数量和质量都达到一个可控的。

银行卡组织的云运维平台是个怎样的产品

接下来给大家介绍一下我们运维平台这个产品，主要四个方面：



第一是资源统一调度，我们可以将资源整合，我们通过资源平台提供的API包括，包括Openstack、数据库管理平台、容器管理平台、分布式存储管理平台、网络管理平台、安全管理平台，将我们所常用的运维操作，都整合在我们这个运维平台中，将我们的运维流程尽量的简化，实现自助化运维。

第二，我们希望借助我们运维平台尽量实现自动化管理，减少我们手工操作，实现自动的数据收集、自动应用安装、自动配置和更新、自动数据分析、自动扩展、自动备份恢复、自动鼓掌处理等。

第三是多维为可视化，让各个角色有一个在平台上都有一个独立的视角，以角色重定义运维。如网络管理视图，系统管理视图、监控视图、报表视图等。统一报表系统，统一全局数据并提供可自定义多维报表。 最后一个就是实现高性能，我们希望我们这个运维平台可以满足万级节点的并发收集、执行。

云运维平台建设场景



这个是我们运维平台的场景规划图，下面是我们一个核心的调动模块。包括执行、采集以及和其他流程的对接，中间是我们这个运维平台主要要做的事情，我们把这个叫做运维OS，图表管理实现自动化拓扑和自定义报表，全生命周期管理是实现应用系统从上线到下线通过我们这个平台实现一个自动化的实施。

运行环境管理和运维工具给实际的运维人员提供一个比较便利的一个操作环境，包括备份比对，作业编排以及参数管理等，容量管理我们是希望通过我们这个平台将监控的数据进行一个汇总，实现对容量的管控。

高可用管理对我们各个应用系统，各个层面的组件的可用性进行一个统一的管理，可用性监控，自动化可用性演练。

重点场景一：生命周期管理



第一个是生命周期管理，我们周围在以前的一个部署过程中，通常是这样的，开发人员写一个是需求文档通过内部流程给运维接口人，他会协调各资源管理员分配资源，形成部署方案，最后将这个部署方案通过人工构建变更的方式实施。

这里面有两个问题，一是传递过程中可能偏差，第是周期比较长，我们希望借助我们的云运维平台实现参数级别的电子化传递，以及自动化的部署。也就是用户在我们平台上面选择需要的组件，以及资源需求，由我们的管理员分配、确认实际的部署资源。

最后由平台进行一个自动化的部署，并在部署过程中自动进行各项规范标准的实施。

重要场景二：运行环境管理



第二个场景是我们的运行环境管理，包括资源类的CPU、内存、IP、端口、访问关系等，以及我们运维人员关注的，定时任务、备份策略、自启动项目等。我们通过云运维平台对运行环境进行管理，替代原有excel表格，并进行自动化设置。

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



第三个场景是持续部署管理，传统部署方式我们会遇到一些问题，包括：应用版本通过版本服务器多次人工传递，各应用的配置、维护脚本没有统一标准;通过表格人工维护各环境的参数差异，不同环境人工修改参数;应用的安装过程视变更人员经验，异常告警没有统一标准，回退方式不统一等。

为此，我们做了一个持续发布的标准，而且将这些标准借助这个平台可以实施，包括：统一版本传递路线，版本标准化;构建生产、测试、研发环境配置差异库，平台根据所在环境自动生存对应参数;标准化应用部署过程，多节点安装顺序自由编排，按照编排顺序进行安装;标准异常告警;故障时按照编排顺序逆向回退。

重要场景四：运行环境维护



第四个场景是是常用运维工具集成，包括我们常用的应用重启、健康检查、隔离、恢复工具，服务器的一些物理测试，以及自动装机后自动接入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，处理完成后返回消息，从而实现多任务的并发异步执行。

数据可视化



我们在数据可视化方面，我们通过采集器采集信息，通过同步器同步其它平台信息，存储在核心数据库，通过阈值库产生进行对比告警，通过分析函数库进行性能分析，并产生一些我们运维需要的报表进行可视化管理。

银行卡组织云运维平台成果展示

我们平台的建设结果，我们这个平台上面已经完全建设的一些部分，另外有一些功能我们在开发，这个是我们在实际中已经上线的平台，大概有几千太的虚拟服务器，我们首先看到这个信息中心里面有一个机房，我们看到一些机柜，并且配置好每一个机柜里面对应的哪些服务器。









这个交换机/F5-物理服务器-虚拟服务器自动拓扑的页面，是我们根据snmp抓取交换机、F5信息，通过anbible抓取物理机的信息，通过openstack抓取虚拟机的信息，根据上述消息自动生成拓扑。




 



数据同步可以自定义定时抓数据。



这是一个实际的备份管理的功能，我们可以用我们的这个平台选取相应的服务器，通过平台自助定时、即时备份。



自助化启动项管理。



自助化定时任务管理。

如何打造一个以应用为核心的运维体系

在前面《有了CMDB，为什么还要应用配置管理》一文中，描述了CMDB和应用配置管理的关系，这里面提到了非常核心的一个概念：应用，。但是，上篇中更多的是从运维的角度看待这两个概念，不过从根源本质上，这个应该是分布式架构中的核心概念才对，只不过是我们在运维过程中整天要面对它，管理它，所以貌似感觉好像这个概念只跟运维相关一样，其实不然，本文详细描述下。

关于服务化

在讲发布系统《XXOps实践：持续发布和部署》的时候提及过，随着业务体量和业务复杂度的上升，单体工程因为紧耦合的原因，会慢慢地无法满足快速迭代的要求，特别是开发人员增加到一定规模的时候，代码的开发和维护变得非常头疼，这个时候必然要对单体工程进行拆分，也就是我们常说的服务化拆分的过程。

以Java为例，我们根据业务模型拆分出不同职责的模块或工程（可独立运行的一套代码），叫做一个应用，在应用里我们会设计很多类出来，其中对外提供业务功能逻辑的类，我们通常定义为服务，也就是我们常见到的xxxxService，这个Service里面我们又可以提供很多的具体调用方法出来，我们叫做API或者Method。大致的逻辑可以用下图表示：



比如电商里面的商品Item，最典型的就会有SKU、Detail、Snapshot、Tag等等的服务，以SKU为例，我们定义为SKUService，做过服务设计和开发的同学肯定都很清楚，接下来我们就要为SKUService提供各种get、list、query、update等方法，有时候为了提供统一的查询或写服务，可能还会专门设计出SKUReadSevice提供统一的各种的query方法。

以应用为核心的运维体系建设

这里面Item就是一个应用的定义，所以我们可以从这里看到，从源头上讲，应用这个标示是在引入服务化，进行架构拆分的时候就应该定义下来的。

但从我个人实际观察到的情况看，大部分的公司在这块的统筹设计上是不够的，我经常看到的场景是，RPC的服务注册或配置中心上，有自己的一套应用名标示，开发要独立去填写；做发布系统的时候，又单独搞出一套应用标示，开发又要填一遍；同理，做监控的时候，监控自己也整一套，到了运维这里，为了维护资源的分配，为了应用跟资源的对应关系，搞不好也会有一套。有时候为了保持各个系统能够很好的协作，又得搞出一个映射关系来，比如运维的应用标示跟监控的应用标示做个对应，或者跟服务化的应用标示做个对应，但是这样做就很难形成统一的体系。所以，我看到的很多平台就都会变成一个个的孤岛，无法成为体系。

所以，在这块的建设上，必须在服务化阶段就得明确应用标示的统一，后续的资源分配、发布、监控、稳定性体系等等，都以此标示为准。这块我们CMDB的文章中已经提到了基于应用为核心，如何去建立CMDB和应用配置的模型，下面直接上图，说明从运维的角度如何去建立应用服务和稳定性体系的模型。



对于服务化的应用：

1、首先是应用，这个要根据产品业务场景去设计。然后拆分出对应的服务，也就是Service这一层，服务里面再设计出对外暴露的方法。这个过程，主要是业务技术架构师和开发Owner要去做。但是应用的标准，要么架构师一开始就能够全局确认下来，否则，运维就必须参与进去跟开发一起明确指定下来。

所以这里的路径就是，应用—服务Service—方法Method

2、基于应用，有了CMDB、应用配置，以及服务的管理，就可以去完成类似于持续集成和发布、自动化扩缩容这些动作了，具体可以结合《XXOps实践：持续发布和部署》

3、有了应用服务管理，接下来可以做的另外一件事情，就是稳定性体系的建设，比如全链路跟踪、容量评估、开关、限流、降级等等。这块后面专门整几篇文章出来。这里特别要说明的一点，所有上面提到的这些技术手段，准确的讲，都应该要加几个定语，就是基于应用的xxxx，或者基于服务的xxx。比如，降级策略，就以Cache故障，自动降级到DB为例，最终这降级策略是要通过配置的方式，下发到应用或服务层面来执行的，具体可以看下上述图示。

最后，有了这样一套基于应用的模型之后，就可以通过应用把这些管理环节给集成起来，放在统一的门户里提供出来，至此，应用为核心的运维体系雏形就有了。简单的示例：



关于微服务和服务化，多说两句：

前两天跟公司一个开发Leader还在探讨是否有必要拆分微服务的问题，这里也分享一下，服务化和微服务的的争议主要是个粒度问题，我们在设计时到底是把应用拆分成粗粒度的一组服务形成一个应用，比如上面提到的Item商品，形成一个单独应用，还是将更细粒度的Service独立成一个个的应用，比如上面提到的Item里面的SKUService这个服务，还是再微服务化一点，甚至可以SKU这个服务里面的读写服务，SKUReadSevrvice和SKUWriteService分别独立出来分别独立出来作为一个应用。

这个说实话没有什么严格标准，横着切也好，竖着切也罢，粒度大也好，粒度小也好，关键还是看这个应用和服务的Owner怎么来把握，或者团队有统一的架构师来定义标准。



不过，个人观点，对于微服务还是持一点保守态度，不要做过细粒度的拆分，也并不是越细越好，这里面有个度的问题。粒度过细就会有大量的应用独立出来，应用之间又会有相互调用，应用的管理和调用链管理就变的异常的复杂，最终意味着管理成本就会非常高。这个时候是需要有非常完善的运维体系来保障的，比如持续集成和发布、全链路保障、容量和性能评估手段等等，而这些保障体系说实话有一定的技术门槛，也需要一定的技术和人才积累，需要有一个迭代的周期来完善，这必然是一个逐步演进的过程，所以这些配套手段跟不上的情况下，过度的微服务化是没有意义的。
【参考文章】

1、如何打造一个以应用为核心的运维体系 – 运维派 http://www.yunweipai.com/archives/21888.html
2、如何打造一个高逼格的云运维平台？-IT运维 -火龙果软件工程 http://www.uml.org.cn/itil/2016120205.asp