CC攻击处置谁值班？分工、交接和升级路径怎么定

作者

CC攻击处置最难的部分不是写规则，而是谁来判断、谁有权动手、夜里两点出事该找谁。本文用 10 个问答讲清 CC攻击处置 的值班分工、交接内容与升级路径，附可直接套用的交接快照脚本和值班记录模板。

Q：为什么 CC 攻击处置要先定人，再定规则？

  • 规则是死的，判断是活的。同一根流量曲线，白天可能是推广高峰，凌晨就是攻击。
  • 现场最常见的卡点不是不会配，而是「谁有权改线上配置」没提前定，来回请示耗掉二十分钟。
  • 角色、权限、升级路径先写清楚，规则才有可能被真正执行。
  • 一句话：CC攻击处置的瓶颈在协作，不在技术。

Q：值班表怎么排才够用？

  • 中小站两个人就能轮：早班 9 点到 21 点，夜班 21 点到次日 9 点，跨零点的那一班要在交接单里写清是哪一天。
  • 必须再留一个不在班但可被叫醒的二线，负责深夜决策，不能把判断和决策全压在值班的人身上。
  • 值班不是守屏幕，是保证告警 5 分钟内被看到。手机上装告警客户端，比挂在墙上的大屏靠谱。
  • 排班表提前一周定死，别当天临时找人换，换班要留记录。

Q：四个人四个角色，具体谁干什么？

  • 判断（值班一线）：确认告警是真是假，做第一轮甄别，不动配置。
  • 操作（有配置权限的人）：执行限流、封禁、切高防，改完立刻记录。
  • 沟通（客服或运营）：对客户和业务方同步，每条告知都要带下次更新时间。
  • 决策（二线或技术负责人）：决定要不要上高防、要不要降级、什么时候回滚。
  • 小团队一人多角没问题，但「谁决策」必须唯一，否则出事没人敢拍板。

Q：交接班必须交哪四件事？

  • 告警状态：还有哪些告警没关闭，哪些是真攻击、哪些是噪声。
  • 已下发规则：过去 12 小时改了什么，改了哪个文件、哪一行、几点生效。
  • 待观察项：哪些 IP 或接口在观察期，明早要看哪几个指标。
  • 对外口径：今天对客户说了什么，下次承诺的更新时间是几点。
  • 只交一句「没什么事」，等于把风险原封不动留给下一班。

Q：交接用什么做凭证？给几条能直接跑的命令

  • 配置快照：每班交接前把线上真正生效的配置存档一次，出问题能 diff 出是哪一班改的。
  • 规则清单：把当前生效的封禁、限流、白名单各导出成一份文本。
  • 指标快照：当前 QPS、5xx 比例、封禁命中数，抄进交接单。
  • 三样东西放同一个目录，按日期时间命名，只保留最近 7 天。
# 1) 存档当前生效配置（比编辑器里那份可信）
D=/var/backup/nginx/$(date +%F_%H%M)
mkdir -p $D && nginx -T > $D/nginx.conf 2>/dev/null

# 2) 导出限流与封禁规则，与上一班 diff
grep -nE 'limit_req|limit_conn|deny' $D/nginx.conf > $D/rules.txt
diff /var/backup/nginx/last/rules.txt $D/rules.txt | head -40

# 3) 指标快照：近 2 万行日志里请求量最大的 10 个 IP
tail -n 20000 /var/log/nginx/access.log | awk '{c[$1]++} END{for(k in c) print c[k], k}' | sort -rn | head -10

ln -sfn $D /var/backup/nginx/last

Q：夜班和白班的处置标准要不要不一样？

  • 要。夜间的原则是只做可逆、影响面小的动作，大改一律留到白天。
  • 夜间可以做：限速、拉黑明确的恶意 IP、开静态页缓存、加一层人机验证。
  • 夜间不要做：大规模改 location、换源站、动证书与 SSL、重启 PHP-FPM。
  • 夜里最容易犯的错是紧张之下把 worker_connections 调大，把崩溃推到第二天上班时间。
# 任何 reload 之前必须过的门，配置有错就 reload 失败，不会半生效
nginx -t && systemctl reload nginx

# 临时限速（可逆，夜班首选）：单 IP 10r/s，突发 20
# 写在 server 块内，回滚就是删掉这两行
limit_req zone=perip burst=20 nodelay;
limit_req_status 429;

Q：什么情况必须升级，升级到谁？

  • 三条硬线：业务已经 5xx 或打不开；攻击持续超过 15 分钟且量还在涨；任何涉及域名、证书、解析的操作。
  • 升级路径写死三级：值班一线、二线技术、供应商（CDN 或高防的 7×24 工单与电话）。
  • 找供应商前先备好账号 ID、实例 ID、合同号，报障时对方第一句就问这个。
  • 深夜电话的优先级高于工单，工单可能两小时才回。
# 业务可用性探测：3 次里 2 次失败即视为不可用，直接触发升级
ok=0
for i in 1 2 3; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -m 5 https://www.example.com/health)
  [ "$code" = "200" ] && ok=$((ok+1))
  sleep 2
done
echo "ok=$ok/3"
[ $ok -lt 2 ] && echo "升级：业务已不可用"

Q：怎么防止值班的人乱改配置？

  • 所有变更走同一入口：改前记录、改后复核、24 小时内必须能回滚。
  • 高危操作（改 location、动证书、批量封 IP 段）要求双人在场，一个念一个敲。
  • 每条规则带注释，写清责任人、日期、原因，半年后还看得懂。
  • 变更窗口尽量放在流量低谷，改完观察 10 分钟再离开，别改完就走。

Q：值班记录该写多细？给个模板

  • 一个事件一行，五列就够：时间、现象、动作、结果、是否升级。
  • 现象只写数字：QPS 多少、5xx 比例多少、峰值连接数多少、头号 IP 打了多少次。
  • 动作写到具体文件和参数，不要写「优化了一下配置」这种无法复盘的话。
  • 记录不是写给人检查的，是给下一个被叫醒的人看的。
时间,现象,动作,结果,是否升级
2026-10-23 02:14,QPS 40 升到 900,5xx 22%,limit_req 10r/s 并封 Top IP,5 分钟回落,否
2026-10-23 03:02,攻击换源 800 个 IP,开 CDN 严格模式,延迟 300ms 业务正常,是（供应商）

Q：还有什么补充建议？

  • 值班手册控制在两页 A4 内：角色、权限、升级电话、五条常用命令，再多就是过度设计。
  • 每季度做一次演练：假装凌晨两点被打，看多久有人响应、多久止血。
  • 交接单必须电子化，口头交接等于没交，聊天记录搜不到就等于没发生。
  • 最后一句：CC攻击处置靠的是分工和留痕，不是某个人的临场发挥。