金融行业IT自动化运维的研究与落地实践

Posted 2021-05-01 红帽

前言：

本文只代表笔者个人观点，文中内容只是建议。本文中所引用的所有图片、材料，大多是自己多年工作的积累，引用的他人图片，也已事前征得原作者同意。

研究方向：金融行业自动化运维

本文主要针对金融行业，尤其是中小金融的自动化运维现状进行分析，并给出发展建议。之所以选择金融行业研究，有两个原因。

第一是因为：在传统的行业中，如金融、制造、能源、教育等行业中，金融行业的业务稳定性要求是最高的。金融行业的IT系统也是最复杂的。有的银行，目前既有大型机，又有小型机、有x86物理服务器、虚拟化、云平台，甚至在容器方面也进行探究。搞懂了金融行业的IT运维面临的问题，其他行业遇到的运维问题也就迎刃而解了。

第二个原因是，笔者长期从事金融行业的售前支持，能够获取到的经验相对多一些，挑一个自己熟悉一点的行业，也能够对以后工作有益。

金融行业IT运维现状

中国金融行业自1993年起实施分业经营，金融业主要包括银行、保险、证券三大子行业，多年来随着一行三会监管制度的建立、金融机构改革的稳步推进，中国金融体系架构初步形成。

在金融行业中，银行又是IT水平最高的细分行业。

国内银行业基本架构如下：

虽然我们将金融统称为一个行业，但银行、证券、保险的IT架构区别很大。下面举两个例子。

下图是一个典型农商行的业务系统：

下面是典型的财险公司IT业务架构：

上面两张图虽然都是属于金融行业，但其中的IT架构差异，十万八千里。因此运维起来，方法一定是有所差别的。

金融行业IT运维现状：

1. 业务的稳定性、可靠性要求越来越高；

2. 业务系统对IT支撑的依赖性越来越强；

3. IT架构的复杂度不断加深；

4. IT部门工作职责越来越重；

5. 人员不足难以应对繁重的运维要求；

6. IT事故将直接影响业务，责任重大。

金融行业IT运维的几个现状，带来的两个运维中两个重大的问题是：

1. 过分依赖人工操作，效率低、风险大

• 操作的效率和准确性依赖于人员的技能；

• 操作周期较长并存在误操作的风险；

• 一旦业务中断，将带来巨大损失。

2. 占用大量人力资源，成本偏高：不同的系统均由专人负责，运维人员的数量会随着信息系统的增加而不断增加。

金融行业Linux运维管理七大难题

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

0 1

自动部署

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

0 2

软件更新

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

0 3

安全更新

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

0 4

合规性检查

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

0 5

软件全生命周期管理

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

0 6

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

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

0 7

服务器组批量操作

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

IT运维的出路

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

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

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

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

金融行业理想的IT运维平台架构

客户理想的自动化平台是：首先要有一个自动化运维门户（unified portal），理想状态是这个门户与客户的云门户统一对接。其次，当IT系统出现问题/需要变更的时候，自动/手动触发处理工单 （这个工单系统符合ITIL流程 ，与行里现有流程和审计对接）。这个工单IT主管可以看到，审批以后、自动执行，把问题修复。比如：linux的根分区不够了，自动触发预运维平台的对应操作是自动扩容，但需要自动触发创建工单。工单到IT主管那，批准之后，自动扩容。

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

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部门的内容用户。做统一的门户。过这个统一的平台，内部用户可以访问这个平台。通常情况，运维门户会与客户的云门户统一。

将每层的定义、功能与红帽和开源的方案相匹配，方案映射图如下：

目前，CloudForms和Ansible Tower可以做到无缝集成。Ansible中的playbook，可以被CloudForms调用，用于云自动化部署和运维自动化。

同样，Satellite和CloudForms也是对接的。Satellite中的各种信息导入到CloudForms，可以形成报表，并进行监控。

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

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

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

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

• 比较容易实现的是：批量作业自动化、自动巡检。(通过Ansible Tower+ 专业服务实现)

• 实现难度中等的是：软件批量分发部署和配置与版本管理。(通过Ansible Tower + Satellite + 专业服务/其他开源工具实现)

• 实现起来最复杂的是：应急故障检查和容灾管理。(通过Ansible Tower + Satellite + ITIL + BPM + 专业服务/其他开源工具实现)
  

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

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

金融行业客户自动化运维的选择

企业实现自动化运维是个大工程，需要找一个技术实力雄厚、经验丰富、兵强马壮的战略合作伙伴。

推荐红帽的理由有：

首先，红帽企业级Linux是全球金融行业用得最多的Linux。寻找运维自动化的合作伙伴，找一个Linux经验最丰富的厂商是靠谱的：

其次，红帽有强大的解决方案支撑运维自动化：CloudForms+ Ansible Tower +Satellite。

Ansible Tower支持的对象：

相关材料阅读：

Satellite的四大功能：

从里往外，顺时针看，红帽卫星的功能分别为：Provisioning, Configuration Management, Subscription Management,Software Management。

Provisioning功能如下：

• 可在裸金属，虚拟化和基于云的环境中进行操作系统以及应用的部署

• 联邦式的内容分发

• 支持基于build以及基于镜像的部署

• 发现还未被部署的的主机

软件管理的功能如下：

• 定义和管理标准的操作环境

• 针对安全漏洞（Heartbleed/shellshock）快速的相应

• 遵守组织内部的相关安全策略

• 部署所有红帽相关的基础设施以及第三方软件

订阅管理的功能如下：

• 集中的管理订阅使用

• 维护准确的库存和利用率的相关信息

• 按小组为单位的订阅消耗报告

配置管理的功能如下：

• 定义系统所需的状态

• 管理和修复配置状态漂移

• 变更时的审核及报告

CloudForms的支持范围如下：

CloudForms的功能列表：

最后，红帽目前的服务支撑体系符合金融行业监管的要求，并且在金融行业有大量成功案例。

结论

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

在构建自动化平台的过程中，我们可以借助于很多开源工具DIY而成，但问题就是除了问题谁来兜底的问题。作为宇宙内业务稳定性要求最高的金融行业，笔者建议客户选择一个又技术实力、经验丰富、兵强马壮、落地性强的战略合作伙伴。