专家观察 | 魏新宇：“金融行业自动化运维的研究与落地”

由工业和信息化部指导，中国信息通信研究院主办，业界知名组织云计算开源产业联盟（OSCAR）承办的2017全球云计算开源大会于4月19日-20日在北京国家会议中心顺利召开。本文为本届大会嘉宾分享的大会演讲速记内容，敬请浏览。

嘉宾介绍：魏新宇

公司职务：红帽软件（北京）有限公司方案架构师

大会演讲速记

大家下午好，我是红帽公司的解决方案架构师魏新宇，我很荣幸跟大家分享这个课题。

金融行业的定义比较广泛，它包含有银行、证券、保险。金融行业的IT化信息较早，例如1980年左右，银行就开始了信息化建设。由于起步和发展早，所以金融行业的IT架构相对来说比较复杂的，像很多银行的IT设备有大型机、小型机、物理服务器、虚拟化，Open Stack，甚至还有容器。

正是由于金融行业各个细分领域，IT业务架构有很大的区别，或者有很大的不同，所以IT运维我们经常遇到一些问题，主要是集中在两方面，一方面运维块效率较低，第二方面就是运维成本非常高。

红帽专家根据多年支持银行业客户，长期经验总结出了七类Linux运维中常见的问题。这七类问题，可以说是很多客户，尤其是客户运维人员的血泪史。当然，有的金融客户面临的问题可能是其中的某一个，有的面临的问题甚至超出了这七种类型。

• 自动部署

目前很多银行内采用各种开源技术实现了操作系统的批量安装和自动化部署、但是先前的做法可重复利用化程度很低，每当有项目需要进行自动部署时都需要针对该项目重新进行配置，工作量大且效率低下而且没有很好的版本管理和回退机制，也缺乏一个很好的管理界面来进行管理，希望通过有效的管理工具来实现快速部署海量服务器的问题。

• 软件更新

很多银行服务器升级都是去红帽官方网站下载然后手工进行升级操作，实效性、可追溯性差，管理员只是被动接收来自安全部门和红帽的安全建议，希望通过一个集中展示平台，直观的看到数据中心内部所有linux服务器目前运行的软件版本和官方版本之间的差异、升级的类型并直接通过统一的展示界面远程直接对需要升级的服务器升级某一个软件的升级程序。

• 安全更新

国家现在对开源软件的安全性要求很高，很多银行的安全部门以及公安部会定期对所有的Linux服务器进行安全扫描并发布安全整改意见，这些意见和厂商提供的安全更新建议往往有很大的出入，迫切的需要一个工具能提供红帽产品的安全更新以及修复建议并且能结合上述的软件更新功能为系统及时的修补安全漏洞

• 合规性检查

大的银行内部有自己的操作系统基线，定义了一系列的标准，这些标准需要人工来实现以及更，参与Linux运维的人员也很多，每个人的能力、对操作系统的理解程度以及使用习惯的不同会造成Linux服务器的配置存在很大的差异，有无可能通过一个集中式管理工具结合行里的运行规范来实现自动化部署并且可以根据已有古规范找出个与规范之间的差异并消除

• 从开发到测试到运维的软件生命周期管理

很多银行的开发测试运维的环境都不完全一样，这就有在开发测试环境中可用但到了生产环境会出现问题的风险，希望通过工具来统筹管理开发、测试和运维平台上的Linux环境的部署，应用软件的分发以及合规性一致性的检测。

• 多用户、用户组管理以及访问控制

很多银行基于Linux的系统都是以项目（业务）的方式进行划分的，每个项目都会有相应的软件中心和数据中心的技术人员负责应用软件和操作系统的开发、部署、上线、维护等工作，为了完成这些工作需要给相应的用户赋予相应的权限以避免越权操作，希望解决在大规模Linux使用环境下用户管理和权限划分的问题。

• 服务器组批量操作

传统的Linux运维管理需要登录到服务器上手工或者通过执行脚本的方式来进行，对于一个项目而言，通常几台甚至几十台服务器的配置和运行环境是完全一样的，希望能实现像操作一台服务器那样操作一组服务器，执行一次操作就可以对该组内所有服务器都生效，即对一组服务器可批量进行升级、部署、管理和维护的工作。

解决错综复杂的运维问题，出路在人员、流程、工具三方面一起下功夫，构建标准，先实现手工标准化运维。接下来，利用现代化IT技术，逐渐减少运维人员的工作量，构建自动化运维。在实现了自动化运维以后，就需要构建集中管理，实现集中化。最后，随着企业IT水平的不断提升，利用CI/CD等技术，构建devops。

参考Gartner IT基础架构和运维成熟度模型中的技术维度，红帽根据在Linux领域长期的经验，提出OS运维成熟度模型。OS运维成熟度越高的企业，其IT架构越敏捷、 Time To Market越短、业务竞争力越强。

根据不完全统计，在传统行业里，IT成熟度较高的用户，其OS成熟度大多处于三级，也就是基本实现了运维制度化、规范化，但仍处于半手工运维的阶段。

而作为对IT运维要求更高的金融行业，显然需将OS运维成熟度至少提升到四级，实现集中化；甚至五级，也就是自动化和运维开发一体化。

客户理想的自动化平台是：首先要有一个自动化运维门户（unifiedportal），理想状态是这个门户与客户的云门户统一对接。其次，当IT系统出现问题/需要变更的时候，自动/手动触发处理工单（这个工单系统符合ITIL流程 ，与行里现有流程和审计对接）。

