一个可供借鉴的中小企业运维管理平台架构样本

本文根据战学超老师在〖Gdevops 2017全球敏捷运维峰会北京站〗现场演讲内容整理而成。

（点击底部“阅读原文”获取战学超演讲完整PPT）

作者介绍

战学超，青岛航空运维经理、高级架构师。曾任职于NEC软件、海尔B2B平台巨商汇，负责企业数据平台构建、B2B电商平台数据管理与搭建、企业运维管理平台搭建。拥有丰富DBA、系统运维架构经验，熟悉运维管理、数据库架构、数据平台搭建、虚拟化、私有云部署、自动化运维等。

我今天要跟大家分享的主题是《中小企业运维管理平台架构》，这是结合我们青岛航空在做运维管理和运营管理平台时的一些经验和问题，希望能够对大家有一定的帮助。

分享大纲：

1. 运维管理思路

2. 运维管理平台架构

3. 未来展望

一、运维管理思路

在运维的初期，我们更多的是一个救火队长的角色，每天数不尽的更新发布和问题修改，运维人员每天的工作都很饱和，压力也很大，是一个比较疲惫的过程。后面我们经过了一个梳理运维流程和整理的步骤，逐渐实现了运维的标准化和流程化，结束运维初期相对混乱的状态。

在做运维标准化流程化的过程中，最初也会利用脚本或者代码、工具来实现运维自动化的工作，大大减少运维的重复性工作，提高运维的效率；也会结合我们在运维标准化、流程化、自动化中积攒的一些数据，结合自身运维的经验和一些机器学习算法，去完成一些智能化相关的工作。

运维的三大主题是监控、安全和灾备，这是围绕运维的基础数据来做的，以保证运维基础数据的稳定。运维周期是从需求开发调研开始的，从开发到测试到上线，这中间借鉴了一些DevOps的思想，也包含了运维人员、测试人员共同维护我们的业务系统，保证业务系统的稳定。

我们做运维管理的时候，始终坚持安全、稳定和高效三个原则，抛弃了这三个原则，之前所做的不管是标准化、流程化，都将为零。通过做运维管理，我们的目的是提高运维质量，降低运维成本。以上就是做运维管理的思路。

二、运维管理平台架构

下面我将从总体架构、标准化、流程化、基础数据、监控管理体系、安全、灾备管理体系、自动化以及其它一些方面进行简单分享。

1、总体架构

从下往上，我们首先通过虚拟化、容器化实现了相对基础的类IaaS平台，这样在做上层运维工作时，可以相对少地去关注底层资源。接下来是基础数据的梳理，基础数据决定了运维的工作对象和范围，上层所运作的所有的工作都紧紧围绕运维基础数据来的。我们在梳理和整理基础运维数据的时候，顺便完成了运维的标准化和流程化的制定以及实施落地。

基础数据之上是监控、安全和灾备三个管理体系，围绕基础数据对运维的基础数据提供保驾护航。再上面是运维自动化，通过运维自动化将固化的运维工作和流程做了一些自动化的开发，减少了运维重复性的工作，提高了运维效率。随着运维自动化的发展演变出了一定的问题，例如自动化脚本越来越多、越来越难管理，我们用的自动化工序也非常多，这时急需一个统一的运维管理平台，帮助去对去做统一的管理，这是我们运维管理平台的情况。

我们的运维管理平台主要是包含用户管理、项目管理、数据中心和创新管理这一块的功能。其中运维管理是以项目为基本单位的，所以说下边做的这种运维自动化和运维标准化的东西是都涵盖项目管理的。数据中心主要跟基础数据做一些紧密的结合，为我们做智能化运维提供基础数据的支持。创新管理这块其实主要是想通过创新性的管理来不断的推进内部的运维技术进步，不断去尝试一些相对比较新、比较高效的技术。这是我们的实际工作情况。

2、标准化与流程化

标准化和流程化主要是通过文档的方式梳理以往的一些工作，进行一些文档性的整理，包括数据中心的建设。对于数据中心，我们是有自建的机房的，包括搬迁新机场后的新机房建设(青岛19年胶东新机场建立完成，航空公司要进行搬迁)，新机房建设是围绕国家标准和地方性的标准来进行建立和建设的。然后硬件设备采购和上下架，这些是硬件相关的东西。

接下来是一个故障排故流程和运维通告，这个帮助运维出现运维故障时，提供一个解决的方式和通报流程。

