本文根据姜岩老师在〖deeplus直播第期〗线上分享演讲内容整理而成。（文末有获取本期PPT回放的方式，不要错过）
姜岩
某城商银行数据中心总经理
拥有27年银行应用系统开发、运维管理、架构管理以及新业务科技实现的设计等相关工作经验；
历经多次核心系统更新换代，对金融科技与业务的配套发展有着深刻的思考。
大家好，借难得的机会，也借dbaplus社群这个平台，跟大家交流和探讨一下容灾容错这套体系的建设，包括实操性演练的一些设计。
一、容错容灾包括什么？为什么是体系？
1、业务连续性需求与容错容灾实施：容错容灾能力是业务连续性保障的基础首先要讨论容灾容错都包括什么？为什么是一个体系？因为容灾容错有它的背景，这个背景主要是从业务连续性管理的范畴角度，业务连续性管理可能很多朋友也都清楚，不清楚的话网上有比较标准的一个解释，这里特殊强调，它主要是针对于企业业务的非计划性问题产生影响，有针对性的去制定一些业务连续性的保障计划，控制企业的经营风险。同时像我们理解的也是为企业的客户提供优质服务的一个手段。
具体的来讲，容灾容错体系的构成主要包括各种可能出现问题的场景。
第一个是小概率大影响的灾难性场景，这也是标准的容灾容错涵盖的内容。假设一个主数据中心，因为电力的原因，或网络的原因，整个系统要全体切换到另一个容灾中心或者同双活的一个中心，这是概率很小，但是影响肯定会非常大的一种情况。
概率比较高和影响也比较大的情况，我觉得也应该纳入到体系里的。一些严重的故障和错误，也会产生这种问题。容灾不仅是灾备中心的整体切换，所以这里要特殊强调容错，这是一类问题。
谈到对客户优质服务，还有一部分客户问题是系统正常但应用程序存在一些逻辑bug的，或者是基础数据问题造成一部分的客户没法去完成交易，这也是我觉得应该涵盖在内的。
所以容灾容错这种实战能力的建设，我理解上认为主要包含三个部分的工作。
第一，是架构和控制这两个问题。
系统整个架构的可靠性设计，这是容灾容错的一个基础。这个基础之上，我们还要有对于服务的可用性控制，即有了这个基础之后，还有一定的发现、定位、处置能力的一个控制能力，结合在一起，才能真正的达到容灾容错实战的能力要求。
第二，是演练和问题的跟踪。
即设定我们的这个场景不一定是能够生效的，所以要有一套演练、问题跟踪、分析成因和形成规范、迭代开发的一个过程。而且这个过程不是突击性的、一次性的任务，是要结合我们日常的运维做的一个任务。
第三，是把它形成常态化。
金融行业经常制订一些工作计划，一年计划几次，在之前大家做了充分的准备，然后演练，但实际真正发生故障，肯定不是跟演练一样的，所以一定要把容灾容错的能力维护建设在常态工作机制中，才能确保随时发生、随时能处理。这是一个简单的理解。
2、容错容灾主要场景：接入、安全、调度、组合、路径、应用、会话、数据、基础容错容灾都主要包括哪些场景？上文也提到很多场景的问题，这里我想简单的举一个例子，可能很多方面是大家曾经发生过的问题，一是应用的系统或者体系，客户接入进来可能发生哪些问题？
安全性的问题，或是大家熟知的像负载均衡等调度问题，还有交易逻辑的组合问题。尤其是银行，银行的交易是比较复杂的，靠多个应用系统组合起来。
一些容灾或者是多活数据中心，一定会产生多路径的问题，包括多路径怎么解决，应用系统自身基础性的条件问题，还有会话的模式和方式的控制。
最重要的是数据，应用系统在工作过程中，既会产生临时性数据，也会产生这种永久性数据，临时性数据会存在一个有状态、无状态的问题。
可能交易是异步的模式，进出是不同的通道，数据落在某个路径上，另一个路径找不到它，这个交易很可能就失败，这些问题都要解决。
另外是最基础的一个问题，上图中我也列出了很多这种技术环境问题，这是容灾容错要考虑的场景，不一一讲，有的我们本身出现过，例如交易逻辑的组合问题，上图特意标出了一个颜色的信贷流程，它是比较复杂的一个业务流程。
我们的应用程序无论怎么开发，都不可能完备的覆盖任何的错误场景，包括像业务员操作的一些输入的错误之后，不可能把这个流程重新发起重走，只能通过这种错误的临时处置机制来处理。我们的技术人员每天也会大量处理这个问题。
另外银行特殊有的，我们叫联机批量交易，即代发代扣，像大家熟知代发工资等等，如果量特别大，它会切分成很多文件，这些文件并发处理之后，并发的锁机制和控制问题，如果控制不好一定会出问题。
再有一点是强调永久数据，大家可能更加