灾备-故障演练
为了确保应用系统具备足够的健壮性,通常需要设计容灾方案进行部署,在容灾方案落地实行之前通常需要进行故障的模拟,以达到:
- 确保系统能够按照预想的方式进行故障恢复;
- 寻找系统意想之外的弱点,提高系统的健壮性。
一、故障演练类型
- 桌面演练:桌面演练是通过对灾难恢复预案的一个理论验证,并不会进行真正的故障注入和恢复,其主要目的是验证方案的有效性,同时方便相关人员了解业务流程和相关人员的综合能力等。
- 模拟演练:模拟演练是以桌面演练为基础,由多个部门参加模拟演练,采用模拟数据和模拟业务系统运行演练。尽可能接近真实环境发生灾难的处理过程,验证方案的有效性和可行性,以及相关人员的配合程度。
- 实际演练:实际演练需要在真实的线上业务场景下进行演练,通过手动注入故障,让灾备中心接替线上业务真正运行一段时间,这种方式更容易发现潜在的问题。
二、故障类型
故障类型 | 举例 |
---|---|
服务故障 | 超时/不可用 |
中间件故障 | 超时/不可用 |
基础设施故障 | 数据库超时/不可用、DNS超时/不可用 |
机器故障 | CPU满载、网络中断、机器宕机、机房断点、磁盘空间满载 |
异常流量 | 入口流量激增、流量掉零 |
三、故障演练顺序
3.1 故障演练前
- 检查必备能力 需要用用具备业务链路流量标记能力;具备下游依赖服务故障注入的能力;具备流量回放/隔离的能力。
- 确定故障演练的范围 故障演练的范围:哪些流量、哪些下游服务、哪个应用环境
- 回放流量隔离
- 制定故障应对预案
- 配置故障
- 确定演练目标
3.2 故障演练中
- 将录制的线上流量逐步加压回放到故障演练的发起应用中的无真实流量机器
- 开启应用的故障模拟开关,观察故障影响
- 启动应用的故障应对预案
3.3 故障演练后
- 现场清理
- 输出演练报告和总结
四、技术难点
- 如何在灾备的故障演练过程中,不影响线上业务,不造成生产环境的数据和日志污染
- 故障演练的流量如何获取
- 故障的影响如何捕捉Asert出来
- 提升故障的覆盖率
个人思考:目前存在的灾备故障模拟工具,例如阿里的ChaosBlade,k8s开源社区的ChaosMesh等都具备了比较强大的混沌实验能力,能够模拟多个场景下常见的系统故障,但是故障的粒度一般来说比较大,比如基础资源宕机、应用服务崩溃等导致服务直接不可用。这些工具没有适配用户的应用系统,同时代码级的故障也无能为力。 个人感觉故障演练和测试团队或者安全领域模糊测试有异曲同工之妙,有可能这个不在故障演练的范畴内,属于用户安全渗透团队的业务范围,但如果故障演练可以包含更细粒度的故障测试,就可以提高灾备能力,应对更多更复杂的故障场景,进一步提高系统的健壮性。