写在前面的话

最近一段时间，一致在做运维，数据库相关的工作，也算是完成了从开发向运维的转变。这半年来的研究也算是基本完成了运维管理平台的初版架构，这里写出来跟大家一起讨论讨论，以便可以更好的完成运维工作，摆脱重复运维劳动，尽快转向自动化运维和云服务这一方向，彻底解放劳动力，实现高效的服务 IT 。

一 总体架构

首先是总体架构图：

可以看出内容相对还是比较简陋一些，期望能够在大家的帮助下，丰富完善起来。

主要分为以下几个部分跟大家介绍：

1 基础数据

2 监控模块，监控管理平台

3 灾备管理平台

4 安全模块，安全管理平台

5 自动化运维平台

6 虚拟化与私有云

7 运维管理页面

本文主要对运维管理平台的这几个模块做一个简介，也是综合了我们平常运维遇到的过的一些问题，计划优先完成的模块。具体如下：

1 基础数据和监控优先

做运维管理平台一般会有一个优先度，很少有公司有充足的运维开发人力一下子同时开展好几个模块。按照优先级快速迭代，永远是解决 IT 与业务部门矛盾的银弹。本人一直也在纠结建立运维平台的模块的优先级排序。经过三思还是决定 首先完成基础数据的收集 ，这里的收集的目的是为了接下来要完成的监控平台的建立。说到底第一步是监控，前提是收集好基础数据。为什么要这样呢？首先建立起监控平台，实现主动监控我们的业务系统，服务器，网络的情况，出现问题，可以第一时间收到告警，这样在面对 IT 故障的时候，可以在与业务部门沟通中占据优先权，而非等业务投诉了，才知道系统出现故障。

很多公司可能没有运维开发的能力，此时 excel 管理基础数据， zabbix or 其他做监控，也是可以很快构建出基础监控平台用来监控 IT 系统的。

2 灾备紧跟

做好数据采集，做好监控，接下来就要考虑做全局备份。完整、可用的备份集是保障企业数据不丢或是最少丢失的最后一道保障。如何做好备份策略，备份集如何验证，都必须要提前做好准备和计划。

3 自动化运维与安全并行

在完成了监控和灾备之后，运维的冗余工作量会得到一定的减少，接下来可以进行自动化的运维工作，例如自动装机，自动部署服务，利用自动化运维将日常的重复工作靠系统完成，大大解放运维的劳动力。让运维可以更多的时间和精力保障整个 IT 系统的安全、稳定和高效。要完成自动运维的搭建，或是在构思自动化运维平台的时候，有一个工作不得不做，那就是： 运维标准化和运维流程化 。系统安装版本， JDK ， Tomcat 部署版本、位置等等，只要提前做好了标准化，才能利用自动化运维工具完成运维的自动化。运维的流程化是指涉及到某一运维主题如应用发布，每一步该如何操作，涉及哪些运维节点，先后顺序等，明确的运维流程，可以有条不紊的保障系统的更新和发布。规范化、流程化的运维操作可以减少运维过程中的失误，也可以在出现问题的时候，迅速找到问题节点，迅速恢复。

安全一直是一个相对忽略的话题。网络安全、系统安全、应用安全、数据库安全等，任何一个节点出现安全漏洞或是故障，都将会给系统带来毁灭性的灾难。安全也并不是购买了商业设备之后，就可以高枕无忧。不断学习，不断研究系统的漏洞，最大程度得结合自身的专业深度和安全设备，为整个 IT 系统筑一道厚重的高墙。

4 虚拟化和私有云

虚拟化和私有云的搭建的最大目的是为了节省公司的 IT 成本，当然也有其他很多优点。例如做虚拟机层面的热备，利用私有云服务快速的搭建需要的需要的服务等。虚拟化和私有云是未来运维的一个方向，一定要把握好时机。给老板省钱，便是跟老板要钱的最佳理由。

5 运维管理集成平台

