什么样的运维神通，才配得上IT在银行业的江湖地位？

声明：

本文是笔者在阅读了《银行新系统架构》、《Ansible自动化运维技术与最佳实践》以及红帽多篇技术文档后，加上自己实践后书写完成，本文只代表笔者的个人观点。

IT在银行业的江湖地位

谈到IT在各个行业中的地位，除了IT行业本身之外，金融行业中IT的重要性应该是最高的了，属于银行业的“老炮”了。

长久以来，IT架构服务于银行的业务架构，并为其发展提供了有利的支撑。

话说，在“很久”以前的20世纪：

• 60年代，台式机的出现使银行的核心账户处理可以实现计算机处理；

• 80年代，C/S架构的出现推动了银行ATM/POS的快速发展；

• 90年代，电子商务和新支付手段的出现，拓展了银行业的业务范围；

• 当下，第三平台（云计算、大数据、移动平台、社交媒体）促进银行业的业务创新。

在当下时代，也就是信息化银行的建设中，IT的地位已经大为提升，开始引领业务发展的趋势。

银行业务与银行中IT的关系，可以从战略和架构两个方面看。

一、从战略层面看（两大战略）

在银行业，无论IT地位如何高，它都是服务于业务的。也就是IT战略必须满足业务战略 。当IT战略与业务战略相匹配时，它就会成为后者发展的助推器，否则会成为业务发展的鸡肋，就犹如生产力和生产关系两者的关系。

银行业的业务战略有很多种：客户战略、渠道战略、营销战略、融资战略、品牌战略等。

IT战略对业务战略支撑的四种类型：

1）支持型：IT提供基本的工具支持业务的发展

2）运营型：IT支撑业务的基本运作

3）变革型：IT推动业务的转型变革

4）战略型：IT全面引领业务的战略发展。

二、从架构层面看（两大架构、三小架构）：

业务战略对应业务架构；IT战略对应IT架构。

业务架构：在逻辑层面阐述了理想的业务视图。例如我们看一张城商行的业务架构图（需要注意的是，业务架构不是银行的应用架构，应用架构只是IT架构的一个分支）：

而IT架构有细分三个子架构：应用架构（银行中高层管理者和业务人员关注）、数据架构（数据主管部门关注）、技术架构（技术设施运维人管关注）。

IT架构的三小架构作用：

1应用架构：回答业务功能在哪实现的问题；

2数据架构：回答数据在哪产生在哪使用的问题；

3技术架构：回答计算和存储资源如何安全、灵活、高效部署和运维的问题；

事实上，IT厂商的产品技术人员（尤其是基础架构），在工作上所有对银行的所有认知，通常不会超过IT架构的范畴。所以IT厂商技术人员，很难说精通银行的业务架构，能一定程度了解银行的应用架构，已经很不容易了。

我们看一张银行业应用架构的图：

银行数据架构图：

网上银行技术架构图：

银行业IT推广自动化运维的必然性

在银行业，“随着IT的江湖地位越来越高，IT运维显得越来与越重要，所以需要IT自动化运维”，这还是从IT的角度看IT。

这次，我们档次高一些，“浓眉大眼”些。从业务的角度看，随着金融机构全面放开*款贷**利率管制，依赖传统存利差保护的银行盈利模式面临绝大的挑战，银行之间的同行业竞争加剧，银行为了提升业务的竞争力，必然要求IT层面更为高效、弹性，风险更低。而从这个层面看，自动化运维有助于提升银行IT的质量，从而促进银行也能能力的提升。对于银行业来说，通过自动化运维，降低IT系统的风险，提升IT系统的质量，将IT运维人员从琐碎、重复的事务中解放出来。在此基础之上，大力发展新型业务，如流程银行、渠道协同、互联网金融等，这才是银行业需要做的事。

什么样的绝世神通？

谈到自动化运维工具，混运维圈的通常能来个贯口，说上十个八个的。而在众多工具中，Ansible、Puppet、SaltStack、Chef应该是知名度最高的四个。

