大家好，借难得的机会，也借dbaplus社群这个平台，跟大家交流和探讨一下容灾容错这套体系的建设，包括实操性演练的一些设计。

首先要讨论容灾容错都包括什么？为什么是一个体系？因为容灾容错有它的背景，这个背景主要是从业务连续性管理的范畴角度，业务连续性管理可能很多朋友也都清楚，不清楚的话网上有比较标准的一个解释，这里特殊强调，它主要是针对于企业业务的非计划性问题产生影响，有针对性的去制定一些业务连续性的保障计划，控制企业的经营风险。同时像我们理解的也是为企业的客户提供优质服务的一个手段。

具体的来讲，容灾容错体系的构成主要包括各种可能出现问题的场景。

第一个是小概率大影响的灾难性场景，这也是标准的容灾容错涵盖的内容。假设一个主数据中心，因为电力的原因，或网络的原因，整个系统要全体切换到另一个容灾中心或者同双活的一个中心，这是概率很小，但是影响肯定会非常大的一种情况。

概率比较高和影响也比较大的情况，我觉得也应该纳入到体系里的。一些严重的故障和错误，也会产生这种问题。容灾不仅是灾备中心的整体切换，所以这里要特殊强调容错，这是一类问题。

谈到对客户优质服务，还有一部分客户问题是系统正常但应用程序存在一些逻辑 bug的，或者是基础数据问题造成一部分的客户没法去完成交易，这也是我觉得应该涵盖在内的。

所以容灾容错这种实战能力的建设，我理解上认为主要包含三个部分的工作。

第一，是架构和控制这两个问题。

系统整个架构的可靠性设计，这是容灾容错的一个基础。这个基础之上，我们还要有对于服务的可用性控制，即有了这个基础之后，还有一定的发现、定位、处置能力的一个控制能力，结合在一起，才能真正的达到容灾容错实战的能力要求。

第二，是演练和问题的跟踪。

即设定我们的这个场景不一定是能够生效的，所以要有一套演练、问题跟踪、分析成因和形成规范、迭代开发的一个过程。而且这个过程不是突击性的、一次性的任务，是要结合我们日常的运维做的一个任务。

第三，是把它形成常态化。

金融行业经常制订一些工作计划，一年计划几次，在之前大家做了充分的准备，然后演练，但实际真正发生故障，肯定不是跟演练一样的，所以一定要把容灾容错的能力维护建设在常态工作机制中，才能确保随时发生、随时能处理。这是一个简单的理解。

容错容灾都主要包括哪些场景？上文也提到很多场景的问题，这里我想简单的举一个例子，可能很多方面是大家曾经发生过的问题，一是应用的系统或者体系，客户接入进来可能发生哪些问题？

安全性的问题，或是大家熟知的像负载均衡等调度问题，还有交易逻辑的组合问题。尤其是银行，银行的交易是比较复杂的，靠多个应用系统组合起来。

一些容灾或者是多活数据中心，一定会产生多路径的问题，包括多路径怎么解决，应用系统自身基础性的条件问题，还有会话的模式和方式的控制。

最重要的是数据，应用系统在工作过程中，既会产生临时性数据，也会产生这种永久性数据，临时性数据会存在一个有状态、无状态的问题。

可能交易是异步的模式，进出是不同的通道，数据落在某个路径上，另一个路径找不到它，这个交易很可能就失败，这些问题都要解决。

另外是最基础的一个问题，上图中我也列出了很多这种技术环境问题，这是容灾容错要考虑的场景，不一一讲，有的我们本身出现过，例如交易逻辑的组合问题，上图特意标出了一个颜色的信贷流程，它是比较复杂的一个业务流程。

我们的应用程序无论怎么开发，都不可能完备的覆盖任何的错误场景，包括像业务员操作的一些输入的错误之后，不可能把这个流程重新发起重走，只能通过这种错误的临时处置机制来处理。我们的技术人员每天也会大量处理这个问题。

另外银行特殊有的，我们叫联机批量交易，即代发代扣，像大家熟知代发工资等等，如果量特别大，它会切分成很多文件，这些文件并发处理之后，并发的锁机制和控制问题，如果控制不好一定会出问题。

再有一点是强调永久数据，大家可能更加关注多活数据中心的交易，但是一个容灾的中心，如果是完备的话，不仅仅是交易能够承载，它必须同时保证数据是一致的，尤其长期历史归档数据。

银行要存储很多交易的历史数据，还有其他的像信贷等等数据，这些数据按照监管或者会计法，至少要保留15年或者更久，这个数据中心一定是对等的，否则它起不到任何容灾的作用。

这些是我简单列出的场景，但是每个场景可能在不同企业中会有不同的问题，要根据实战来考虑。

为什么容灾容错是个体系，我理解上认为容灾容错是一种能力建设，而不是一种资源配置。

容灾容错的能力，实际是由日常的事情发生并逐渐演化过来的。我们在日常中不一定能预见到一个灾难或者一个重大故障的发生。刚开始可能就是一个小的事件和苗头，所以在容灾容错我们重点考虑的一个是监控事件，我理解的就是在日常中经常会有报警发生的，需要处理或者是无需处置，或处理起来相对比较简单的，像应用的队列清理和清理之后的重启服务，这些我理解就是监控事件，需要处置。

容错场景比较复杂，而且影响也相对比较严重。另外处置过程中，既需要人的介入，也需要系统之间互相关联处理。有的交易链条比较长，由a、b、c几个系统串联起来，a处理的时候，后续的b和c连带的必须要处理，这是容错的场景。

容灾，对服务有严重影响，处置前中后过程中，需要全面控制系统内外部、各类业务场景的关系，容灾是技术与业务全面共同处置。这也是上文提到BCM为什么是以业务场景为主导的必须要细分。

在我们日常的一些故障之中也遇到过，出现过不是纯粹的技术问题，业务也有一套准备。这也是监管部门对于业务连续性保障，从业务角度要求去考虑的一个问题。

我们应用系统设计的时候一定要考虑个问题，叫可靠性设计，整个系统如何做可靠性设计。设计了后，一定要做破坏性测试，即假设容错或者容灾的场景发生后，会产生的结果和设计有效性。

这步过了之后，就要做适配。上文说到可用性控制能力是很重要的，所以配套的监管控体系一定要配上，最终要形成标准化的操作。这样一线的工程师在值班的时候出现这些场景，才能够迅速的发现，并能够按照要求去处理，真正的形成能力。

最后是工具化验证和培训，这是一个迭代的过程。在演练或者在实战中，肯定会发现漏洞，因为任何一个体系都会有漏洞，一定要回到最开始的可靠性设计来讲，要不断的完善一个技术规范标准，控制整个体系的设计质量，提高整体的可用性，这是容灾容错为什么叫一个体系原因。

上文谈到体系的一些概念，那我们日常工作要怎么落地？这一块我们也在总结自己的经验，并且不断的按照这个思路去推进自己的工作。它和平时的日常运维工作要怎么结合，即怎么能让它常态化呢？

做运维的，会有一个运维的全生命周期管理的过程，我们跟研发共同探讨设计这个系统，最后投产，再加上运维方面的一套理论，包括ITIL事件问题，包括变更和配置管理，管理之后一定要形成一个有效的配置管理数据库，这个是重要的。

配置管理数据库怎么展开去讨论，这是一个比较大的话题。但是我们可以根据自己的需要。我现在以事件的发现和处置为主，那么它主要信息就是为了监控服务的，最后有一部分，主要配置通过了，基于配置信息就要生成监控它的配置库，也就是监控本身一定要知道都有被监控的系统，知道哪些是被储备的，能够有场景去处理的。

之后要有一套的监控工具和手段，同时要把配置信息拿给我们，这叫容灾的管理。

容灾是监控的一个子集，如果监控其中有一部分是跟上文说的容错容灾的场景相关的，一定要拿进来，对它做额外的检查确认，确认它场景是否发生。如果发生后，对它一定要有的一个处置的过程。这个过程，如果有运维自动化的工具，就用自动化来处理，前提一定是先标准化，不管是手工操作，还是人工管理，先标准化再自动化，再处理事情。这样的话，又返回到我可能调度一些已经设置好的运维工具的这么一个循环过程，上图是个简要图示。这个目的就是怎么与我们正常的运维工作结合在一起，形成常态化，让它形成一个真正的实战能力。

接下来，架构的可靠性设计，这个是容灾容错的一个基础和必要条件。没有这个的话实际谈不上真正系统的高可用性，架构的设计肯定是差异化的，不可能一概而论。

服务接入渠道类：以典型的银行为例，接入类的，就是大家熟知的或使用的网上银行、手机银行等等，即对客户直接服务的，这一类的特点是，多活、弹性、弹性扩展、多路接入等等。

在容灾方面，要考虑会话的一致性，这是一个典型的问题。我们在自身的实践中也发现了这些问题，例如跨中心双活时，有的系统不能简单切换过去，尤其是同步的或者异步交易的来回通路不在一起，中间可能有负载均衡资源等情况，它已经把连接池化了，怎么能保证一致性，这是一个重点要考虑的问题。

这里我就不再展开讲了，因为每一块内容，像负载均衡等等展开讲，在我们的论坛，或者我看过的以前一些文章，都非常专业，也讨论得非常深入细致。

它既要负载均衡的设置策略，也要研发的应用程序开发，这两个必须配套。我们也曾出现的问题就是这两个环节不配套，最后造成了一个多路的会话不一致，也有可能只是少数客户的交易就出现超时或者失败。

业务逻辑平台类：在银行来讲，典型的有网上银行这类服务平台，或者是信贷的业务平台。这一类，它的业务数逻辑的一致性要求比较高。另外，它数据的处理逻辑也比较复杂。

在可靠性设计来讲，是上文提到的落地数据的多路径一致性，因为很多交易是必须要做落地文件的，不可能全是走报文。落地文件之后，这个文件进出如果落在不同路径上应该怎么处理？

现在通用的一种方式，可以用一个NAS存储资源共享文件系统，但在细化设计上，各个业务通道，进出的时候要写到不同的文件目录下，避免混淆，同时变更发布也会更方便，这是细节了，就不再展开谈。

核心账务服务类：不管是银行，还是其他企业，肯定有自己的核心系统。核心系统的要求，在整个架构里，越往里层，对它的交易时间、完成速度等要求则越高，这一层在可靠性设计上，各家企业都不一样，包括技术人员的数量和素质配比、投入资源都是不一样的。结合自身，我们采取的是简单可控的模式。

例如基于小型主机的核心系统，针对它的HA设计，考虑到我们企业中高级技术专家资源有限，就没有采用更快速但是更复杂的技术方案，而是选择了比较传统的HA加数据库资源模式，但是Ha里放的Resource资源一定要很少，只有最基本的存储和数据库，这样切换的耗时和成功率是可预期的，每次切只要是10分钟之内完成，就是我们可以接受的。

数据仓库分析类：数据仓库这一类的架构设计，它虽然不是一个在线的交易系统，但像金融企业要产生的一些报监管的数据，或后台的总账数据等等很重要的，都特殊强调数据来源需要与容灾切换必须配合。因为前面的业务系统切走了，数据抽取的时候，如果没有控制好，可能抽的就是上一日或者是错的数据，更可怕的是没发现，最后你报出去的数据或者出去的总量数据是错的。

这个事好像不是太难，但其实这个数据分发路径在任何一个大的企业，包括有一定规模的银行去梳理的时候都是很困难的。谁和谁传了什么数据，数据供给方如果切走了，IP地址换了，抽取数据能不能准确地跟上，这都是一套机制，这也是上文容错和容灾里强调的。跟日常监控处理不一样，它是要跨系统之间要协同，所以可靠性的差异化设计要综合考虑不同类型的应用系统。

