目前工作过程中遇到的一些涉及到容灾的场景：
1、atpp_case_remote case远程通信插件测试，容灾场景：
a、消息发送端在网络异常场景下，第一次发送消息失败之后的处理。
手段：拔网线模拟；
结果：开发设计之初没有考虑这种场景，后增加一个google的queue依赖
解决这个问题。实现方式是，当第一次发送失败后会将发送数据保存一份到本地文件中，然后不断进行重试发送，直到发送成功；
2、法网狙击项目暴露了很多异常测试和容灾测试方面的考虑欠缺：
a、 PMC流程某个节点服务调用异常的情况下，系统的处理。
按照开发的设计，需要在此时进行调用重试，每2分钟一次，共重试5次，最后失败才生成小二任务。
手段：日常下，利用TCC工具对azeroth里面的代码进行异常注入，使代码运行到该方法时抛出异常，从而模拟异常场景。
结果：发现从开始使用PMC开始，就没有对这些异常情况进行考虑，所有的异常都是马上生成了小二任务进行处理，甚至有一些流程就这样一直卡住，没有任何补救措施。
解决：修改PMC的配置，添加异常重试的处理，按照之前的设计进行。
b、 调用消保的冻结、解冻、转移保证金接口，发生不同的异常场景，返回不同的ERROE CODE，最后本系统进行处理的细节考虑不全。
系统间交互容易出现的问题（针对hsf调用）：
（异常场景）
1、超时时抛出超时异常；
2、序列化/反序列化失败时抛出HSF异常；
3、没有可用的目标服务地址时抛出HSF异常；
4、服务端抛出业务异常，返回同样的业务异常；
5、依赖应用封装了下一级应用的异常，返回相应的ERROE_CODE；
6、调用的目标服务地址有通信问题，自动尝试有限次数重新选址；
（并发场景）
1、识别可能存在并发的场景，模拟依赖应用返回并发的ERROR_CODE
（幂等调用）
1、如何模拟幂等调用？？看对方是怎样判断幂等性的，如果无法真实模拟对方返回幂等调用结果的场景，则mock掉真实的调用情况，直接返回幂等调用时候的ERROR_CODE。
解决方案：
测试场景应该细化考虑异常场景，包括，超时异常，hsf异常以及各种业务异常返回的处理，而不仅仅是类似系统异常（RuntimeException然后看系统是否重试这么简单而已）
采用的方式，mockHsf服务调用的返回。之前的方式（bugfix的时候）通过开发在日常debug，修改服务调用返回值来处理。
第一步，先梳理所有调用到消保接口的类和方法；
第二步，每个调用到的地方都尝试进行mock超时、hsf异常返回的处理，并且明确其他业务异常的返回和处理。
第三部，补充接口脚本覆盖这些场景。