在完成了基础数据采集， CMDB 建立，监控平台，灾备，运维自动化，虚拟化和私有云的时候，我们需要一套 IT 系统来集成各个模块，统一管理，这便是我们的运维管理平台。

接下来将围绕上面几个部分做一个简单的概述，简单概述之后，会陆续推出各个模块的建设心得，技术方案和踩过的坑等，敬请期待。

二 基础数据

巧妇难为无米之炊，基础数据便是我们运维管理平台的米。基础数据方面主要分一下几个部分：

1 CMDB

CMDB 在这里更多的偏向 IT 设备管理，因为这样可以更快的完成，与传统的 CMDB 不同，我们把配置管理放在了自动运维模块了。这里的 CMDB 主要是将整个 IT 部门的硬件资源，已有系统，服务包括供应商做一个管理，为以后的监控和自动化运维等提供基础数据。该平台 CMDB 的建设思路主要以产品线和项目为导向，具体顺序说明如下。

1.1 产品线和项目

首先是确定整个公司的 IT 产品线。以某航空公司为例，涉及到的系统有运行控制系统，飞行排班系统，机务管理系统， B2C 官网系统，呼叫中心系统等。经过分析判断，可以确定该公司主要两大产品主线，即：运行相关系统主线，市场相关主线。运行相关涉及到运行控制，飞行排班，机务等各个项目系统；市场相关系统主要有呼叫中心， B2C 等。为了更好的理解产品线和项目的划分，再举一个 B2B 电商的例子：买卖家管理系统，订单系统，支付系统，物流系统，对账系统等。可以大概分为销售产品线：买卖家管理，订单管理；财务产品线：支付系统，对账系统；物流产品线：物流系统，第三方物流接口等。

产品线的划分一定要站在公司的角度进行划分，可以结合公司的主要部分，和大产品群进行划分。产品线划分好后，接下来就是梳理整个公司的所有项目，将每一个项目，按照所属产品线进行归类。

1.2 IT 资产管理

经过产品线划分和项目归类之后，可以一目了然的看到目前公司所有的 IT 系统。接下来根据每一个项目梳理项目中涉及到的服务器或是虚拟机。然后还需要从另一个维度去梳理：每一台服务器或是虚拟机上面部署的项目，服务 ( 数据库， tomcat,weblogic 等 ) 。经过这一步，可以明确每一个项目涉及哪些服务器或是虚机，每一台服务器虚机上又关联多少项目，部署了多少服务。

虚机在哪些宿主机，宿主机有分布在哪些物理机上，而这些物理机又部署在哪个机房的哪个机柜；网络连接是怎样，上行和下行分别是什么，都需要进行梳理和完善，这样可以从硬件层面去关注每一个系统的硬件关联。如果硬件或是网路出现任何问题，可以快速的清楚涉及到的系统和影响度。

1.3 供应商管理

每一个公司的 IT 设备或是系统基本都会有供应商公司的参与。集中统一管理这些供应商的信息，可以在系统出现问题的时候紧急联系供应商，进行协助帮忙解决。

2 生产数据库

生产数据库作为基础数据的重要一环，为业务数据监控提供主要途径。我们在监控模块中有一个业务监控，主要依赖业务数据库中的数据，根据业务逻辑进行数据比对，判断业务的实时性和准确性。

一般在监控和备份的时候，数据库都会作为单独的一个主题进行（因为太重要）。在基础数据模块，将所有的生产数据库信息进行集中采集，可以很方便的为以后的数据库监控和备份等运维工作提供操作对象参考，以免遗漏。

生产数据库一般按照数据库的类型 (mysql,oracle,sqlserver 等 ) 进行分类管理。数据库的名称一般即业务系统的名称，简单标识，见名知意。

3 日志数据

日志数据是 IT 系统的重要数据之一，可以很好的反映系统的运行状况，系统出现问题的时候，可以通过反查日志进行查因、排故。

3.1 系统日志