从架构设计来讲，肯定是自上而下进行整体考虑的，上图图示的是一个典型的银行交业务系统的结构。客户怎么进来，怎么进到业务的平台，怎么到后台的核心系统，当然都通过这种企业的服务总线，到最后线的数据仓库类等等，都涉及到上文说到的不同会话模式怎么考虑的问题。

（1）访问的接入

对外提供服务，有的是直接对客户来提供的，另外也有机构之间互联的，就像银行跟三方支付。C2S、S2S的访问目标需要考虑域名，尤其容灾中心，我从外联专线，从主中心切到另一个中心的话，运营商没法保证公网地址是一致的，域名、端口要怎么处理。另外还有现在要面临的，也是我们正在做的V4到V6的转换容错，这些都是访问接入问题。

（2）会话模式

会话模式涉及到两个，一个是上文提到的长连接的断链重联协同控制，如果系统复杂了，互相之间可能有的不需要重连，有的需要重连，这些要靠日常尝试，并在确认后要形成一套针对这种灾难场景的操作规则。

短连接的多路径均衡和流量控制，这也是一个要考虑的问题。两个不同中心或者更多中心，从多路经进来以后，怎么进行负载流量均衡？因为有可能你后台的一个系统，像核心交易从a中心切到b中心，毕竟在一个小的局域网，前面接入层的配比一定得调，把快的部分调大，把交易相对比较慢一点的调小，以保证对外的可用性。

（3）临时数据

临时数据上，从上图可以看到，尤其是图中左上角的几种交易类型，大家要熟知一下，一是单向的这种联机交易，二是双向的联机交易。所谓双向就互为可难端，这个开端口和可靠性重联机制都是会不一样。

另外是单向的批量，也就是传数据的，传落地文件的，还有双向的，都要考虑上文提到的有状态无状态的控制。

还有就是文件并发。并发是为了提高效率，但是它锁机制控制一定不能出现问题。当然我们自身也出现过各种问题，从这个问题的解决，总结经验再去改进它。

（4）流量控制

流量控制上，既然是多活多路径的，就一定要有一套的流量控制方法，否则流量异常或者是有一路堵了之后，没有相关控制手段，就会造成恶性循环不可控，这个是可能要考虑的关于整个架构设计的问题。

应用系统间怎么调度和控制的，这个大家都很熟悉，无非是负载均衡，至于是用开源软件，还是用一个商业化的软件做，或是用纯粹的硬件设备，这个根据自己的流量性能要求而不同。一般在银行的关键业务系统上肯定是选择专用的硬件设备。

（1）均衡调度的设计需求

选择均衡调度系统时候，第一是考虑它的可靠性，像冗余无单点设计，运行状态可监测等等。

另外是性能。最小的或者是单中心的，甚至是单台设备，就能支持支撑所有的高并发，保证在极端情况下，还能够承载最高并发度的一个业务。

再就是控制，能提供标准的API，让它的启停、操作、切换，数据的采集等能够自动化，这是对于负载均衡的一个设计要求。

（2）均衡资源使用策略

分发调度上针对短连接类请求，实现流量配比调度、后台资源监控、服务异常调度、防止交易混流。

无缝切换则针对长连接，实现后台状态监测、异常情况下前端连接的平滑性控制、会话一致性保持。

还有一个是跨中型的，后台的服务是不同的IP地址段的，关于网络的二层三层这种互通差异的配比调度。

我们所叫的应用程序，和应用系统之间是有区别，应用程序我们可以理解成代码。

应用程序内部的可靠性设计，这里列举了一些问题：

（1）接入一致性保持

用户和系统的重复访问控制，我们也曾出现过，尤其是多活多路径的一个用户，重复登录了，有可能会造成业务的一些问题。

还有就是负载均衡的配套设计，上文提到负载均衡如果配了一个参数，后台的应用系统必须要配套去按照这种模式写程序或者是设计。

另外是二三层访问之间的实现。

（2）业务逻辑可靠性

业务逻辑，这是应用代码要考虑的。我们很多开发同事未必会考虑这种边界条件或者极端情况，业务逻辑异常中断后，能不能断点续做？有没有查询冲正和报错输出这种机制等等。特殊提到的重复代发，我们自身就出现过这个问题，它因为异常中断了以后，锁机制实效，可能造成代发工资，重复发两份等问题。

（3）日志完整性控制

日志完整性的控制很重要。一个应用系统，正常的交易也要写日志，这是为了在排查一些应用或者业务问题时可以来使用。再就异常报错日志的信息完整性、日志输出的标准化。

这里特殊强调跨站点的多路模式的采集，因为很多交易可能是异步模式，进出不同通道，一旦客户的账务出现问题，或者是有其他复杂问题，我们去追踪，去检查的时候就很困难。如果分散到每一台机器日志上，那业务员和技术人员要每一台机器登录去检查日志，而且要把交易的整个场景拼出来是很困难的。所以跨路径采集，也是发挥我们日志的采集、分析的。

为什么叫应用系统？就是我把这段程序代码装到了一套系统中，应用的外部部分，无论是动态的、静态的部分，我装到外部server中，应用程序我装到APP的server中，当然像银行还有核心系统，很多它的批量程序我装到它的DB server上，我的整个网络环境，负载均衡设备，包括DNS这都是要配置的，跟应用有关的还有网络的访问关系控制，包括Ha等等，这些配置完了我们叫它为一个应用系统，这个时候应用系统作为一个完整的，有自身体系的，才能够对外提供服务，才能发挥它的作用。

（1）应用服务状态监控

在应用系统的可靠性上，一个是应用服务状态要可监控和采集，否则我们不能确保它是否能够正常运行。

说起来简单，但是做并不容易。最简单的监控某个进程，监控它的应用服务技能、端口等在不在，即使在也不一定代表是正常工作的，它僵死了，我们可能也不知道，这就需要讨论一些方法了。

例如用日志给它输出心跳信息，每10秒、20秒钟输一个报正常平安的一个状态，连续多长时间收不到的，表示它有可能僵死了。这个时候就需要决策，可能要涉及到的，如果是简单的即监控事件处理，如果复杂的就是容错容灾的处理。

（2）系统资源调用控制

另外应用程序，它对于系统资源的调用，最主要的像数据库、文件传输、加解密设备等都是有调用关系的。有调用关系，有一定的结构，它就一定存在不可靠性。那就要考虑可靠性的提升。

（3）后线持续运行控制

切换后的一个仓库的系数，一旦核心系统切换了以后，卸数后面的数据仓库等一定要跟上，包括数据备份，上文前面提到过，双中心或者多中心，它数交易能力对等前提下，数据一定是对等的。

我在a中心有的全量的数据备份归档，可能有30年、40年的数据，我在b中心必须也有。像我们一个应用系统瘫痪了，客户可能一段时间做不了交易，这只影响客户体验。但一旦数据备份丢了，这个是永远补不了，这个是灾难性的。所以在应用系统的可靠性设计上，综合要考虑的都是这些点。

提到应用系统，既然叫系统，即应用程序叫资源。这里最重要的一个资源，大多数应用系统都避不开的就是数据库，尤其是关键系统数据库的压力比较大，像银行核心系统，24小时运行也没有任何的时间专维护和处理的。另外它数据量可能非常大，一个要求数据的完全的强一致，这个就要考虑它可能出现什么场景。简单列举了一下，有数据库僵死、服务器的硬件故障、同城站点故障、数据库逻辑故障、数据库软件BUG、城市灾难问题以及其它不可预见问题。

针对这些场景的异常处置有本机重启，即主机故障以后重启，这是可能的一种操作。其他的不详细讲。

上图提到克隆，就是说同构要有个克隆，例如我是Oracle，我克隆的软件也要是一个Oracle，保证它正好切过来。我们努力的目标是要它做一个异构的克隆，它主要是防数据库软件的BUG。这个就是在数据库的场景上，当然每个展开了以后，可能会有详细的一些设计。

大家觉得最传统、最直接的这种数据库主备机HA切换，如果真去维护一套数据库的DB的小机的HA体系，这是非常复杂的。因为任何一个细节考虑不到，可能就会造成HA切换失败，这个时候还比较麻烦。因为大家也不知道数据库是什么状态，没法去处理。这就是数据库按场景的可靠性设计。

再往下层是现在银行叫的两地三中心，可能也是多中心，网络基础环境需要怎么设计。我们自己具体在做的，可能还是相对比较传统的，就是两地三中心这种方式用光纤联通，同城因为是在一定的距离范围内，能够满足这种相当于存储同步，异地的话只能异步了。就是相当于RPO不是0，同乘RPO则可以是0。

另外就是上文提到在整个架构设计的时候，要考虑不同系统的特点。小范围的可能要打通网络二层，打通的目的是给这些核心类系统，把它放在里头。这样的话，两个中心，同城容灾中心和主中心，它所有设备都在同一个IP地址段，比较方便前面连接和转的这种切换，同时交易的耗时也会相对比较小。

但是一定要控制范围，因为大家也都知道网络二次打通是有一定风险的，虽然现在能够解决生成数问题，但是也是尽量控制纳入网络二次打通范围的主机的数量，数量少，相对都是小机，变更少，出现问题的可能性就很小。

另外其他的部分，像我们熟知的网上银行等，一定要放在三层。无论是它的Web、APP还是DB，都要解决切换访问的问题，有的不能去支持DNS则要想别的办法。

应用系统连数据库的时候，因为我们有些数据库是放在三层的，这样主备中心数据库肯定不是一个IP地址段，就要想一些临时性办法或者是简单的办法。

两种配置文件应用去联库的时候，一个配置文件的点a、点b，两个分别根据情况给copy到真正的配置文件叫.online，完了再重启应用，这样就能够连接到我要联接的库上。当然这个就涉及到容灾切换的操作细节控制。

同时二层打通还要专门给存储开辟一个通道，保证同城中心的备份能够在一个比较顺畅的网络环境过去，而且不影响其他的交易系统的网络。

再往下一层就是存储资源。存储本身，包括分布式存储，还有软件定义存储等等都有，但这个不是一个简单罗列。上图的右侧，我们要知道应用系统数据在前端这个部分，渠道部分进来是放在什么位置。

我们提到过的这种临时性落地式的文件，它是一种对存储的需求，这里又分结构化数据和非结构化数据。

中间的业务层它是一个什么样的需求？包括对性能和双中心。容灾有状态的可能几乎都是最长。再往前一层，可能是无状态，那我只要是跟盘，速度足够快就行了。

再往中间这一层就是它真正的核心类的交易，它也有结构和非结构两种数据，怎么考虑？在后线长期归档部分怎么处理？因为可能这一个环境里的应用系统不用去双活，但是数据一定要过去。

另外，这个出来之后就要根据高低配的存储和存储特性的不同，去配置和管理整个存储资源，包括对容量，就是切换的可靠性、可行性等等，这就是存储要考虑的问题。

上文提到过两个中心一定是数据本身的备份和归档对等的，所以在整个架构的可靠性设计的时候，要特殊考虑归档和备份的问题。

大家都知道真正做备份的时候，它是很耗带宽、耗流量的，所以在网络设计上要单独留出二层通道给它。本身裸光纤的整体带宽是有限的，所以要做一定的带宽控制，还有其他的就不细讲。但是两个中心任务一定要能够充分的调度，尤其是由一个中心切到另一个中心的时候，这个还要能反向回到。

假如我的应用是由a中心切到b中心了，备份的任务就会备份到b中心，但是同时必须要异步的提供给a中心。

