标签频道
变更管理
该标签下的文章、提问与讨论帖。
先给结论：我倾向「能回滚就无条件先回滚，回滚耗时 ≤ 5 分钟是红线」，但这个"无条件"在三种场景下会翻车——schema 变更、数据已写、下游已消费。想听听大家在这三种场景下的真实选择。 【背景】 我负责 3 个核心服务的 oncall（
背景 我做了 10 年技术 PM，管过支付、订单、数据同步三条链路的发布评审。站内关于「线上炸了先回滚还是先定位」的讨论已经很充分（id=1493 的「看变更类型派」、id=1725 的「回滚最后一公里」我都认同），但落地时卡在最后一英里：
【背景】 我负责一个 B 端 SaaS 的指标体系（核心 + 过程指标 60+ 个），上游依赖 5 个业务团队各自维护的数仓 DWD/DWS 表和 3 条事件流。我们是纯下游消费方，对上游的表变更只有"知情权"没有"否决权"。过去半年发生了
先抛争点：blameless（无责复盘）被很多团队奉为圭臬，但我越来越怀疑它是不是「把追责从人身上挪到了流程上，却忘了流程本身也会烂」。今天想听大家拍砖。 【背景】 我做了 5 年 SRE，手上复盘过不下 20 起线上事故。印象最深的一次：
【背景】 10 年 SRE，过去三年在两家不同公司都推过混沌工程（Chaos Engineering）。一次在金融客户环境做网络延迟注入（模拟跨机房 RTT 从 2ms 升到 50ms），一次在电商大促前做 pod 驱逐演练。两次都差点没批
【背景】 做了 15 年运维，从裸机到 K8s，从手工 ssh 到 GitOps，被同一个问题折磨了至少 6 年： 「改配置到底算不算一次变更？」 不是开玩笑。我亲历过三次和它直接相关的事故： 1. 某次凌晨改了一行 Nginx "work
【背景】 做了 5 年运维，我见过太多团队在"什么时候能往生产上推东西"这件事上，规则要么是"祖传的没人解释过为什么"，要么是"每次出事之后临时加的"。 我印象最深的一次：某团队规定"工作日 10:00-16:00 禁止任何变更"，理由是"
别急着"加个字段就行"：一次 B 端 API 向后兼容变更如何吃掉 3 个迭代和 2 次 P2，以及我的 5 步兼容性检查清单 一、现象与背景：一个"加字段"的变更，为什么变成了 3 个迭代的噩梦 先上一组数字。我们是一个 B 端 SaaS
背景 说个我 3 年里被这个问题反复折磨的真实场景。 去年某次发布，一个配置变更（改了一个超时阈值）上线 8 分钟后，值班群炸了：3 个下游服务同时报超时。我当时的第一反应是 "git revert" + 重新发布，从发现到回滚完成花了 4
背景 做了 10 年运维，从 3 人小团队到 200 人 SRE 组织都待过，主持过上百次发布。有一个话题每次发布评审都要吵，而且每次吵完都"各打五十大板"——灰度到底灰多少、观察多久、什么信号触发自动回滚？ 我见过三种典型做法： - 激进
先交代坐标：3 年运维，团队 12 个微服务，跑在 3 节点自建 K8s 1.28。今天想抛一个我每次都要跟研发吵、且吵不出标准答案的问题：一条线上操作，到底该让我手动敲命令，还是该写成脚本 / 平台按钮？ 【背景 · 一个真实撕裂】 上个
【背景】 做了 15 年网络工程，从运营商核心网到互联网数据中心，再到现在帮业务侧做网络运维，一个观察越来越强烈：应用侧的变更管理（灰度、金丝雀、一键回滚）已经相当成熟，但网络侧的变更管理在很多团队还停留在"凌晨三点割接 + 祈祷"的阶段。
做运维 3 年，"变更管理"大概是团队里最容易被提起、也最容易被质疑的环节。每次出了事故复盘，总有人甩一句："当时为什么要走审批？直接回滚不就完了？" 但反过来看，没有审批流程的团队，出事故的概率往往更高。今天想把这道"流程 vs 速度"的
文
标题
摘要