上面两行是服务器的申请、服务器的部署（包括配置变更等），还有权限管理。运维服务的申请到运维服务的部署，包括应用的部署等主要是通过这样一些文档和流程来规范我们日常的运维工作。标准统一了，我们做运维时就相对容易很多。

3、基础数据管理

• CMDB

这里分为几大部分。首先是CMDB，这个跟传统的ITIL有一些不同的地方，我们的CMDB以产品线为主线，每个产品线下包含很多项目，而每个项目里也有很多的服务，每个服务会有不同的应用在上面跑。这些服务，或者说这些应用，都跑在我们的虚拟机或者容器上，而这些虚拟机和容器又分布在不同的物理机上，到了物理机这一层也就到了资产管理这块。

资产管理这块主要是我们的一些硬件，包括网络设备和物理机等。通过产品线和生产管理，把日常运维的一些对象去做定义，另外我们也把项目和项目之间的依赖关系，包括物理硬件之间的依赖关系都做了统一的梳理，这样的话，当某一个节点出现问题时，对它所带来的影响会有一个比较全面的认识。

供应商环节，因为我们属于民航业，有一些供应商涉及得比较多，所以把供应商单独拿出来做管理，主要是供应商的一些信息和合同。这样做的好处便是，当问题比较难以解决时，通过统一的供应商管理，可以快速查到对应的供应商信息。

• 重要数据和日志

重要数据主要是针对我们的数据库的数据。日志也不用多说，是很重要的信息，包括系统日志应用日志、数据库日志、设备日志包括硬件设备的日志，目前我们在逐步完善硬件设备的日志，因为它要对接很多不同的协议，相对复杂。

• 知识库

知识库主要是事件库和问题库，事件库记录了日常所做的运维事件，当运维事件短时间内无法解决，需要通过开发做一些变更时，我们便将这个事件升级为问题，并通过问题库来跟踪运维事件变更所带来的具体进展情况。经典案例库和解决方案库主要是对于运维遇到的一些经典问题的解决方法，包括系统的经典的部署方法、解决方案等，我们都做了一些统一的记录或存储，当有新的系统要部署时，也是可以通过这样查阅解决方案以及经典案例，快速得到部署的方法。文档库主要是存储了我们在标准化和流程化时做的一些文档，去做一些存储，其中也有一些版本是管理相关的东西。这是运维的基础数据。

接下来是安全、灾备、管理三个主题讲一下。

4、监控管理体系

首先是监控。监控的目标是通过内外部的多套监控去实现一个相对立体化的监控体系，根据系统的优先级将所有的系统和我们的硬件去做一个监控。另外就是监控的维度，首先第一个维度是覆盖所有系统和软硬件；其次是监控维度，包括应用系统可用性，数据库运行状态，网络状况等；第三个维度是全部时间，主要是我们会对监控的历史数据做一个存储，包括过去一些系统或者是服务器信息的状态和当前的状态。这里其实也是为我们做智能化运维提供了一些历史性的数据。

下面列举一下我们当前监控的一个情况。首先是机房和硬件的监控，机房监控我们主要依赖在机房建立初期供应商提供的机房环境监控系统进行监控。硬件监控的话，我们采购不同的硬件都有各自的监控方式，我们也做一些整合和整理，争取形成统一的硬件监控。虚拟机和容器监控主要是监控虚拟机或容器的状态和可能性等。网络监控主要是用以监控网络运行状态。这里也会有系统、数据库以及一些应用和业务的监控。监控用到的工具主要是一些开源的工具，其中Lepus是监控数据库，Zabbix监控我们的操作系统等，我们也会根据实际情况去开发我们自己的监控脚本。通过多种监控方式和工具多维度监控我们的运维对象，这是监控体系的情况。

5、安全、灾备管理体系

安全和灾备是比较难以分割的两个主题，我们的灾备方案也是为了系统或数据安全不丢失。

• 灾备管理

大概的思路，首先是两地三中心+云这样的经典方式，搭建同城的实时同步，异地延迟同步的方式作为我们灾备方案的主体，当然我们也将一些数据不太敏感的资源、备份数据逐渐放到云上进行备份。

灾备管理的手段主要是高可用+备份，对每一个系统和物理硬件都做一些高可用的方案，去避免单点故障。另外在做高可用的同时也建立备份机制，包括数据备份、文件备份、底层虚拟机和容器备份等，这样既有高可用也有备份，最大强度保证了系统的可用性。

此外，这个备份也要有一套独立的备份方案验证模块，是为了验证我们之前所做的这些备份的可用性和准确性。因为如果没有定时验证备份是否可用的话，当真出现故障时，我们可能不太敢直接把这种备份用到生产上去。

