文章

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

2017-11-24战学超

1842阅
在运维的初期,我们更多的是一个救火队长的角色,每天数不尽的更新发布和问题修改,运维人员每天的工作都很饱和,压力也很大,是一个比较疲惫的过程。
    我今天要跟大家分享的主题是《中小企业运维管理平台架构》,这是结合我们青岛航空在做运维管理和运营管理平台时的一些经验和问题,希望能够对大家有一定的帮助。
 
    分享大纲:
 
    1.运维管理思路
 
    2.运维管理平台架构
 
    3.未来展望
 
    一、运维管理思路
 
    在运维的初期,我们更多的是一个救火队长的角色,每天数不尽的更新发布和问题修改,运维人员每天的工作都很饱和,压力也很大,是一个比较疲惫的过程。后面我们经过了一个梳理运维流程和整理的步骤,逐渐实现了运维的标准化和流程化,结束运维初期相对混乱的状态。
 
    运维管理
 
    在做运维标准化流程化的过程中,最初也会利用脚本或者代码、工具来实现运维自动化的工作,大大减少运维的重复性工作,提高运维的效率;也会结合我们在运维标准化、流程化、自动化中积攒的一些数据,结合自身运维的经验和一些机器学习算法,去完成一些智能化相关的工作。
 
    运维的三大主题是监控、安全和灾备,这是围绕运维的基础数据来做的,以保证运维基础数据的稳定。运维周期是从需求开发调研开始的,从开发到测试到上线,这中间借鉴了一些DevOps的思想,也包含了运维人员、测试人员共同维护我们的业务系统,保证业务系统的稳定。
 
    数据
 
    我们做运维管理的时候,始终坚持安全、稳定和高效三个原则,抛弃了这三个原则,之前所做的不管是标准化、流程化,都将为零。通过做运维管理,我们的目的是提高运维质量,降低运维成本。以上就是做运维管理的思路。
 
    二、运维管理平台架构
 
    下面我将从总体架构、标准化、流程化、基础数据、监控管理体系、安全、灾备管理体系、自动化以及其它一些方面进行简单分享。
 
    1、总体架构
 
    架构
 
    从下往上,我们首先通过虚拟化、容器化实现了相对基础的类IaaS平台,这样在做上层运维工作时,可以相对少地去关注底层资源。接下来是基础数据的梳理,基础数据决定了运维的工作对象和范围,上层所运作的所有的工作都紧紧围绕运维基础数据来的。我们在梳理和整理基础运维数据的时候,顺便完成了运维的标准化和流程化的制定以及实施落地。
 
    基础数据之上是监控、安全和灾备三个管理体系,围绕基础数据对运维的基础数据提供保驾护航。再上面是运维自动化,通过运维自动化将固化的运维工作和流程做了一些自动化的开发,减少了运维重复性的工作,提高了运维效率。随着运维自动化的发展演变出了一定的问题,例如自动化脚本越来越多、越来越难管理,我们用的自动化工序也非常多,这时急需一个统一的运维管理平台,帮助去对去做统一的管理,这是我们运维管理平台的情况。
 
    我们的运维管理平台主要是包含用户管理、项目管理、数据中心和创新管理这一块的功能。其中运维管理是以项目为基本单位的,所以说下边做的这种运维自动化和运维标准化的东西是都涵盖项目管理的。数据中心主要跟基础数据做一些紧密的结合,为我们做智能化运维提供基础数据的支持。创新管理这块其实主要是想通过创新性的管理来不断的推进内部的运维技术进步,不断去尝试一些相对比较新、比较高效的技术。这是我们的实际工作情况。
 
    2、标准化与流程化
 
    标准化和流程化主要是通过文档的方式梳理以往的一些工作,进行一些文档性的整理,包括数据中心的建设。对于数据中心,我们是有自建的机房的,包括搬迁新机场后的新机房建设(青岛19年胶东新机场建立完成,航空公司要进行搬迁),新机房建设是围绕国家标准和地方性的标准来进行建立和建设的。然后硬件设备采购和上下架,这些是硬件相关的东西。
 
    接下来是一个故障排故流程和运维通告,这个帮助运维出现运维故障时,提供一个解决的方式和通报流程。
 
    数据管理
 
    上面两行是服务器的申请、服务器的部署(包括配置变更等),还有权限管理。运维服务的申请到运维服务的部署,包括应用的部署等主要是通过这样一些文档和流程来规范我们日常的运维工作。标准统一了,我们做运维时就相对容易很多。
 
    3、基础数据管理
 
    监控
 
  • CMDB
 
    这里分为几大部分。首先是CMDB,这个跟传统的ITIL有一些不同的地方,我们的CMDB以产品线为主线,每个产品线下包含很多项目,而每个项目里也有很多的服务,每个服务会有不同的应用在上面跑。这些服务,或者说这些应用,都跑在我们的虚拟机或者容器上,而这些虚拟机和容器又分布在不同的物理机上,到了物理机这一层也就到了资产管理这块。
 
    资产管理这块主要是我们的一些硬件,包括网络设备和物理机等。通过产品线和生产管理,把日常运维的一些对象去做定义,另外我们也把项目和项目之间的依赖关系,包括物理硬件之间的依赖关系都做了统一的梳理,这样的话,当某一个节点出现问题时,对它所带来的影响会有一个比较全面的认识。
 
    供应商环节,因为我们属于民航业,有一些供应商涉及得比较多,所以把供应商单独拿出来做管理,主要是供应商的一些信息和合同。这样做的好处便是,当问题比较难以解决时,通过统一的供应商管理,可以快速查到对应的供应商信息。
 
  • 重要数据和日志
 
    重要数据主要是针对我们的数据库的数据。日志也不用多说,是很重要的信息,包括系统日志应用日志、数据库日志、设备日志包括硬件设备的日志,目前我们在逐步完善硬件设备的日志,因为它要对接很多不同的协议,相对复杂。
 
  • 知识库
 
    知识库主要是事件库和问题库,事件库记录了日常所做的运维事件,当运维事件短时间内无法解决,需要通过开发做一些变更时,我们便将这个事件升级为问题,并通过问题库来跟踪运维事件变更所带来的具体进展情况。经典案例库和解决方案库主要是对于运维遇到的一些经典问题的解决方法,包括系统的经典的部署方法、解决方案等,我们都做了一些统一的记录或存储,当有新的系统要部署时,也是可以通过这样查阅解决方案以及经典案例,快速得到部署的方法。文档库主要是存储了我们在标准化和流程化时做的一些文档,去做一些存储,其中也有一些版本是管理相关的东西。这是运维的基础数据。
 
    接下来是安全、灾备、管理三个主题讲一下。
 
    4、监控管理体系
 
    灾备
 
    首先是监控。监控的目标是通过内外部的多套监控去实现一个相对立体化的监控体系,根据系统的优先级将所有的系统和我们的硬件去做一个监控。另外就是监控的维度,首先第一个维度是覆盖所有系统和软硬件;其次是监控维度,包括应用系统可用性,数据库运行状态,网络状况等;第三个维度是全部时间,主要是我们会对监控的历史数据做一个存储,包括过去一些系统或者是服务器信息的状态和当前的状态。这里其实也是为我们做智能化运维提供了一些历史性的数据。
 
    下面列举一下我们当前监控的一个情况。首先是机房和硬件的监控,机房监控我们主要依赖在机房建立初期供应商提供的机房环境监控系统进行监控。硬件监控的话,我们采购不同的硬件都有各自的监控方式,我们也做一些整合和整理,争取形成统一的硬件监控。虚拟机和容器监控主要是监控虚拟机或容器的状态和可能性等。网络监控主要是用以监控网络运行状态。这里也会有系统、数据库以及一些应用和业务的监控。监控用到的工具主要是一些开源的工具,其中Lepus是监控数据库,Zabbix监控我们的操作系统等,我们也会根据实际情况去开发我们自己的监控脚本。通过多种监控方式和工具多维度监控我们的运维对象,这是监控体系的情况。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
读者评论 (1)
  • teamczyx7-15
    浏览器自动填表软件 www.teamczyx.com
以上网友发言只代表个人观点,不代表本网站观点或立场。
请您登录/注册后再评论