大数据平台红蓝对抗 - 磨利刃,淬精兵!

京东云开发者
• 阅读 128

背景

目前大促备战常见备战工作:专项压测(全链路压测、内部压测)、灾备演练、降级演练、限流、巡检(监控、应用健康度)、混沌演练(红蓝对抗),如下图所示。随着平台业务越来越复杂,红蓝对抗的作用愈来愈明显,下面将详细介绍大数据平台在大促备战工作中是如何开展红蓝对抗的。

大数据平台红蓝对抗 - 磨利刃,淬精兵!

首先我们先了解一下什么是红蓝对抗,它都有哪些好处?

一、红蓝对抗介绍

红蓝对抗是网络安全领域常见的一种对抗性演练方法,是指为发现并整改企业内外网资产及业务数据深层次安全隐患,在确保业务平稳运行的前提下,整合平台安全威胁监测能力、应急处置能力和防护能力,以真实网络环境开展实兵红蓝对抗演练,提高并完善安全防护技术与管理体系。

蓝方代表攻击方,红方代表防守方。红蓝对抗模拟了真实的网络攻击和防御过程,在受控的环境中进行,蓝方通过模拟各类威胁和攻击手段,对红方进行攻击,测试其防御能力和系统高可用情况。红方则负责防御和应对,寻找并修复系统中的问题,并且收集关于攻击者的信息。

大数据平台红蓝对抗 - 磨利刃,淬精兵!

二、红蓝对抗的好处

1.保证监控告警有效性

红蓝对抗可帮助产研验证监控告警的配置有效性,通知及时性,信息准确性。

2.增强系统可靠性

红蓝对抗通过识别可能导致系统发生错误的潜在问题,帮助提高系统的可靠性。

3.降低风险

红蓝对抗通过识别可能被恶意攻击者利用的潜在弱点,帮助降低发生线上问题的相关风险。

4.经济高效的测试

红蓝对抗模拟了生产环境的场景,但却不会对生产环境产生风险,从测试角度来看保障系统的质量。

大数据平台红蓝对抗 - 磨利刃,淬精兵!

三、红蓝对抗实践

红蓝对抗演练实践主要包括:演练公告、人员指定与任务分配、演练前场景梳理、红蓝对抗过程、演练结果收集、演练复盘共6个部分。

大数据平台红蓝对抗 - 磨利刃,淬精兵!

1、演练公告

主要包括两个部分:

第一、本次红蓝对抗主负责人组织对抗演练启动会、确定对抗演练时间范围、指定实时|离线演练接口人。

第二、实时|离线产品提前邮件|咚咚通知业务用户将进行红蓝对抗演练。

大数据平台红蓝对抗 - 磨利刃,淬精兵!

2、人员指定与任务分配

首先,指定本次红蓝对抗的主负责人。负责整个红蓝对抗演练的统筹工作,包括方案制定、演练对抗文档落地、场景收集通知及复核、组织攻击方发起及防守方防御过程、演练复盘工作。

其次,分别指定实时和离线侧备战接口人。充当蓝方攻击方,主要是指定演练攻击场景、发起系统攻击。

再次,分别指定实时和离线侧backup兜底人员。一般为核心研发人员,由于发起攻击的具体时间是不确定,为避免蓝方发起攻击后,红方由于各种特殊原因不能及时处理故障导致影响线上正常业务,backup兜底人员可快速的恢复系统。

最后,分别指定实时和离线侧演练监测员。一般为测试人员,主要是记录演练过程中发出的告警信息(mdc、ump)以及复核演练记录文档。

大数据平台红蓝对抗 - 磨利刃,淬精兵!

3、演练前场景收集

该部分是演练前最重要的环节,主要包括确定演练应用范围、确定攻方演练场景。

3.1、确定演练应用范围

演练应用建议优先选取应用等级L0和L1的应用,具体可根据业务需要进行选取。另外,可通过以下两种方式快速查询对应的应用:

http://XXX.jd.com/dashboard/4/node/XXX

http://XXX.jd.com/health

详细演练应用列表由实时|离线接口人(经过C3领导复核通过)提供,输出:攻方批量注入场景收集,

大数据平台红蓝对抗 - 磨利刃,淬精兵!

3.2、收集演练故障场景

jdos应用 主要是借助【混沌工程】平台进行故障注入,采用以下演练场景:

cpu使用率高、内存使用率高、磁盘使用率高、网络延迟、网络丢包、进程终止、mysql请求延迟异常、jimdb请求延迟异常等。

底层集群 主要是运维人员通过脚本、命令等方式进行故障注入。主要包括以下演练场景:

数据库实例CPU打高、hdfs队列打满、计算任务pending、RSS集群繁忙、zk节点宕机异常等。

4、红蓝对抗过程

有了演练场景,产品也发送了演练通知邮件后,就可以进行红蓝对抗了。这里要说明几点:

① 不能将具体的攻击时间“透露”给蓝方。

② 建议选择生产环境应用或集群进行攻击,尽可能真实的模拟线上问题。

4.1、【主负责人】演练前通知

主负责人在蓝方攻击方正式演练前提前在群里发消息,模板如下:

@全体成员  
【重要通知】
今天17:30~21:30大数据平台(实时+离线)进行红蓝对抗演练,不定时进行故障突袭。请各位同学将跟进处理过程在本群进行同步。  分三个阶段:问题发现、原因分析诊断、故障处理。
每个环节(问题发现、故障诊断、故障处理)确定后立马发消息,不要最后发总结!
每个环节(问题发现、故障诊断、故障处理)确定后立马发消息,不要最后发总结!