既然是异步的，它一定是有时间差，可能还有最坏的情况，就是在时间差内，中心出现断电等问题，有一部分时间段的数据归档是缺失的。当然无论怎么断电，因为有备份，它是不可能完全丢失的，这就需有一套机制，要知道这些断电的部分，丢失的归档部分，把它补回到a中心，保证两个中心的数据是必须完整、一致的。

这个要投入大量的人力，包括系统这个工作，后续我们要选择一些国产化的备份软件时候，我们在交流的时候发现大家也提出这些需求了，因为早期的备份软件没有考虑到过跨中心这种多中心的情况下保证数据归档一致性等问题，所以相应的管理功能要差。

把这些从上而下几个关键层的整体可靠性，简单的罗列了一些以后，下面涉及的是整个架构和控制。

我觉得架构设计一方面，它是一个静态的，另外控制它本身也是一种可靠性设计。从上图可看到主生产中心到同城容灾，它有一部分是二层打通的，也看到应用是怎么写进来的，同时异步的也有写到灾备中心。

这里也涉及到一个问题，就是所谓的控制的可靠性设计，变更发布的控制是绝对不能漏掉的。

要多活的应用系统可能还比较容易发现，因为我要是漏掉了一个b中心或者c中心的一个应用，它一定会产生逻辑错误，能发现。如果是那种非多活的，平时没用到，变更漏掉的环节的话，等真正去用它的时候切过来，就会出现问题，那是短时间没法恢复的。

既有应用层面的变更，也有像网络负载均衡，包括安全设备等等一系列的。这个扩展后就是我们所谓的运维自动化，包括标准化控制等。设计的时候一定要考虑它，这是让整体的架构具备比较完备的一个可靠性的基础。

可用性的控制，是容错容灾的核心能力，所以容错容灾这个体系的基本构成要素是很重要的。

从我们自身实践来讲，有三个最主要的要素。

第一个就是要准确的掌握容错容灾的配置信息。这个理解很简单。一个应用系统，它的数据库和高可用性对我是非常关键的。哪怕它丢一些数据，即使是一些渠道类型。像手机银行、网上银行等的渠道类型都是交易流水信息，哪怕丢一些数据也无所谓，但一定要尽快回复，否则客户就没法使用。

这种的话，如果给它配了一个克隆数据库，克隆的硬件、软件环境一定要纳入在一倍的配置信息里头，如果没有纳入，根本就谈不上实现可用性控制。

第二个，我们既然知道配置了，就一定要有一个检查的场景，知道在什么条件下一定要去用它。当数据库不可用了，不一定就一定要用克隆库，像前文列举的数据库场景，主备切换了或者重启了，也许都能解决它。当然出现那种逻辑，坏块等错误，数据库无法重启了，就要用它了。所以这是平时，或者是实时的，或者是定时的，有人工去检查的方法一定要确认下来。

第三，精确的处置操作控制能力。强调一下实战跟演练是不同的，它一定不是发生在你预想的时间点上，也可能系统的管理员和技术工程师没有在现场，所以一定要有实际的操作控制能力，这是容灾体系的基本构成要素之一。

这里把我们日常的工作中做一些分享，我们的技术工程师和专家们花费了很大精力和时间去做下面这个事情。

（1）容错容灾配置管理参考：以应用系统为对象实体，按场景维护管控与关联信息

第一个容灾的配置就是以应用系统为对象实体，按场景维护管控与关联信息。

一个应用系统，它在主中心有哪些服务器，包括具体的IP地址名称，它的用途，还有对于服务器的一些健康情况和图中展示的启停，以及一些检查的脚本是怎么检查的。这个脚本要标准化，我们内部交流后，认为它一定要放在标准目录下，方便运维自动化。

另外在同城的中心是什么环境，还有跨中心共享的网络存储等设备一定要清楚。

再就是容错环境，这里要特殊举例，像上文提到的克隆库是一定要掌握的，当然这个是我们在完全手工管理模式下做的，每个工程师掌握一个表。靠人工，比如最近做了一些重大变更之后，我就要同步地维护表，这个效率是比较低的，也比较耗费人的工作精力，下文会单独谈怎么去做常态化工作。

（2）容错容灾场景管理工作参考：单系统容错场景，前提条件（监控）、集成、授权

第二个就上文提到的场景，既然有这套配置了，针对这个场景，它是检查什么条件，它前提条件是什么？它检查的目的是什么？如果发生了怎么处理？这些技术场景的设立，都肯定是要详细考虑的。

这里还有跟业务有关的。我们也去真正的操演练过，如果我的系统彻底停掉了，暂时起不来。但是我有些客户要紧急用款，这时我们考虑到，在核心系统不能工作之前有克隆库，能够查出客户最后一个时间点的余额是多少，紧急用款上，我们也跟业务人员共同梳理一套流程来。当然也会有一套授权机制给客户提现金，保证客户自身需求的满足。

关于它实现授权和预演，就不一一细说了，上文已经反复提到过，这是在它的场景管理。

（3）容错容灾场景管理工作参考：多系统组合场景，业务与技术的组合，逻辑预演

再有个场景管理就是上文提到的容灾，这个是比较复杂的，也是我们实际切换的一个场景。大家都知道上文说的在应用的架构设计上，系统是互相牵连的，当一个系统走的时候，或者切，或者处理的时候，其他系统必须配合。我们在演练过程中可能有十几个系统来去切换。

假如核心系统，它切换有几个大的步骤或者几个任务。它开始的时候，有的系统是不能动的，有的系统是可以同时动，但是完成了第一步以后，后面其他系统可以做哪几步，这个是在容灾场景管理中必须要反复的逻辑的预演出来以后给它固化的。

（4）容错容灾操作过程的标准化：对象、环境、操作、输出等，是工具化的基础

操作的标准化，在没有任何工具的情况下，这个是基础，有了这个基础，才具备实施工具化的可能。

操作标准化的话，在前图的这个逻辑时序，它只是个大的任务，整体性的说是停止核心的一个服务，但是它具体登到不同的机器上，要去处理不同的操作等。这个操作怎么做，怎么让它标准化，都是要细细考虑的。

第二个，整体持续控制之后，就具体到每一个系统中的每一个操作任务，第一要明确在哪个 IP地址，操作它的用户环境是root用户还是其他用户？再是脚本的具体名称或者是命令，包括输出的结果正常是什么？如果输出正常了，下一步是串行还是并行都要标识清楚。这个是之后工具化的一个基础。这些也是在平时的工作中，我们的系统专家和工程师在负责一些系统的时候，会很细化的去处理的这问题。

（5）容错容灾流程的自动化控制：分层级的流程控制，整体、分类、局部三层流程

上文说过，我们从场景的检查、场景确定之后的处理等都涉及到流程，但可能不是一个简单的大流程，在我们实践中，实际是三层表。

第一是整体的，主要是针对容错容灾比较大的场景，我们要知道整体场景下都涉及到哪些系统。假设上文提到的最核心的是核心系统，它切换时跟着它走的大概有三十几个系统，整体有一个调度逻逻辑时序，这个为了方便指挥，并不是实际到某个机器上进行操作的一个命令。

第二就是分类，可能在处理的时候有前台、中台、后台，但是有大类，它内部之间是有持续逻辑的，分类之间它有它的关系，把它分层，每一层简化。

上图表格，是操作的一个详细流程。我们可以用一键式切换工具，或者自动化工具，在已经验证过后，在标准的操作流程基础上给它自动化，这样会大量节省时间长。

真正发生故障的情况下，我可能不在场，所以一定要工具化，让一线值班的工程师有能力去处理，这就是流程。从整体到分类到局部，我们也在朝这个方向去努力，现在有些局部已经能做到，自动化处理的速度也是比较快的。

有效的监控体系是容灾容错的基础，监控也一样，它可能涵盖的范围更大，因为一些小故障它也要监控。像直播间失效了，但我们后台技术上还没有发现，这个是监控配置的管理。

另外是监控的策略，例如针对一个部件，像Oracle数据库，怎么证明它是可用的？直接连接，Select一张表，是一种方式。另外像数据库日志的报错以及一些等待事件等，这些都是标准策略。

(1)有效监控体系的建设策略：以结果为导向，以准确配置为基础，以有效指标为手段

监和控，在目前很多谈的监控实际是监，即我查看CPU，查看内存之间是否有空，发现了一个现象，我虽然能处理，但处理是规避，并不是真正找到原因，从根本上解决。

或要做变更，怎么规避？最简单的方式是多路多活的时候，如果某一路出现问题，像拥堵，则直接停掉这一路，让别的路去工作，可以避免某一些客户进到一个通路以后，全堵死在一个通路里头。这只是一种规避方式。

所以上文一再强调有效的监控体系，它的一个建设策略就是以结果为导向，以配置为基础，以有效指标为手段。刚开始建的时候，都不知道有哪些策略，就是由结果去反推有效率。

监控报警有效率有下面这些点：

除此外，还有监控策略准确性，我们根据监控报警的效果分析，持续调整优化监控指标、补充缺失监控指标，确保监控策略的准确性。

（2）监控管理与系统建设策略：以对象、指标、策略为基础，跟踪监控发现率、持续优化策略

监控档案：在现实中存在这样的问题，虽然有很多技术人员，但有的专注于工具开发，有的专注于系统集成，有的去被动改进，我们没有整体规划，都是出事后亡羊补牢，这虽然是一种方式，但跟实际的运维是有偏差的。实际运维需要有一个明确的监控配置，就是档案。

另外场景要有针对性的设计，有持续更新计划。像上图右侧是我在网上看到的一个运维的技术专家面试的时候，面试人员大量提了我熟悉Nagios、Cacti等等，但他忽视了作为一个监控的管理人员，应该知道Oracle要如何检查判断是否正常，以及某一类的应用系统要如何确定是否正常。我们有效监控体系里，大家更关注于工具和开发，却往往忽视了它的有效性。

（3）详细准确的监控配置信息，是有效监控的基础：实现与系统变更同步的监控配置控制

上文提到监控的基础是准确的配置信息，配置信息一定是跟研发有关的，肯定要跟研发同步。所以在日常的管理中，在跟研发的应用产品设计的时候，一定是从设计开始，如现在有的应用系统数量以及它应用系统模块数量，这个信息要跟后台的配置。

上图右侧，大家可以看到监控自身的属性，有系统架构、逻辑结构，以及底下配的系统资源。上文监控系统部分已经提到，它调的存储，调的数据库，调的安全设备等等，都一定要很清晰的控制起来。研发和运维整个管理工作的衔接，涉及到大家熟知的一些领域，运维和开发理解角度可能不同，但统一后大家可以清晰了解，所以详细准确的监控配置信息是监控的一个基础。

（4）监与控是容错容灾能力的关键构成：发现、定位、处置，通过场景判定严重性

监和控，是容灾容错能力构成的关键部分。

什么是控？实际是我们从一些实践场景中逐渐去分析它，去控制它。

控前提是要怎么控，所以有三个关键词：发现、定位和处置。

上图右侧是以前很早的时候遇到过的一故障，柱状图是交易的量，折线图是它的响应时间，可以看到响应时间基本接近50送达那就断了。

面对这个系统，例如直播间后台系统出问题了，我们处理的时候，一定会考虑网络情况、系统的报文、资源等，一层一层去想，如果都登录系统自己去查会很耗时间，更何况一个大系统的维护环境里，我们不可能有权限登录所有的，所以需要把它定位的场景逐项进行梳理，列成一个表格。

如果有工具，可以工具化，用自动化来检查，检查发生场景，知道如何处理，这是监和控的关系。

（5）容错容灾管理与监控管理的关系：对象、组件、场景、流程、任务、关联

