1.3.2　拆IT系统“烟囱”的挑战

近年来，很多商业银行都提出“科技引领”“科技赋能”等口号，也充分体现了银行业对信息科技能力建设的重视。但对于银行信息科技部门来说则是喜忧参半，他们既要不断响应业务部门需求，快速发布相关的应用系统以匹配新提出的业务需求，又要保障存量已上线业务系统的可靠、稳定运行。对于IT能力本就不足的中小商业银行而言，根本无力承接。如果信息科技部门尚未做好充分准备，那么在这个过程中必然会被动触发IT服务管理方面的变革，IT运维团队面临的可能是来自技术架构、业务架构等多位实力选手的组团围攻，竖烟囱式业务系统的同学已经做好热身，准备首发上场。

随着业务的发展，上线投产的各类系统必然会越来越多。比如，开发部门收到新的业务需求后，发现由于之前的设计在通用性和业务前瞻性方面考虑不足（很多银行采用第三方项目外包或人员外包，缺乏长远规划或者人员能力参差不齐），要满足新的业务需求，原有的应用系统就需要做出较大改动，这样一方面有可能会对原有的业务系统造成影响，另一方面，时间紧、任务急，客观条件上也不允许。在这种情况下，研发人员宁愿选择保持现有服务稳定，重新开发一套与这套差不多的业务系统。我想科技团队一线人员对此应该深有体会：线上运行着大量功能高度重合，但完全独立运行的应用系统。长此以往，一个个烟囱式业务系统就竖起来了。

由于对业务需求的理解偏差、频繁出现的需求变更、架构规划的前瞻性（这是很考验设计功力的），以及技术栈的更迭，在业务规模和业务系统不断扩张的背景下，支撑业务运行的应用系统在投产运行一段时间后，其设计的软件架构不能很好地支撑业务的发展（不管是自研还是外采，都存在这样的情况）。涉及架构层面的更迭从来都不是小事情，尤其我们身处银行业，业务不能停，服务不能断。所有想法的出发点都是好的——原有系统上的业务照跑，先重新规划一套新的架构，等待基于新架构运行的系统上线稳定之后，再将老系统逐步迁移和切换过来。但实际情况是，迁移和切换是不可能的，甚至在整个软件生命周期内都不可能，不管新系统还是老系统都会长期运行下去。毕竟生产环境上线一套系统很容易，但想下线一套应用实在太难了，于是架构的烟囱也竖起来了。

在过去虚拟化尚未普及的年代，一台物理机上往往要部署多套应用系统，这也与应用系统架构和业务规划有关。大部分应用系统在上线前期申请资源时，哪怕明知道初期不会有太大流量，但是考虑到未来预期，仍然会对计算、存储、网络资源等设备设施提出较大容量需求。而实际上线后，在一段时间内系统负载并不高，设备利用率有限，资源闲置的情况比较普遍，那么在这种情况下，当需要上线新的应用系统时，会优先考虑部署在有空闲资源的基础设施中，于是系统部署的烟囱也竖起来了。

不知不觉，隐患逐步累积。一方面，不同的应用系统所需的运行环境、资源可能有较大差异，将不同应用系统整合部署在一起其实极具挑战性，IT运维管理的成本和复杂度直线攀升，也会给运维标准化、自动化、资源管理等方面带来相当大的障碍；另一方面，业务需求持续不断，随着时间的推移、人员的流动，整个架构越来越复杂，系统升级改造变得越来越吃力，到最后某个业务链路已经复杂到完全无法直视，没有任何一个人能够完整讲清楚，任意小的改动都可能牵涉一堆系统，让信息科技的管理者感觉整个应用系统和业务服务都处在失控的状态。

这样的场景并不是在讲故事，即便是现如今，“照着XXX系统改一改，很快就能上线一套新的”“为什么不能在一台机器上部署多个应用”“现有系统已无法满足未来业务需求，必须重构”这样的声音仍然时常在耳边响起。

国内外现代商业银行信息化的实践表明，IT管理思维的升级所带来的竞争优势远胜于依靠采买更多更先进的计算机设备，这一点在银行业内也基本成为共识。我们必须正视，基于目前的技术水平，并在目前对数据实时强一致性的要求下，大多数商业银行的核心业务场景尚不能完全摆脱对集中式架构的依赖；必须认识到，IT系统本身必然会经历渐进式演进过程；必须重视IT架构转型，加强向在新技术应用方面更具优势的互联网企业学习；必须加强与业务部门的密切合作，协同推进IT架构以发挥其最大价值；必须从顶层设计出发，构建规范、灵活，兼具稳定与开放的信息科技架构体系，使它既适用于传统的瀑布式大型项目开发，也能兼容敏捷开发模式，推动创新产品的迅速投产。