故障演练

【背景】 10 年 SRE，过去三年在两家不同公司都推过混沌工程（Chaos Engineering）。一次在金融客户环境做网络延迟注入（模拟跨机房 RTT 从 2ms 升到 50ms），一次在电商大促前做 pod 驱逐演练。两次都差点没批

【背景】 做了 10 年网络工程，管过跨机房的 BGP 路由、专线冗余和一批 7×24 的网关集群。去年做告警治理时，我把 200 多条告警按「过去 90 天触发次数」排了个序，发现一半以上 90 天里一次没响。团队内直接吵起来了： - 一

【背景】 做了 10 年分布式系统，我见过太多团队在架构评审时把"可回滚性"当默认前提——好像 CI/CD 管道通了，回滚就是点一下按钮的事。但每次真出事，回滚的"最后一公里"才暴露出来：数据库 schema 变更没法回滚、消息队列里的消息

背景 我在做安全加固时反复撞到一个看似「运维配置」、实则是产品级取舍的问题：当请求链路里的认证服务 / 风控引擎 / 黑名单 / 设备指纹这类安全依赖不可用（超时、熔断、返回 5xx）时，业务侧到底该： - A. fail-open：放行请

先交代下背景，免得大家各说各话。 我在一个 20 人左右的后端团队做 SRE，服务跑在自建 K8s 1.28 上，核心链路是「网关 → 订单 → 库存 → 支付」。去年 Q4 开始，我们引入了故障演练：用 ChaosMesh 在 stagi

做运维 3 年，"混沌工程"这个词大概是我在团队周会上被提得最多、但真正落地次数为零的话题。每次有人拍桌子说"我们得搞混沌工程"，另一头就有人回一句"你先把告警误报治干净再来谈这个"。今天想把这个争论摊开，听听大家怎么算这笔账。 【背景：混

«结论先行：我们以为"功能上线"的判据是主路径 100% 通过，但真正出事故的几乎全是降级路径——因为降级路径平时不跑，代码在腐化，验收单上也没人验证它。这篇文章给一份可以直接抄进验收单的"降级链路验收清单"，并附上我踩过的 4 个坑。»

背景 上周在排查一次 P99 毛刺时，顺带翻了下我们网关侧的几段老代码，发现一个挺有意思的分歧：同一个团队里，三个不同服务的"安全门"（鉴权、风控、限流、白名单校验）在下游依赖抖动时，处理方式完全不一样——有的直接 403 拒掉，有的直接放