CC攻击打上来之后，技术侧往往半小时就压住了，但客户投诉会持续一整天。本文用 10 个问答讲清 CC攻击期间的告知节奏、对外口径红线、状态页搭建、分级响应、可用性补偿计算与客服话术，让沟通也有标准动作。
Q：CC攻击一打，为什么投诉会瞬间集中？
- 因为用户感知的不是攻击，而是「你的服务坏了」。他不管 pps，只知道自己付款失败了三次。
- 第二个原因是信息真空：客服不知道发生了什么，只能回「正在处理中」，用户听到就等于听到「没人管」。
- 所以沟通第一目标不是解释技术，而是消除不确定性：什么状态、影响哪些功能、下次何时更新。
- 主动告知能把投诉量压到三到五成，被动等客户来问基本翻倍。
Q：第一份告知什么时候发，发什么？
- 时间窗定在确认异常后 15 分钟内。超过 30 分钟，社交媒体上已有人替你发布版本，且大概率是错的。
- 第一份告知只答四个问题，别多写：
【服务异常告知 · 第 1 号】
影响范围：首页与登录接口访问缓慢
当前状态：已确认遭受异常流量冲击，正在执行流量清洗
已采取措施：启用限流与缓存回源保护，优先保障登录与支付链路
下次更新：20 分钟后（预计 14:35）- 「下次更新」这行不能省，它把「无限等待」切成「等一个确定时间点」，降投诉最有效。
- 之后按固定节奏更新，没解决也要发「仍在处理，新增情况如下」，沉默比坏消息更伤人。
Q：对外口径有哪些红线？
- 不给恢复时间承诺。流量随时可能翻倍，说到没做到，第二波投诉比第一波更凶。只用「预计」和「下次更新」。
- 不披露攻击规模与细节。带宽峰值、pps、来源、设备型号，都等于给对手送情报，也可能被放大成恐慌。
- 不用「网站被打死了」这类说法，改成「遭受异常流量冲击，已启动防护」。前者让客户想搬家，后者让客户想等。
- 不甩锅给客户。哪怕真是客户程序有漏洞，对外先说「正在处理」，内部复盘再定责。
- 不做超出能力的承诺。没上高防就别暗示「绝对防得住」，这句话后面往往跟着退款要求。
Q：状态页怎么在十分钟内搭起来？
- 别等出事才做。提前放静态状态页，文件开关控制，出事
touch就生效：
# 1. 维护页（纯静态，不依赖后端）
mkdir -p /var/www/status
cat > /var/www/status/maintenance.html <<'EOF'
<!doctype html><meta charset="utf-8">
<title>服务维护中</title>
<h2>服务正在维护</h2>
<p>检测到异常流量，已启动防护，正在逐步恢复。</p>
<p>预计下次更新：30 分钟内。</p>
EOF
# 2. Nginx 侧的文件开关 + 503 + Retry-After
# /etc/nginx/conf.d/status.conf
server {
set $maint 0;
if (-f /etc/nginx/maintenance.on) { set $maint 1; }
if ($maint = 1) { return 503; }
error_page 503 /maintenance.html;
location = /maintenance.html {
root /var/www/status;
internal;
add_header Retry-After 1800 always;
add_header Cache-Control "no-store" always;
}
}
# 3. 一键开启 / 关闭
touch /etc/nginx/maintenance.on && nginx -s reload # 开启
rm -f /etc/nginx/maintenance.on && nginx -s reload # 关闭- 两个关键点：返回 503 而不是 200（200 空页面会被判低质）、带 Retry-After。
- 状态页必须禁止 CDN 缓存，否则恢复后用户还看到维护页，等于人为延长故障。
Q：分级响应怎么定，才不至于全员慌乱？
把「严重程度」和「谁到场」提前绑定，出事照表执行，不做临场讨论。
- P1：核心链路不可用（登录、支付、下单全挂）。5 分钟响应，技术+客服+业务负责人到场，30 分钟更新一次。
- P2：核心功能变慢但可用，或部分接口 5xx。15 分钟响应，技术+客服值班，每小时更新。
- P3：非核心页面受影响或仅告警。30 分钟响应，值班工程师处理，按需告知。
- P4：潜在风险（流量上升但未影响业务）。2 小时内评估，不对外告知。
- 每级写清谁有权切流量、谁有权发公告。最耽误事的往往不是技术，是「发公告还要等三个人审批」。
Q：补偿和退款按什么算，才不至于被无限加码？
- 核心原则：按可用性算，不按情绪算。有公式谈判才有边界，没公式每次都是拉锯。
- 先算实际可用性。固定探测点每分钟一次，取失败比例：
# probe.log 格式：时间 URL 状态码
# 计算当月可用性
awk '{t++; if($3!="200" && $3!="301" && $3!="302") bad++}
END{printf "探测 %d 次，失败 %d 次，可用性 %.3f%%\n", t, bad, (1-bad/t)*100}' probe.log- 再按阶梯表给补偿，写进合同并公开，比事后一件件谈省事得多：
月度可用性 ≥ 99.9% → 不补偿
99.0% ~ 99.9% → 补偿月服务费的 10%
95.0% ~ 99.0% → 补偿月服务费的 30%
< 95.0% → 补偿月服务费的 50%，可申请按剩余天数退款- 补偿以服务时长或服务费抵扣，不做现金赔付。必须写进合同，否则一次攻击就赔掉全年利润。
- 明确免责情形：攻击超出约定防护能力、未按要求接入、客户程序缺陷、不可抗力。免责条款是为了划清责任边界，不是赖账。
Q：客服话术怎么写，才能既不承诺又不冷场？
用三段式：承认感受 + 说明事实 + 给出动作。缺第一段显得冷漠，缺第三段显得敷衍。
- 「你们网站又崩了」：确实添麻烦了，目前是异常流量导致访问缓慢，已启动限流与缓存保护，登录和支付链路优先恢复。您的操作我先记录，恢复后回访。
- 「什么时候好」：还在清洗流量，给不了准确时间，每 30 分钟在状态页更新进展，恢复后第一时间通知您。
- 要求赔偿：理解您的心情。按协议，可用性低于承诺值可申请服务费补偿，我先登记受影响时段，恢复后统一核算。
- 共同点：不承诺时间、不评价攻击、都给下一步动作。客服别自己判断原因，口径从技术侧拿。
Q：怎么用监控数据避免事后扯皮？
- CC攻击的争议很少在「有没有故障」，而在「故障了多久」。所以要有多探测点、可导出、带原始记录的监控。
- 自建用 blackbox_exporter 加两个以上地域探测点，间隔压到 1 分钟，原始结果落文件：
# blackbox_exporter 探测模块（prometheus.yml 片段）
- job_name: 'site_probe'
metrics_path: /probe
params:
module: [http_2xx]
static_configs:
- targets:
- https://www.example.com/
- https://www.example.com/api/health
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- target_label: __address__
replacement: 127.0.0.1:9115- 第三方监控更是第三方视角的证据。客户说挂了 4 小时、你说 40 分钟，要的是能对上时间轴的原始日志。
- 每次故障留一条时间线：开始、恢复、影响面、动作、公告编号。同样的攻击再来，处置时间能砍一半。
Q：攻击结束后，复盘要交什么？
- 对外一页说明：发生什么、影响多久、已做哪些改进、下次如何更快发现。客户要的是「学到了什么」。
- 一份对内的完整复盘：攻击特征（UA、IP 段、请求路径、频率）、防护规则命中情况、哪些规则误杀了正常用户、监控是否提前发现、沟通环节哪里卡住。
- 复盘必须产出可验收的改进项：新增哪条限流、状态页是否自动化、告警阈值调多少、话术是否更新。没有责任人和时间的改进项等于没写。
- 最后对重点客户做一次主动回访。CC 攻击之后流失的客户，多数不是因为那次故障，而是因为故障期间没人理他。
Q：还有什么补充建议？
- 把沟通成本算进防护预算。多数人只算带宽与清洗费用，忽略攻击期间的人力消耗，客服与技术的加班成本往往更高。
- 提前备好三份材料：状态页、公告模板、补偿阶梯表，平时用不上，出事能省半天。
- 对外口径统一由一个出口发布，技术、客服、销售别各说一套。口径不一致的信任损失比故障更难修复。
- 最后一句：CC攻击考的是防护能力，投诉潮考的是流程能力。前者花钱能买，后者只能平时练。