交易流程容灾及测试策略-2

　　删除已经设置的从某ip过来的流控规则（直接替换添加流控规则命令中的add为del即可）：

　　sudo tc filter del dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst **.**.**.**/32 flowid 1:351Testing软件测试网*u"|~5i,R"D

　　注：51Testing软件测试网/p? _]Y8V$Ig

　　linux tc流量控制是个非常复杂的工具，这次容灾测试也只是粗浅的了解。

Q&v*bH0?w0　　希望深入了解的同学可以进入这里进一步学习：http://feisky.diandian.com/post/2011-11-13/1549455951Testing软件测试网!LN4fagd

6Io)a&y|*gUBS:q.[0　　容灾项目特点51Testing软件测试网y3u"tZ*B)ZR(^zM

　　1、项目需求无法提前计划：所有容灾的设计都是在不断优化和测试的过程中不断发现新的需求。51Testing软件测试网2YN7~0E vh#N

a~2hl1H LW a"~V0　　2、项目研发涉及到的业务场景覆盖广，涉及研发人员多，测试数据准备工作量大51Testing软件测试网QT{V5y(I$q

};?*^"]
H;V0　　3、项目测试环境依赖多，复杂度高

~v2ITIW0　　4、容灾测试点相互交错复杂，并行测试难度高，测试效率低51Testing软件测试网\(Z!k3@[H,v

waem~)j0　　5、测试难度较其他普通业务项目要求高，需要同步根据日志定位所有的测试场景出现原因

　　容灾项目测试策略

!~i;|0F Ge;BS9P9z0　　针对以上容灾项目独立的特点，测试也需要一定的测试策略来应对容灾的测试工作

c$K&S7KZ F$oY0　　1、测试计划的敏捷安排

5q]o%J]"F"|3`0　　容灾项目测试因为需求不确定、涉及业务广等原因导致前期测试计划较难做，需要有个非常敏捷的流程来应对各种需求的测试。 我们需要能够在项目期间的任意一个时间点随意的添加删减测试人员，这就要求我们能够有一个人能通盘全局了解所有的容灾点，在任何时候能够对新人进行测试指 导，并帮助容灾测试同学排除所有的外在干扰，让测试同学能够快速的开始具体的容灾测试。同时考虑容灾业务涉及广，为了避免业务测试场景上的遗漏，我们需要 采取一人协调，多业务测试专员配合的模式来开展容灾测试。他们各自的职责有：

(fD@,{#[Mzdx9aK0　　【总协调人员/测试PTM】：

%qqp7By4s z0　　- 配合开发人员，对系统整体的容灾点进行梳理和汇总

　　- 协调不同的业务测试同学进行各容灾点的测试51Testing软件测试网cJ#x
U)u,RF&UX

　　- 容灾测试的技术指导和工作review51Testing软件测试网AV~C}Wt6K+Y1`5N

