遭遇持续攻击时如何保住核心业务？优先级怎么排，应对策略有哪些

持续攻击下，保住核心业务的优先顺序是：先断臂求生，再回血复活，最后重建防线理解这一顺序的核心是在资源耗尽前保住最赚钱的那个业务。

别急着救火，先搞清谁是家人

把业务当成一栋房子,持续攻击就是有人拿着火把围着房子转。最蠢的做法是拿着水桶到处乱喷，有人做过对比试验：同样遭遇持续攻击，A组先保住核心业务，B组试图平等保护所有系统，结果A组在几小时内恢复收款，B组则陷入全系统瘫痪的泥潭，这不是个例。

行业共识认为,持续攻击下的第一原则是接受部分损失，攻击者要消耗的，是你们的带宽、服务器资源、技术人员精力，你要做的，是让这些消耗集中在次要系统上，给核心系统争取喘息时间。

判断优先级要看三个指标：产生收入的直接程度、恢复成本高低、合规风险大小，先看一张全景表：

下面拆开细说。

支付/交易系统家里的顶梁柱

这是最不能断的业务，想象一个卖场收银台，其他区域可以暂时关闭，收银台一旦关门，整个卖场就没有存在意义，支付链路直接决定现金流流入。所有安全资源要先倾斜到这里，包括高级别的防护策略、独立带宽、专职运维盯守。

生存条件很简单：流量入口尽可能收敛，能走API不走网页，能走专线不走公网，攻击者往往先探测支付接口，一旦发现这里有高防护，大部分会转向更弱的攻击面，业内专家指出，支付系统多撑一小时，可支配的应急资源就多一倍。

优先级：第一个保，最后一个放，哪怕官网被篡改挂马，支付和交易链路也要保持通着。

用户账户系统房子的大门

门不能塌,这里说的不是所有账户都保持百分百可用，而是保证认证服务不挂，用户登录不了，后面一切操作都无从谈起，持续攻击下最常见的现象是撞库和暴力破解流量暴涨，先打垮的是认证服务。

实际操作中,可以临时砍掉非核心登录通道，只保留密码+短信验证码这一种登录方式，多因素认证里的验证码通道本身也可能被打瘫，建议预先准备多个验证码服务商，随时切换。

账户系统的另一层价值在于信任，一旦用户发现账户被盗刷或数据泄露，比系统宕机造成的品牌损伤严重得多，这里需要投入安全审计资源，确保异常登录能快速发现。

优先级：紧跟支付系统，第二个保。

核心数据库全家的存折

没了存折,等于白干，业务数据、订单记录、用户信息都在这里，持续攻击的常见套路是勒索加密，打穿应用层之后直奔数据库写完再要赎金。

应对策略靠的是平时的备份功夫,如果备份完整且隔离，数据库本身不需要在攻击期间硬扛直接断网隔离，用副本恢复一个干净的库，但如果备份机制不完善，那就得寸步不让地守住数据库。

很多团队在攻击来临时,最慌的就是数据库，建议提前演练“一键隔离数据库”这个动作，训练到不用想就能操作，隔离之后用只读副本支撑查询，写入操作先落日志，等攻击结束再回放。

优先级：视备份完善程度而定，备份好，排第三；备份差，直接排第一。

客服工单系统安抚后方的传声筒

客服系统挂了,用户找不到人，火气会翻倍，但它的防护价值低，占用的资源却不少。这是一个典型的“可以牺牲”的模块。

具体操作：把工单系统降级为一个静态表单页，收集用户问题和联系方式，后台用共享表格记录处理进度，不追求实时交互，工单积压不影响核心业务，攻击期间用户的需求其实很简单有个能说话的地方、有回复的预期。

优先级：中等，第四位处理，可以允许短期不可用。

内部办公OA与官网房子外院的摆设

这两类系统是最先该放弃的，OA承载的是内部流程审批，官网本质是品牌展示页，持续攻击中，它们反而是攻击者最喜欢的突破点防护弱、暴露面大，一旦攻破就可以挂着恶意软件截图传播，造成“这家公司被黑得很惨”的舆论。

正确做法：直接主动关停，官网切成一个静态页或云防护页面，OA切换为内网访问或干脆暂停非紧急审批，主动关停比被动打瘫痪更有面子，还能省下资源，恢复成本也低，几分钟到几小时就能重新上线。

优先级：最后保，主动牺牲，舆情上需要提前预备话术：“为保障服务稳定，官网临时维护”，这是业内的常规操作。

网站被攻击如何恢复业务，按分钟排操作顺序

知道了优先级,还得知道先迈哪条腿，持续攻击中的正确动作是反弹式的：先从震中脱离，再逐步恢复。

前5分钟：踩刹车，不是踩油门

很多人第一反应是加强防护、增加带宽，这等于攻击时还在给房子添柴。第一动作是切，把所有业务切到备用IP或云防护节点，原IP直接放空，攻击流量找不到目标就会散开，观察几分钟能看出攻击类型和规模，切记不要立刻反制，容易引火烧身。

