作者介绍
战学超，青航数据架构师。曾任职于NEC软件、海尔B2B平台巨商汇，负责企业数据平台构建、B2B电商平台数据管理与搭建。拥有丰富DBA、系统运维架构经验，擅长数据库、数据平台搭建、私有云部署、自动化运维等。
最近一段时间，一直在做和运维、数据库相关的工作，也算是完成了从开发向运维的转变。这半年来的研究基本完成了运维管理平台的初版架构，这里写出来跟大家一起讨论交流，以便更好地完成运维工作，摆脱重复运维劳动，尽快转向自动化运维和云服务这一方向，彻底解放劳动力，实现高效的服务IT。
总体架构
首先是总体架构图：
可以看出内容相对还是比较简陋一些，期望能够在大家的帮助下，丰富完善起来。
我主要分为以下几个部分跟大家介绍：
-
基础数据
-
监控模块，监控管理平台
-
灾备管理平台
-
安全模块，安全管理平台
-
自动化运维平台
-
虚拟化与私有云
-
运维管理页面
本文主要对运维管理平台的这几个模块做一个简单介绍，同时综合了我们平常运维遇到过的一些问题，计划优先完成的模块。具体如下：
1基础数据和监控优先
做运维管理平台一般会有一个优先度，因为很少有公司有充足的运维开发人力一下子同时开展好几个模块。按照优先级快速迭代，永远是解决IT与业务部门矛盾的银弹。本人一直也在纠结建立运维平台的模块的优先级排序。经过三思还是决定首先完成基础数据的收集，这里的收集的目的是为了接下来要完成的监控平台的建立。说到底第一步是监控，前提是收集好基础数据。
为什么要这样？首先建立起监控平台，实现主动监控我们的业务系统、服务器、网络的情况、出现问题，从而可以第一时间收到告警，这样在面对IT故障的时候，可以在与业务部门沟通中占据优先权，而非等业务投诉了，才知道系统出现故障。
很多公司可能没有运维开发的能力，此时利用Excel管理基础数据，Zabbix or其它做监控，也是可以很快构建出基础监控平台来监控IT系统。
2灾备紧跟
做好数据采集与监控之后，接下来就要考虑做全局备份。完整、可用的备份集是保障企业数据不丢或是最少丢失的最后一道保障。如何做好备份策略，备份集如何验证，都必须要提前做好准备和计划。
2自动化运维与安全并行
在完成了监控和灾备之后，运维的冗余工作量会得到一定的减少。接下来可以进行自动化的运维工作，例如自动装机，自动部署服务，利用自动化运维将日常的重复工作让系统完成，大大解放运维的劳动力。让运维可以有更多的时间和精力保障整个IT系统的安全、稳定和高效。
要完成自动运维的搭建，或是在构思自动化运维平台时，有一个工作不得不做，那就是：运维标准化和运维流程化。系统安装版本、JDK、Tomcat部署版本、位置等等，只要提前做好了标准化，才能利用自动化运维工具完成运维的自动化。
运维的流程化是指涉及到某一运维主题如应用发布，每一步该如何操作，涉及哪些运维节点，先后顺序等。明确的运维流程，可以有条不紊地保障系统的更新和发布。规范化、流程化的运维操作可以减少运维过程中的失误，也可以在出现问题的时候，迅速找到问题节点，迅速恢复。
安全一直是一个相对忽略的话题。网络安全、系统安全、应用安全、数据库安全等，一旦任何一个节点出现安全漏洞或是故障，都将会给系统带来毁灭性的灾难。安全并不是购买了商业设备之后，就可以高枕无忧。不断学习，不断研究系统的漏洞，最大程度地结合自身的专业深度和安全设备，为整个IT系统筑一道厚重的高墙。
4虚拟化和私有云
虚拟化和私有云的搭建的最大目的是为了节省公司的IT成本。当然也有很多其他优点，例如做虚拟机层面的热备，利用私有云服务快速地搭建需要的服务等。虚拟化和私有云是未来运维的一个方向，一定要把握好时机。给老板省钱，便是跟老板要钱的最佳理由。
5运维管理集成平台
在完成了基础数据采集、CMDB建立、监控平台、灾备、运维自动化、虚拟化和私有云之后，我们需要一套IT系统来集成各个模块，统一管理，这便是我们的运维管理平台。
后面将围绕上面几个部分做一个简单的概述，简单概述之后，会陆续推出各个模块的建设心得，技术方案和踩过的坑等，敬请期待。
基础数据
巧妇难为无米之炊，基础数据便是我们运维管理平台的米。基础数据方面主要分一下几个部分：
1CMDB
CMDB在这里更多是偏向IT设备管理，因为这样可以更快地完成。与传统的CMDB不同，我们把配置管理放在了自动运维模块了。这里的CMDB主要是将整个IT部门的硬件资源，已有系统，服务包括供应商做一个管理，为以后的监控和自动化运维等提供基础数据。该平台CMDB的建设思路主要是以产品线和项目为导向，具体顺序说明如下。
一、产品线和项目
首先是确定整个公司的IT产品线。以某航空公司为例，涉及到的系统有运行控制系统、飞行排班系统、机务管理系统、B2C官网系统、呼叫中心系统等。
经过分析判断，可以确定该公司主要分为两大产品主线，即：运行相关系统主线和运营相关主线。运行相关涉及到运行控制、飞行排班、机务等各个项目系统；运营相关系统主要有呼叫中心、B2C等。
为了更好地理解产品线和项目的划分，再举一个B2B电商的例子，涉及到的有买卖家管理系统、订单系统、支付系统、物流系统、对账系统等。可以大概分为销售产品线：买卖家管理、订单管理；财务产品线：支付系统、对账系统；物流产品线：物流系统、第三方物流接口等。
产品线的划分一定要站在公司的角度进行，可以结合公司的主要部门，和大产品群进行划分。产品线划分好后，接下来就是梳理整个公司的所有项目，将每一个项目，按照所属产品线进行归类。
二、IT资产管理
经过产品线划分和项目归类之后，可以一目了然地看到目前公司所有的IT系统。接下来根据每一个项目梳理项目中涉及到的服务器或是虚拟机。然后还需要从另一个维度去梳理：每一台服务器或是虚拟机上面部署的项目，服务(数据库、Tomcat、WebLogic等)。经过这一步，可以明确每一个项目涉及哪些服务器或是虚拟机，每一台服务器或虚拟机上又关联多少个项目，部署了多少服务。
虚拟机在哪些宿主机，宿主机又分布在哪些物理机上，而这些物理机又部署在哪个机房的哪个机柜；网络连接是怎样，上行和下行分别是什么，都需要进行梳理和完善，这样可以从硬件层面去关注每一个系统的硬件关联。如果硬件或是网路出现任何问题，可以快速地清楚知道涉及到的系统和影响度。
三、供应商管理
每一个公司的IT设备或是系统基本都会有供应商公司的参与。集中统一管理这些供应商的信息，可以在系统出现问题的时候紧急联系供应商，进行协助解决。
2生产数据库
生产数据库作为基础数据的重要一环，为业务数据监控提供主要途径。我们在监控模块中有一个业务监控，主要依赖业务数据库中的数据，根据业务逻辑进行数据比对，判断业务的实时性和准确性。
一般在监控和备份的时候，数据库都会作为单独的一个主题进行（因为太重要）。在基础数据模块，将所有的生产数据库信息进行集中采集，可以很方便地为以后的数据库监控和备份等运维工作提供操作对象参考，以免遗漏。
生产数据库一般按照数据库的类型(MySQL、Oracle、SQL Server等)进行分类管理。数据库的名称一般即业务系统的名称，简单标识，见名知意。
3日志数据
日志数据是IT系统的重要数据之一，可以很好地反映系统的运行状况，系统出现问题的时候，可以通过反查日志进行查因、排故。
一、系统日志
系统日志主要是包括操作系统级别的日志，包括物理机、宿主机、虚拟机等部署有操作系统的系统日志。一般主要关注以下几种日志：系统操作日志、安全日志、定时任务日志等。
系统操作日志可以看到什么用户什么时间登录了哪台操作系统，做了什么操作等；安全日志可以判断系统是否已遭受或是正在遭受攻击，是否有过危险操作等；定时任务日志可以看到部署在系统中的定时任务是否按时准确地执行完成。
系统日志主要反映系统级别的运行情况，一定要做好备份和分析的工作。
二、应用日志
应用日志一般分应用服务日志和业务操作日志。应用服务日志指如Tomcat、Nginx运行时候产生的日志等，通过其可以看到应用服务运行的健康情况；业务操作日志主要是业务系统将部分业务操作或是业务错误写到日志中，可能单独一个日志文件也可能集成到应用服务日志中。业务操作日志是进行业务审计，业务监控的重要数据源。
三、数据库日志
这个不多说，数据库中的数据往往是企业的核心资产。数据库日志反映着数据库的每一步每一个事务的操作，以及数据库运行的监控状况，进行日志监控和分析时，数据库日志是不可缺少的。
四、设备日志
设备日志往往是比较容易忽略的。但设备日志可以直观地反映出设备运行的状况，以及设备出现问题的时候，可以通过日志快速准确地找到原因。如交换机日志、防火墙日志等。通过防火墙日志可以看出系统是否遭受攻击，交换机日志可以看到网络流量是否呈现陡增陡降等突发状况。实时监控和管理设备日志是日志管理的重要工作之一。
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、应用变更申请流程与上述类似，都是先经过测试，再进行变更。服务器变更申请如扩容等会根据资源利用率和硬件资源池进行评估后，给出变更建议。
此外自动运维平台还提供架构自动诊断、压力测试、系统巡检、故障自诊断等方面的功能，具体不再一一赘述。
总结
运维管理平台的建立涉及到运维工作的方方面面，以减少运维重复工作，提高运维效率为目标，如果大家有新的意见和建议的话，欢迎一起沟通交流。
转自：http://www.sohu.com/a/141415011_487514