从保底防护迁移到弹性防护前，如何评估业务停机窗口、数据规模与回退条件

保底防护能覆盖日常风险，不代表一定能应对突发攻击；弹性防护可以按服务规则扩展能力，也不代表扩展没有上限、费用和生效条件。迁移前要同时回答三件事：现有防护是否确实不足，弹性能力能否覆盖预期风险，以及入口或配置变更失败时能否及时恢复。

判断所需防护值时，应把业务正常峰值、已观测攻击、应用承载能力和服务商的指标口径分开核对。评估停机窗口时，则先确认是否改变业务入口；评估数据规模时，重点盘点防护对象和规则，而不是默认需要迁移数据库或网站文件。

先确认迁移收益：同一口径比较保底与弹性

保底防护通常是在约定的基础能力范围内持续提供防护；弹性防护通常是在满足服务触发条件后扩展能力。具体触发方式、容量边界、计量方式和超限处置因服务而异，应以服务协议、控制台说明或服务方书面确认的信息为准。

“DDoS 保底防护和弹性防护有什么区别？如何评估所需防护值？”不能只用一个带宽数字回答。两类服务的区别在于基础能力边界、扩展机制和相应的成本及运维要求；所需防护值则必须按服务实际采用的指标分别评估。

例如，网络流量带宽、数据包速率、并发连接数和每秒请求数是不同指标，不能互相替代。并发连接数表示某一时点同时存在的连接量，RPS 表示每秒请求数；不能把并发连接数直接换算成 RPS。若服务同时给出多项容量指标，应逐项核对业务需求和服务边界。

评估可以用变量表达：

• D_req,i：第 i 项防护指标的目标值。
• D_hist,i：历史记录中该指标的相关峰值。
• D_scenario,i：业务方确认的风险场景中，该指标可能达到的值。

可先按 D_req,i = max(D_hist,i, D_scenario,i) 形成待核实的目标，再与服务方确认该指标的统计方式、是否包含正常业务流量，以及所报防护容量代表的具体口径。这个表达式用于整理需求，不代表服务商最终应提供的容量，也不意味着所有服务的容量都按同一方式计算。

如果没有攻击记录，不要用正常流量峰值冒充攻击规模。可以先记录为待验证的风险场景，并向服务方核实触发条件和弹性上限。即使网络侧容量满足目标，源站资源不足、应用处理能力受限或业务规则误拦截，也仍可能造成服务不可用。

判断窗口和配置规模：入口变更比对象数量更影响切换风险

先确认变更范围是只调整防护策略，还是会更换接入地址、转发路径或解析记录。前者通常不涉及业务数据搬迁，但仍需验证策略是否正确生效；后者可能影响用户访问路径，需要为变更、观察和回退预留窗口。

窗口不能只按解析记录的 TTL 估算。递归解析缓存、客户端连接复用和业务自身缓存都可能影响实际切换过程。建议把窗口拆成四段：变更前检查、执行变更、业务验证、必要时回退，并结合业务高峰和关键操作安排观察时间。若业务不能接受短时连接中断，应先确认服务是否支持并行接入、灰度验证等方式；未经确认，不要假设切换可以无感完成。

这里的“数据规模”主要是防护配置和依赖关系的规模，而不是默认要迁移数据库。盘点内容至少包括：

• 受保护的地址、域名、业务系统及其对应关系；
• 解析记录、端口、协议、回源地址和访问控制规则；
• 白名单、黑名单、限速等策略及其优先级；
• 当前服务涉及且需迁移的证书、健康检查、源站校验等配置；
• 告警联系人、日志、审计记录及保留要求；
• 与防护入口关联的接口调用、回调地址和外部依赖。

对象越多、规则越复杂，漏项和验证时间越容易增加。给每项标记“必须迁移”“可重建”或“无需迁移”，并向服务方确认新服务对地址范围、协议、规则字段和规则数量的支持情况。若确有业务数据需要变更，应另行制定备份和一致性方案，不要把防护配置切换等同于数据迁移。

按顺序实施：备份、配置、小范围验证，再决定是否扩大