前30分钟：断尾求生，保住核心

按上面说的优先级清单,砍掉OA、官网等非核心业务，把资源集中到支付和登录，如果攻击强度超出承受力，启动降级预案只读模式、限制并发、关闭非关键接口，具体操作路径是：先改DNS切流量、再开防火墙黑名单、最后关闭非核心端口。

2小时内：把血止住，开始缝合

支付和登录稳定后,开始恢复账户系统，此时攻击者可能还在打，但打的是已经空掉的壳，逐步恢复核心业务流程，验证订单能下、支付能通、数据能对账，此时客服工单用临时表单顶着，不追求全部恢复。

更关键的是切一部分流量回生产环境试探观察攻击是否跟随流量回来，很多攻击是自动化的，打不到就放弃；也有顽固的，会出现反复拉锯，这个阶段别急，让一部分灰度用户先走通全流程。

24小时内：复盘与加固

攻击停了不等于结束,需要在攻击链条上进行细节复盘，比如攻击源IP、路径、使用漏洞等，加固核心系统，同时启动异常监控，特别是数据库的写入审计和支付回调的完整性校验。

业务容灾优先级怎么定：一次说透持续攻击中的资源分配

这里有个反直觉的事实：持续攻击中，多数的死亡是因为资源耗尽，而不是防线被破，技术人员困了累了、带宽耗尽、备用系统来不及调，防线自然就垮了，所以资源分配比技术对抗重要得多。

人力分配：不要全员扑在对抗上

安排一部分人专职对抗攻击，另一部分人专注核心业务运维，全员对抗是常见失败原因，攻击者可以轮班打，但团队的三班倒需要同步安排好，战斗超过一定时长，轮换制度必须启动。

再安排一个人专门对外说话同步客户、向管理层汇报、控制舆情，这个角色很重要，目的是为技术团队挡住外界干扰。

成本分配：钱得花在刀刃上

持续攻击的账单包括云资源消耗、带宽费用、安全设备租用。先保障核心业务的防护预算，非核心系统可以牺牲订单量去换，比如临时扩容只针对支付链路和数据库所在区域，而不是全站扩容。

攻击期间产生的损失清单、费用发票都要留下来，作为后续保险理赔或法律追责的依据，不少团队在忙乱中忽略这一点，事后追责时拿不出证据。

演练不能省：业务的“全家福”得先拍好

怎么知道哪个业务核心？平时就得做业务影响力分析，业务负责人写清楚“我这条业务断了会怎样”，技术负责人评估“恢复它需要什么”，两相对比才能算出优先级，很多企业没有这一步，攻击来了靠拍脑袋决定先保谁，很容易保错对象。

几个常见误区，踩中一个就翻车

• 把网站上所有按钮都加上防护，攻击者总会在你想不到的地方下手，分散防护等于没有防护。
• 硬扛不降级，明明扛不住还要支撑全站正常，最后全面崩溃，主动降级反而能保住核心。
• 报了110就万事大吉，等警察叔叔来之前，你的业务已经掉了好几个小时，自救方案才是第一道防线。
• 备份了就当无事发生，备份的恢复演练远比备份本身重要，真正备份过并能快速恢复的团队，在持续攻击中的表现会从容很多。

攻击结束后，别急着庆祝

业务恢复正常后,还有一件事：查找攻击原因并及时补上，一个常见的规律是，攻击者会在短时间内卷土重来，修一半的系统往往更容易被再次打穿，在保障核心业务的同时，把被攻破的路径、漏洞全部修补好，组织一次复盘，让整个团队都知道下次该怎么应对，持续攻击教会大家的是：不是每个业务都要救，但是核心业务一定不能丢，把优先级刻进骨子里，比任何安全设备都管用。

业务连续性管理 优先级：两个高频问题

问：持续攻击下，为什么不能把业务全部切到云防护？
答：云防护有容量上限，也存在被穿透的风险，而且在攻击期间接入云防护的流程本身需要时间，更麻烦的是，某些业务存在合规要求，数据不能出指定区域，所以需要按优先级筛选核心业务接入，其他业务先降级或关停。

问：如何确定哪个业务才是真的核心？
答：看两个标准：离钱最近的业务、离合规红线最近的业务，前者是公司的现金牛，断了就没有收入；后者是法律要求，出问题会被处罚甚至叫停，这两个业务一定是最优先保障的，其他业务都可以往后放。

问：攻击持续超过几天，该怎么办？
答：按目前一线应对持续攻击的经验来看，应该是边打边退、边退边修，核心业务始终保持在可用的最低水平，同时积极联系更高级别的防护资源介入，长期对抗中，优先保障团队轮换和核心业务的稳定，比试图击退每一位攻击者更实际，攻击者往往也会评估投入产出比，他们看到防线难以突破后会转向更容易的目标。