工作中，对于本分以外的要求，越是举手之劳，越要学会拒绝

刚下班去吃了个肯德基，听到店长在训斥店员，听了下，事情经过大概是这样的：

有顾客嫌冰淇淋太少（实际上是标准量，并没有少），要求店员多打一圈。 虽然这样做违反规定，但店员觉得多给一点没什么，就照做了，也没有征求店长的许可。 店长在例行查看监控录像时发现问题，找店员去对峙，于是发生了我看到的一幕。

店员小姑娘很委屈：就为一点冰淇淋至于么，能值多少钱？就当我请那位顾客的了，你从我工资里扣吧。

店长更生气了：你以为我在心疼那点冰淇淋的钱？这是公平问题、信誉问题！ 顾客花多少钱，就应该给多少钱的货，一分不多一分不少。 你偏袒这位顾客，其他顾客看到了怎么想？要是被录下来投诉到总部，起码罚一万，也由你来赔么？ 到时候我们店被扣分，我这个店长可能都没得当，你跟我一起喝西北风去吧。

想到十年前我初进职场的时候，也曾因为不会拒绝而捅了篓子，而且情况要更加严重。

那天，后端负责人请了病假，但他那边有代码急着上线， 于是用钉钉让我在内网提交一下发版审批，他直接在钉钉上确认，就可以上线了。 他还补充说，代码已经 review 过，且合并到了稳定分支，可以放心发版。

本来这次发版只有后端的改动，和我这个前端切图仔没什么关系， 但我当时觉得这只是举手之劳，并没有考虑到潜在的后果，于是就照做了。

发版后不到一个小时，客服那边反馈说客户遇到了 bug ，而且是十几个客户遇到了相同的 bug 。 没办法，那就回滚吧。可当我提交了回滚的发版审批之后，后端负责人已经“失联”了（后来才知道他那时正在手术台上）。

这时客服又来催，说是有 VIP 客户的业务受到了这个 bug 的影响。 后端同事这时好像已经找到 bug 原因了，但只有他们的负责人有发版权限，他们也只能干瞪眼。

他们给我出了个（馊）主意：回滚审批的页面上有个“紧急发布”功能，可以越过审批人强制发布。 只需要写个小作文说明原因，然后由 SRE 同意即可发布。

我当时也是心急火燎，没有多想就申请了强制回滚。 SRE 那边问我，确定要回滚么？出事了你可要负责。 我迟疑了一下，但看着客服在催，后端负责人一直不回消息，其他后端同事觉得回滚没问题，于是就咬牙确认了。

于是灾难的一幕发生了：原本只是某个功能模块有 bug ，现在是整个服务不可用。 后端同事一拍脑袋，哎呀忘了，新版本执行了数据迁移，数据结构都变了，旧版本不仅跑不了还会导致数据损坏。 赶快回滚数据库到发版前的时刻。

可是回滚数据库的审批链条长得可怕，什么 DBA ，SRE ，甚至一堆人的 leader 都要参与审批。

我的这个审批工单还惊动了部门老大，他此时正在上海开会。 因为此次事故不得不中断会议，Zoom 过来协助解决问题。

他的第一句话就是，不要回滚数据库，发版后产生的所有数据一条也不能丢。除非你想让整个部门跟着消失。

后面的事就不用多说了。在服务完全中断的五个多小时后，所有损坏的数据均完成修复，新版本代码也成功上线。 后端负责人负此次事故的主要责任，case study 结束后就再也没见到过他，钉钉显示已离职。 我和一堆后端还有 QA 同事负次要责任，不仅要参与他们的 case study ，还要背最低绩效，年终奖归零。

因为这件事我在组里也一直抬不起头，过完年就直接提了离职。人生中的第一次也是唯一一次大厂工作经验就此落幕。

所以我想说的是，在工作中，对于那些本来不应该由自己做的事，哪怕这件事再简单， 看上去再无害（实际上你可能没有能力判断是否有风险），也不要不好意思拒绝。 至少要先请示一下自己的上级，有个人给你兜底。