分布式 / 容器化背景下，中小银行传统基础架构岗位面临的新挑战以及应对方法

分布式 / 容器化背景下，中小银行传统基础架构岗位面临的新挑战以及应对方法

1、前言

随着 AI 、大数据、云计算、分布式、容器化等 IT 新技术日新月异地发展，以造价高昂的 IOE 架构为基础的传统银行 IT 业也受到了极大地冲击，传统银行 IT 基础架构正面临诸多由稳态逐步向敏态转型带来的挑战。本文从基础架构的角度出发，结合作者自身的工作经历，就技术转型过程中遇到的问题提出一些个人看法与大家交流，以期达到抛砖引玉的目的。

2、面临的挑战

传统银行 IT 运维部门，一般是由负责基础架构、 DB 以及网络这几个部分组成。随着近年来 IT 技术发展的速度越来越快，出现的新技术越来越多，对运维人员的要求也越来越高。同时，由于新上线的业务需求的增加，对硬件的性能及数量的要求也越来越高，这也无疑加重了运维人员工作的负担。同时，运维部门是一个有机的整体，作为基础架构分支的人员，不仅要对本职工作涉及到的技术要有较好的掌握，要想较好的完成自身的工作，还必须要对 DB 、网络甚至业务有一定的了解。

2.1 硬件设备数量的迅速增长

基础架构运维人员无疑是整个数据中心中，与硬件打交道最多的人群之一。随着业务部门新上线的需求以及业务系统越来越多，对硬件的要求也越来越高，这不仅仅体现在对硬件设备性能的要求上，同时也会体现在对设备数量的要求上。新上线的业务系统大多会用上诸如分布式、容器化等新技术，这些对横向扩展支持较好的技术，对底层的服务器 / 交换机等硬件资源提出了近乎于变态的要求。急速增长的设备数量，会对数据中心底层的各方面提出更高的要求：不限于机柜空间、空调制冷、 UPS 供电等等。

2.2 双活 / 容灾架构带来的数据中心整体复杂度的提升

银行 IT 对稳定性要求是较高的，监管部门也对不同等级的业务系统有着不同要求的容灾 / 双活要求。双活架构涵盖了 IT 数据中心运行的各方面的内容，其中不仅会涉及到基础架构方面，如服务器、存储、 SAN 交换机等，还会涉及到网络设备、上层应用甚至业务逻辑。双活、双中心会在日后的发挥越来越重要的作用，同时，支撑起双活双中心的运行，也对运维部门提出了较高的技术及管理方面的要求。

2.3 来自分布式、容器化、云化等新技术的冲击

传统的银行 IT 业经过了近几十年的发展，根据不同银行规模的也发展出了不同的技术路线。从中小银行基础架构普通使用的 IOE 架构来看，稳定性值得称道，即我们通道所说的稳态架构，但传统的稳态架构也带来了成本高、不易实现敏捷开发等诸多缺点。近年来，从互联网公司开始兴起的分布式、容器化、云化等新技术开始慢慢进入我们的视线。银行业和互联网公司的业务方面差异是比较大的，银行业是否有必要对现有的稳态架构进行转型改造，也成为了热议的话题。众所周知，分布式技术出现了有一些年头了，从分布式存储，到分布式数据库等等，一切皆可分布式，但我们是否应该将各种眼花缭乱的分布式技术全盘引入，也有待讨论。

容器技术是另外一个绕不开的话题，其被誉为虚拟化技术出现后的下一个革命性技术。 docker/k8s 作为容器技术目前最火热的代表，已成为事实标准。银行业引入容器技术是迟早的事情，但引入容器技术之后，对于原有业务的改造也是必然的，这将会涉及到很多方面的协调以及配合的工作，这些改造其中的阵痛期，是每个进行容器化改造的银行都必须要经历的。

2.4 来自国产化的冲击

