银行IT系统的质量控制_银行IT系统

传统的IT架构使用了这么多年，所有的监控设备以及网络架构都是基于此打造，那么在传统架构虚拟化、云化后的今天，如何针对虚拟化、云计算的环境如IAAS、PAAS进行运维？

传统监控系统主要是基于传统的环境构建。主要是针对基础的硬件设备、业务系统的监控，对于虚拟化环境的覆盖是不足甚至可以说是零覆盖的，特别是在虚拟化技术引入之后，每台宿主机里面的众多虚拟机怎么去运维？众多的容器 、微服务 、APP怎么运维

如何监控是云化后运维监控面临的挑战。

博睿数据依托完整的IT运维监控能力，公司利用大数据和机器学习技术构建的先进智能运维监控能力，可基于自身的通用性，满足最为广泛的用例，有效控制企业成本，确保数字化业务平稳运行，保证成功交易，保障良好的数字化体验，更有针对性地向客户提供服务。

截至2023年3月1日，博睿数据已经拥有17项已授权发明专利、111项软件著作权、27项核心技术，在应用性能管理领域实现了多项技术突破，具备较强的技术先进性。如今，公司已经与CNNIC、CFCA、IATA、中国互联网协会、数据中心联盟、中国信息通信研究院、中国金融产业科技发展联盟、华为等机构和企业达成了多元合作，并成为中国信息通信研究院AIOps标准工作组、中国电子工业标准化技术协会信息技术应用创新工委会等行业权威组织的会员单位。

博睿数据秉承“让IT运营更智能”的品牌理念，成立15年以来，公司已在北京、上海、广州、深圳、武汉、成都等地设立了营销中心，在北京、武汉、厦门等地设立有研发中心。持续对IT运维监控技术的专注，使得公司的解决方案覆盖了IT运维监控管理所有分支领域（DEM、APM、ITIM、NPM和智能运维管理），并被广泛应用于互联网、金融、制造业、电信相关服务、电商等多个领域，客户包括阿里巴巴、腾讯、百度、华为、国泰君安证券、中信银行、中国南方航空等行业巨头，覆盖IT运维人员、开发人员、技术支持人员、前端业务人员等多种职业角色。

金融 科技 薄弱

关于金融 科技 对于银行未来发展的重要性，我曾经写过多篇文章论述，最近的一篇是《金融 科技 助力银行业务》。可以说，金融 科技 是银行转型发展的重要基石。在金融 科技 的竞争中，全国性大型银行已经一马当先了，相比之下地方中小银行在金融 科技 方面已经全面落后。

在基础架构方面，大型银行中有些已经完成了从传统IT架构向云计算基础架构的转型。在应用开发方面，四大行和招行已经基本完成了核心系统的自主可控开发和周边系统的敏捷开发，IT系统对于业务的响应速度大幅提升。

但是，反观地方中小银行目前的IT基础架构还是以传统的竖井式结构为主，应用开发严重依赖于ISV和外包公司，整个IT建设思路缺乏统一规划。以至于，现有的IT系统不仅无法支持银行的业务创新，连基本的精细化管理都难以推进。当然，这种落后并不完全是中小银行管理的问题，里面有几个客观存在的因素：

首先是规模效应问题，云计算，Dev-Ops，开源自主开发，人工智能，大数据等这些技术是非常好。但是，有个问题是金融 科技 的投入是巨大的，全套玩下来IT预算非常大。这里面不仅包括大型计算中心的建设，还包括常年维持巨大的开发运维团队。以招行为例，2017年之后开始加大金融 科技 的能力建设，5年的时间，开发人员从原来的800多人增长到8000多人。像工商银行这样的巨无霸，IT开发运维人员有接近20000人。

如此，巨大的IT投入，需要银行的业务规模和营收能力与之相配。因为，IT建设具有明显的长尾效应，即同样的系统服务1000万客户和服务1亿客户的成本可能只增长一倍，但是收入可能会增长4-5倍。所以，金融 科技 是有阈值的，如果规模没有达到一定级别，金融 科技 更像是一个花瓶，中看不中用。中小银行规模小，金融 科技 难有突破性进展。

