一、背景介绍

相比于其他行业，银行业对于信息系统可用性与连续性有着很高的要求，基于这样的客观需求，同时也是满足银保监会《商业银行数据中心监管指引》的要求，绝大部分大中型银行都已经建立两地三中心架构，甚至多地多中心架构。为了验证同城中心或者异地中心的 IT 服务连续性保障能力，需要持续开展灾备切换演练，一般情况下分为同城灾备切换演练与异地灾备切换演练。

在进行经验分享之前，需要统一对于 IT 服务连续性的理解，明确一下  IT 服务连续性的目标和原则， 以便更好在各类管理措施与技术方案的选择上面进行抉择。

首先， IT 服务连续性的目标是为了保障业务连续性，他的目标最终是为了保障银行的业务的可用性与连续性，这是我们开展各项工作的基本原则，针对灾备切换，换句话说，不一定只有通过将所有应用系统从 A 中心切换到 B 中心才能保障业务连续性。

第二，业务分级与重要业务优先原则，在我们开展业务连续性工作、进行切换演练或者实施真实切换等阶段，如果在人力资源、系统资源、时效性、工具系统建设或者存在限制或者相互冲突的情况下，我们应该优先考虑重要信息系统，着重以最短的时间恢复重要系统的连续运行，对一般性业务进行降级或者将恢复一般性业务作为第二阶段工作。

第三，要以应对真实场景，有效保障业务系统连续性为原则，此原则看似简单，但是在实际处理过程中，具体的工作要求或者方案设计会与此原则存在一定差距。

二、存在的问题及解决方案

银行 IT 服务连续性体系是一个涉及组织结构、数据中心架构与高可用设计、应用架构规范与治理、应急管理的系统性工程，也是一项长期性工作，需要统筹设计、整体建设、持续改进，不是单纯依靠加强一个方面就能达成目标的，例如依靠灾备切换工具的能力。其主要包含以下方面的工作：

（一）数据中心的布局设计

为保障 IT 服务连续性，数据中心应如何布局，现有的数据中心布局应如何优化？首先建立异地灾备中心比同城灾备中心的成本更高，一方面是需要申请至少两条以上高带宽长途专用线路，费用较高，第二是异地中心的基础设施资源相对于同城中心来说，更难以复用，第三是建立异地模式灾备中心，在人员日常组织协调与管理方面的成本更高，因此如果按照监管要求，无需建立异地灾备的小型银行，可建立同城灾备中心。

对于按照监管要求，需要设立异地灾备中心的大中型银行，在设立异地中心的情况下，是否有必要设立同城中心。大中型银行普遍对于可用性与连续性有着更高的要求，虽然设立异地灾备中心是为了应对地理区域级别的灾难，但是由于距离的因素，因此异地灾备中心数据同步的时效性远低于同城灾备中心，对于联机交易同城数据中心数据同步时效性接近 0 ，但是异地数据同步一般为分钟级。因此大中型银行在具备异地灾备中心后，仍然有必要设立同城灾备中心，同时设立同城数据中心为了实现应用系统同城双活创造了条件，甚至直接建设或者后续演进至一个区域内的多活数据中心，类似 AWS 的一个 region 的多个 AZ ，众多分布式多活技术组件有三个以上副本的要求。

对于有能力将大量应用、甚至核心应用做到异地多活的银行，也有足够人力物力资源的情况下，可以考虑在异地也设立双活中心或者多活中心，实现异地双活或者异地多活，设置多个地域，但是达成上述要求，对于应用架构、应用治理与分布式基础设施组件的方面，提出了很高的技术能力与治理能力要求，在这方面互联网行业的一些技术创新可以作为重要的参考。对于大中型银行，是否需要在异地建设多数据中心是一个需要全面论证和权衡的问题，需要分析投入产出比，或者在可用性因素之外，有其他行内的特殊情况需要在异地设立多中心。

