SRE实践

概述 某年双十一前 14 天，某电商平台启动了全量封板——所有非紧急变更一律冻结，CI/CD 流水线闸门关闭，只留一个安全补丁通道。运维团队松了口气，觉得这回稳了。 结果大促当天凌晨 2 点，支付链路 P0 告警炸了。 根因不是新代码，而是一个封板前 3 天上线的配置变更——某个限流规则的白名单写错了 IP 段，平时流量小没问题，双十一零点流量打到 8 倍，限流规则误杀了 30% 的正常请求。封板期间没人复查这个配置，因为"封板了，不动了嘛"。 这次故障给我最大的冲击是：封板 14 天，零代码变更，还是炸了 P0。问题不在变更多少，在于变更冻结制造了一种虚假的安全感——你以为关了闸门就安全了，实际上水位一直在涨。 行业数据也支持这个判断。SRE 实践白皮书指出，约 70% 的线上生产故障由变更直接引发。但"变更引发故障"不等于"减少变更就能减少故障"——封板期间积累的配置偏差、无人维护的监控规则、被延迟修复的隐患，都在暗处发酵。 这篇文章要拆解的就是：人工封板到底哪里出了问题，以及如何用错误预算驱动的动态变更窗口替代日历封板。我会给出 5 个工程决策，每个都来自实际项目中的踩坑和修正。 变更冻结的本质：你以为在防故障，其实在做"安全剧场" 先说清楚"变更冻结"到底是什么。 变更冻结（Change Freeze），行业里也叫封板、blackout period、code freeze，指的是在特定时间段内禁止或严格限制生产环境的任何变更操作。常见触发场景： 双十一/618 等大促前 1-2 周 春节/国庆等法定长假期间 核心系统迁移或基础设施切换期间 合规审计期间 IBM 在其云服务的维护策略中明确定义了 Change Freeze Period 的概念：在冻结期内系统正常运行，所有标准自动化流程（如数据库备份）照常执行，但协调性变更（如应用升级）不可用，SRE 团队不在此期间安排维护。 这个定义本身没问题。问题出在执行层面——大多数团队的封板实践，本质上是一种"安全剧场"（Security Theater）： 做法 看起来在做 实际效果 关闭 CI/CD 闸门 阻止新代码上线 配置变更、手动操作绕过流水线照样上 全量冻结所有变更 风险最小化 安全补丁被延迟，隐患变成定时炸弹 人工审批特例变更 精准放行 审批人不懂技术细节，变成橡皮图章 封板期间不巡检 “稳定"了不用看 配置漂移、监控失效无人发现 我不是反对变更冻结——在特定场景下，封板确实有必要。我反对的是"一刀切式"的静态封板：用日历决定什么时候能变更，而不是用数据决定风险有多大。...

概述 Netflix 说混沌工程让线上重大事故减少了 70%。这个数字很多团队都看过，但真正在生产环境跑过故障注入的，寥寥无几。 原因很简单：怕。注入一个网络分区，Pod 卡死怎么办？模拟磁盘写满，数据库崩了怎么办？在凌晨 3 点手动注入故障然后手忙脚乱地回滚——这不是演练，这是制造事故。 我曾经在某新能源物流平台的 K8s 迁移过程中，需要在 120+ 微服务全量切换前验证容灾能力。纯靠理论推演不够，团队需要眼见为实。于是我们在预发环境做了一轮故障注入测试，结果第一次注入网络分区就发现了 Pod 驱逐延迟 6 分钟的问题——如果这个 bug 在生产环境暴露，RTO 直接超标。 这篇文章不讲混沌工程的入门概念（那篇 相关文章：混沌工程：主动发现系统弱点 已经讲过），而是直接进入生产级决策：怎么选工具、怎么控制爆炸半径、怎么设计自动化演练流水线，以及 3 个我在实战中踩过的反直觉坑。 故障注入测试 vs 混沌工程：分清两件事 很多人把这两个词混着用。它们不一样。 故障注入测试是一种测试技术——你明确知道要注入什么故障（比如"把节点 A 和节点 B 之间的网络断开 5 分钟"），有明确的预期结果（比如"流量应该自动切换到节点 C"），有通过/不通过的判定标准。它的核心是验证：你已经设计的容错机制到底管不管用。 混沌工程是一种工程实践——你随机注入故障，观察系统行为，发现你不知道的弱点。它的核心是探索：系统在未知故障组合下会怎样。 维度 故障注入测试 混沌工程 目标 验证已知容错机制 发现未知弱点 故障选择 预定义、有针对性 随机、组合式 预期结果 明确的通过/失败标准 观察系统行为 执行频率 发布前、变更后 持续、定期 适用阶段 预发 → 生产灰度 生产环境常态运行 风险可控性 高（已知故障、已知预期） 中（随机组合可能暴露级联失效） 我推荐的落地路径：先做故障注入测试，再做混沌工程。原因很实际——如果你的系统连已知的、单一的故障都扛不住，随机组合只会制造混乱。 四类故障的注入方式与生产风险 故障注入的核心是覆盖系统最可能出问题的维度。我按实践经验分成四类，每类的注入方式、验证目标和生产风险完全不同。 网络故障：最危险的一类 网络故障包括网络分区（partition）、延迟（delay）、丢包（loss）、带宽限制（bandwidth）。其中网络分区是最危险的——它会导致分布式系统的"裂脑"（split-brain）。 为什么危险？因为网络分区不像 Pod 被杀那样有明确的故障信号。K8s 的 kube-controller-manager 需要等待 node-monitor-grace-period（默认 40 秒）才把节点标记为 NotReady，然后再等 pod-eviction-timeout（默认 5 分钟）才开始驱逐 Pod。加起来将近 6 分钟，在这段时间内，节点上的 Pod 仍然在运行，仍然认为自己是"活的"，但和其他节点的通信已经断了。...

