深色模式
应急止血手段
摘要：止血的目标是"先恢复业务，再找根因"。本文按优先级给出限流、降级、切流、回滚、扩容五种手段的操作方式与副作用，强调顺序选择和容量评估，避免止血动作本身引发二次故障。
适用环境
bash
kubectl version --short 2>/dev/null || kubectl version
nginx -v 2>/dev/null
which redis-cli 2>/dev/null1
2
3
2
3
排障步骤
第 1 步：判断该用哪种手段
| 场景 | 首选手段 |
|---|---|
| 流量超出容量 | 限流 |
| 非核心功能拖垮核心 | 降级 |
| 单机房/单节点异常 | 切流 |
| 最近有变更 | 回滚 |
| 容量确实不足 | 扩容 |
第 2 步：限流 —— 控制进入量
bash
# nginx 层按 IP 限流（需先在 http 段定义 limit_req_zone）
grep -rn 'limit_req' /etc/nginx/conf.d/*.conf 2>/dev/null
nginx -t && nginx -s reload1
2
3
2
3
限流阈值必须有依据
凭感觉设的 QPS 上限可能直接把正常流量掐死。应参考压测容量或历史峰值的百分比来设定。
第 3 步：降级 —— 关掉非核心
bash
# 通过配置开关关闭非核心功能（推荐：开关应提前内置）
curl -sS -X POST http://127.0.0.1:8080/admin/switch -d 'feature=recommend&enabled=false'1
2
2
降级优先关闭：推荐、统计、报表、异步任务等非主链路功能。
第 4 步：切流 —— 摘掉异常节点
bash
kubectl scale deployment/<name> -n <ns> --replicas=0 # 摘掉整组
kubectl get endpointslices -n <ns> -l kubernetes.io/service-name=<svc>1
2
2
切流前必须算容量
摘掉一半节点后，剩余节点要承接全量流量。未确认容量就切流会把故障从"部分"变成"全部"。
第 5 步：回滚 —— 撤销变更
bash
kubectl rollout history deployment/<name> -n <ns>
kubectl rollout undo deployment/<name> -n <ns>
kubectl rollout status deployment/<name> -n <ns>1
2
3
2
3
回滚前确认数据兼容性
新版本若已写入新格式数据，旧版本可能无法处理，回滚会造成二次故障。这类变更应使用双向兼容方案。
第 6 步：扩容 —— 增加容量
bash
kubectl scale deployment/<name> -n <ns> --replicas=10
kubectl get pod -n <ns> -l app=<name> -w1
2
2
扩容不能解决依赖瓶颈
如果瓶颈在数据库或下游服务，扩容上游只会把更多压力传导下去，加速恶化。
第 7 步：全程盯指标
bash
kubectl top pod -n <ns>
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://<域名>/health1
2
2
验证
bash
curl -sS -o /dev/null -w 'code=%{http_code} total=%{time_total}\n' https://<域名>/api
kubectl get pod -n <ns> | grep -c Running
kubectl logs -l app=<name> -n <ns> --since=5m | grep -ci error1
2
3
2
3
常见坑
止血后不再追根因
止血只是恢复业务，根因未修必然复发。必须在恢复后转入根因分析。
同时执行多种止血手段
限流 + 降级 + 回滚一起上，事后无法判断哪个真正生效，也不利于复盘。应逐项验证效果。
降级开关从未演练
真出故障时才发现开关不生效或依赖已失效的服务。降级开关需要定期演练验证。
用重启代替止血
重启能短暂缓解但会丢失现场证据，且冷启动（缓存、连接重建）可能带来新一轮冲击。应先抓证据再重启。