1、问题发现
【问题发现】
产品-服务名称:
(1)收到电话/咚咚告警,告警内容xxx  
或
(2)雷达大屏飘红,截图xx  开始排查处理

2、原因分析
【故障诊断】
产品-服务名称:xx问题原因已查到,原因概要描述。

3、故障处理
【故障处理】
产品-服务名称::xx问题已处理,已恢复,并给出告警恢复/监控截图。

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告警。减少用户在多个平台系统来回切换。

四、总结

通过本次红蓝对抗演练,既有效的增强了大数据平台系统应用的抗风险能力,降低了生产环境系统发生故障的概率,又大大的提升了研发人员解决问题故障的能力,也沉淀了一套快速高效的演练的方案。

作者:京东零售 尹伟

来源:京东云开发者社区 转载请注明来源

点赞
收藏
评论区
推荐文章
京东物流常态化压测实践 | 京东云技术团队
大促备战压测备战时间紧、任务多,压测备战压力较大,在大促备战多专项并行资源紧张情况下,频繁的系统调优给整个大促带来不可控的风险因素。引入常态化压测的手段,通过每周或每月的定期压测行为,持续把控系统性能表现,保证服务稳定性;同时将需求上线引起的性能问题前置暴露,及时定位优化问题;减轻备战压力,提升压测效率。
浅析大促备战过程中出现的fullGc,我们能做什么?
在日常压测和大促期间,经常会发生Jvm出现大量youngGc和部分fullGC的情况,导致性能下降,可用率降低等情况。
大促质量备战之三化战役:“常态化、精细化、一体化” | 京东云技术团队
大促作为JD一年两度的盛事,质量备战是不可或缺的重要环节。每逢大促都是一次大型的联合战役,在这种战役中,不仅有各种“海陆空”技术争奇斗艳,还会让我们的技术视野变得更宽阔,让我们协同变得更默契,所谓以战养兵。测试团队作为质量备战团队,沉淀了“常态化”、“精细化”、“一体化”的三化备战策略,希望与君共勉,共保大促!
京东云开发者 京东云开发者
11个月前
浅谈常态化压测 | 京东物流技术团队
随着业务的不断增长,支撑业务系统的压力也逐渐增加,会面临如系统越来越厚重、逻辑越来复杂、迭代节奏越来越快等繁杂的情况。我们当前并没有做到在每次变化时快速识别出性能风险,检测产品或系统的稳定性、可靠性,而且我们还在不断的投入人力成本在压测这件事情上也是不合理的,所以我们要将性能验证融入到我们日常的工作中,把压测做到常态化,做成平常的一件事。
京东云开发者 京东云开发者
7个月前
谈谈压测方案的那点事 | 京东物流技术团队
前言在现阶段大促备战的压测不算是一件新鲜事,已经不存在什么技术瓶颈或者资源问题,每个团队都有很多人能够执行性能测试,在一些团队也已经落地了日常常态化,但压测也没有简单到只在压测平台上设置参数、运行脚本,然后去看压测报告中某个指标是否满足压测目标那么简单,我
京东云开发者 京东云开发者
7个月前
00后如何组织双十一大促看这一篇就够了! | 京东云技术团队
引言大家好,我是王蒙恩,一名“整顿职场”的00后。作为一名去年刚刚加入京东的校招生,我有幸成为本次CDP平台的11.11备战负责人。虽然早在实习的时候就经历过大促,但是真正组织整个部门的备战还是很难忘的。于是提起笔,给自己做一个大促总结,记录下11.11大
京东云开发者 京东云开发者
6个月前
大数据平台红蓝对抗 - 磨利刃,淬精兵! | 京东云技术团队
一、背景目前大促备战常见备战工作:专项压测(全链路压测、内部压测)、灾备演练、降级演练、限流、巡检(监控、应用健康度)、混沌演练(红蓝对抗),如下图所示。随着平台业务越来越复杂,红蓝对抗的作用愈来愈明显,下面将详细介绍大数据平台在本次双十一大促备战工作中是
京东云开发者 京东云开发者
5个月前
大数据平台Bug Bash大扫除最佳实践
一、背景随着越来越多的"新人"在日常工作以及大促备战中担当大任,我们发现仅了解自身系统业务已不能满足日常系统开发运维需求。为此,大数据平台部门组织了一次BugBash活动,既能提升自己对兄弟产品的理解和使用,又能促使自家产品功能日趋完善。今天来给大家分享一
京东云开发者 京东云开发者
2个月前
对号入座,快看看你的应用系统用了哪些高并发技术?
一系统简介百舸流量运营平台承接着京东金融APP核心资源位和京东APP部分重要资源位,大促单接口QPS达到10w,压测单接口到20w,典型的c端读链路高并发场景。接下来,聊聊我们的系统都有哪些应对高并发的“武功秘籍”。二“武功秘籍”1缓存(redis缓存
架构师日记 - 从技术角度揭露电商大促备战的奥秘 | 京东云技术团队
本文从技术角度深入分析了大促备战的背景和重要性,重点介绍了备战期间稳定性保障的相关措施,包括具体的指导方向和落地细节。本文旨在回顾和梳理备战期间的关键步骤,以帮助我们更加从容的应对系统稳定性的挑战。