其次，是IT团队建设的问题。借用**里的一句台词：二十一世纪什么最贵？人才最贵。金融 科技 拼到最后就是拼人才，拼IT团队的技术水平。这里就有个大问题，我国的IT发展极不平衡。IT精英基本集中在北上广深等一线城市和个别IT业比较发达的二线城市，比如：杭州，成都等。其他地方，特别是中西部城市，IT人才难觅影踪。所以，这些地方的地方银行在金融 科技 方面有天然的劣势，基本属于无解。

经营理念陈旧

去年12月1日，银保监会官网发了一篇文章《加快建设中国金融人才库 为中小机构高质量发展提供人才保障》，文章指出：

高风险金融机构出险的重要原因在于，主要高管人员完全是非专业人士，长期存在“乱作为”现象。建设金融人才库主要是加强规范统一管理，鼓励和支持大型银行保险机构临近退休的专业人才，通过市场化双向选择，到中小银行保险机构担任董事长、高级管理人员、独立董事或外部监事等职务，更好发挥其丰富的经验和专业价值，补齐中小银行保险机构金融人才队伍建设短板。

这篇文章也从一个侧面作证了我这里要谈的：目前国内很多中小银行的高管经营理念陈旧，对风险控制还是凭经验，对国家金融发展的认识滞后于经济发展的实际需求。存款立行，规模为王，存贷为主的业务模式和目前国家倡导的大力发展直接融资，稳杠杆，支持新兴 科技 和普惠金融的发展方向不一致。

未来，随着居民财富管理意识的觉醒，居民存款被分流是必然的结果。银行的负债结构必须多元化，存款，同业，央行借款多渠道发力。对公客户的金融需求也会更加多元化，需要银行提供的是综合金融服务，而不是仅仅依靠压低利率放贷款。

我国经济降速换挡，过去那种拉来存款一定能放出去，放出去的贷款就一定能挣钱的日子一去不复返了。货币增速下台阶，规模扩张对不良的稀释作用降低。银行需要根据风险和盈利能力去做业务决策。过去粗放的经营理念已经完全不能适合经济发展的需求，银行未来需要以精细化经营为基础，推进EVA, RORAC等监控体系，让银行从一味做大走向做有特色的银行。

地方债务暴雷风险增加

最后这个困境是一个老问题，这个老问题在当下的环境中更加严峻了。地方债务如果从狭义上讲是指地方政府在公开市场上发行的债券。因为，地方政府原则上讲是不能向银行贷款的，但是地方政府管理的国资公司可以向银行就某具体项目贷款。这种地方国资管理的公司举债行为，就是我们说的广义上的地方债务。

广义地方债务最主要的呈现形式就是地方政府融资平台。 地方政府融资平台就是指地方政府发起设立，通过划拨土地、股权、规费、国债等资产，迅速包装出一个资产和现金流均可达融资标准的公司，必要时再辅之以财政补贴作为还款承诺，以实现承接各路资金的目的，进而将资金运用于市政建设、公用事业等项目。

地方政府融资平台主要表现形式为地方城市建设投资公司（简称“城投公司”）。这类城投公司多数不具备独立盈利能力，主要依靠地方政府补贴或者度让部分权益。多数城投公司都或明或暗地具有地方隐形担保。所以，地方融资平台的债务应该被算作地方政府的隐性债务。地方融资平台的偿付能力主要依靠地方政府的财政收入。

今年国家加强了房地产调控的力度，房地产公司拿地热情下降很快，不少二三线城市的土地供应出现了流拍。土地财政是目前地方政府财政收入的主要来源，如果这部分收入减少，有些地方的城投公司偿债能力将出现较大的问题。过去，银行给城投公司贷款考虑到政府的隐形担保，默认风险是很低的，如果一旦这个趋势出现反转，地方融资平台贷里面可能出现不少雷。

一般全国性银行对于地方融资平台的贷款是比较慎重的，会选择经济比较发达的省市发放平台贷，而且也会严控平台贷的总体风险敞口。以招商银行为例，2020年招行在年报中披露：