系统日志主要是包括操作系统级别的日志包括物理机，宿主机，虚拟机等部署有操作系统的系统日志。一般主要关注以下几种日志：系统操作日志、安全日志、定时任务日志等。系统操作日志可以看到什么用户什么时间登录了哪台操作系统，做了什么操作等；安全日志可以判断系统是否已遭受或是正在遭受攻击，是否有过危险操作等；定时任务日志可以看到部署在系统中的定时任务是否按时准确的执行完成。

系统日志主要反映系统级别的运行情况，一定要做好备份和分析的工作。

3.2 应用日志

应用日志一般分应用服务日志如 tomcat,nginx 运行时候产生的日志等，通过其可以看到应用服务运行的健康情况；业务操作日志主要是业务系统将部分业务操作或是业务错误写到日志中的，可能单独一个日志文件也可能集成到应用服务日志日志中。业务操作日志是进行业务审计，业务监控的重要数据源。

3.3 数据库日志

这个不多说，数据库中的数据往往数企业的核心资产。数据库日志反映着数据库的每一步每一个事务的操作，以及数据库运行的监控状况，进行日志监控和分析，数据库日志不可缺少。

3.4 设备日志

设备日志往往是比较容易忽略的。但设备日志可以直观的反映出设备运行的状况，以及出现设备问题的时候，可以通过日志快速准确的找到原因。如交换机日志，防火墙日志等。通过防火墙日志可以看出系统是否遭受攻击，交换机日志可以看网络流量是否陡增陡降等突发状况。实时监控和管理设备日志是日志管理的重要工作之一

4 知识库

在基础数据中，我们单独设立知识库这样一个模块，主要包含事件库，问题库，经典案例库，解决方案库等。

事件库主要是在运维工作中遇到的一些运维事件或是事故，在事件库中详细记录事件的原因和处理过程。如果涉及到需求变更或是需要修改系统进行解决的，此时由事件库进入到问题库。问题库涉及到问题解决流程，问题解决的过程中，可能涉及到应用变更发布等。通过问题库的统计可以侧面反馈系统的状况。

经典案例库记录了解决经典问题的方式和方法例 如防火墙故障，交换机故障如何从查找原因到排故到解决的过程，以供解决类似故障处理参考。

解决方案库主要存放一些经典的解决方案如 nginx+tomcat+redis 的部署方案， mysql 的 HA ， oracle 的 RAC 等等解决方案。以便在构建新的系统的时候可以快速的选择解决方案。

基础数据为以后的运维工作做铺垫，基础数据的收集一定要全面，不能遗漏，否则就是以后运维的一个潜在问题点。

三 监控模块

监控模块主要分为以下几个部分：

1 系统监控

主要监控系统层面的健康状况如内存， cpu 告警，硬盘存储不足等等，系统层面的监控可以快速反应系统问题，运维工程师可以提前处理可能出现的系统问题。

2 网络监控

通过进行网络监控，包括网络的正常性，是否联通，网络访问量是否陡增陡降等，监控和预防网络问题带来的故障。

3 应用监控

主要监控应用的可用性如 tomcat 的端口， nginx 的端口，错误日志等等。应用出现问题导致应用不可用，都可以通过应用监控及时发现。

4 数据库监控

主要监控数据库的可用性，通过监控数据库状态，日志是否有警告错误，表空间等方面来监控数据库监控与否。

5 业务数据监控

通过业务数据监控以监控系统中是否含有业务逻辑错误的情况。例如：每一笔订单支付成功都应该有对应的支付流水号和物流流水号，通过监控数据库中的数据，来观察是否已经生成支付流水和物流流水。

6 全链路监控

通过全链路监控可以明确的看到业务操作的每一步正确与否。

7 第三方监控

以上 6 种监控基本都是从公司内部进行监控，如果是公司级别的网络问题或是服务器大面积故障，可能难以通过内部监控得到信息，此时需要借第三方云监控进行协助监控，如监控宝、听云等产品。

