@CEBBCAT 你这属于是 AI 用多了看啥都像 AI 我现在就可以把肯德基店长还有前同事的联系方式发给你，让你自己去查证。 但我早就不是意气用事的毛头小伙子了，不会为这种事给别人添不必要的麻烦。

这个只是 op 在的公司。我现在的公司就没有这个顾虑了，有问题，提出来，谁有时间，改就是了。 上次印象深刻，另外一个组找我们老大沟通一个东西，老大没问我们，就回复说可以那样干。结果人家组就这么干了，结果我 review 的时候，一看这样做就不对，拉个会 @讨论一下，领导上来就跟人道歉说他没想到这样做不行。结果别的组也说，没关系，没关系，改了就是了。 第二次也是他们组，我当时没跟他们细说，以为他们懂，ingress 加一行配置就行。结果他们组一个同事哼哧哼哧搞了半个月，用 spring 写了一个 http 代理转发，说白了就是个简单得 NGINX ，让我 review ，我哭笑不得。明明几分钟的事情，搞了半个月，结果在转发文件上传的请求时很不稳定，没办法，同事说框架的问题，解决不了。最后我给他们说具体的方案，他们恍然大悟，最后几行配置搞定。这里很明显我背锅，要是早说不至于浪费同事的时间，我也跟他们道歉了。 说到底，要是一个环境，没有年终奖，员工也不怕裁员（裁员了，失业津贴 100%发十个月），哪儿来这么多破事，说到底还不就是那个恶心人的绩效考核。

首先你这是跟肯德基两码事，肯德基那个是造成对客户不公平的结果 其次，你前端代人上线本来就是不对的，后端负责人不在也应该是他组内代理人去执行，上线没有小事

肯德基事件应该有标准处理的培训吧，没有的话不应该批评店员。

权限职责分离是对的；不要轻易回滚也是对的

我这边可以看到的，op 当年大概犯了以下几个错误，当然都和肯德基的例子没什么关系😂 1. 帮别人进行线上发布，我觉得最核心的不是答应帮别人发布，而是没有理解线上发布需要做什么事情，发布不是只点一个发布按钮就结束了，灰度、业务报警、客户反馈，这些需要时刻跟踪，发布版本的变更内容和可能造成的影响都得了然于胸。如果对发布有了这些认知，相信 op 也不会随随便便答应别人（还是不同业务线的人）的发布要求。 2. 线上紧急回滚需要谨慎，不能一键回滚，而是要当做发布来处理，灰度、监控报警观察等等一些系列操作都不能缺失，一把梭等于是在玩命，当然版本发布者的回滚风险评审确认也是必不可少。所以，也是为什么发布必须又核心开发者本人来执行，而不是找人代发。 顺便推荐下我写的一篇博客，https://jt26wzz.com/posts/0007-online-firefighting-real-world-lessions-from-4-years-on-call/

感谢分享经验，我见过好几次了，前端有时候，经常直接改我们后端的东西，以为很简单，不就一行代码嘛，为了省事，结果有时候还是出错，一查日志，结果发现前端改的。

刚入职场，领导教我第一个事情就是：遇到不确定的事情千万不要自己蒙头做，找你上级领导确认一下总没错。

@bernardkickass #10 很抱歉给你造成困扰，原因是字里行间和以往读过的文字不太像，却和 LLM 润色过的文章缥缈之处有些神似。看来阁下的行文错别字很少了，感谢分享真实故事👍

这种事情基本上小公司的日常了，小公司出问题基本不回滚，直接等服务端修复完再重开服务。