概述 凌晨 2 点 17 分，手机弹出告警：核心机房 A 区网络设备故障，数据库主从同步中断。值班 SRE 切到灾备机房 B 区，发现应用连上新主库后，部分订单数据查不到——异步复制窗口期丢了 47 秒数据。业务恢复用了 38 分钟，超出 RTO 目标 8 分钟。 这是一次真实的容灾切换事故。事后复盘发现，系统设计了容灾架构，配置了数据同步，也写了切换脚本，但真正切换时还是出了问题。问题不在于"有没有灾备"，而在于容灾架构的每个环节是否真正经得起生产级考验。 本文拆解跨机房容灾的核心架构决策，覆盖同城双活、异地灾备、两地三中心三种模式的选型权衡，同步复制的性能代价与脑裂防护，异步复制的窗口期补偿机制，以及故障切换从决策到执行的完整流程。每个环节都附有真实踩坑记录和性能数据。 在我经手过的跨机房容灾方案中，最终达成 RPO<5min、RTO<30min 的指标。这个数字看起来不算极致，但它是成本、稳定性和业务需求三方博弈后的工程最优解——不是理论上的 RPO=0，而是生产环境能跑通、能验证、能回滚的方案。 RPO 和 RTO 的工程真相 不是技术指标，是业务指标 RPO（Recovery Point Objective）和 RTO（Recovery Time Objective）这两个词被技术圈用烂了，但很多人理解反了——它们首先是业务指标，然后才是技术指标。 RPO 回答的是"能容忍丢多少数据"。比如一个电商系统，订单数据的 RPO 必须是 0（不能丢订单），但用户行为日志的 RPO 可以是 1 小时（丢了不影响核心交易）。RTO 回答的是"能容忍停多久"——核心交易系统 RTO 要 <5 分钟，而报表系统的 RTO 可以是 4 小时。 关键认知：不要一刀切。 我见过太多团队把所有系统都按 RPO=0、RTO<1min 设计，结果容灾建设成本翻了好几倍，非核心系统根本不需要这么高的规格。 按业务重要性分级设计容灾目标： 级别 系统类型 RPO 目标 RTO 目标 同步方式 P0 核心交易、支付 0 <5min 同步复制 P1 用户中心、订单查询 <1min <15min 半同步复制 P2 内容管理、报表 <30min <2h 异步复制 P3 日志分析、离线计算 <1h <4h 定时备份 RPO=0 的代价不是线性的 很多人觉得"RPO 越小越好"，但 RPO 从 1 分钟到 0 的成本跳跃是指数级的：...

概述 凌晨三点，手机震动。告警群炸了 200 条消息，用户投诉已经涌进客服群。你爬起来打开电脑，登录跳板机，发现某个核心接口 P99 飙到 8 秒。接下来 30 分钟你都在翻日志、查 Grafana、问上下游——最终定位到是某个配置中心推了一行错误参数。 这个场景太熟悉了。在我经手的上百次线上故障中，定位环节消耗的时间占 MTTR 的 60% 以上。恢复操作本身可能只要 2 分钟（回滚、重启、切流量），但找到"到底哪里出了问题"往往要花 20-30 分钟。 MTTR（Mean Time To Repair/Recovery）衡量的是从故障发生到服务恢复的平均时间。但这个数字是个黑盒——30 分钟的 MTTR 里，到底哪些环节在拖后腿？检测花了多久？响应花了多久？定位花了多久？恢复花了多久？不拆开看，优化就无从下手。 这篇文章拆解我在某出行项目和某电商项目中实战验证的 MTTR 优化体系——四层防御模型：检测层、响应层、定位层、恢复层。每层有具体的工程手段和度量指标，不是空谈方法论。最终效果：核心服务 MTTR 从 40 分钟降到 8 分钟，故障定位时间从 30 分钟降到 5 分钟。 MTTR 拆解：你优化的是哪个环节 很多人把 MTTR 当成一个整体来优化，这是错的。MTTR 至少要拆成四个阶段： 阶段 全称 含义 典型耗时 优化重点 MTTD Mean Time To Detect 从故障发生到告警触发 1-5 min 监控覆盖、SLO 告警 MTTA Mean Time To Acknowledge 从告警触发到有人开始处理 2-10 min On-Call 机制、告警路由 MTTI Mean Time To Identify 从开始处理到定位根因 10-30 min 可观测性、诊断工具 MTTR Mean Time To Restore 从定位根因到服务恢复 1-5 min 回滚、自愈、预案 注意 MTTR 有两种常见解读：Repair（修复）和 Recovery（恢复）。SRE 语境下我更推荐用 Recovery——目标是恢复服务而非彻底修复 Bug。彻底修复是 Postmortem 之后的事（相关文章：故障复盘改进项跟踪）。...