银行在规划异地多活数据中心时候，可能会陷入一个技术误区，就是要实现异地多活，任意中心故障情况下都能做到对业务无影响 RTO 等于 0 ，数据强一致性，同时还要保证日常数据处理系统具备足够的性能，在多活数据中心超过一定距离的情况下，类似 CAP 原理，可用性、一致性、高性能是存在矛盾的，无法做到兼顾。因此对于异地多活中心，在发生区域性故障时，一般情况下会降低部分用户的可用性，保留一定的 RTO 时间，保证受影响部分用户的数据强一致性，在预估 RTO 过长或者对于数据一致性要求不那么高的业务，也可以选择快速恢复可用性，降低 RTO 时间，但是容忍短期部分数据的不一致性，事后通过技术或者业务层面的补帐机制去保障业务最终一致。

在目前 IT 技术、互联网、电子化渠道已经代替原始线下纸质凭证的情况下，纯业务层面的补帐机制会存在很多局限性，并且通常需要更长的时间。在远距离情况下，通过在应用技术层面设计补帐机制，能够大程度上减少数据一致性差异，降低 RTO 时间。

（二）应用架构应该符合哪些规范，应如何对应用进行持续治理

建立同城双活或者异地双活数据中心，实现高可用的信息系统架构，不只是能够单纯依靠建设数据中心或者依靠双活 / 多活基础设施就可以获得的，需要在符合要求的基础设施之前，制定应用系统部署与运行规范，对应用系统进行治理和改造，才能够达成信息系统高可用与连续性目标，有效支撑业务系统的连续运行。

这里面需要目前 IT 业界比较火热的云原生应用、应用微服务化、 DEVOPS 等理念与技术，对于实现应用同城或者多活，互联网行业也有很多的先进经验。但是银行业是否能直接拿来使用，是否应该直接生搬硬套就能满足我们的需求，需要值得考量。 银行信息系统与其他行业信息系统相比，存在一些特殊情况：

第一是存量系统的转型问题， 银行以及产品供应商经过多年的研发，银行信息系统已经形成了一套应用系统体系和大量存量应用，这些系统早期设计研发时，更多地考虑功能性和性能需求，对于本地多活或者异地多活的需求没有现在要求这么高，基于成本或者其他方面的考虑在这方面有没有做过多的研发和支持，在产品和体系都较为成型的情况下，进行重构和设计需要投入大量的研发资源，在供应商方面即满足需求又经过市场检验的产品较少，比如目前市场上的分布式核心银行系统，这就决定各个银行必须制定适合自己的应用治理路线和技术规范标准，并且这个标准一般情况下是分步骤分阶段，每个阶段都需要权衡投入产出比。

第二是互联网行业自主研发的情况较多， 对比银行业，除了大型商业银行能够做到自主研发外，小型银行与部分银行只能依靠采购供应商产品和定制化开发，进行应用的改造或者重构涉及成本问题、厂商的产品市场方向以及厂商自身研发实力的问题。

第三是银行业对于强一致性的要求很高， 行业对于一致性方面的偏好直接决定了实现多活以及实现异地多活的架构设计难度、投入成本、可能造成的风险，并且银行业业务交易对于响应时间等非功能性需求要求也很高，因此在远距离情况下，如果实现强一致交易很大程度上会带来性能与整体可用性的下降。

第四是监管层要求的不同， 银行业受到的监管较为严格，一方面是对于生产故障事件的监管和考核，导致银行实施系统改造或者实施演练的过程中，需要提前控制可能造成的生产故障风险，因此这些会影响系统重构或者改造的步伐，其次对于开源软件的自主可控问题，导致引入一些多活类支撑类基础软件还是需要依托厂商或者自身投入更多的开源自主可控力量，另外监管对于业务高峰业务时段控制的要求以及研发与运维人员分离的要求，也对银行引入新的应用架构和研发过程体系提出更多的要求。

也是基于这样的角度考虑， 银行选择建设同城双活、异地灾备的数据中心架构， 相对实现异地多活来说，实现同城双活能够很好地应对单个数据中心故障，但是又能够很好降低技术难度，降低应用改造与迁移成本，虽然未实现异地双活，但是整个地区遭遇毁灭性故障本身属于极低概率事件，并且在此情况下，也能够容忍一定的 RTO 时间。 同时，制定了适应同城双活、异地灾备的应用部署架构规范与治理规范， 实现能够在较短的时间内，对应用改造成本的情况下，最大地发挥现有数据中心基础设施的能力，并提高整体信息系统可用性与连续性。