境内公司贷款余额1,14902亿元，较上年末增加8727亿元，占本公司贷款和垫款总额的243%，较上年末下降011个百分点。报告期内，受宏观经济下行等因素影响，个别企业风险有所暴露，截至报告期末，地方政府融资平台业务不良贷款率055%。2021年，本公司将按照“优选区域、择优支持、合规运作、限额管理、强调自偿、一城一策”的总体策略，秉承商业化原则，坚决打消政府兜底思维，根据项目和客户经营性现金流对自身债务的覆盖程度优选业务。

但是，地方性银行特别是欠发达地区的地方性银行有大量的贷款投向了地方融资平台。地方融资平台的贷款在银行贷款分类中的类别属于“租赁和商务服务业”。国家统计局对于“租赁和商务服务业”的定义中74大类的7412小类“ 投资与资产管理 ” 与地方政府融资平台高度相关。

有兴趣的读者可以自行查看关心的城商行这一分类下的贷款余额占比和不良率。你们会发现很多城商行这一块的贷款占比远高于全国性银行。目前我观察的数据介于6%~20%之间，甚至有些城商行此类贷款是对公贷款分类中占比最高的。而这部分贷款的不良率又非常低，多数不足1%，有的甚至常年低于05%。

所以，我们表面上看着很多上市城商行的不良率很低，其实有一定地方平台隐性债务风险暴露不充分的原因。明、后年，这部分贷款的资产质量将受到一定考验。实际上，今年有些地方的土地出让就是清一色的本地城投公司兜底拿地。这是在为地方政府财政续命，把问题往后拖。但是，土地财政的问题终究是要解决的，如果未来货币增速放缓，那么地方融资平台的风险无法得到稀释，能藏得了一时藏不了一世，总有一天会图穷匕见的。

在IT系统的需求分析阶段，保证项目以业务需求为目标; 在系统交付时，进行充分的功能测试和性能测试; 在运行阶段，保持对系统的监控，这是进行IT系统质量管理的关键。 IT系统作为银行业务的有力支撑，越来越受到重视，各家银行纷纷通过改善IT系统来节约实施和维护成本，提高客户的满意度和增加收入。但是，随着IT系统的建设越来越多，结构越来越复杂，如何保证IT系统的质量，使其真正能够满足日益发展的业务需要，逐渐成为各家银行重点考虑解决的问题。具有雄厚资金实力和IT投资预算的大型商业银行，已经开始着手IT系统和软件产品的质量控制和管理建设，制订出从业务需求到开发、测试、部署以及产品和系统上线以后的实时监控等一揽子规划，并且开始着手购买各种软件和工具进行实施。但是对于大多数银行，每年的IT预算有限，如何保证IT系统的质量面临不小困难。笔者结合目前国际上流行的质量控制和管理趋势，根据自身在银行方面质量管理和控制项目支持的经验，提出一个分阶段分步骤进行建设的建议，以供广大银行的决策者及相关人员参考。

测试工具的选择

银行作为一个特殊的行业，对于IT系统的功能性要求和性能性要求都比较高。对于银行IT系统，功能上不能有丝毫的马虎，客户交易必须正确记录，决不允许错记、漏记，如果发生错误，对于客户是经济损失，对于银行来说则是信用的损失。性能上为了提高客户的满意度，在各种渠道上都需要保证在一定的时间内完成交易，如果客户存取一笔款项需要花费很多时间，那么客户对于银行的抱怨是无法想象的，很有可能使这位客户转而投入其他银行的怀抱。从技术上说，对于功能和性能方面的质量都必须通过测试来进行验证，这是保证IT系统在功能和性能方面能够满足业务需求的基础。在功能和性能方面的投资可以优先考虑两个方面: 测试管理工具和性能测试工具。

软件测试目前作为软件工程中的一个重要的环节受到各个企业的重视，并且大家也普遍承认，这是一个需要进行有效管理的过程，因为其中涉及到测试需求的选择、测试案例的设计、测试执行的管理以及缺陷跟踪的流程等多个方面和环节，如果还停留在依靠手工处理、电话或者邮件通知、人工收集数据、使用Office软件来进行统计的阶段，那么工作量相对来说是很大的，而且不能及时反映整个测试阶段的进程和情况，因此在准备进行测试时，选择一个业界承认的优秀的测试管理工具是很有必要的。