最后还有一个应急预案管理，这个主要是缓解一些灾难性故障时的应急措施，这样做的好处就是当出现重大问题，且短时间难以恢复，包括备份不太可用时，我们会按照应急预案进行处理。应急预案也会有定期演练的过程，以此保证应急预案和实际情况的结合。

• 安全管理体系

安全管理是一个比较大的主题，这里简单说一下我们的体系思路。首先是安全依据，主要有法律法规、行业背景和公司需求，包括《网络安全法》，民航也有自身的网络安全管理体系。根据这些依据去制定安全策略，同时依赖于安全技术帮我们做一些安全操作，这样可通过安全策略、安全管理、安全技术、安全操作来保证我们的安全性。具体落地方面，我们主要有防火墙、IPS、WAF等安全设备。

着重介绍一下我们的UMS账户管理模块，很多系统是公司内部人员使用的，比如当人员离职时，首先在OA体现出来，如果管理人没有及时关注这个人员，极有可能他离职了，这个账户还存在的。但通过UMS这个模块跟OA系统打通，人员离职时对他业务系统的帐号做及时的清理，保证了账号随同人员离职一起销毁，避免数据泄露的。

6、运维自动化

首先是关于服务器的申请、操作系统的安装、服务申请，然后服务自动部署等。接着去做一些发布，发布的申请、变更的申请等，这些都是大家在做运维自动化的时候几乎都会去做或是实现的工作。除此之外，这里着重跟大家介绍一下我们的一个关于资源申请评估指导和资源利用报告的情况。

我们的资源申请评估指导主要结合了自身经验，根据系统的行业请求和系统情况来以及压力测试的结果参考等制定了一个相对比较科学的资源申请情况。当有一个新的需求要去申请我们资源时，我们会根据资源申请评估指导里面的算法，预估出他的系统变化量，自动计算出一个比较科学的硬件资源。资源利用报告呢，是我们定期对所有的服务器（包括虚拟机）所做的一个资源利用的情况，这样根据我们的资源利用报告去做一些服务器的资源性变化和处理，确保我们的硬件资源是最大的利用率。

另外，我们做运维自动化时，也包括了我们架构的自动诊断、压力测试、自动巡检和故障自动诊断等功能。

说一下架构自动诊断，不知道大家有没有这样的情况，公司里经常遇到上线比较着急的一些系统，但是上线运营一段时间以后，跟开发人员一沟通，发现这是很重要的系统，可当时上线比较匆忙没有做任何高可用方案，如果没有及时沟通，很可能这个重要的系统一直在单节点运行。为了规避这种情况，我们的架构自动诊断是通过开发人员可能在申请新的系统上线时，会做系统等级的填写，这个架构自动诊断会根据系统的等级，结合系统线上的情况，如果缺少备份和只是单节点，它会自动提醒，让我们的运维人员及时搭建架构，避免重要系统的单点故障。

截止到目前，平心而论，我们现在的运维自动化是处于一个尴尬状态，因为之前花了大量的时间，研究了大量的工具，包括写了大量的脚本实现运维自动化，但结合Docker容器化时，我们发现脚本、服务器的安装和服务部署（包括一些发布）等会有比较大的颠覆。当我再去建一个容器时，我直接从私有仓库中拉取，发布时也是镜像更新，并不是我们之前所做的去写一些脚本，或者去做一些发布。结合现状，我们现在在逐渐结合Docker，包括之前做的运维自动化工作，逐渐改变运维自动化的情况。

7、其它

经过了标准化、流程化，包括自动化之后，我们已经积攒了很多自动化的脚本等，管理起来相对复杂，东西也比较多。这时我们需要一个自身的运维管理平台来去做统一的管理。

目前我们的运维管理平台大致包括四个功能：

1. 数据管理：数据管理主要是组织用户权限和绩效考核的功能。

2. 项目管理：即运维管理，运维管理以项目管理为单位工作，跟开发工作相结合。我们公司在逐渐推进以项目为单位定义运维工作并且与开发项目管理结合起来共用一套系统，这样我们运维的项目周期以开发的需求分析为起点，可加深我们运维对系统的理解，也会更好地帮助运维人员做线上的运维和运营工作。

3. 数据中心：工作也好项目也好，实际上都通过数据的方式进行展示和分析，我们力图通过用数据衡量运维的质量情况，后面我们也会逐渐利用数据中心为我们的自动化运维做一些改变。

