很多做混沌工程测试的同学，可能都踩过这样的坑：本来想测测服务挂掉的时候系统会不会自动降级，结果不小心把故障打到了生产环境，刚巧碰上晚高峰，用户请求全卡500，好不容易赶过来的流量直接流失，还被运维同学追着要说法。今天我们就聊一聊怎么用Linkerd这个工具，把故障注入的安全边界拉满，让混沌测试只在“测试区”生效，绝不反噬生产。
一、为什么故障注入会反噬生产？
混沌工程的核心是“主动制造小故障，发现系统的隐藏问题”，但生产环境是真金白银的用户在使用，你能拿用户做“容错测试”吗？很多人一开始没搞懂这一点：故障注入的技术本身没问题，但如果没给它划好“地盘”，让它在生产的核心区域乱撞，就是给自己挖坑。举个真实的例子：上周朋友的公司想测“订单服务挂掉时，支付服务能不能自动切流”，为了方便，他们直接在生产集群的订单命名空间里，给所有用户请求加了1秒延迟。结果刚好碰上618预热，流量比平时涨了3倍，1秒的延迟直接把支付服务的请求队列塞满，整个订单流程崩溃了整整10分钟，损失至少几十万。问题出在哪？他们把故障注入的范围设成了“整个订单命名空间”，而且没控制故障的比例，结果刚好撞在流量高峰的枪口上。
二、Linkerd里的故障注入怎么设置安全边界？
很多人知道Linkerd是个“服务代理工具”，每个服务旁边都会加一个小代理，叫Sidecar，它可以拦截所有进出服务的请求，故障注入就是靠这个Sidecar来实现的——不用改业务代码，只要告诉Sidecar，给哪些请求加什么样的故障，就能完成测试。但要让它安全，得做好四层边界。
2.1 先把测试环境和生产环境彻底隔离开
最基础的安全，就是不让测试的故障跑到生产集群里。Linkerd支持多集群部署，你可以搞两个K8s集群：一个叫“测试集群”，专门用来做混沌测试；一个叫“生产集群”，只放正式业务。这样哪怕测试时搞出天大的故障，也不会影响真实用户。怎么用？你只需要在本地切换K8s的上下文就好：
# 查看当前电脑上所有配置好的K8s集群
kubectl config get-contexts
# 切换到测试集群上下文，后续操作只会影响测试集群
kubectl config use-context cluster-test
2.2 给故障注入加“流量比例限制”
就算不小心在生产集群操作了，也得让故障只影响一小部分用户，而不是全量。比如你测服务容错，最多给10%的请求加故障，剩下90%的用户还是能正常用。Linkerd的FaultInjection资源里有个percentage字段，就是干这个的。举个例子，假设你生产环境里有个用户服务叫user-service，你想测它遇到500错误时，前端会不会自动重试，那你可以这么配置：
apiVersion: policy.linkerd.io/v1beta1
kind: FaultInjection
metadata:
name: test-user-service-fault
namespace: prod-app # 必须写生产命名空间，和测试环境区分
spec:
http:
- abort:
httpStatus: 500 # 故障类型：返回HTTP 500错误
percentage: 10 # 流量限制：仅10%的请求会触发故障
target:
kind: Service
name: user-service # 仅针对该服务，不是集群里的所有服务
2.3 只针对“测试版本”打故障，别碰全量流量
很多团队会用K8s的灰度发布（Canary），把新功能的服务放到单独的Pod里，打个标签，比如version=canary。你可以让故障注入只打在这些灰度Pod上，全量用户的服务完全不受影响。怎么实现？Linkerd的FaultInjection里可以用match规则，筛选Pod的标签。比如：
apiVersion: policy.linkerd.io/v1beta1
kind: FaultInjection
metadata:
name: test-canary-fault
namespace: prod-app
spec:
http:
- delay:
duration: 5s # 故障类型：加5秒延迟
percentage: 50 # 仅50%的灰度请求加延迟
target:
kind: Pod
selector:
matchLabels:
version: canary # 仅匹配版本为canary的Pod，全量Pod不受影响
2.4 装个“紧急停止按钮”，故障失控就立刻停
就算把所有边界都设好了，万一碰上突发情况（比如监控没注意到，故障比例设高了），得有个自动停止的机制。Linkerd有个命令可以看服务的成功率，你可以写个简单的脚本，定时检查，如果服务的成功率低于95%，就自动删除FaultInjection资源，停止故障注入。比如这个Shell脚本：
#!/bin/bash
# 检查生产环境user-service的请求成功率
SUCCESS_RATE=$(linkerd stat service user-service -n prod-app -o jsonpath='{.routes.successRate}')
# 用bc做浮点运算，判断成功率是否低于95%
if (( $(echo "$SUCCESS_RATE < 0.95" | bc -l) )); then
echo "警告：用户服务成功率不足95%，自动关闭故障注入"
kubectl delete faultinjection test-user-service-fault -n prod-app
fi
你可以把这个脚本放在K8s的CronJob里，每1分钟跑一次，万一真出问题，系统会自动关掉故障，不用人熬夜盯着监控。
2.5 我们团队的踩坑教训
之前我所在的团队，第一次做混沌测试的时候，没注意边界，直接在生产命名空间给所有服务加了100%的延迟故障。结果刚加上，监控就跳红：订单服务的延迟涨到了10秒，错误率40%。我们赶紧删掉故障，排查才发现，我们把target的字段写错了，写成了kind: Namespace，而不是Service，所以所有服务都被加了延迟。后来我们就定下了几个死规矩：1. 故障只在测试集群跑，要测生产必须走灰度；2. 故障比例绝对不能超过20%；3. 必须装自动停止脚本。从那以后，我们做了上百次混沌测试，没再出过生产事故。
三、Linkerd混沌工程的应用场景
哪些场景适合用这种安全的故障注入？
3.1 服务容错能力验证
比如你的服务有自动重试、降级的逻辑，你可以加延迟或错误故障，测这些逻辑会不会生效，有没有漏处理的情况。
3.2 限流熔断测试
测限流组件（比如Linkerd自带的限流规则）会不会在流量突增时正常触发，不会出现漏流或者限流太严的问题。
3.3 跨服务依赖测试
比如A服务挂了，B服务能不能自动切换到备用节点，不会影响用户请求，避免出现服务雪崩的情况。
四、Linkerd故障注入的优缺点
优点很明显：第一，不用改业务代码，Sidecar代理直接处理，部署快，几乎对业务无侵入；第二，安全边界灵活，从集群、命名空间、服务到Pod标签，多层级筛选，想怎么限就怎么限；第三，和K8s生态完全兼容，灰度发布的服务直接加标签就能测，不用额外改造。缺点也有：对新手来说，配置的细节比较多，比如选错target就会影响生产；另外，故障注入的范围越小，配置越复杂，需要一点点成本来维护规则。
五、注意事项
5.1 绝对不要给全量服务打故障
哪怕比例再小，也别给生产的全量服务加故障，必须只针对灰度版本或者专门的测试服务，这是最核心的红线。
5.2 紧急停止脚本必须上线
别觉得不会出问题就不写，真出问题的时候，人不可能24小时盯着监控，自动停止是最后一道保险，必须设置好。
5.3 测试集群要和生产一模一样
不管是服务版本、配置，还是流量模型，测试集群尽量和生产贴近，这样测出来的结果才有用，不然在测试环境测的没问题，到生产就崩了，等于白测。
六、总结
混沌工程是发现系统问题的好方法，但它就像一把菜刀，用来切菜很方便，用来砍人就会出事。Linkerd的故障注入工具给我们提供了“安全砍”的可能，只要把边界划清楚：隔离测试和生产集群、限制故障流量比例、只打灰度版本、装自动停止按钮，就能把故障控制在“测试区”，绝不会反噬生产。对不同基础的开发者来说，不用害怕做混沌测试，只要把安全边界做好，就能大胆测试，让系统越来越稳。
Comments