因为监控是容灾基础，他们之间如果要去做工作，或者是做一个工具平台系统的时候要怎么集成？

因为监控管理一定要有准确的监控配置信息，监控配置之后，每一个部件要布一些策略，它产生的报警信息要给到容灾管理的工作环节中，而容灾是以应用系统为基本单元，把它拆分构成的组件，刚才说到它调用这些组件，它自己服务器数据库等等。

每一个组件有自己场景，确认这个场景发生了，就要处置场景，这指的就是一个任务。上文我也提到，流程分成整体的、局部的和细节的，有一二三层，这个任务相当于二层，具体任务的执行可能需要自动化工具或者人工去执行。

当然也要考虑跟其他的应用系统间的逻辑和时序关系，即相互间切换的时候，我先走一步，你再去走你的第一步，那之后我走第二步，我俩234之间都可以并行处理，但是我4，到了你4的时候，一定要等我的第4步，这是有可能会有逻辑关系的，所以要做控制，容灾管理和监控之间要形成一个集成关系和工作上的一个互动关系。

有了上面基础后，我们要讨论的一个话题就是如何将容灾容错的演练形成实战能力。

我们2020年已经做过演练，6月份计划9月份做一次演练，在这期间，大家都会检查自己环境，把应该测试的脚本进行测试，反复的讨论逻辑、过程，等都已经讨论清楚后，大家就开始在一个指定日期去做，这就是一个演练过程。

演练目的一定是为了找问题，因为如果不实际操作，一定不能把所有问题都发现了。只有找到问题，分析它的原因和改进方法，才能为形成实战能力打下一个好的基础。

演练的过程，第一要有实操的任务，任务有去执行的人，同时也一定要有观察记录的人，记录耗时跟预计是否相符以及出现的问题等等。

当然还有一个授权，真正演练的时候，因为是实操性演练，就要授权。关键点上一个控制或一些关键操作，像存储的同步调头等等，一定是靠人来控制，不能完全自动化，否则风险太高。

这个就是演练它的设计和意义。大家往往演练时忘了去详细记录，等演练完了，特别大的问题也许会记住，但一些细节问题可能记不住，这样演练后，就浪费了机会，没有完全发现问题。当真正实战时，可能就会因为一个小的点造成整个容灾切换结果不是太好，所以这就是一个目的。

另外做操性演练，我们还要确认一点，在把一个关键系统切到了同城的一个中心，有的系统本身是多活的，涉及到切只是流量配比调一下，但像银行核心例如账务系统等，是很难做到或者没必要去做到跨站点的这种数据库的双活，而且这个是很复杂的，它就是一道切的动作。

切过去之后，因为相当于它到另一个中心，它跟有些系统相当于跨了中心跑。跨中心跑的，它之间是互联的裸光纤，每一个具体的网络的就是一个会话，可能会延迟几毫秒，累积起来会有几十毫秒的延迟。如果不实操，我们就不清楚这个系统切过去后，在日常的工作场景下，它性能是否可承载业务，所以这个是我们实操之后得到的一个结果。

上图可看到，整个系统的交易成功率和响应时间是不同的。请求了，搜索端的网卡马上有反应，图上左侧是切换前，右侧是切换后，切换前后基本一致，但是有差异，时间、成功率稍稍有下降。它后台的账户系统是一个原子交易，但对于前台客户，这个在他可接受范围内，在两秒钟之内反映交易回来，可以接受，也影响不大，这样评估下来，可以确认我们容灾中心是可用的，这个也是一个演练目的。

容灾容错演练和实战之间的差异，有两个是最大的差异。

上文说到了演练都是有计划性的，是准备好的，实战是我们不能预计的，不知道什么时候发生的。所以可以总结这么几点：

第一，演练是有计划性的，肯定要预先梳理检查。我们可能会花了几个月时间去准备、报备和协调，并且所有环节都要经过测试。最关键的是操作时候，还是由专门系统的技术工程师去操作的。

第二，实战的随时性。不可预计发生时间，随时开始实战。真正发生故障时，我们会面临系统的高频率变更，因为像一些大的企业数据中心，例如银行一样，几乎每天每周都在变化，它变更如果我们没跟上，变更环节没有纳入我们视野和控制范围，切换一定会失败，所以操作一定要随着变更去同步，这是实战中随时要解决的问题。

另外最关键的一点是，好多系统是365天7×24小时运行的，我们具体负责的工程师不可能24小时准备着，所以故障发生的时候，操作很可能是由一线的值班工程师或者B角实施的，这个是演练和实战的不同。

第三，演练是有确定性的。因为我们可以知道今天是针对核心系统做切换，而且可以事先梳理它相关联的系统。

第四，实战的随机性。真正实战发生的时候，往往是从一个小事情发生了，但大家没有意识到它是个灾难，灾难发生，不知道它是什么情况，这个就是所谓的随机性。

实战和演练是完全不同的，所以一定要有很强的发现、定位、处理能力，才能够真正的达到实战性的要求，这就是演练和实战之间的差异。我们可能经常演练，却忽视了实战性的建设和培养，等真正发生灾难的时候，完全处理不了。其实对于一个企业来讲，巨大的人财物的投入，在真正需要的时候没发生作用，这是最不可接受的了。

这就是整个演练和实战的差异。将容错容灾演练形成实战能力，就一定要通过日常的实践分析，不断的去完备监控体系，也同时形成完备的容错容灾体系。

从源头上设计。因为总有达不到100%可用性的情况，达不到了什么程度也一定要分析原因。

原因分析是针对于特殊标记的客户问题的容错处理。例如代发工资，企业有1万人发工资，但是有一部分人因为它的卡状态或者什么历史数据问题，或者是因为签约关系或应用的bug问题，一部分人发不了工资。

我们一定要进行容错处理，分析情况发生的原因。或者去改应用系统的业务逻辑，或开发一个关于错误处理的工具，在特殊情况下我们绕过业务，直接把应发的客户工资发下去，这个就叫一个整体性设计，整个过程是迭代的。

通过这种方式，包括上文提到的，先把工作标准化，之后再把它工具化，再加上培训和迭代开发，最终让我们的容灾容错能力极大的接近于实战的最高要求，这就是整体的一个建设思路。

日常工作中可能更细节的一些。最关键、最直接的就是前文提到的，我们整个的数据中心的系统，它在不停的变更，监控要跟上，监控跟上以后容错也要跟上，我们自己内部也在讨论，在逐渐朝这个方向努力。

应用、系统、网络的管理员一定要遵循变更的管理要求，去把变更分成标准的、常规的、紧急的等等，包括按照风险级别。我们的技术人员，尤其是要求高可靠性、高安全性的人员，一定要遵守合规审计等的要求，这也是一项IT的管理。

我们要严格按照着做，只要做了变更，就一定要及时登记，当然要有工具来自动扫描、自动化。现在有些领域是完全可以的，像IT资产是完全可以做到的，要保证它是准确的，它是我们一切工作的基础。

监控的管理员，只要是一个生产的对象，我们就一定要维护到监控的档案中，并且这个对象，我们一定要给配上标准的和非标准的监控策略，由监控的开发人员部署下去，这样整个体系才会完备，监控没有漏洞和死角。

在这个之上，我们再把需要容灾的部分单独标识出来，如果有专职的容灾的管理员会更好。系统可能有几百个，但真正的重要系统可能是一小部分，系统的管理员需要识别出自己哪些系统是容错的，像上文的监控事件，容错场景它大体的区别就需要标注上。

这样的话，后线有专门容灾的管理，对于它的配置，巡检的场景和处置，要不停的迭代更新和验证，这样的话把它形成一个常态化工作。

所以今天主要分享的内容是这些，可能每一个层面只是点到了没有去展开讲，为大家整体梳理一个思路，关于怎么建设整体的容灾容错的能力。

Q1：容灾可视化平台可以集成哪些双活的指标？

A1 ：这个实际是监控的一个展现问题，因为我们本身哪些系统是跨中心双活的，我从实时监控上一定能看到，包括配套一些巡检。

Q2 : Oracle数据库的双活中心？

A2 ：是说的跨站点双活，我没有做，因为跨站点的话，双活一定是有延迟的，无论你裸光纤速度再快、再可靠，都一定有延迟。甚至于同中心，我们也没有做数据库Oracle的，因为选择某种技术方案，要看实际的环境。

第一，对于我们来讲，单独的小机，假如每天1000万的交易量是能够承载的，我没必要去做集群，集群有集群的复杂性，包括一个故障的处理，以前我们拿别的系统验证过。另外，我们自身没法配那么多的高级DBA去维护，所以我们我退而求其次。当然有的特别大的数据中心和银行只能用集群，单机不够，容量不够。

单机够的话，我这个HA配成最简单的这种劝阻装置，我们因为数据库是多实例的，实例更简单的可以用克隆方式来更快切换，一两分钟之内。越简单，它是越可预期的，可靠性越强的。我一旦这个环节出现10分钟我能恢复，那就行，这也满足监管对于30分钟恢复的要求。

Q3 : 对于自动化运维监控，运维工具有什么要求？

A3 : 实施方案不具体谈了。最关键的点，第一要知道整个体系架构中，有哪些部件要纳入监控范围。可能我们像看一部车，它的所有的部件过程部件都要有一定的监测，否则这个车一定是失控的。监测的策略是什么？有了这些我再去选择工具，工具无非说开源的等等，这个工具是替你把数据采集回来，你一定要有统一的监控。把它从这种message消息一定处理成带有结构信息、可利用的监控数据。

最后对于定位和处置，尤其在定位准了之后，才能去处置，这个是真正发挥效果的。也就是说监和最终的控非常重要，不能是只监不控。

Q4：银行自己容灾体系要求达到几级标准？

A4 : 我们具体现在是按照监管要求，把重要的系统，同城的情况下，它的 RPO肯定是0，因为银行的数据不能丢，丢了出账务风险了。

RTO在监管要求是30分钟之内，当然你会力求越短越好，因为我们很多系统多活之后，它涉及不到切的动作了，那可能就是一瞬间把可能堵塞的a中心的某些路给它停掉，这个停我们是利用监控自动化的方式，实际类似于我们红绿灯的调度方式，只要它标识了之后，负载均衡就不再给它分流量了，马上就停掉。它速度会更快。

但是具体到核心系统，它没有办法，只能切。这个切，我们演练的方式，也是最后能够达到验证，等待30分钟内能切完，这也满足监管的要求。

Q5 : 规避容灾应急切换的风险点？

A5 ：切换中间动作一定会有失败的。像数据库，我们也列了，要有退路，我们作为运维的技术工程师，一定要有b计划或者c计划，一定要想到最坏的情况下，即使RTO已经很长了，也要去监管汇报了，必须要把业务和数据恢复过来，不管是后果是什么，这是要首先保障的。

Q6 : 进行容灾应急切换演练的规划，系统的高可用性融资应该建设到什么程度？

A6 : 规划的话，几百个系统，我们有监管重点盯着这些系统，达到RTO在30分钟之内，RPO是0，这个在同城可以，异地做不到，可能要有一个时间限制。

另外根据自身要求，因为要保障对于客户的优质服务，它本身是有要求，我们把这些系统排查出来。

我们有一套排查方法，从几个维度，业务影响度、损失、技术的关键性等，因为有些基础应用系统是没有业务的这种直接损失，但是它影响大，所以我们会综合打个分，根据分数来做容灾的配置，是同城双活，还是同城的2+2的方式，或2+1的方式，或者同城做数据集，根据结论来配置，大体根据投入产出和具体情况来看。

姜岩

某城商银行 数据中心总经理 

 

• 拥有27年银行应用系统开发、运维管理、架构管理以及新业务科技实现的设计等相关工作经验；