选择一个好的测试管理的意义在于:

● 能快速学习测试管理工具中附加的先进经验和最佳实践;

● 能有效地进行测试资产的集中管理和控制;

● 能理顺并完善适合本企业内部的测试管理流程，并且映射到测试管理工具中;

● 能促进各个团队进行有效沟通和分工协助;

● 能方便地进行各种数据统计和图表处理，有利于了解项目测试的情况。

在选择测试管理工具时，决策者和相关人员可以根据以上要求来考量测试管理工具是否适合和满足本企业的要求，同时要考量测试管理工具的平台性，即不仅仅只是一个工具，而同时要具有开放性、可扩展性等平台特性，这样才能很好地融入到企业IT建设架构中，真正地成为企业IT建设的基础。

功能和性能测试方面的投资当然是以性能测试为主。原因一方面在于，IT系统的性能问题不易发现，在测试期间只有少量用户使用，往往不会暴露出存在的性能瓶颈，只有上线了以后，千百个分行支行网点的用户使用、并发量大的情况下才会出现，而使用性能测试工具可以模拟这种大批量的用户并发使用。另一方面，性能测试要衡量的指标有很多，依靠工具更加易于进行统计和分析，帮助测试人员发现和定位性能问题。

选择性能测试工具要考量的指标一般有:

● 是否易于创建测试脚本。如通过录制就可以完成，不需要或者需要很少的手工编制;

● 是否能够精确地模拟现实中系统上线后的运行情况;

● 是否能够在压力加载的同时，收集被测系统的资源消耗情况，并且这些数据是真实准确的;

● 是否提供了强大的分析模块和报告生成能力;

● 是否能够和测试管理工具很好地集成。

性能测试工具的价格往往很昂贵，在购买时可以考虑先购买部分功能和模块，然后再分阶段逐步完善。

在自动化功能测试方面，尤其要注意不要盲目地购买，然后仓促地、大范围地在系统功能测试中使用。因为自动化功能测试工具的优点在于通过可重用的脚本和模块，简化脚本创建和维护的工作，同时通过重放，在回归测试中将测试人员从重复性的单调 *** 作中解放出来，使他们更加专注于缺陷修复和功能变更后的模块测试。由于自动化功能测试工具目前大多是通过录制生成脚本，如果以单独一次测试来和人工相比，往往不具有明显的优势。使用自动化功能测试工具能够提高投资回报率的关键在于，通过自动化功能测试工具测试生命力相对持久的系统。例如银行核心业务系统、信贷系统等，通过不断积累和完善该系统的功能测试脚本，可简化该系统变化相对不大的模块的功能测试。

在选择功能测试工具时，需要考虑的最主要指标是工具的简单易用性，因为就实际经验来说，自动化功能测试工具往往由业务人员直接使用，如果 *** 作简单，脚本可维护性好，结果报告清晰明了，那么就会达到事半功倍的效果。

总体上，第一阶段可以考虑优先购买和实施测试管理工具和自动化性能测试工具，同时可以考虑选择一到两个相对修改不会很大的系统来使用自动化功能测试工具录制功能脚本，进行自动化功能测试前期的积累。

逐步建立质量管理体系

如果前一阶段我们的目的是选择测试管理工具和测试工具，同时选择固定的人员，组建相对独立的测试队伍，实现知识共享和经验积累，那么第二阶段我们的目标就是基于本企业内部的情况，制定出适合本企业的质量管理体系，全面控制和管理测试工作，加强功能和性能测试方面的自动化程度，将测试工作和测试团队纳入到整个企业的质量管理工作中，同时可以考虑在本阶段将设计、开发和测试集成起来协同工作。

