目前大促备战常见备战工作:专项压测(全链路压测、内部压测)、灾备演练、降级演练、限流、巡检(监控、应用健康度)、混沌演练(红蓝对抗),如下图所示。随着平台业务越来越复杂,红蓝对抗的作用愈来愈明显,下面将详细介绍大数据平台在本次双十一大促备战工作中是如何开展红蓝对抗的。
首先我们先了解一下什么是红蓝对抗,它都有哪些好处?一、红蓝对抗介绍4.2、【蓝方】创建&执行演练任务蓝方在混沌工程平台,按照之前收集的演练场景创建演练任务或批量创建演练任务。如下图 说明以下几点:① 底层集群的攻击主要通过命令、脚本实现,这里暂不详细叙述。② 网络延迟、丢包故障可能演练失败,原因:限制网络故障演练(该宿主机内核版本存已知BUG不能演练) "4.18.0-80.11.2.el8_0.x86_64"。③ 内存利用率100%场景,因为linux内存满了会触发oom kill,所以建议设置90%。④ 演练时长建议大于5分钟,原因:有些应用配置的mdc报警周期范围是5分钟内,如果演练时长小于5分钟可能收不到报警。4.3、【红方】防守修复故障蓝方发起攻击后,红方会收到咚咚报警,按照既定预案进行故障修复。部分截图如下: 4.4、【红方】系统恢复有些演练场景(进程终止)不会自动恢复,需要红方手动重启系统应用服务,确保生产应用服务均正常。4.5、【红方+蓝方】演练结束红蓝对抗演练结束后,红蓝双方均填写“红蓝对抗演练场景”文档,蓝方填写:混沌任务链接、混沌演练场景、演练状态、混沌演练执行开始时间、混沌演练执行结束时间。红方填写:排查人、告警信息、根因、排查到原因时间、排查过程描述(包含排查过程,使用工具,辅助决策判断)、计划解决方案&应急预案、预估影响 处理时间。如下图所示: 5、演练结果收集主负责人复核演练结果、梳理分离演练问题,让红蓝双方尽早完善。主要存在以下问题:1) 未及时处理:红方收到告警后, 由于种种原因(开会、未在工位等)未及时处理故障。2) 处理不完整:红方处理完ns失败问题后,未通知用户处理失败任务。3) 未收到报警:① 未配置报警规则。例,mdc或ump平台未配置报警。② 未触发告警阈值。例,蓝方攻击时cpu利用率90%但mdc报警规则配置的是95%。③ mdc平台禁用告警。例,mdc暂时禁用了模版中心的MDC监控与告警。 6、演练复盘主负责人组织红蓝对抗复盘会议,提供演练结果、问题列表,实时+离线架构师均参加,从演练过程、演练效果等角度对本次演练进行评价或建议。① 告警级别需要自查修正。目前部分告警级别配置偏低,cpu利用率大于90%时,报【警告】,建议改为【紧急】。② 延长攻击时间。找某几个应用,攻击时间为30+分钟,验证防守人员是否真正摘流量。③ 混沌演练常态化。可通过混沌工程平台-常态演练进行,并结合值班表增加演练频次,以战养兵。④ 分步演练【警告】、【紧急】场景。第一步先攻击10分钟触发【警告】的场景,第二步再攻击10分钟触发【紧急】的场景。⑤ java方法异常、延迟场景未演练。后续期望测试人员通过forcebot压测来支持流量流入。期望混沌平台的支持:① 混沌工程平台支持一次批量选择多个应用创建、启停混沌演练任务。 可提高创建任务效率,目前的批量创建演练任务功能,只能一个一个的添加应用进行创建。② 混沌工程平台提供常态化混沌演练api。方便用户自定义创建常态化演练任务。③ 混沌工程平台支持在平台内查看mdc、ump告警。减少用户在多个平台系统来回切换。四、总结@全体成员
【重要通知】
今天17:30~21:30大数据平台(实时+离线)进行红蓝对抗演练,不定时进行故障突袭。请各位同学将跟进处理过程在本群进行同步。 分三个阶段:问题发现、原因分析诊断、故障处理。
每个环节(问题发现、故障诊断、故障处理)确定后立马发消息,不要最后发总结!
每个环节(问题发现、故障诊断、故障处理)确定后立马发消息,不要最后发总结!
1、问题发现
【问题发现】
产品-服务名称:
(1)收到电话/咚咚告警,告警内容xxx
或
(2)雷达大屏飘红,截图xx 开始排查处理
2、原因分析
【故障诊断】
产品-服务名称:xx问题原因已查到,原因概要描述。
3、故障处理
【故障处理】
产品-服务名称::xx问题已处理,已恢复,并给出告警恢复/监控截图。
- END -