• 历经多次核心系统更新换代，对金融科技与业务的配套发展有着深刻的思考。

大家好，借难得的机会，也借dbaplus社群这个平台，跟大家交流和探讨一下容灾容错这套体系的建设，包括实操性演练的一些设计。

首先要讨论容灾容错都包括什么？为什么是一个体系？因为容灾容错有它的背景，这个背景主要是从业务连续性管理的范畴角度，业务连续性管理可能很多朋友也都清楚，不清楚的话网上有比较标准的一个解释，这里特殊强调，它主要是针对于企业业务的非计划性问题产生影响，有针对性的去制定一些业务连续性的保障计划，控制企业的经营风险。同时像我们理解的也是为企业的客户提供优质服务的一个手段。

具体的来讲，容灾容错体系的构成主要包括各种可能出现问题的场景。

第一个是小概率大影响的灾难性场景，这也是标准的容灾容错涵盖的内容。假设一个主数据中心，因为电力的原因，或网络的原因，整个系统要全体切换到另一个容灾中心或者同双活的一个中心，这是概率很小，但是影响肯定会非常大的一种情况。

概率比较高和影响也比较大的情况，我觉得也应该纳入到体系里的。一些严重的故障和错误，也会产生这种问题。容灾不仅是灾备中心的整体切换，所以这里要特殊强调容错，这是一类问题。

谈到对客户优质服务，还有一部分客户问题是系统正常但应用程序存在一些逻辑 bug的，或者是基础数据问题造成一部分的客户没法去完成交易，这也是我觉得应该涵盖在内的。

所以容灾容错这种实战能力的建设，我理解上认为主要包含三个部分的工作。

第一，是架构和控制这两个问题。

系统整个架构的可靠性设计，这是容灾容错的一个基础。这个基础之上，我们还要有对于服务的可用性控制，即有了这个基础之后，还有一定的发现、定位、处置能力的一个控制能力，结合在一起，才能真正的达到容灾容错实战的能力要求。

第二，是演练和问题的跟踪。

即设定我们的这个场景不一定是能够生效的，所以要有一套演练、问题跟踪、分析成因和形成规范、迭代开发的一个过程。而且这个过程不是突击性的、一次性的任务，是要结合我们日常的运维做的一个任务。

第三，是把它形成常态化。

金融行业经常制订一些工作计划，一年计划几次，在之前大家做了充分的准备，然后演练，但实际真正发生故障，肯定不是跟演练一样的，所以一定要把容灾容错的能力维护建设在常态工作机制中，才能确保随时发生、随时能处理。这是一个简单的理解。

容错容灾都主要包括哪些场景？上文也提到很多场景的问题，这里我想简单的举一个例子，可能很多方面是大家曾经发生过的问题，一是应用的系统或者体系，客户接入进来可能发生哪些问题？

安全性的问题，或是大家熟知的像负载均衡等调度问题，还有交易逻辑的组合问题。尤其是银行，银行的交易是比较复杂的，靠多个应用系统组合起来。

一些容灾或者是多活数据中心，一定会产生多路径的问题，包括多路径怎么解决，应用系统自身基础性的条件问题，还有会话的模式和方式的控制。

最重要的是数据，应用系统在工作过程中，既会产生临时性数据，也会产生这种永久性数据，临时性数据会存在一个有状态、无状态的问题。

可能交易是异步的模式，进出是不同的通道，数据落在某个路径上，另一个路径找不到它，这个交易很可能就失败，这些问题都要解决。

另外是最基础的一个问题，上图中我也列出了很多这种技术环境问题，这是容灾容错要考虑的场景，不一一讲，有的我们本身出现过，例如交易逻辑的组合问题，上图特意标出了一个颜色的信贷流程，它是比较复杂的一个业务流程。

我们的应用程序无论怎么开发，都不可能完备的覆盖任何的错误场景，包括像业务员操作的一些输入的错误之后，不可能把这个流程重新发起重走，只能通过这种错误的临时处置机制来处理。我们的技术人员每天也会大量处理这个问题。

另外银行特殊有的，我们叫联机批量交易，即代发代扣，像大家熟知代发工资等等，如果量特别大，它会切分成很多文件，这些文件并发处理之后，并发的锁机制和控制问题，如果控制不好一定会出问题。

再有一点是强调永久数据，大家可能更加关注多活数据中心的交易，但是一个容灾的中心，如果是完备的话，不仅仅是交易能够承载，它必须同时保证数据是一致的，尤其长期历史归档数据。

银行要存储很多交易的历史数据，还有其他的像信贷等等数据，这些数据按照监管或者会计法，至少要保留15年或者更久，这个数据中心一定是对等的，否则它起不到任何容灾的作用。

这些是我简单列出的场景，但是每个场景可能在不同企业中会有不同的问题，要根据实战来考虑。

为什么容灾容错是个体系，我理解上认为容灾容错是一种能力建设，而不是一种资源配置。

容灾容错的能力，实际是由日常的事情发生并逐渐演化过来的。我们在日常中不一定能预见到一个灾难或者一个重大故障的发生。刚开始可能就是一个小的事件和苗头，所以在容灾容错我们重点考虑的一个是监控事件，我理解的就是在日常中经常会有报警发生的，需要处理或者是无需处置，或处理起来相对比较简单的，像应用的队列清理和清理之后的重启服务，这些我理解就是监控事件，需要处置。

容错场景比较复杂，而且影响也相对比较严重。另外处置过程中，既需要人的介入，也需要系统之间互相关联处理。有的交易链条比较长，由a、b、c几个系统串联起来，a处理的时候，后续的b和c连带的必须要处理，这是容错的场景。

容灾，对服务有严重影响，处置前中后过程中，需要全面控制系统内外部、各类业务场景的关系，容灾是技术与业务全面共同处置。这也是上文提到BCM为什么是以业务场景为主导的必须要细分。

在我们日常的一些故障之中也遇到过，出现过不是纯粹的技术问题，业务也有一套准备。这也是监管部门对于业务连续性保障，从业务角度要求去考虑的一个问题。

我们应用系统设计的时候一定要考虑个问题，叫可靠性设计，整个系统如何做可靠性设计。设计了后，一定要做破坏性测试，即假设容错或者容灾的场景发生后，会产生的结果和设计有效性。

这步过了之后，就要做适配。上文说到可用性控制能力是很重要的，所以配套的监管控体系一定要配上，最终要形成标准化的操作。这样一线的工程师在值班的时候出现这些场景，才能够迅速的发现，并能够按照要求去处理，真正的形成能力。

最后是工具化验证和培训，这是一个迭代的过程。在演练或者在实战中，肯定会发现漏洞，因为任何一个体系都会有漏洞，一定要回到最开始的可靠性设计来讲，要不断的完善一个技术规范标准，控制整个体系的设计质量，提高整体的可用性，这是容灾容错为什么叫一个体系原因。

上文谈到体系的一些概念，那我们日常工作要怎么落地？这一块我们也在总结自己的经验，并且不断的按照这个思路去推进自己的工作。它和平时的日常运维工作要怎么结合，即怎么能让它常态化呢？

做运维的，会有一个运维的全生命周期管理的过程，我们跟研发共同探讨设计这个系统，最后投产，再加上运维方面的一套理论，包括ITIL事件问题，包括变更和配置管理，管理之后一定要形成一个有效的配置管理数据库，这个是重要的。

配置管理数据库怎么展开去讨论，这是一个比较大的话题。但是我们可以根据自己的需要。我现在以事件的发现和处置为主，那么它主要信息就是为了监控服务的，最后有一部分，主要配置通过了，基于配置信息就要生成监控它的配置库，也就是监控本身一定要知道都有被监控的系统，知道哪些是被储备的，能够有场景去处理的。

之后要有一套的监控工具和手段，同时要把配置信息拿给我们，这叫容灾的管理。

容灾是监控的一个子集，如果监控其中有一部分是跟上文说的容错容灾的场景相关的，一定要拿进来，对它做额外的检查确认，确认它场景是否发生。如果发生后，对它一定要有的一个处置的过程。这个过程，如果有运维自动化的工具，就用自动化来处理，前提一定是先标准化，不管是手工操作，还是人工管理，先标准化再自动化，再处理事情。这样的话，又返回到我可能调度一些已经设置好的运维工具的这么一个循环过程，上图是个简要图示。这个目的就是怎么与我们正常的运维工作结合在一起，形成常态化，让它形成一个真正的实战能力。

接下来，架构的可靠性设计，这个是容灾容错的一个基础和必要条件。没有这个的话实际谈不上真正系统的高可用性，架构的设计肯定是差异化的，不可能一概而论。

服务接入渠道类：以典型的银行为例，接入类的，就是大家熟知的或使用的网上银行、手机银行等等，即对客户直接服务的，这一类的特点是，多活、弹性、弹性扩展、多路接入等等。

在容灾方面，要考虑会话的一致性，这是一个典型的问题。我们在自身的实践中也发现了这些问题，例如跨中心双活时，有的系统不能简单切换过去，尤其是同步的或者异步交易的来回通路不在一起，中间可能有负载均衡资源等情况，它已经把连接池化了，怎么能保证一致性，这是一个重点要考虑的问题。

这里我就不再展开讲了，因为每一块内容，像负载均衡等等展开讲，在我们的论坛，或者我看过的以前一些文章，都非常专业，也讨论得非常深入细致。

它既要负载均衡的设置策略，也要研发的应用程序开发，这两个必须配套。我们也曾出现的问题就是这两个环节不配套，最后造成了一个多路的会话不一致，也有可能只是少数客户的交易就出现超时或者失败。

业务逻辑平台类：在银行来讲，典型的有网上银行这类服务平台，或者是信贷的业务平台。这一类，它的业务数逻辑的一致性要求比较高。另外，它数据的处理逻辑也比较复杂。

在可靠性设计来讲，是上文提到的落地数据的多路径一致性，因为很多交易是必须要做落地文件的，不可能全是走报文。落地文件之后，这个文件进出如果落在不同路径上应该怎么处理？

现在通用的一种方式，可以用一个NAS存储资源共享文件系统，但在细化设计上，各个业务通道，进出的时候要写到不同的文件目录下，避免混淆，同时变更发布也会更方便，这是细节了，就不再展开谈。

核心账务服务类：不管是银行，还是其他企业，肯定有自己的核心系统。核心系统的要求，在整个架构里，越往里层，对它的交易时间、完成速度等要求则越高，这一层在可靠性设计上，各家企业都不一样，包括技术人员的数量和素质配比、投入资源都是不一样的。结合自身，我们采取的是简单可控的模式。

例如基于小型主机的核心系统，针对它的HA设计，考虑到我们企业中高级技术专家资源有限，就没有采用更快速但是更复杂的技术方案，而是选择了比较传统的HA加数据库资源模式，但是Ha里放的Resource资源一定要很少，只有最基本的存储和数据库，这样切换的耗时和成功率是可预期的，每次切只要是10分钟之内完成，就是我们可以接受的。

数据仓库分析类：数据仓库这一类的架构设计，它虽然不是一个在线的交易系统，但像金融企业要产生的一些报监管的数据，或后台的总账数据等等很重要的，都特殊强调数据来源需要与容灾切换必须配合。因为前面的业务系统切走了，数据抽取的时候，如果没有控制好，可能抽的就是上一日或者是错的数据，更可怕的是没发现，最后你报出去的数据或者出去的总量数据是错的。

