认识达内从这里开始

相信大多数的企业软件运维管理员在刚刚开始展开工作的时候，大部分的情况下都是哪里有问题就解决哪里，没有一个详细规范的操作方法。

所以，为了提高大家的工作效率，我们今天就给大家简单分享一个大部分的企业都可以使用的运维管理方法，希望对大家的工作有所帮助。

一、运维管理思路

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

运维管理

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

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

数据

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

二、运维管理平台架构

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

1、总体架构

架构

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

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

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

2、标准化与流程化

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

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

数据管理

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

3、基础数据管理

监控

CMDB

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

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

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

重要数据和日志

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

知识库

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

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

4、监控管理体系

灾备

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

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

5、安全、灾备管理体系

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

灾备管理

灾备

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

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

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

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

安全管理体系

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

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

6、运维自动化

运维自动化

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

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

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

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

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

7、其它

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

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

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

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

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

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

原文来自微信公众号：DBAplus社群

【免责声明】本文转载自网络，著作权属原创作者所有。经检索无法确定原创作者，故未标明作者。我们分享此文出于传播更多资讯之目的。如涉著作权事宜请联系小编更正!