由中行IBM大型机宕机谈银行系统运维

12月15日中行IBM大型机宕机，系统没有第一时间切换到热备或者异地容灾上，直接影响中行的信用卡支付相关业务，直到4小时之后才恢复服务。由于银行业务的特殊性，对于系统的可用性要求极高，就此事件，我们采访了兴业银行系统分析师周伟然、支付宝应用运维架构师陆惟凯（花名：近南），请他们谈一下对于银行系统运维的一些看法。

InfoQ：作为一名银行金融行业的IT技术专家，您认为本次中行IBM大型机宕机的体现出哪些问题和教训？

陆惟凯：主要的问题是灾备或大型故障的演练与决策，对于硬件或者机房故障的大型故障，需要有经过验证演练的切换方案来保证切换风险可控。对于故障决策来说是否启动灾备切换是个艰难的决定，不过确实也要能够下决策去切换。其实一切的根源还是在切换方案是否足够可靠、是否经过演练。只要切换风险可控，切换得决策其实不会太纠结。

周伟然：对于本次中行事件，具体原因不了解得情况下不好直接评论。但所谓相关金融系统的运维是一个复杂的系统功能，不能单纯的从main frame的稳定性一概而论。设备运行的稳定性也只是整体系统稳定性的很小部分。除了环境保障中包含的网络环境、硬件资源、存储设备、操作系统数据库等基础软件环境以外，应用运行、系统间互操作等事件都可能产生重大影响。而风险是无法完全避免的，这才显示的出灾难备份和应急预案的重要性，最大程度降低风险暴露后的影响是验证应急体系有效性的重要指标。

InfoQ：ITIL流程是否在您所在的组织中使用？对于类似事故，ITIL流程的处理应该是什么样子？

陆惟凯：使用，不过不是标准的ITIL流程。我们有一个应急响应的Team在处理相关决策以及应急事务。对于特别重大的问题会在应急响应TEAM内进行决策。

周伟然：我行使用ITIL。无论是ITIL还是各级监管机构，乃是内部风险机构，对于银行应急处理的流程均有严格的要求，基本上是系统分类，根据不同等级重要性提出不同的风险要求。对于重要系统，需要建设完备的灾备体系，建立完善的应急预案 并且需要确保灾备和应急预案的有效性。对此，监管和内部审计通过演练进行确认。 所谓的演练非模拟实际环境的演练，而是在实际的生产环境进行的模拟灾难，各机构对演练的频度和内容均有严格的要求，并且重大演练时，监管官员将进行现场检查 通过各银行每年发出的停业公告可以看到这些演练信息。

InfoQ：在你们的系统中，“桌面模拟演练”和“Call Tree演练”是如何进行的？

陆惟凯：模拟演练比较少吧。方案定了之后模拟其实都是没问题的，定期的review是需要的。演练相关主要是定期组织运维的容灾演练与应急演练以及网购节（双11大促）之前的演练。

周伟然：据我所知，在股份制银行或规模以上银行，重要系统演练多以实际生产系统的方式进行，模拟演练主要用于系统正式上线之前的验证，在实际生产运行时并不采用也不符合监管要求。所有实际生产系统，即实际生产后台、实际渠道系统，但限定范围，例如，在演练时，可能关闭网银入口，使用户无法直接登录，控制演练本身造成的二次风险。

InfoQ： 相对互联网行业来说，银行金融行业的IT运维人员的素质和技能具体有哪些不同？

陆惟凯：个人感觉是比较接近的。可能是我在支付宝工作的缘故，IT相关企业的运维人员根据企业的性质不同（门户，电商，游戏，SNS）等会有一些各自有特色的容灾以及流控方案。所以需要相关的运维人员更多的了解前端业务，能够根据不同的故障情况进行不同的处理。（例进行功能的删减控制，流量开关，流量切换等）。另外IT企业运维人员遇到的外部故障会更多一些比方外部攻击，或运营商，或应用异常出现的故障。。另外传统IT业的系统更新频率会比金融业快上很多。相关应用发布带来的一些故障处理也会对运维人员提出更高的需求。传统金融行业的容灾方案相对来说就比较单纯一些。在数据备份方面IT企业根据企业特性不同，数据备份的重要性也会不同。金融行业对可用率以及数据备份的要求会更高。

周伟然：由于不太了解互联网的运维素质所以不好比较。但对于金融行业运维，制度性准确性和规范性是很重要的。由于银行设计大量资金和重要隐私，在制度规范上有着较为严格的规定，例如业务、研发人员与生产系统严格分离、生产数据完全无法接触的到、需要检查分析时需要通过严格的审批流程。在研发软件下发生产也必须严格进行内容审查和审批，操作步骤必须清晰描写，而对于运维把控的是对于审批结果的执行，精确执行审批结果而不能自行改动丁点，而且执行过程被记录，可被审计 在风险发生时，则应依照预案进行各项操作。运维人员对于应急预案的制定的维护，需要基于大量运维经验，并且通过不断优化验证的。

InfoQ：能否介绍下：在您所在的组织中，关键业务系统的备份是怎么做的？

陆惟凯：同城容灾加异地灾备吧..同城容灾包括机房内单点容灾（备份）以及机房间的相互备份。

周伟然：备份方式对于重要系统均需多方面考虑，例如某关键系统，首先在运行时就使用应用集群的方式确保可用性，通讯接入采用端口和地址复用进行多重备份。运行体系基本需要确保无单点故障，即单一功能点在2个或以上并行运行的节点。其他设备采用热备或冷备方式。该数据库备份基于数据库引擎和高端引擎进行远程灾备同步的功能，为单数据源热备份，数据的保存备份对于非监管要求数据，根据内部管理规定制定备份保存时间，备份至专用数据平台、对于监管要求的数据，在一定时间内在线保存至数据平台，长时间后转磁带长期保存。

InfoQ：在网友评论中看到一句话：“最关键的是一般都是只有设备容灾，没有人员组织架构的容灾。”请问您觉得“人员组织架构的容灾”应该如何理解？

陆惟凯：人员组织架构的容灾分两部分来看，一部分是操作以及一线的处理人员的备份，这块要保证相关的运维的操作技能与权限到位，在第一联系人没有联系到的情况下可以联系第二联系人来进行处理。

第二是决策人员的备份对于决策的人员存在联系不上的情况下，可以联系备份决策人员来进行决策。

当然这里的人员组织架构容灾基本还没有考虑到一个异地或者其他的成分，如果遇到毁天灭地型的地震或者更极端的灾难的时候，可能会缺乏异地的人手来处理问题。。

周伟然：人员组织的架构在银行来说有着明确的规定。首先对于每个系统对应的负责人员需要报送管理，并且做到A、B角等多角定义，在系统故障和重大事件保障时均遵循流程对应具体人员。日常工作时，大家对ab角等也有一定的注意，例如某集体全体不宜同一趟飞机出行等来降低风险。

InfoQ：能否介绍一些国外银行金融企业对类似问题和事故的处理经验？

陆惟凯：没有相关的经验。

周伟然：处理经验其实之上各题中均有提到，即功夫在平时。好的应急预案和备份需要大量前期工作和定期优化维护，并且验证，每次处理之后通过仔细的分析、审计、故障报告等方式探讨不足，不断地优化和改进。