这个事好像不是太难，但其实这个数据分发路径在任何一个大的企业，包括有一定规模的银行去梳理的时候都是很困难的。谁和谁传了什么数据，数据供给方如果切走了，IP地址换了，抽取数据能不能准确地跟上，这都是一套机制，这也是上文容错和容灾里强调的。跟日常监控处理不一样，它是要跨系统之间要协同，所以可靠性的差异化设计要综合考虑不同类型的应用系统。

从架构设计来讲，肯定是自上而下进行整体考虑的，上图图示的是一个典型的银行交业务系统的结构。客户怎么进来，怎么进到业务的平台，怎么到后台的核心系统，当然都通过这种企业的服务总线，到最后线的数据仓库类等等，都涉及到上文说到的不同会话模式怎么考虑的问题。

（1）访问的接入

对外提供服务，有的是直接对客户来提供的，另外也有机构之间互联的，就像银行跟三方支付。C2S、S2S的访问目标需要考虑域名，尤其容灾中心，我从外联专线，从主中心切到另一个中心的话，运营商没法保证公网地址是一致的，域名、端口要怎么处理。另外还有现在要面临的，也是我们正在做的V4到V6的转换容错，这些都是访问接入问题。

（2）会话模式

会话模式涉及到两个，一个是上文提到的长连接的断链重联协同控制，如果系统复杂了，互相之间可能有的不需要重连，有的需要重连，这些要靠日常尝试，并在确认后要形成一套针对这种灾难场景的操作规则。

短连接的多路径均衡和流量控制，这也是一个要考虑的问题。两个不同中心或者更多中心，从多路经进来以后，怎么进行负载流量均衡？因为有可能你后台的一个系统，像核心交易从a中心切到b中心，毕竟在一个小的局域网，前面接入层的配比一定得调，把快的部分调大，把交易相对比较慢一点的调小，以保证对外的可用性。

（3）临时数据

临时数据上，从上图可以看到，尤其是图中左上角的几种交易类型，大家要熟知一下，一是单向的这种联机交易，二是双向的联机交易。所谓双向就互为可难端，这个开端口和可靠性重联机制都是会不一样。

另外是单向的批量，也就是传数据的，传落地文件的，还有双向的，都要考虑上文提到的有状态无状态的控制。

还有就是文件并发。并发是为了提高效率，但是它锁机制控制一定不能出现问题。当然我们自身也出现过各种问题，从这个问题的解决，总结经验再去改进它。

（4）流量控制

流量控制上，既然是多活多路径的，就一定要有一套的流量控制方法，否则流量异常或者是有一路堵了之后，没有相关控制手段，就会造成恶性循环不可控，这个是可能要考虑的关于整个架构设计的问题。

应用系统间怎么调度和控制的，这个大家都很熟悉，无非是负载均衡，至于是用开源软件，还是用一个商业化的软件做，或是用纯粹的硬件设备，这个根据自己的流量性能要求而不同。一般在银行的关键业务系统上肯定是选择专用的硬件设备。

（1）均衡调度的设计需求

选择均衡调度系统时候，第一是考虑它的可靠性，像冗余无单点设计，运行状态可监测等等。

另外是性能。最小的或者是单中心的，甚至是单台设备，就能支持支撑所有的高并发，保证在极端情况下，还能够承载最高并发度的一个业务。

再就是控制，能提供标准的API，让它的启停、操作、切换，数据的采集等能够自动化，这是对于负载均衡的一个设计要求。

（2）均衡资源使用策略

分发调度上针对短连接类请求，实现流量配比调度、后台资源监控、服务异常调度、防止交易混流。

无缝切换则针对长连接，实现后台状态监测、异常情况下前端连接的平滑性控制、会话一致性保持。

还有一个是跨中型的，后台的服务是不同的IP地址段的，关于网络的二层三层这种互通差异的配比调度。

我们所叫的应用程序，和应用系统之间是有区别，应用程序我们可以理解成代码。

应用程序内部的可靠性设计，这里列举了一些问题：

（1）接入一致性保持

用户和系统的重复访问控制，我们也曾出现过，尤其是多活多路径的一个用户，重复登录了，有可能会造成业务的一些问题。

还有就是负载均衡的配套设计，上文提到负载均衡如果配了一个参数，后台的应用系统必须要配套去按照这种模式写程序或者是设计。

另外是二三层访问之间的实现。

（2）业务逻辑可靠性

业务逻辑，这是应用代码要考虑的。我们很多开发同事未必会考虑这种边界条件或者极端情况，业务逻辑异常中断后，能不能断点续做？有没有查询冲正和报错输出这种机制等等。特殊提到的重复代发，我们自身就出现过这个问题，它因为异常中断了以后，锁机制实效，可能造成代发工资，重复发两份等问题。

（3）日志完整性控制

日志完整性的控制很重要。一个应用系统，正常的交易也要写日志，这是为了在排查一些应用或者业务问题时可以来使用。再就异常报错日志的信息完整性、日志输出的标准化。

这里特殊强调跨站点的多路模式的采集，因为很多交易可能是异步模式，进出不同通道，一旦客户的账务出现问题，或者是有其他复杂问题，我们去追踪，去检查的时候就很困难。如果分散到每一台机器日志上，那业务员和技术人员要每一台机器登录去检查日志，而且要把交易的整个场景拼出来是很困难的。所以跨路径采集，也是发挥我们日志的采集、分析的。

为什么叫应用系统？就是我把这段程序代码装到了一套系统中，应用的外部部分，无论是动态的、静态的部分，我装到外部server中，应用程序我装到APP的server中，当然像银行还有核心系统，很多它的批量程序我装到它的DB server上，我的整个网络环境，负载均衡设备，包括DNS这都是要配置的，跟应用有关的还有网络的访问关系控制，包括Ha等等，这些配置完了我们叫它为一个应用系统，这个时候应用系统作为一个完整的，有自身体系的，才能够对外提供服务，才能发挥它的作用。

（1）应用服务状态监控

在应用系统的可靠性上，一个是应用服务状态要可监控和采集，否则我们不能确保它是否能够正常运行。

说起来简单，但是做并不容易。最简单的监控某个进程，监控它的应用服务技能、端口等在不在，即使在也不一定代表是正常工作的，它僵死了，我们可能也不知道，这就需要讨论一些方法了。

例如用日志给它输出心跳信息，每10秒、20秒钟输一个报正常平安的一个状态，连续多长时间收不到的，表示它有可能僵死了。这个时候就需要决策，可能要涉及到的，如果是简单的即监控事件处理，如果复杂的就是容错容灾的处理。

（2）系统资源调用控制

另外应用程序，它对于系统资源的调用，最主要的像数据库、文件传输、加解密设备等都是有调用关系的。有调用关系，有一定的结构，它就一定存在不可靠性。那就要考虑可靠性的提升。

（3）后线持续运行控制

切换后的一个仓库的系数，一旦核心系统切换了以后，卸数后面的数据仓库等一定要跟上，包括数据备份，上文前面提到过，双中心或者多中心，它数交易能力对等前提下，数据一定是对等的。

我在a中心有的全量的数据备份归档，可能有30年、40年的数据，我在b中心必须也有。像我们一个应用系统瘫痪了，客户可能一段时间做不了交易，这只影响客户体验。但一旦数据备份丢了，这个是永远补不了，这个是灾难性的。所以在应用系统的可靠性设计上，综合要考虑的都是这些点。

提到应用系统，既然叫系统，即应用程序叫资源。这里最重要的一个资源，大多数应用系统都避不开的就是数据库，尤其是关键系统数据库的压力比较大，像银行核心系统，24小时运行也没有任何的时间专维护和处理的。另外它数据量可能非常大，一个要求数据的完全的强一致，这个就要考虑它可能出现什么场景。简单列举了一下，有数据库僵死、服务器的硬件故障、同城站点故障、数据库逻辑故障、数据库软件BUG、城市灾难问题以及其它不可预见问题。

针对这些场景的异常处置有本机重启，即主机故障以后重启，这是可能的一种操作。其他的不详细讲。

上图提到克隆，就是说同构要有个克隆，例如我是Oracle，我克隆的软件也要是一个Oracle，保证它正好切过来。我们努力的目标是要它做一个异构的克隆，它主要是防数据库软件的BUG。这个就是在数据库的场景上，当然每个展开了以后，可能会有详细的一些设计。

大家觉得最传统、最直接的这种数据库主备机HA切换，如果真去维护一套数据库的DB的小机的HA体系，这是非常复杂的。因为任何一个细节考虑不到，可能就会造成HA切换失败，这个时候还比较麻烦。因为大家也不知道数据库是什么状态，没法去处理。这就是数据库按场景的可靠性设计。

再往下层是现在银行叫的两地三中心，可能也是多中心，网络基础环境需要怎么设计。我们自己具体在做的，可能还是相对比较传统的，就是两地三中心这种方式用光纤联通，同城因为是在一定的距离范围内，能够满足这种相当于存储同步，异地的话只能异步了。就是相当于RPO不是0，同乘RPO则可以是0。

另外就是上文提到在整个架构设计的时候，要考虑不同系统的特点。小范围的可能要打通网络二层，打通的目的是给这些核心类系统，把它放在里头。这样的话，两个中心，同城容灾中心和主中心，它所有设备都在同一个IP地址段，比较方便前面连接和转的这种切换，同时交易的耗时也会相对比较小。

但是一定要控制范围，因为大家也都知道网络二次打通是有一定风险的，虽然现在能够解决生成数问题，但是也是尽量控制纳入网络二次打通范围的主机的数量，数量少，相对都是小机，变更少，出现问题的可能性就很小。

另外其他的部分，像我们熟知的网上银行等，一定要放在三层。无论是它的Web、APP还是DB，都要解决切换访问的问题，有的不能去支持DNS则要想别的办法。

应用系统连数据库的时候，因为我们有些数据库是放在三层的，这样主备中心数据库肯定不是一个IP地址段，就要想一些临时性办法或者是简单的办法。

两种配置文件应用去联库的时候，一个配置文件的点a、点b，两个分别根据情况给copy到真正的配置文件叫.online，完了再重启应用，这样就能够连接到我要联接的库上。当然这个就涉及到容灾切换的操作细节控制。

同时二层打通还要专门给存储开辟一个通道，保证同城中心的备份能够在一个比较顺畅的网络环境过去，而且不影响其他的交易系统的网络。

再往下一层就是存储资源。存储本身，包括分布式存储，还有软件定义存储等等都有，但这个不是一个简单罗列。上图的右侧，我们要知道应用系统数据在前端这个部分，渠道部分进来是放在什么位置。

我们提到过的这种临时性落地式的文件，它是一种对存储的需求，这里又分结构化数据和非结构化数据。

中间的业务层它是一个什么样的需求？包括对性能和双中心。容灾有状态的可能几乎都是最长。再往前一层，可能是无状态，那我只要是跟盘，速度足够快就行了。

再往中间这一层就是它真正的核心类的交易，它也有结构和非结构两种数据，怎么考虑？在后线长期归档部分怎么处理？因为可能这一个环境里的应用系统不用去双活，但是数据一定要过去。

另外，这个出来之后就要根据高低配的存储和存储特性的不同，去配置和管理整个存储资源，包括对容量，就是切换的可靠性、可行性等等，这就是存储要考虑的问题。

上文提到过两个中心一定是数据本身的备份和归档对等的，所以在整个架构的可靠性设计的时候，要特殊考虑归档和备份的问题。

大家都知道真正做备份的时候，它是很耗带宽、耗流量的，所以在网络设计上要单独留出二层通道给它。本身裸光纤的整体带宽是有限的，所以要做一定的带宽控制，还有其他的就不细讲。但是两个中心任务一定要能够充分的调度，尤其是由一个中心切到另一个中心的时候，这个还要能反向回到。

