什么样的运维神通，才配得上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、RedHatCloudForms、Google、Linode、DigitalOcean等
在上图中，关于是否支持webui这一项，ansible写明是需要商业版本。其实这指的是AnsibleTower。因为Ansible是免费使用的，AnsibleTower是付费产品。
关于AnsibleTower收费这个问题，很多朋友问过我怎么破，我的观点是，根本无需破。因为在我所关注的金融行业，尤其是银行业，自动化工具是否收费的优先级排名，远远低于这个工具的安全性和可控性。
我们想象一个场景，IT管理员要删除/var/log下的所有文件，正常的操作是这样的:
如果是这样呢？
如果使用了自动化运维工具，在1000个Linux上进行了这样的操作呢？
当然，首先这种错误很低级，犯这种错误概率很低。但一个运维工程师职业生涯中犯过一次类似这样的错误，他的职业生涯和被犯错误的IT系统所承载业务系统的公司，很可能就Over了。
所以，AnsibleTower除了提供ansible的UI，它更是（如果我们把ansible理解成esxi，那可以将ansibletower理解成vCenter）：
一个简约的按角色／权限／控制的的集中自动化平台，与操作／日志／审计／版本控制结合的一个数据中心自动化管控平台。AnsibleTower本质上是Ansible的统一管理界面，类似虚拟化中的管理平台。它可以和AD，LDAP等认证方式做对接、通过统一图形化界面直观地看到被管系统的状态。
所以说，AnsibleTower是能够匹配IT在银行业江湖地位的自动化运维工具。因为他安全可控，他靠谱。
不看广告看疗效–两个例子：
接下来我们看看Ansible本身的易用性。我们，举两个例子：
第一个例子:
实现目的：批量给大量Linux操作系统修改密码，修改密码的用户名和密码参数化，并且在执行过程中输入：
ok，接下来看干货。首先写个简单的playbook：
然后，本地执行，确认有效：
接下来，通过ansibletower依赖此playbook先创建项目，再创建模板：
创建项目：
创建模板：
然后，在模板最下方，注明prompt变量：
这样，当我们运行模板时，会提示输入变量，也就是需要修改多台Linux主机的那些用户，并且将密码修改成什么(不用担心密码明文，后台都是以MD5方式传输和注入密码的)
执行成功：
第二个例子：
目的：为500个Linux操作系统进行基线检查，检查结果生成excel表格，统一展示。
首先，我们先看一个Linux系统执行效果：
/dev/sda1*20482099199104857683Linux/dev/sda22099200167772159828364808eLinuxLVM————————-/dev/mapper/rhel-root50G8.7G42G18%//dev/sda11014M173M842M18%/boot/dev/mapper/rhel-home26G37M26G1%/home————————-192.168.137.42kdump_is_enabledTrue192.168.137.42selinux_is_disabledTrue192.168.137.42runlevel_is_3False192.168.137.42bonding_confN/A192.168.137.42ntp_confTrue192.168.137.42logrotate_confFalse192.168.137.42audit_confFalse192.168.137.42filesystemFalse192.168.137.42ulimit_confFalse192.168.137.42crontab_disable_mailTrue192.168.137.42password_agingFalse192.168.137.42password_complexityFalse192.168.137.42password_multiplexingFalse192.168.137.42password_lockingTrue192.168.137.42no_uid0_except_rootFalse192.168.137.42no_emptypasswordTrue192.168.137.42systemaccount_disabledFalse192.168.137.42unused_service_disabledFalse192.168.137.42shell_history_time_formatFalse192.168.137.42shell_prompt_commandFalse192.168.137.42shell_history_ignoredupsFalse192.168.137.42shell_histsizeFalse192.168.137.42shell_timeout_setFalse192.168.137.42file_umask_setFalse192.168.137.42disable_usb_storageTrue192.168.137.42ctrl_alt_del_disabledTrue192.168.137.42grub_password_protectFalse192.168.137.42Xwin_disabledFalse192.168.137.42sshd_port_22True192.168.137.42sshd_proto_v2True192.168.137.42sshd_disable_root_loginFalse192.168.137.42sshd_loglevel_infoTrue192.168.137.42sshd_MaxAuthTries_setFalse192.168.137.42sshd_disable_EmptyPasswordTrue192.168.137.42sshd_banner_setFalse192.168.137.42vsftpd_confFalse192.168.137.42issue_file_updatedFalse192.168.137.42file_permissions_confFalse192.168.137.42dangerous_file_removedTrue192.168.137.42command_su_confFalse那么，基线设置如何实现的呢？
首先，我们先为不同版本RHEL设置不同的基线项：
进入到rhel7目录中，查看一个基线检查项（检查密码复杂度）的描述：
这个检查项的设置是：密码长度至少是8位(minlen=8)；密码必须至少包含一个大写字母(ucredit)、一个小写字母(lcredit)、一个数字(dcredit)、一个标点符号(ocredit)。
而基线检查的playbook，正是将几十个基线检查项的参数设置汇总，对指定多的linux主机进行查看，并生成excel表格的。
可能有人会问，这个工作量大不大？实话实说，不小。但是，我们已经在金融行业，尤其是银行业，通过项目，积累了大量的经验和playbook，可以为我们的客户使用。