通过监控可以主动及时的得到系统的故障信息，在与业务部门的沟通中，化被动告知为主动监控，也为解决故障赢得宝贵的时间，这样可以把影响范围和影响时间将至最低。

四 灾备管理平台

灾备管理首先有条件的话可以两地三中心，即同城实时，异地延迟备份。注意一定不能全部都是实时备份，否则在出现问题的时候，尤其是数据篡改实时同步到备份端的话，也将是错误的数据。所以一定要有实时和延迟的策略。另外备份层面可以分数据库备份，文件备份 ( 如应用程序包等 ) ，虚拟机备份，存储级别的备份。

有备份就一定要有验证，而且验证要持续不间断，有计划的实施。只要通过验证可用的备份集才能保障系统的可用性。

在灾备管理模块存储各种系统的应急预案，这样在出现灾难性的故障的时候，可以迅速启动应急预案，进行灾难处理。

五 自动化运维和安全

1 安全

安全管理必不可少，而自动化运维是为了最大程度的减少运维的重复劳动，提高运维的工作效率。自动化运维减少的工作量可以转化为更多对系统安全的关注。

安全模块主要从上图的几个方面进行：

登录服务器通过堡垒机，而非直接 SSH 登录，另外利用堡垒机做系统操作审计，利用业务操作日志做业务审计（一般很难）。通过审计挖掘潜在的系统风险和威胁，防患于未然。

UMS 即用户账号管理。操作系统的用户，业务系统的用户密码往往没有一个统一集中的地方进行管理，这些管理员级别的账户一旦泄漏，危害是很大的。所以通过 UMS 进行这些用户的管理，并且指定责任人、权限和密码修改策略，最大程度的避免密码泄漏和丢失的风险。

企业中一般有多种安全设备，防火墙、 WAF 、 IPS 等，通过一个统一管理入口，既列举了所有的安全设备，也方便操作。这里往往是通过 URL 跳转到各种安全设备的管理界面。

漏洞管理平台主要是几个爬虫去爬当前主流系统漏洞和最新的漏洞，在平台进行反馈，以便运维工程师及时获得漏洞信息和思考处理办法。

当运维的服务器数量上来的时候，自动化运维就显得非常重要了。例如漏洞管理平台发现的一个新的漏洞，需要在几百台服务器上打补丁，此时没有运维自动化，每一台都登录处理的话，将是非常大的一个工作量。

2 自动化运维

在这里简单介绍一下运维自动化涉及到的内容。结合前面说的运维流程化中的流程，大概分为以下几点：

(1) 服务器申请与操作系统自动安装（自动安装的操作系统是经过系统安全加固和优化后的系统）。

(2) 系统部署服务（如数据库， TOMCAT 等）的申请和自动部署。一般版本要求统一，或是特定版本。部署的服务需要从自建软件仓库或是自建的 yum 源进行自动安装。

(3) 应用发布申请与应用的自动部署。我们这里采用的是开发从代码库中检出代码通过编译服务器进行编译，将编译后的程序包和配置文件（如果修改的话）在系统进行提交发布申请；测试人员收到开发的发布申请后，点击发布，发布程序先执行备份，然后自动发布到测试环境，测试人员进行测试，测试有误，回滚测试环境，流程退回至开发，无误则点击生产发布（有的公司会要求预生产发布测试）；运维人员收到测试通过的包和发布时间后，点击创建发布即可。到时会定时在服务器先备份后发布。

(4) 应用变更申请流程上述类似，都是线经过测试，在进行变更。服务器变更申请如扩容等根据资源利用率和硬件资源池进行评估，给出变更建议。

此外自动运维平台还提供架构自动诊断，压力测试，系统巡检，故障自诊断等方面的功能，具体不再一一赘述。

六 总结

运维管理平台的建立涉及到运维工作的方方面面，减少运维重复工作，提高运维效率为目标，如果大家有新的意见和建议的话，欢迎一起沟通交流。