假如我的应用是由a中心切到b中心了，备份的任务就会备份到b中心，但是同时必须要异步的提供给a中心。

既然是异步的，它一定是有时间差，可能还有最坏的情况，就是在时间差内，中心出现断电等问题，有一部分时间段的数据归档是缺失的。当然无论怎么断电，因为有备份，它是不可能完全丢失的，这就需有一套机制，要知道这些断电的部分，丢失的归档部分，把它补回到a中心，保证两个中心的数据是必须完整、一致的。

这个要投入大量的人力，包括系统这个工作，后续我们要选择一些国产化的备份软件时候，我们在交流的时候发现大家也提出这些需求了，因为早期的备份软件没有考虑到过跨中心这种多中心的情况下保证数据归档一致性等问题，所以相应的管理功能要差。

把这些从上而下几个关键层的整体可靠性，简单的罗列了一些以后，下面涉及的是整个架构和控制。

我觉得架构设计一方面，它是一个静态的，另外控制它本身也是一种可靠性设计。从上图可看到主生产中心到同城容灾，它有一部分是二层打通的，也看到应用是怎么写进来的，同时异步的也有写到灾备中心。

这里也涉及到一个问题，就是所谓的控制的可靠性设计，变更发布的控制是绝对不能漏掉的。

要多活的应用系统可能还比较容易发现，因为我要是漏掉了一个b中心或者c中心的一个应用，它一定会产生逻辑错误，能发现。如果是那种非多活的，平时没用到，变更漏掉的环节的话，等真正去用它的时候切过来，就会出现问题，那是短时间没法恢复的。

既有应用层面的变更，也有像网络负载均衡，包括安全设备等等一系列的。这个扩展后就是我们所谓的运维自动化，包括标准化控制等。设计的时候一定要考虑它，这是让整体的架构具备比较完备的一个可靠性的基础。

可用性的控制，是容错容灾的核心能力，所以容错容灾这个体系的基本构成要素是很重要的。

从我们自身实践来讲，有三个最主要的要素。

第一个就是要准确的掌握容错容灾的配置信息。这个理解很简单。一个应用系统，它的数据库和高可用性对我是非常关键的。哪怕它丢一些数据，即使是一些渠道类型。像手机银行、网上银行等的渠道类型都是交易流水信息，哪怕丢一些数据也无所谓，但一定要尽快回复，否则客户就没法使用。

这种的话，如果给它配了一个克隆数据库，克隆的硬件、软件环境一定要纳入在一倍的配置信息里头，如果没有纳入，根本就谈不上实现可用性控制。

第二个，我们既然知道配置了，就一定要有一个检查的场景，知道在什么条件下一定要去用它。当数据库不可用了，不一定就一定要用克隆库，像前文列举的数据库场景，主备切换了或者重启了，也许都能解决它。当然出现那种逻辑，坏块等错误，数据库无法重启了，就要用它了。所以这是平时，或者是实时的，或者是定时的，有人工去检查的方法一定要确认下来。

第三，精确的处置操作控制能力。强调一下实战跟演练是不同的，它一定不是发生在你预想的时间点上，也可能系统的管理员和技术工程师没有在现场，所以一定要有实际的操作控制能力，这是容灾体系的基本构成要素之一。

这里把我们日常的工作中做一些分享，我们的技术工程师和专家们花费了很大精力和时间去做下面这个事情。

（1）容错容灾配置管理参考：以应用系统为对象实体，按场景维护管控与关联信息

第一个容灾的配置就是以应用系统为对象实体，按场景维护管控与关联信息。

一个应用系统，它在主中心有哪些服务器，包括具体的IP地址名称，它的用途，还有对于服务器的一些健康情况和图中展示的启停，以及一些检查的脚本是怎么检查的。这个脚本要标准化，我们内部交流后，认为它一定要放在标准目录下，方便运维自动化。

另外在同城的中心是什么环境，还有跨中心共享的网络存储等设备一定要清楚。

再就是容错环境，这里要特殊举例，像上文提到的克隆库是一定要掌握的，当然这个是我们在完全手工管理模式下做的，每个工程师掌握一个表。靠人工，比如最近做了一些重大变更之后，我就要同步地维护表，这个效率是比较低的，也比较耗费人的工作精力，下文会单独谈怎么去做常态化工作。

（2）容错容灾场景管理工作参考：单系统容错场景，前提条件（监控）、集成、授权

第二个就上文提到的场景，既然有这套配置了，针对这个场景，它是检查什么条件，它前提条件是什么？它检查的目的是什么？如果发生了怎么处理？这些技术场景的设立，都肯定是要详细考虑的。

这里还有跟业务有关的。我们也去真正的操演练过，如果我的系统彻底停掉了，暂时起不来。但是我有些客户要紧急用款，这时我们考虑到，在核心系统不能工作之前有克隆库，能够查出客户最后一个时间点的余额是多少，紧急用款上，我们也跟业务人员共同梳理一套流程来。当然也会有一套授权机制给客户提现金，保证客户自身需求的满足。

关于它实现授权和预演，就不一一细说了，上文已经反复提到过，这是在它的场景管理。

（3）容错容灾场景管理工作参考：多系统组合场景，业务与技术的组合，逻辑预演

再有个场景管理就是上文提到的容灾，这个是比较复杂的，也是我们实际切换的一个场景。大家都知道上文说的在应用的架构设计上，系统是互相牵连的，当一个系统走的时候，或者切，或者处理的时候，其他系统必须配合。我们在演练过程中可能有十几个系统来去切换。

假如核心系统，它切换有几个大的步骤或者几个任务。它开始的时候，有的系统是不能动的，有的系统是可以同时动，但是完成了第一步以后，后面其他系统可以做哪几步，这个是在容灾场景管理中必须要反复的逻辑的预演出来以后给它固化的。

（4）容错容灾操作过程的标准化：对象、环境、操作、输出等，是工具化的基础

操作的标准化，在没有任何工具的情况下，这个是基础，有了这个基础，才具备实施工具化的可能。

操作标准化的话，在前图的这个逻辑时序，它只是个大的任务，整体性的说是停止核心的一个服务，但是它具体登到不同的机器上，要去处理不同的操作等。这个操作怎么做，怎么让它标准化，都是要细细考虑的。

第二个，整体持续控制之后，就具体到每一个系统中的每一个操作任务，第一要明确在哪个 IP地址，操作它的用户环境是root用户还是其他用户？再是脚本的具体名称或者是命令，包括输出的结果正常是什么？如果输出正常了，下一步是串行还是并行都要标识清楚。这个是之后工具化的一个基础。这些也是在平时的工作中，我们的系统专家和工程师在负责一些系统的时候，会很细化的去处理的这问题。

（5）容错容灾流程的自动化控制：分层级的流程控制，整体、分类、局部三层流程

上文说过，我们从场景的检查、场景确定之后的处理等都涉及到流程，但可能不是一个简单的大流程，在我们实践中，实际是三层表。

第一是整体的，主要是针对容错容灾比较大的场景，我们要知道整体场景下都涉及到哪些系统。假设上文提到的最核心的是核心系统，它切换时跟着它走的大概有三十几个系统，整体有一个调度逻逻辑时序，这个为了方便指挥，并不是实际到某个机器上进行操作的一个命令。

第二就是分类，可能在处理的时候有前台、中台、后台，但是有大类，它内部之间是有持续逻辑的，分类之间它有它的关系，把它分层，每一层简化。

上图表格，是操作的一个详细流程。我们可以用一键式切换工具，或者自动化工具，在已经验证过后，在标准的操作流程基础上给它自动化，这样会大量节省时间长。

真正发生故障的情况下，我可能不在场，所以一定要工具化，让一线值班的工程师有能力去处理，这就是流程。从整体到分类到局部，我们也在朝这个方向去努力，现在有些局部已经能做到，自动化处理的速度也是比较快的。

有效的监控体系是容灾容错的基础，监控也一样，它可能涵盖的范围更大，因为一些小故障它也要监控。像直播间失效了，但我们后台技术上还没有发现，这个是监控配置的管理。

另外是监控的策略，例如针对一个部件，像Oracle数据库，怎么证明它是可用的？直接连接，Select一张表，是一种方式。另外像数据库日志的报错以及一些等待事件等，这些都是标准策略。

(1)有效监控体系的建设策略：以结果为导向，以准确配置为基础，以有效指标为手段

监和控，在目前很多谈的监控实际是监，即我查看CPU，查看内存之间是否有空，发现了一个现象，我虽然能处理，但处理是规避，并不是真正找到原因，从根本上解决。

或要做变更，怎么规避？最简单的方式是多路多活的时候，如果某一路出现问题，像拥堵，则直接停掉这一路，让别的路去工作，可以避免某一些客户进到一个通路以后，全堵死在一个通路里头。这只是一种规避方式。

所以上文一再强调有效的监控体系，它的一个建设策略就是以结果为导向，以配置为基础，以有效指标为手段。刚开始建的时候，都不知道有哪些策略，就是由结果去反推有效率。

监控报警有效率有下面这些点：

除此外，还有监控策略准确性，我们根据监控报警的效果分析，持续调整优化监控指标、补充缺失监控指标，确保监控策略的准确性。

（2）监控管理与系统建设策略：以对象、指标、策略为基础，跟踪监控发现率、持续优化策略

监控档案：在现实中存在这样的问题，虽然有很多技术人员，但有的专注于工具开发，有的专注于系统集成，有的去被动改进，我们没有整体规划，都是出事后亡羊补牢，这虽然是一种方式，但跟实际的运维是有偏差的。实际运维需要有一个明确的监控配置，就是档案。

另外场景要有针对性的设计，有持续更新计划。像上图右侧是我在网上看到的一个运维的技术专家面试的时候，面试人员大量提了我熟悉Nagios、Cacti等等，但他忽视了作为一个监控的管理人员，应该知道Oracle要如何检查判断是否正常，以及某一类的应用系统要如何确定是否正常。我们有效监控体系里，大家更关注于工具和开发，却往往忽视了它的有效性。

（3）详细准确的监控配置信息，是有效监控的基础：实现与系统变更同步的监控配置控制

上文提到监控的基础是准确的配置信息，配置信息一定是跟研发有关的，肯定要跟研发同步。所以在日常的管理中，在跟研发的应用产品设计的时候，一定是从设计开始，如现在有的应用系统数量以及它应用系统模块数量，这个信息要跟后台的配置。

上图右侧，大家可以看到监控自身的属性，有系统架构、逻辑结构，以及底下配的系统资源。上文监控系统部分已经提到，它调的存储，调的数据库，调的安全设备等等，都一定要很清晰的控制起来。研发和运维整个管理工作的衔接，涉及到大家熟知的一些领域，运维和开发理解角度可能不同，但统一后大家可以清晰了解，所以详细准确的监控配置信息是监控的一个基础。

（4）监与控是容错容灾能力的关键构成：发现、定位、处置，通过场景判定严重性

监和控，是容灾容错能力构成的关键部分。

什么是控？实际是我们从一些实践场景中逐渐去分析它，去控制它。

控前提是要怎么控，所以有三个关键词：发现、定位和处置。

上图右侧是以前很早的时候遇到过的一故障，柱状图是交易的量，折线图是它的响应时间，可以看到响应时间基本接近50送达那就断了。

面对这个系统，例如直播间后台系统出问题了，我们处理的时候，一定会考虑网络情况、系统的报文、资源等，一层一层去想，如果都登录系统自己去查会很耗时间，更何况一个大系统的维护环境里，我们不可能有权限登录所有的，所以需要把它定位的场景逐项进行梳理，列成一个表格。

如果有工具，可以工具化，用自动化来检查，检查发生场景，知道如何处理，这是监和控的关系。