随着去 IOE 的呼声越来越高，以及中美贸易战期间美国对于中国的芯片出口限制等等事件的发生，让国产化的趋势越来越明显。从银行业传统稳态 IT 架构来看，严重依赖于国外的技术，包括但不限于 IBM 大机 / 小机 /Intel x86 CPU ，或者是 IBM/EMC/HDS 的存储，以及广泛用作核心数据库的 DB2/Oracle ，这些封闭的技术不仅让上述的厂商在国内赚的盆满钵满，同时也存在国内无法对其进行自主可控的风险。国产化、自主可控已经是迫在眉睫的要求，由于国内自行研制的软硬件与国外成熟可用的竞品还存在一些差距，这不仅仅体现在产品的性能上，同时会也体现在使用方法上，这使用采购使用国产的软硬件将会对银行传统稳态 IT 架构造成巨大的冲击。

2.5 对自学能力提出了更高的要求

新技术出现的速度越来越快，新技术新产品的引入，这将会要求传统银行 IT 业的运维人员具有更深更广的知识结构，否则将会被时代所淘汰。在熟练掌握并使用传统的稳态架构下的技术多年之后，运维人员必须要学习更多的新知识新技术，才能不被时代淘汰。组织统一大规模的培训基本是不太现实的，新技术的学习，绝大多数情况下都需要我们进行自学，这就对我们的自学能力提出了更高的要求。

3、面对挑战应该如何应对

传统银行 IT 业发生变革是必然的，整个运维部门的技术人员都不可避免的要进行思想、技术层面的转变才能跟上技术的发展以及时代的变化。就以上提出的问题，以及在技术转型中出现的挑战，我们可以从以下几个方面来进行尝试解决。

3.1 积极拥抱新技术

银行 IT 业传统的稳态架构已经用时间证明了其在稳定性方面的表现，但时代在发展，业务也在发展，新技术的出现必然会取代旧技术，这只是时间问题。

举个例子，虚拟化技术的应用。在虚拟化技术出现之前，系统管理员需要管理大量的物理服务器设备，包括但不限于：服务器设备上架安装，操作系统的安装，设备台帐的更新等等工作。自从虚拟化技术出现之后，使得系统管理员从对大量服务器设备繁重的管理工作中解脱出来，虚拟化技术简化了对服务器的管理，提高了硬件设备的资源使用率，节省了机柜的空间以及机房制冷的开销。时至今日，没有人再会质疑虚拟化技术是否值得使用，它已经广泛被应用于各大企业以及银行业的 IT 基础架构中。

新技术的出现，总是为了解决一些传统的旧技术所无法解决的问题。随着业务的增长，企业规模会越来越大，数据以及应用系统也会越来越多。在日常工作中，我们发现性能问题正在越来越多地出现，分布式技术的出现为我们带来了解决问题的曙光。在传统的稳态 IT 架构中，要想对现有架构进行扩容，一般只能进行纵向扩展，也就是所谓的采购越来越高级越来越昂贵的硬件。分布式技术的出现，可以让我们采购相对较为廉价的硬件来实现系统的横向扩展。当然目前各类分布式技术从实现的功能性上说还有诸多的局限，但这并不影响它成为未来的趋势。传统单一集中化的架构已无法满足爆炸式增长的数据操作要求，而对于这些数据的存储、处理、以及分析，我们只能采用分布式的架构来实现。

而容器则是另一个侧重点的新技术。传统的应用发布，需要经过开发人员开发 / 通过预投产环境测试 / 打包安装文件 / 发布新版本到生产环境 / 运行等等这一系列的步骤。而容器技术则是解决了应用的部署麻烦的问题，开发人员直接将测试通过的应用打包成容器镜像，推送到生产环境，运行。它比虚拟机更轻量级，运行更快，是对敏捷开发模式的最好的诠释。

容器技术出现之后催生了窗口云平台，作为广义的 PaaS 平台，容器云平台让我们对业务以及运维的平台化、云化有了更多的想象空间。在日常运维中我们发现，近年来新上的不少业务已经在虚拟机中运行 docker 甚至 k8s ，容器在运行起来之后对 CPU 内存占用较多，导致虚拟化的物理宿主机资源紧张。从统一管理容器平台以及优化虚拟化平台资源利用率的角度考虑，我们计划建设容器云平台，项目将会采购专用的物理机来运行容器平台，以充分利用容器技术的优势来支撑敏捷开发及业务需求。

从上述几个例子中我们能看出，我们不应该对于新技术抱着排斥的态度，它能解决传统的技术所无法解决的问题，同时有助于提高整个 IT 系统运转的效率。唯一的问题可能就是我们什么时候引入新技术，以及我们如何才能更好地掌握新技术，让它们为我们所用。