具体的应用部署架构规范主要包含如下几个方面：

1、 应用系统的应用节点部分需要支持多活部署和运行，这是实现同城双活的基础条件。 一般应用节点不包含持久化数据的情况下，一般较为容易满足此项条件，并且每个应用至少在本地中心和同城中心各部署 2 个以上节点，并且在一个数据中心也需要使用非亲和性调度策略使得两个阶段不处于同一个机房模块或者机架。但是对于数据库实现跨数据中心多活，存在一定技术难度，同时某些特殊或者极端情况下，反而会带来整体可用性的下降，或者在人工介入进行恢复操作场景下反正增加恢复难度，因此对于应用系统的数据库节点，仍然采用较为可靠的主备方案，同时在存储层面以最大可用模式进行数据复制，一般情况下 RPO=0 ，同时在同城双中心连接出现中断，或者备中心出现故障时，不会影响主中心数据库的正常运行。

2、 应用系统双中心流量基本均衡。 应用系统在进行了双活改造和双活部署的情况下，在运行时候仍然会发现双中心的交易流量不均衡，或者一个中心出现流量为 0 的情况。造成这种情况的原因有很多可能性，例如应用实现了双活，但是线路未实现双活，或者对接的应用系统、对接的合作方、第三方未均衡地分配交易流量，只有双中心真实承载均衡的交易流量，才能保证双中心都是处于可用状态，同时也能够提高两个中心基础设施资源利用率。同时，在各类渠道的流量调度策略也需要结合业务场景进行调整，比如实现一个网点的柜员和 ATM 分配到不同的数据中心，这样在故障发生后切换恢复前，至少有一半左右的柜员或 ATM 可用，保证在业务层面能够继续为客户提供服务。

3、 基础设施、应用系统的同城双中心解耦。 为了实现高可用性与连续性，需要在基础设施以及应用系统的架构设计与实施上，要减少单一故障原因导致的双中心同时故障，首先例如在基础网络层面如果实现大二层可能会带来网络层面的单一故障点，其次是应用系统联机交易应避免使用双中心共享存储节点，因为此类共享存储节点故障就会造成双中心同时故障，第三在应用层面，要求一个应用不应跨中心访问其他应用系统，保障流量进入一个数据中心后续交易不会分派到另外一个中心，避免在切换操作过程无法快速有效地隔离某个数据中心，降低灾备切换操作的难度，第四，要求应用系统在发布过程需要采取蓝绿发布等模式，避免同时在双中心更新应用版本，导致全局故障。当然，能够导致双中心同时故障的单一故障点无法绝对消除，例如非同城多活的数据库节点，只能减少存在的点或者降低发生的概率。

4、 各类应用节点、数据库节点需要进行 DNS 改造、自动重连改造。 应用的 DNS 改造，包括数据中心对外服务的 DNS 改造，以及数据中心内部应用之间访问的 DNS 改造、应用内部应用节点间访问的 DNS 改造（如应用节点访问数据库节点），对数据中心以外来说，实现 DNS 改造后，能够很好地做到应用切换对于用户的透明，加强灾备切换操作的难度，例如柜员在配置域名访问的情况下，数据中心可以通过切换域名对应的 IP 地址就可以容易完成应用切换。在数据中心内部，实现 DNS 改造能够很好实现组件之间的解耦，减少组件动态迁移对于其他组件的影响，例如应用对于数据库的访问，在数据库切换完成后，应用无需进行复杂的重新配置与重启操作，降低切换操作难度，提高切换操作成功率，降低切换操作时间继而降低业务中断时间。同时，在组件可能出现动态迁移或者切换的情况下，应用节点需要进行自动重连改造，一般情况下在切换过程不需要也不应该对应用进行类似重启操作，在演练过程中也不需要出于保证演练对于业务无影响的角度出发对应用进行重启，进而更好地通过演练发现问题，落实责任，保障在正式场景下快速切换恢复业务，以免应用产生更多对于基础设施和切换工具的依赖，简而言之，为了实现高效灾备切换，更要把工作做到前期设计和研发阶段，降低演练中的复杂度，降低真实故障下的复杂度。

