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

　　sudo tc filter del dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst **.**.**.**/32 flowid 1:3

　　注：

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

　　希望深入了解的同学可以进入这里进一步学习：http://feisky.diandian.com/post/2011-11-13/15494559

　　容灾项目特点

　　1、项目需求无法提前计划：所有容灾的设计都是在不断优化和测试的过程中不断发现新的需求。

　　2、项目研发涉及到的业务场景覆盖广，涉及研发人员多，测试数据准备工作量大

　　3、项目测试环境依赖多，复杂度高

　　4、容灾测试点相互交错复杂，并行测试难度高，测试效率低

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

　　容灾项目测试策略

　　针对以上容灾项目独立的特点，测试也需要一定的测试策略来应对容灾的测试工作

　　1、测试计划的敏捷安排

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

　　【总协调人员/测试PTM】：

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

　　- 协调不同的业务测试同学进行各容灾点的测试

　　- 容灾测试的技术指导和工作review

　　- 各容灾测试环境的协调

　　- 帮助业务测试同学排除所有的外在干扰

　　【容灾测试执行人员】：

　　- 根据已梳理好的容灾点完成容灾测试

　　- Bug录入和跟进，并定时汇总给总协调人员

　　2、容灾测试的需求文档管理

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