准备条件应包括：明确变更负责人、业务验证人和回退决策人；取得新服务的能力口径、弹性上限、触发方式、费用规则和超限处置说明；确认现有配置可导出或可恢复；记录当前访问情况、错误率、响应时间和告警状态。任何关键业务规则的兼容性尚未确认时，都不应直接全量切换。

配置前保存当前有效策略和解析记录，记录导出时间、版本及恢复方法。备份可能包含敏感信息，应按企业权限要求保存，不要直接粘贴到公开文档或无权限控制的工单。准备一份变更清单，至少记录业务对象、旧配置、新配置、验证方式、负责人和对应回退动作。

若使用 Linux 环境检查域名解析与 HTTP 业务路径，可在变更前后使用以下命令作对照。将示例域名和路径替换为实际业务地址；系统需已安装 dig 和 curl。命令仅用于观察解析和请求结果，不会代替控制台或服务端的防护状态核验。

# 检查域名当前解析结果
dig +time=2 +tries=1 A example.com

# 检查关键业务路径的 HTTP 状态码与请求耗时
curl --connect-timeout 5 --max-time 15 -sS -o /dev/null \
  -w 'http_code=%{http_code} total_time=%{time_total}\n' \
  https://example.com/health

把变更前后的输出连同测试时间保存下来。解析结果符合预期，只能说明查询时得到的解析回答；请求成功也只说明该次请求完成，不能单独证明弹性触发、攻击清洗能力或所有用户路径均正常。还要结合控制台状态、业务日志、告警和真实业务操作验证。

执行时优先选择服务支持的测试对象或灰度范围。核对规则是否导入、源站是否可达、健康检查是否正常，再按计划逐步切换入口或策略。验证应覆盖关键页面或接口、登录或提交等核心操作、回源状态、错误率、响应时间和误拦截情况；不要通过制造真实攻击测试防护能力，测试方式应先取得服务方和业务方确认。

成功验收条件应在变更前写清楚，例如核心业务操作正常、请求经过预期防护路径、关键依赖可用、错误率没有超出业务允许范围，且触发与告警机制已验证或有明确的后续验证安排。观察时间要覆盖业务自身的重要时段；尚未覆盖高峰或关键业务周期时，只能标记为阶段性验收。

预先设定回退条件，按影响范围恢复

回退阈值应依据业务基线和可接受的降级范围事先确定，不宜在故障发生后临时凭感觉判断。出现以下情况时，应暂停扩大变更，并按预定条件决定是否回退：

• 核心业务操作不可用，或错误率持续超出业务允许范围；
• 正常请求被明显误拦截，且无法在约定时间内安全修正；
• 回源异常、入口指向错误，或关键依赖无法访问；
• 弹性触发、告警或用量计量与已确认的服务规则不符。

若本次只调整了防护策略，按备份恢复旧策略；若改变了解析或入口，则恢复原记录及相关配置，并继续关注缓存和存量连接造成的过渡影响。恢复后重新检查核心业务、访问路径、源站日志和告警。旧配置应保留到新方案完成验收且回退窗口关闭，不要提前删除唯一可用的恢复依据。

常见结果可按低风险顺序排查：配置显示成功但业务未恢复，先核对对象映射、入口指向和回源连通性；只有部分用户异常，检查解析缓存、连接复用和灰度范围，并暂停扩大切换；正常请求被拦截，核对规则范围与优先级，优先恢复受影响规则；弹性未按预期触发，核实指标口径、触发条件和人工确认流程，不要用不受控流量验证；用量或费用异常，保留告警和记录，核对触发时间与计量规则，并依服务约定确认。

根据实际不足决定升级时机

现有保底能力频繁接近业务风险边界、历史事件显示基础能力可能不足，且弹性上限、触发方式、费用规则和兼容性都已核实，同时回退路径可执行时，迁移更有依据。若业务峰值稳定且保底能力已覆盖评估目标，或弹性上限和触发机制仍不清楚，或没有可验证的回退条件，应先补齐流量与风险记录，或进行受控的小范围验证，而不是仅凭“弹性”名称替换现有方案。

迁移后持续记录峰值、攻击告警、弹性触发、误拦截和用量情况。若实际流量长期接近保底边界、弹性触发频繁、扩展上限成为瓶颈，或业务入口和规则规模发生明显变化，再按相同指标口径重新评估目标值、兼容性与回退条件。