3.2 推进自动化运维的应用

不可否认的一个事实就是，我们的日常工作其实很多时候都是在做一些重复的事情，比如：新服务器的上架安装需要安装操作系统，发现了软件漏洞之后需要打补丁，调整某些系统参数，系统的容量报告等等。如何提高日常的重复工作的效率，成为了运维人员都比较关注的点。

自动化运维的出现为解决这个痛点问题提出了一个可行的方案。自动化运维并不是一个单一的工具，它是一整套工具的组合，目前市面上并没有一套能适配所有企业使用需求的自动化的方案，不同场景下使用的工具一般是不一样的。例如，对于系统管理员，我们经常需要做的是批量安装部署新上架的服务器的操作系统；对于虚拟化管理员，我们经常需要做的是批量部署同一业务系统的多台虚拟机。

对于基础架构的硬件来说，目前新出的产品大多都会支持 REST API ，这也给我们管理不同的基础架构设施提供了一个新的思路：通过调用 REST API 来实现不同厂商设备的管理以及自动化运维工作。而不同的设备提供的 REST API 接口大多不太一样，需要我们自己去有针对性地学习如何调用。同时， python 作为目前最为火爆的编程语言，运维人员也需要掌握一定的编程技能，让 python 与 REST API 结合起来，自己编写适合本单位使用的自动化运维的小脚本、小工具。

推进自动化运维的应用，我们需要做的就是循序渐进，针对不同的应用场景，使用不同的工具来实现，只有在实际应用中不断地尝试使用不同的自动化工具，不断地优化工具的使用方法，才能探索出哪些工具才是最适合我们使用的，只有这样，才能把我们从那些繁杂重复的工作中解脱出来。

3.3 重视国产化的崛起

去 IOE 的浪潮以及自主可控要求的兴起，让国产化成为必然的选择。而 19 年上半年中美贸易战也让我们看到，我们严重依赖的稳态架构的软硬件，很可能会被美国以国家安全的借口断供！

传统 IOE 稳态架构，我们一般是使用 IBM 的小型机上跑的 Oracle/DB2 的核心数据库，而外围的应用则是跑在 VMWare 的虚拟化平台上。纵观业界，国内自研的操作系统、数据库、 CPU 等硬件目前尚处于早期的阶段。全面国产化在目前看来还不太现实，但逐步使用国内自研 IT 产品替换国外产品的趋势是越来越明显的，我们可以考虑先从外围重要程度较低的业务系统开始做实验性的迁移，逐步进行国产化的迁移。

当然，我们也要看到，国内的 IT 产品跟国外的产品大多都还有一定的差距，不仅是性能上，也包括稳定性上。同时，使用习惯上也可以存在较大的差异，但我们应该以相对宽容的态度来对待国产化软硬件产品，给国产化产品以时间，假以时日，相信国产的产品一定能迎头赶上。

3.4 加强部门之间的沟通

运维部门主要是业务系统运行进行支撑，对业务系统的全生命周期进行运行维护，保障业务系统的正常运行。银行的科技部门普遍由多个下属条线组成，上面提到的几条应对技术架构转型带来的挑战的建议，会涉及到很多需要进行业务改造的地方，都需要各部门配合来进行。

在我们的日常工作中，经常遇到由于沟通不顺畅造成的诸多问题，使得大家浪费了不少的时间来处理原本十分细微的事情。而在整个架构的转型和改造中，由于涉及了太多的地方，则更需要大家坐下来一起协调沟通。例如，对原来某业务系统进行容器化的改造，就会涉及到原系统的微服务化的拆分，这部分需要开发部门来进行。而对原业务进行微服务化拆分的过程中必然会涉及到某些业务逻辑的优化，这就需要开发部门与需求部门沟通。在最后上线阶段，需要运维部门来协调容器化之后的新系统的上线以及旧系统的资源回收等工作。

4、结语

银行业 IT 架构由于其高复杂度，转型实施起来并不容易，除了加强我们自身学习能力来提高技术水平之外，还需要各部门之间相互沟通协调，才能实现共同的目标，跟上时代的技术潮流，为企业的发展贡献出自己的一份力。