而经过笔者的经验，目前银行业或者说金融业，受关注度最高的应该是Ansible、SaltStack和Puppet三个。这其中，Ansible算是后起之秀，但大有后来居上的态势。

接下来我们看看三者的对比（这张图源自google搜索）：

从上图看，整体而言，Ansible不需要客户端（agent）这点上，很符合很多大行的监管要求的。在支持的操作系统平台上，Ansible与Puppet、SaltStack基本打个平手，但不要一点，由于ansible不需要客户端，并且可以通过openssh认证，就决定了它不仅忽略可以管理各种OS（作为自动化工具的基本功，就像售前必须会讲PPT），它还能支持很多其他类型的平台和设备。

Ansible几乎支持数据中心的一切自动化，包括系统本身各种自动化工作，同时它还支持：

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

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

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

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

• 红帽解决方案：支持几乎所有红帽解决方案的一键部署和配置：Openshift、Ceph、Gluster等。

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

在上图中，关于是否支持web ui这一项，ansible写明是需要商业版本。其实这指的是Ansible Tower。因为Ansible是免费使用的，Ansible Tower是付费产品。

关于Ansible Tower收费这个问题，很多朋友问过我怎么破，我的观点是，根本无需破。因为在我所关注的金融行业，尤其是银行业，自动化工具是否收费的优先级排名，远远低于这个工具的安全性和可控性。

我们想象一个场景，IT管理员要删除/var/log下的所有文件，正常的操作是这样的:

如果是这样呢？

如果使用了自动化运维工具，在1000个Linux上进行了这样的操作呢？

当然，首先这种错误很低级，犯这种错误概率很低。但一个运维工程师职业生涯中犯过一次类似这样的错误，他的职业生涯和被犯错误的IT系统所承载业务系统的公司，很可能就Over了。

所以，Ansible Tower除了提供ansible的 UI，它更是（如果我们把ansible理解成esxi，那可以将ansible tower理解成vCenter）：

一个简约的按角色／权限／控制的的集中自动化平台，与操作／日志／审计／版本控制结合的一个数据中心自动化管控平台。AnsibleTower本质上是Ansible的统一管理界面，类似虚拟化中的管理平台。它可以和AD，LDAP等认证方式做对接、通过统一图形化界面直观地看到被管系统的状态。

所以说，Ansible Tower是能够匹配IT在银行业江湖地位的自动化运维工具。因为他安全可控，他靠谱。

不看广告看疗效--两个例子：

接下来我们看看Ansible本身的易用性。我们，举两个例子：

第一个例子:

实现目的：批量给大量Linux操作系统修改密码，修改密码的用户名和密码参数化，并且在执行过程中输入：

ok，接下来看干货。首先写个简单的playbook：

然后，本地执行，确认有效：

接下来，通过ansible tower依赖此playbook先创建项目，再创建模板：

创建项目：

创建模板：

然后，在模板最下方，注明prompt变量：

这样，当我们运行模板时，会提示输入变量，也就是需要修改多台Linux主机的那些用户，并且将密码修改成什么(不用担心密码明文，后台都是以MD5方式传输和注入密码的)

执行成功：

第二个例子：

目的：为500个Linux操作系统进行基线检查，检查结果生成excel表格，统一展示。

首先，我们先看一个Linux系统执行效果：

那么，基线设置如何实现的呢？

首先，我们先为不同版本RHEL设置不同的基线项：

进入到rhel7目录中，查看一个基线检查项（检查密码复杂度）的描述：

这个检查项的设置是：密码长度至少是8位(minlen=8)；密码必须至少包含一个大写字母(ucredit)、一个小写字母(lcredit)、一个数字(dcredit)、一个标点符号(ocredit)。

而基线检查的playbook，正是将几十个基线检查项的参数设置汇总，对指定多的linux主机进行查看，并生成excel表格的。

可能有人会问，这个工作量大不大？实话实说，不小。但是，我们已经在金融行业，尤其是银行业，通过项目，积累了大量的经验和playbook，可以为我们的客户使用。