（三）应急预案的编写

根据监管部门业务连续性与应急管理要求，应急预案需要明确各类故障的诊断方法和流程，需要明确系统恢复流程和处置操作手册， 目前在业界编织应急预案的时候主要存在以下难点：

1、 明确应急预案的启动条件较为困难， 比如某个应急预案的启动条件是单个数据中心出现整体性故障，但是在实际单个数据中心故障场景下，例如 20 个以上的服务器 ping 不同属于单个数据中心出现整体故障了吗？同时，各个层面各个专业都会出现大量告警信息，告警的信息也在变化，给启动条件的明确增加了更多的困难。

2、 故障的诊断流程可操行性差，难以细化。 数据中心包含多个模块机房，每个机房有各类设施，每类设备都有各类组件，在出现故障的情况下，在这么多预案中，我们应该首先选择执行哪个预案呢，所以各类现象和告警信息可以提供一些参考信息，但是预案梳理仍然较多。同时，问题的诊断流程实质上会出现很多分支，类似于决策树，从一个现象出现，会诊断出来大量可能的故障，每个故障都有不同的流程，难以在一个预案中明确。

3、 以应用 / 设备内部技术告警信息作为启动条件，应用 / 设备内部的各类技术部件和告警信息繁多， 例如每天网络设备产生的告警数多达百万级别，此类告警可能对业务有影响但是有时候又不影响业务，应急人员频繁进行应急处置，会消耗大量的无效成本。同时，在服务出现异常时，此时设备也不一定出现告警信息，或者即使出现，该类告警信息也会淹没在日常大量的告警信息中。

经过长期的摸索和实践，总结出来一条行之有效的应急预案编写实践经验：

1 、应急以快速恢复业务原则，降低业务影响为原则，不以定位问题原因为原则。 这个原则虽然很容易理解，但是技术人员在编写预案或者实际操作过程容易陷入寻找问题原因。应急诊断过程中，需要进行分析将故障区域明确至一个可执行预案的级别，但是一旦明确后，在应急现场不需要再进一步分析故障原因。同时，监控等工具系统也要配合进行监控覆盖，以最快的速度给应急处置人员提示故障域信息。

2 、合并故故障域原则， 因为数据中心从数据中心级别、机房模块级别、应用集群级别、设备级别都进行冗余设计，我们可以在数据中心级别、机房模块级别、应用集群级别、设备级别进行隔离切换。如果可以判断是设备级别故障，我们就隔离整台设备，而无需关注设备内部什么部件因为什么原因出现故障，应用集群、机房模块、数据中心也以此类推。同时，无法短时间明确故障域，可直接将故障域上提一个层次，但是需要控制上一级别故障域应急操作带来的风险。同时，如果高层次应急操作操作简单，经过多次检验，风险较低，可以删除低层级应急操作预案，以降低应急预案数量，以较少的预案应对更多的故障，降低应急预案编织、管理与演练的成本。

3 、尽可能从业务角度判断服务正常作为启动条件，  例如从业务交易影响占比角度判断是否出现数据中心整体故障，例如一个数据中心的业务交易出现 30% 以上失败时即认为数据中心出现整体性故障，作为数据中心级别切换的启动条件，对于网络设备以观察网络异常流量的占比（网络数据包重传）作为判断网络设备是否故障的判断条件（网络提供的服务即网络通讯），对于应用集群也是同理。这样做一方面，应急启动条件和现象很明确，监控工具也很容易落地，应急处置人员也很容易掌握。另一方面，包含的故障场景很全面，可能影响业务的技术故障一般情况下都会涵盖，同时对于不会影响业务的技术故障，不会启动应急，节约宝贵的人力与 IT 资源。

（四）切换工具建设实践