这一阶段我们应该充分发挥测试管理工具的开放性和集成性，一方面通过它实现与设计、开发、部署等过程良好集成，例如将设计需求快速转变为测试需求，通过测试管理工具管理 单元测试 等; 另一方面可以通过工具提供的功能或者二次开发，建立关键性能指标，从测试管理工具中提取数据，展现测试项目和测试工作的全面视图，例如缺陷的趋势图（每天新增加的缺陷和处理完毕的缺陷）、测试案例计划和执行分析图、测试项目总体进度图等，这样就能通过完善系统质量的衡量指标，逐步建立起质量的评估体系来。

在功能和性能测试方面，由于经过第一个阶段自动化功能测试的积累，已经具有很强的脚本编制和功能组件划分能力，因此可以逐步建立起自动化功能测试的框架，这样做的好处在于: 首先，可以大大简化后期脚本的维护和自动化功能测试的运行; 其次，可以利用框架，快速构建新的系统的自动化功能测试; 再次，可以充分利用业务人员对于业务的熟悉，让他们加入到自动化功能测试过程中来，便于他们使用自动化功能测试工具; 最后，具有一个良好的框架，将来可以快速建立基于业务流程和数据驱动的测试方法，推动回归测试和冒烟测试。

性能测试在这个阶段可以继续深入，一方面通过工具进行针对应用开发代码的性能诊断，协助开发人员发现和定位代码方法级别的性能瓶颈，另一方面要收集各种测试的结果数据，建立起性能和硬件配置的估算模型，充分保证在硬件投资上的最合理支出，提高投资回报率。

该阶段还需要加强的是设计、开发和部署时通过建模工具、配置工具、变更管理工具、运维监控工具、帮助开发人、测试人员和运维人员协同工作，高效率地完成应用系统的整个生命周期中关键环节的管理。由于中小型银行系统主要以外包为主，这里就不做细致的阐述了。

该阶段要注意的是，由于开发以外包为主，所以更需要加大测试方面的投入。因为完善的设计理念、先进的开发技术和方法论、良好的团队合作和项目管理，并不能绝对保证开发出具有优秀功能和性能的应用系统，更何况系统的参数配置对运行的性能影响同样巨大，因此功能和性能是否能够满足业务的需要，最终还是要通过测试来检验。这就好像一个人，虽然具有良好的家庭背景、教育环境、生长氛围，并不一定会成为一个优秀的人才一样，是否有能力能够胜任工作，还是需要通过考试等测评方法来衡量他的综合素质才可以下结论。

促使IT系统和业务目标的统一

银行业IT系统的根本目标是提高生产效率，为银行业务的实现提供强有力的支持。因为银行IT系统本身并不会为银行带来经济收入，收入是依靠其支撑的业务运营来实现的，因此IT系统从设计的那天起，就决定了其要为业务运行服务，要帮助达成业务目标。

但是实际应用开发过程中，由于开发人员过于理想化、开发管理不善等各种问题和各种变化，往往导致最终完成的系统与业务目标具有一定的偏离，这种偏离有时候是很大的，甚至可以称作鸿沟，而IT系统质量管理发展阶段的最终目标就是建立机制，消除这种鸿沟，使IT系统真正能够满足业务目标的需求。

要消除这种鸿沟，可以从以下几个方面考虑:

● 需求和项目管理。这里的需求指的是业务需求，通过项目全生命周期的有效管理，保证应用开发项目的设计、开发和测试都以业务需求为目标，使项目最大化地满足业务需求，实现业务价值。

● 质量保证。通过测试保证应用系统在功能上满足业务需求。

● 性能验证。通过测试验证应用系统在性能上是否满足业务需求。

● 服务水平管理。应用系统上线后，通过实时监控等手段保证应用系统能够满足服务水平协议，使最终用户能够通过应用系统实现业务 *** 作，提高最终用户的满意度。

● 变更生命周期管理。在应用系统整个生命周期中，能够使需求变更被控制在管理范围内，并且能够按照需求的这种变更快速地组织开发、测试和上线后的监控，使这种变更还是依照业务需求进行。

可以看出，需求和项目管理、变更生命周期管理两方面都需要银行内部各部门之间的协助，只有建立起全面的内部质量管理体系和制度才能很好地实现，而质量保证和性能验证就是前阶段的功能测试和性能测试。只有通过测试，才能从功能上和性能上保证应用系统满足业务需求。