4. 创新管理：主要还是想以创新驱动技术进步，提高运维质量，比如我们在运维管理中逐步实现Docker容器化的操作，去做一些智能化运维的实践，以此帮助我们做一些运维工作和技能的提高。

三、未来展望

首先是DevOps、SRE。我们将联合业务、开发、测试、运维共同推进DevOps的进步，因为我们是相对传统的行业，很难立即全面推动DevOps或SRE这一步，还是需要一个循序渐进的过程。

第二步是智能化运维，我们目前做的主要是一些故障的自动处理，例如像一些日志空间的自动释放、常见问题的自动处理等，这是相对初步的实践。

接下来我们也会结合自身运维的实际情况，对内部做一些智能化运维的技术性研究，但智能化运维对业务人员的技术要求是比较高的，而青岛招人又很难，怎么办？其实我们做DevOps时，已经跟开发、测试建立了一个相对比较好的关系，所以我们可以依赖于开发来做一些技术性的指导，结合自身的运维经验来逐渐推进智能化运维的一些工作。

然后私有云和混合云这一块，我们之前已经实现了虚拟化和容器化，接下来我们将逐渐利用OpenStack或K8s完成私有云相关的架构和操作，争取通过云服务降低我们的IT成本。

最后Serverless，不知道我的理解跟大家的是不是一样，我们的实践是将内部现在大概十多套的系统用户管理模块去做一个服务的统一抽取，当再有一个新的系统要上线时，我们不需要再去单独开发这样一套用户管理系统，而是直接接到这套用户管理系统的用户管理这样一个平台上，也是提高了一定的程度。通过构建多套系统的公用模块进行函数开发，实现系统直接调用。这跟微服务似乎有点相似。

运维这几年的发展其实有很多的技术不断的融进，我们始终坚持着安全、稳定和高效三大原则，没有这三大原则我们上面做的所有的操作全都是零。这是我今天的分享，谢谢大家！

Q&A

Q1：总体架构设计时用了哪些开发工具，用的都是开源的吗？

A1：目前很多都是开源的，除了有几套应用是跑在Weblogic，我们大部分是Tomcat，我们目前也在将一些商用的Weblogic、Oracle等迁移至开源替代产品中去，降低IT成本。数据库主要以MySQL和Oracle为主，Oracle主要是核心的系统在用。至于像我们这种监控和管理，也是开源性的工具多，例如监控主要是Zabbix和自定义脚本进行监控。安全这一块的话，相对比较多的是一些商业产品，例如我们的防火墙或者WAF应用防火墙，安全方面主要还是以商业产品为主。开源的安全产品，我们目前也在测试，但由于团队的技术所限，没有太大的精力去研究开源的安全产品也没有决心去生产使用。

大概的简图如下：

注：统一任务调度使用tbschedule，消息队列使用ActiveMQ，分布式文件服务器使用的fastDFS。接下来我会写单独一篇文章详细介绍我们的系统架构，敬请期待。

Q2：你们现在用K8s用到什么程度了，多大规模？

A2：K8S我们目前正在技术研究和测试阶段，主要在测试环境进行了一些试用。K8S还是Mesos来管理编排我们的容器，目前都在测试中。

其实今天也是想听一下大家对于Docker结合当前的情况做一些沟通。谈到Docker大家可能会有一个疑问，用了Docker之后会不会把之前的虚拟化抛弃掉？我们公司目前做的虚拟化是抛弃不掉的，因为我们有一些服务、应用部署在Windows服务器上，包括我们的Oracle架构也是在这上面。到目前为止还没有听说有公司在Docker跑RAC的一些架构。所以未来相对比较长的时间，我们公司还是虚拟化和容器化是并存的情况，算是一个逐渐转型吧。回头Docker生产集群搭建完毕，投入使用一段时间后，再跟大家做详细的分享。

Q3：请问你们在Docker上的总体驱动、整个场景规划，用K8s都做的话可能有一些缺点，所以你们整个集团是如何在调研K8s落地的？目前大家都想用K8s，但真的技术落地时，确实很多困难。

A3：说到k8s这块，生产中并没有做k8s的推广和实践，刚刚也说了我们目前正在进行技术调研。由于我们在青岛新机场会开一个新的数据中心，以此为契机，进行容器化技术和集群的研究和实践，争取在新数据中心实现内部高效的运维服务，通过新技术降低成本。这里也希望有生产经验的同学能够多分享一下生产的经验，我们好提前学习。

不过瘾？

想了解更多运维管理干货？

来2017 Gdevops广州站吧！

战学超老师将在【讲师交流专场】带来更多精彩的分享

近期热文：

点这里下载干货PPT