应急切换工具平台的建设属于运维自动化的范畴之一，技术上存在通用型，只是应对业务场景不同而已。 IT 服务连续性体系和应急管理体系的建设不能过于依赖切换工具平台的建设。 首先，如果我们的基础设施和应用如果标准化程度不高，就会导致自动化平台切换步骤多样且复杂，在应急情况下能够成功完成切换的可能性就会降低，这一点跟实现 IT 运维自动化的前提是标准化类似。其次，很多情况下，应急切换工具自身也会受到故障的影响，因此需要在设计预先设计并验证，保证应急工具自身的可用性。最后，技术存在局限性，因此需要保持自动化切换失败场景下，通过手工进行切换的能力，保证大家都是技术知识和操作步骤的熟悉程度。

切换工具的建设投入也与上述故障场景与应急预案的设计明确密切相关，如果能对于故障域进行整合，从业务监控层面设计应急场景，应急场景与应急预案，以至于应急切换步骤都可以得到大幅度的减少和简化。

自动化切换平台建设在技术上与自动化运维平台差别不大，相关方式和方法、技术手段、技术框架都可以复用，自动化运维平台开源工具、厂商提供的工具较多，因此本文不做过多介绍， 主要针对切换平台需要在建设过程中需要特殊关注的点进行经验分享：

1、 切换工具自身如何实现高可用

如何避免切换工具自身受到故障的影响， 主要需要遵循的原则就是就是切换工具需要保障在被切换对象外部，同时在基础设施层面，要保证在所设计的故障场景下被切换对象的可达，包括故障场景下网络可达等。 例如两地三中心情况下，异地切换工具可以部署在异地中心。对于同城 AB 中心，可以将工具双活部署在 AB 中心， A 中心故障情况下登陆 B 中心切换工具进行切换， B 中心故障情况下，登陆 A 中心切换进行切换，同时两个中心切换工具的配置数据层面进行定期同步，由于切换工具对于数据一致性与实时性的要求较低，因此一般实现起来具备可行性。可以将 AB 中心的工具地址提供给用户，并在操作手册中注明，在什么场景下应该登陆对应的地址进行操作。

另外，数据中心基础设施一般都建设有带外网络，异常情况下可以手工通过带外网进行操作，因此切换工具也应利用带外网络代替人工进行应急切换操作，切换工具需要在带外网络部署相应节点，并且这些节点能够保证在与带内网络端口的情况下，具备可用性。

2、 切换工具的容错

切换工具在编排操作时，一般情况下不应考虑进行故障域的内部进行操作，比如数据中心整体故障场景下，一般不编排进入故障数据中心对于某个应用进行关闭或者重启操作。如果只是进行尝试性操作，也应保证程序的容错，也即如果对象可达且可操作，则按照步骤进行操作，如果不可达或者不可操作，也应自动跳过继续后续流程的处理，并注意超时时间的控制。

3、 切换流程的执行控制

切换流程一般都是多种多样，一般需要引入工作流引擎，引入 activity 编制并驱动工作量。工作流的设计遵循 BPMN2.0UI 规范，一方面 BPMN2.0 规范能力强大，能够表达的场景较为丰富，并且作为一个通用标准，便于与其他工具的开发以及与其他外部系统的对接。工作量需要支持丰富的人工介入手段，以支持应急切换中碰到的特殊情况，一般情况下需要支持人工暂停、重试、跳过等操作，以及对于执行中流程实例的调整能力，比如增加或者删除操作步骤、子流程。

实现流程编排可视化，可以降低编排工作的难度，简化流程编排人员的工作量，同时，在切换过程中进行可视化展现，也能方便在应急协同过程中，现场各专业人员对于进度的掌握。

三、整体总结

在上述体系化思想指导下，可建设完成同城双活、异地灾备的金融云数据中心基础设施架构体系，在基础设施层面实现了同城双中心解耦，应用系统层面实现同城双活部署，对应用系统全面治理与云化改造，并部署面向业务的监控工具体系，建设同城切换自动化平台，并成功实施同城数据中心切换演练， RTO 控制在 5 分钟以内，对银行业乃至金融业的建设高可用性架构体系，完善业务连续性能力提供参考，具有很好的借鉴意义。