这个工单IT主管可以看到，审批以后、自动执行，把问题修复。比如：linux的根分区不够了，自动触发预运维平台的对应操作是自动扩容，但需要自动触发创建工单。工单到IT主管那，批准之后，自动扩容。

如果按照上一小节的“OS运维成熟度模型”来衡量该架构，上图这个架构不仅实现了自动化，也实现了集中监控。因此其等级至少为4+，接近于5级。

构建自动化运维平台中，红帽的左膀右臂分别是Ansible Tower和Satellite。

Ansible Tower作为一款优秀的自动化运维工具，它有四大特点：

• 使用简单而功能强大（它可以支撑整个IT架构，从物理机、操作系统、虚拟化、云、容器到网络设备。语言简单易学）
• 操作安全可控（ansible tower基于RBAC方式对用户进行授权，AD，LDAP等认证方式做对接）
• 适应传统行业客户与互联网行业（ansible是git hub上最受欢迎，使用最广的自动化工具）
• 在金融行业已经积累了海量的playbook（红帽的的用户可以直接拿来用，红帽在很多金融行业客户积累的经验）。

金融行业

satellite则在系统部署、订阅管理、软件管理、配置管理四方面帮助客户实现IT运维标准化。

红帽云管平台Cloudforms，可以与AnsibleTower和Satellite对接，实现云平台管理与运维统一。

那么，IT自动化运维平台架构如何落地？

首先我们先看自动化运维平台的架构：从下往上：IT环境、基础架构管理、数据展示层。

IT环境层，指的是自动化运维平台需要纳管的对象。在一个复杂的数据中心中，运维绝不是仅仅针对一种操作系统，或者一种型号的服务器。而是整个数据中心，包括（但不限于）：

1.系统层面：从Linux（物理机、虚拟机、云环境）, Unix,到Windows。

2.虚拟化平台：VMware、Docker、Cloudstack、LXC、Openstack等。

3.商业化硬件：F5、ASA、Citrix、Eos以及各种服务器设备的管理。

4.系统应用层：Apache、Zabbix、Rabbitmq、SVN、GIT等.

5.商业化软件如：Openshift、Ceph、Gluster、Oracle等。

6.云平台：支持的云平台有AWS、Azure、Cloudflare、Red Hat CloudForms、Google、Linode、Digital Ocean等。

基础架构管理层

基础架构管理层的职责分为三大块：集中监控、运维自动化平台、内控平台。

1.集中监控平台包含平台（如虚拟化平台）监控和应用（如oracle数据库）监控。

2.运维自动化平台，它是基础架构管理层的核心组件。它需要完成四类操作：作业调度、自动巡检、批量发布、容灾管理。也就是说，运维自动化平台必须能够驱动IT环境层的七种对象。

3.内控平台，主要负责合规控制。它完成：合规管理、风险管理、用户管理、访问控制。

整体而言，在基础架构管理层中，运维自动化平台是最关键的，它是管理层的发动机。而集中监控平台和内控平台则是辅助自动化平台的。前者负责运维自动化的全生命周期管理，后者负责运维自动化平台的合规和安全。

服务管理层

服务管理层通常通过ITIL等架构理念，与客户的规章制度与业务流程匹配，需要做定制化开发。目前绝大多数金融行业用户都有流程，只是体现在纸面上。需要做的是将纸面上的流程IT工具化。

数据展示层：

主要是面向企业内部IT和非IT部门的内容用户。做统一的门户。过这个统一的平台，内部用户可以访问这个平台。通常情况，运维门户会与客户的云门户统一。

金融行业客户自动化运维平台实施步骤

任何一个大型平台，无论是混合云平台，还是自动化运维平台，它们的构建都不是一蹴而就的。都需要客户结合自身的情况，分步骤、分阶段走。

下面我们看一下自动化运维平台常见的几类工作，按照OS运维成熟度模型进行评估，六类工作都能实现自动化的话，IT成熟度可达到接近于5级的水平。

在这六类工作中，按照难易程度，大致可以分为三类：

• 比较容易实现的是批量作业自动化、自动巡检。(通过Ansible Tower+ 专业服务实现)
• 实现难度中等的是：软件批量分发部署和配置与版本管理。(通过Ansible Tower + Satellite + 专业服务/其他开源工具实现)
• 实现起来最复杂的是：应急故障检查和容灾管理。(通过Ansible Tower + Satellite + ITIL + BPM + 专业服务/其他开源工具实现)

因此，针对于目前完全没有进行自动化构建的小型金融客户，建议从批量作业自动化、自动巡检开始，先通过这两步，解放运维人员的生产力；对于在自动化运维有过一定探究的中等规模银行，可以考虑实施软件批量分发部署和配置与版本管理；对于IT程度较高的大型商业银行，需要考虑的问题是，如何实现应急故障检查和容灾管理的自动化。

实现六类工作与构建服务管理层和展现层并不冲突。流程、工具、人员三者必须同步进行。当然，在早期，服务管理层可以考虑先使用人工的方式。随着IT规模的增加以及管理要求的提高，再将纸质流程IT工具化。

刚才所讲的内容我放到公众号上了，大家有兴趣可以看，谢谢大家。

文章来自微信公众号：云计算开源产业联盟

本文链接：https://www.yunweipai.com/16929.html