VO?gi3?7X0　　- 各容灾测试环境的协调51Testing软件测试网{npl1d-R4@ T

;mee.U5K:h!U0　　- 帮助业务测试同学排除所有的外在干扰

　　【容灾测试执行人员】：

e,d0{X5tc0　　- 根据已梳理好的容灾点完成容灾测试

　　- Bug录入和跟进，并定时汇总给总协调人员51Testing软件测试网UF2K![,s+u AY9?;h

.J4[yK9Gl"N0　　2、容灾测试的需求文档管理51Testing软件测试网_,K%]}9`+l

　　容灾项目测试的需求一般会系统不断的优化、测试以及火花的碰撞而不断增加，涉及到的团队和人员也非常广，所以非常需要一个共享的方式来管理需 求。本次容灾项目中，我们在中后期采取了百科共享的方式来管理所有的待做事项和容灾点，并进行了统一的分类，大大提高了沟通的效率。51Testing软件测试网bQ Nw,G

　　3、容灾测试的数据准备51Testing软件测试网*t,L|Y8e7X${1L

{ G)B&Pknb0　　容灾测试的数据准备一定要全，不全的数据非常容易遗漏测试场景。可以结合不同的业务测试同学分别准备，既可以保证数据的准确和完整性，也保证了效率。

　　4、测试环境的协调

oY&~3C,F o6\0　　容灾项目的测试无法和普通的业务测试共用一套环境，需要准备独立的环境来进行。不同的测试同学在共用这一套环境时，切换不同的容灾开关需要及时 知会到所有人，以防对他人造成影响。当然，如果条件允许，多备几套容灾测试环境自然更好，那样大家就可以完完全全的并行测试了。

+[(?+c9fev2\0　　5、容灾测试和普通业务项目测试的不同以及注意事项51Testing软件测试网8wigk7J-x'd k$p^

&wH!nF"V Xl0　　- 测试容灾点时，需要同步分析日志。因为容灾一般都是测试的异常场景，我们的测试环境经常不稳定，出现各种异常，所以测试时一定要仔细结合日志分析，确认当前展示的结果是否是由于我们的容灾代码生效而出现的。

oB9uH0Uz0　　- 对于开发新增的业务代码要尤其注意，重视并配合开发一起做好新代码的容灾工作51Testing软件测试网:Ttv%g @#Ax

　　- 不同系统之间的容灾设计、以及同一个系统中的不同容灾场景的设计需要仔细评估，对潜在可能相互关联的容灾点要重点测试，预防互相影响，导致在极端情况下，出现无法预料的结果。51Testing软件测试网I9o f&@z9j

Q1f,b+oN\9mM0　　6、代码review51Testing软件测试网Co Ca&d)fH x'}Z

K+]@:O'|3wLRIF0　　容灾项目的代码review非常重要。因为测试工作量大，涉及点多且咋，测试会重点关注已知的容灾点测试，对于未知的场景，只有通过代码 review来发现。比如本次的容灾项目中，研发同学通过代码review发现了我们的流控拦截代码将不该拦截的业务代码也给拦截了，而这个如果期望依靠 测试来发现，成本将会高很多很多。

　　7、容灾测试的自动化

t M4}2M.\uV0　　容灾测试的自动化工作是势在必行的。各种大促活动不断的涌入，每次大量的人力成本投入容灾测试着实一种资源浪费。思考了一下后期自动化开展的方式和问题，有待实践论证，这里简单列一下：51Testing软件测试网U5W,Lu$uc-M

　　业务降级/数据备份/请求拦截/自动流控：可以直接选择Ruby自动化或者接口测试来实现，只需提前将对应的开关设置为相应状态即可。但是需要一套独立的环境，不能和正常的业务测试环境共用一套，会相互干扰。51Testing软件测试网;tS-qbAF)s

　　强弱依赖设计：需要提前配置一套正确的环境，对环境要求非常高。并且不同的容灾场景无法连续执行，需要手工在机器上执行不同的命令以模拟断网或者流量控制。实现难度较大。远程执行脚本也许可以解决这个问题，有待具体实践。51Testing软件测试网/y+aj-D@f.N9}

　　8、容灾线上演练

4R'QVs7xmI's0　　容灾线上演练是容灾项目中特有的一个流程，在前期准备和演练过程中需要注意以下几点：51Testing软件测试网 Km9^O5Mg'W

　　- 提前准备好所有的生产环境测试数据。因为演练一般从夜里凌晨开始，短短的几个小时时间需要演练较多的开关，测试数据准备的充分，可以大大提高演练的效率。

　　- 提前在测试环境做充分的测试，演练的效率才会高。

　　- 开关切换时间尽量短。虽然是在深夜，也依然有很多用户在使用我们的系统，所以每个开关的切换都要考虑到对当前用户的影响。开关生效时间尽量缩短。51Testing软件测试网 Cd`-V+Xt]6a@

　　- 每个开关切换后都一定要切回并再次验证。必要时演练结束后将所有系统全部重启。51Testing软件测试网
u6gMV bV H

　　- 不同系统之间的同业务的开关执行顺序需要提前沟通好。

　　业务容灾的测试在我产品线尝试已有两年之余，但是只有今年的容灾测试才开始趋于系统。经验尚浅，大家如有其他建议或异议，非常欢迎能多沟通交流，期望业务容灾的测试工作能在不断的实践和沟通过程中越来越完善。51Testing软件测试网(_/_"|^6^;~a5dW@Y