这里面要强调一下服务水平管理，虽然目前银行运维部门大多已经具有一系列的工具和手段，可以监控Unix服务器、数据库、网络等底层应用基础架构运行的状况，但是银行是以业务为主导的，最终这些软硬件的运行是要保证业务功能的实现，因此银行监控观念和侧重点应该有一定的转变，即最关键的应该是监控业务功能是否能够正确实现，业务流程是否能够正常流转。举例来说，网上银行系统被不小心修改了登录页面，导致页面出错，这时候传统的监控工具看到的情况是Unix *** 作系统正常、数据库正常、网络正常，但是客户却不能使用网银系统，如果使用了基于业务流程的监控工具，就可以监控到这种错误，并且报警，同时可以帮助运维人员定位到是应用级别出现了错误，从而帮助快速解决这个问题。

选择这类监控工具一方面是要考虑能够有效地模拟真实的用户 *** 作，另一方面是能够将业务流程和底层应用基础架构映射，将业务流程的失效定位到应用基础架构问题。

至此本文介绍了银行IT系统质量管理建设各阶段要考虑的方面，如果我们把银行应用系统比做一个人，那么各阶段的建设可以形象地总结如下:

● 测试先行。就像人定期的健康体检一样，以检查是否有潜在的疾病。

● 全面的质量管理体系。从饮食习惯、作息起居、日常锻炼等方面来提高人的机体的整体免疫力。

● IT管控，消除IT与业务需求的鸿沟。真正明白人生存的价值和意义，不仅仅要有一个健康的体魄，更要从精神、心态等方面来全面调节生理和心理，使自己具有一个乐观、积极的人生。

（作者单位:美科利公司技术顾问）

行业里有个笑话：越高级的运维越像个隐形人！所以楼主是遇到困惑了，提供自己的能力吧！

说到运维，多半是甲方单位招聘的，乙方一般是研发和实施。项目结束后甲方需要运维。从基层职位看，运维和开发（含产品经理）的分工还是挺大的。

本人做软件开发多年，平时主要考虑功能和非功能的实现，运维负责系统上线后系统的稳定、高效运行。所以在所需技术上也大有不同。

开发重点在各种开发语言、开发框架、持续性集成环境、软件工程、算法以及对应的业务等等，对底层的运行环境 *** 心的不太多，尤其上了云环境之后，越来越少 *** 心负载均衡、高可用这些非功能需求。

运维的重点在于系统运行的各种环境，从机房、网络、存储、物理机、虚拟机这些更基础的架构，到数据库、中间件平台、云平台、大数据平台，偏重的也不是编程，而是对这类平台的使用和管理。

所以开发重建设、运维当然就是维护。所以运维比开发更不受重视也是可以理解的，很难出彩，不出事就是成绩，尽管付出的努力并不少，甚至更多。看过产品运营的人说过一句话“不要管开发做出的是什么垃圾产品，留住客户才是运维关心的“

但是在高层考虑中，尽管运维仍然受重视程度比不上开发，但已经不仅仅是考虑要尽快满足业务需求的问题了。基础架构越来越有话语权。一方面，确实这个是很耗钱的事情（有钱就有话语权）。开发个系统不是有代码就能运行的，养个机房（特别是高端机房），动辄投资也得上亿，上千台服务器也不是那么容易管的，每年的折旧、报废也是钱啊，光电费也够养几个高级RD了。另一方面基础架构，特别云化之后，更是要制约开发使用的语言和程序架构。还有越来越受重视的安全管理，更是巨大的投资，甚至上升到维稳层面。

但是总体来说，运维工程师是IT的后台，IT是一般甲方业务的后台。所以，重要是很重要，但是可能永远不如RD受重视。当然，小部分运维也很受重视，比如制造业，但毕竟是少数。

所以，it运维工程师选择就没有回头路，努力提供自己能力是王道！

以上就是关于企业建立支持数字化转型的组织架构，IT部门应该如何应对全部的内容，包括:企业建立支持数字化转型的组织架构，IT部门应该如何应对、关于地方中小银行的思考之困境篇（下）、银行IT系统的质量控制_银行IT系统等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！