（5）容错容灾管理与监控管理的关系：对象、组件、场景、流程、任务、关联

因为监控是容灾基础，他们之间如果要去做工作，或者是做一个工具平台系统的时候要怎么集成？

因为监控管理一定要有准确的监控配置信息，监控配置之后，每一个部件要布一些策略，它产生的报警信息要给到容灾管理的工作环节中，而容灾是以应用系统为基本单元，把它拆分构成的组件，刚才说到它调用这些组件，它自己服务器数据库等等。

每一个组件有自己场景，确认这个场景发生了，就要处置场景，这指的就是一个任务。上文我也提到，流程分成整体的、局部的和细节的，有一二三层，这个任务相当于二层，具体任务的执行可能需要自动化工具或者人工去执行。

当然也要考虑跟其他的应用系统间的逻辑和时序关系，即相互间切换的时候，我先走一步，你再去走你的第一步，那之后我走第二步，我俩234之间都可以并行处理，但是我4，到了你4的时候，一定要等我的第4步，这是有可能会有逻辑关系的，所以要做控制，容灾管理和监控之间要形成一个集成关系和工作上的一个互动关系。

有了上面基础后，我们要讨论的一个话题就是如何将容灾容错的演练形成实战能力。

我们2020年已经做过演练，6月份计划9月份做一次演练，在这期间，大家都会检查自己环境，把应该测试的脚本进行测试，反复的讨论逻辑、过程，等都已经讨论清楚后，大家就开始在一个指定日期去做，这就是一个演练过程。

演练目的一定是为了找问题，因为如果不实际操作，一定不能把所有问题都发现了。只有找到问题，分析它的原因和改进方法，才能为形成实战能力打下一个好的基础。

演练的过程，第一要有实操的任务，任务有去执行的人，同时也一定要有观察记录的人，记录耗时跟预计是否相符以及出现的问题等等。

当然还有一个授权，真正演练的时候，因为是实操性演练，就要授权。关键点上一个控制或一些关键操作，像存储的同步调头等等，一定是靠人来控制，不能完全自动化，否则风险太高。

这个就是演练它的设计和意义。大家往往演练时忘了去详细记录，等演练完了，特别大的问题也许会记住，但一些细节问题可能记不住，这样演练后，就浪费了机会，没有完全发现问题。当真正实战时，可能就会因为一个小的点造成整个容灾切换结果不是太好，所以这就是一个目的。

另外做操性演练，我们还要确认一点，在把一个关键系统切到了同城的一个中心，有的系统本身是多活的，涉及到切只是流量配比调一下，但像银行核心例如账务系统等，是很难做到或者没必要去做到跨站点的这种数据库的双活，而且这个是很复杂的，它就是一道切的动作。

切过去之后，因为相当于它到另一个中心，它跟有些系统相当于跨了中心跑。跨中心跑的，它之间是互联的裸光纤，每一个具体的网络的就是一个会话，可能会延迟几毫秒，累积起来会有几十毫秒的延迟。如果不实操，我们就不清楚这个系统切过去后，在日常的工作场景下，它性能是否可承载业务，所以这个是我们实操之后得到的一个结果。

上图可看到，整个系统的交易成功率和响应时间是不同的。请求了，搜索端的网卡马上有反应，图上左侧是切换前，右侧是切换后，切换前后基本一致，但是有差异，时间、成功率稍稍有下降。它后台的账户系统是一个原子交易，但对于前台客户，这个在他可接受范围内，在两秒钟之内反映交易回来，可以接受，也影响不大，这样评估下来，可以确认我们容灾中心是可用的，这个也是一个演练目的。

容灾容错演练和实战之间的差异，有两个是最大的差异。

上文说到了演练都是有计划性的，是准备好的，实战是我们不能预计的，不知道什么时候发生的。所以可以总结这么几点：

第一，演练是有计划性的，肯定要预先梳理检查。我们可能会花了几个月时间去准备、报备和协调，并且所有环节都要经过测试。最关键的是操作时候，还是由专门系统的技术工程师去操作的。

第二，实战的随时性。不可预计发生时间，随时开始实战。真正发生故障时，我们会面临系统的高频率变更，因为像一些大的企业数据中心，例如银行一样，几乎每天每周都在变化，它变更如果我们没跟上，变更环节没有纳入我们视野和控制范围，切换一定会失败，所以操作一定要随着变更去同步，这是实战中随时要解决的问题。

另外最关键的一点是，好多系统是365天7×24小时运行的，我们具体负责的工程师不可能24小时准备着，所以故障发生的时候，操作很可能是由一线的值班工程师或者B角实施的，这个是演练和实战的不同。

第三，演练是有确定性的。因为我们可以知道今天是针对核心系统做切换，而且可以事先梳理它相关联的系统。

第四，实战的随机性。真正实战发生的时候，往往是从一个小事情发生了，但大家没有意识到它是个灾难，灾难发生，不知道它是什么情况，这个就是所谓的随机性。

实战和演练是完全不同的，所以一定要有很强的发现、定位、处理能力，才能够真正的达到实战性的要求，这就是演练和实战之间的差异。我们可能经常演练，却忽视了实战性的建设和培养，等真正发生灾难的时候，完全处理不了。其实对于一个企业来讲，巨大的人财物的投入，在真正需要的时候没发生作用，这是最不可接受的了。

这就是整个演练和实战的差异。将容错容灾演练形成实战能力，就一定要通过日常的实践分析，不断的去完备监控体系，也同时形成完备的容错容灾体系。

从源头上设计。因为总有达不到100%可用性的情况，达不到了什么程度也一定要分析原因。

原因分析是针对于特殊标记的客户问题的容错处理。例如代发工资，企业有1万人发工资，但是有一部分人因为它的卡状态或者什么历史数据问题，或者是因为签约关系或应用的bug问题，一部分人发不了工资。

我们一定要进行容错处理，分析情况发生的原因。或者去改应用系统的业务逻辑，或开发一个关于错误处理的工具，在特殊情况下我们绕过业务，直接把应发的客户工资发下去，这个就叫一个整体性设计，整个过程是迭代的。

通过这种方式，包括上文提到的，先把工作标准化，之后再把它工具化，再加上培训和迭代开发，最终让我们的容灾容错能力极大的接近于实战的最高要求，这就是整体的一个建设思路。

日常工作中可能更细节的一些。最关键、最直接的就是前文提到的，我们整个的数据中心的系统，它在不停的变更，监控要跟上，监控跟上以后容错也要跟上，我们自己内部也在讨论，在逐渐朝这个方向努力。

应用、系统、网络的管理员一定要遵循变更的管理要求，去把变更分成标准的、常规的、紧急的等等，包括按照风险级别。我们的技术人员，尤其是要求高可靠性、高安全性的人员，一定要遵守合规审计等的要求，这也是一项IT的管理。

我们要严格按照着做，只要做了变更，就一定要及时登记，当然要有工具来自动扫描、自动化。现在有些领域是完全可以的，像IT资产是完全可以做到的，要保证它是准确的，它是我们一切工作的基础。

监控的管理员，只要是一个生产的对象，我们就一定要维护到监控的档案中，并且这个对象，我们一定要给配上标准的和非标准的监控策略，由监控的开发人员部署下去，这样整个体系才会完备，监控没有漏洞和死角。

在这个之上，我们再把需要容灾的部分单独标识出来，如果有专职的容灾的管理员会更好。系统可能有几百个，但真正的重要系统可能是一小部分，系统的管理员需要识别出自己哪些系统是容错的，像上文的监控事件，容错场景它大体的区别就需要标注上。

这样的话，后线有专门容灾的管理，对于它的配置，巡检的场景和处置，要不停的迭代更新和验证，这样的话把它形成一个常态化工作。

所以今天主要分享的内容是这些，可能每一个层面只是点到了没有去展开讲，为大家整体梳理一个思路，关于怎么建设整体的容灾容错的能力。

Q1：容灾可视化平台可以集成哪些双活的指标？

A1 ：这个实际是监控的一个展现问题，因为我们本身哪些系统是跨中心双活的，我从实时监控上一定能看到，包括配套一些巡检。

Q2 : Oracle数据库的双活中心？

A2 ：是说的跨站点双活，我没有做，因为跨站点的话，双活一定是有延迟的，无论你裸光纤速度再快、再可靠，都一定有延迟。甚至于同中心，我们也没有做数据库Oracle的，因为选择某种技术方案，要看实际的环境。

第一，对于我们来讲，单独的小机，假如每天1000万的交易量是能够承载的，我没必要去做集群，集群有集群的复杂性，包括一个故障的处理，以前我们拿别的系统验证过。另外，我们自身没法配那么多的高级DBA去维护，所以我们我退而求其次。当然有的特别大的数据中心和银行只能用集群，单机不够，容量不够。

单机够的话，我这个HA配成最简单的这种劝阻装置，我们因为数据库是多实例的，实例更简单的可以用克隆方式来更快切换，一两分钟之内。越简单，它是越可预期的，可靠性越强的。我一旦这个环节出现10分钟我能恢复，那就行，这也满足监管对于30分钟恢复的要求。

Q3 : 对于自动化运维监控，运维工具有什么要求？

A3 : 实施方案不具体谈了。最关键的点，第一要知道整个体系架构中，有哪些部件要纳入监控范围。可能我们像看一部车，它的所有的部件过程部件都要有一定的监测，否则这个车一定是失控的。监测的策略是什么？有了这些我再去选择工具，工具无非说开源的等等，这个工具是替你把数据采集回来，你一定要有统一的监控。把它从这种message消息一定处理成带有结构信息、可利用的监控数据。

最后对于定位和处置，尤其在定位准了之后，才能去处置，这个是真正发挥效果的。也就是说监和最终的控非常重要，不能是只监不控。

Q4：银行自己容灾体系要求达到几级标准？

A4 : 我们具体现在是按照监管要求，把重要的系统，同城的情况下，它的 RPO肯定是0，因为银行的数据不能丢，丢了出账务风险了。

RTO在监管要求是30分钟之内，当然你会力求越短越好，因为我们很多系统多活之后，它涉及不到切的动作了，那可能就是一瞬间把可能堵塞的a中心的某些路给它停掉，这个停我们是利用监控自动化的方式，实际类似于我们红绿灯的调度方式，只要它标识了之后，负载均衡就不再给它分流量了，马上就停掉。它速度会更快。

但是具体到核心系统，它没有办法，只能切。这个切，我们演练的方式，也是最后能够达到验证，等待30分钟内能切完，这也满足监管的要求。

Q5 : 规避容灾应急切换的风险点？

A5 ：切换中间动作一定会有失败的。像数据库，我们也列了，要有退路，我们作为运维的技术工程师，一定要有b计划或者c计划，一定要想到最坏的情况下，即使RTO已经很长了，也要去监管汇报了，必须要把业务和数据恢复过来，不管是后果是什么，这是要首先保障的。

Q6 : 进行容灾应急切换演练的规划，系统的高可用性融资应该建设到什么程度？

A6 : 规划的话，几百个系统，我们有监管重点盯着这些系统，达到RTO在30分钟之内，RPO是0，这个在同城可以，异地做不到，可能要有一个时间限制。

另外根据自身要求，因为要保障对于客户的优质服务，它本身是有要求，我们把这些系统排查出来。

我们有一套排查方法，从几个维度，业务影响度、损失、技术的关键性等，因为有些基础应用系统是没有业务的这种直接损失，但是它影响大，所以我们会综合打个分，根据分数来做容灾的配置，是同城双活，还是同城的2+2的方式，或2+1的方式，或者同城做数据集，根据结论来配置，大体根据投入产出和具体情况来看。