最近各家服务崩的此起彼伏，到底是不是跟裁员有关？

[Fcsle]

阿里云，滴滴，七牛，美团？。。。。接下来会不会更多。 所以是不是降本增效进入深水区了。。。

而且最近 b 站也总是给推荐 “怎么降低代码可读性”、“怎样跟自己代码附魔”.......

[archxm]

@likooo125802023 百度还在用 gcc3 么

[BUHeF254Lpd1MH06]

虽然但是，事故总是暂时的，今天修复了未来基本上可以确保风险会越来越低。资本家也是会算账的，裁员带来的的这种风险，也一定是在他们心理预期之内。很多人喊着开源节流徒增笑耳，实际上也只是好不容易抓到机会了嘲讽一番。

[SantinoSong]

@reoah2 #2 降本增效把做技术的给优化了，降了个鸡毛。。。

[aleimu]

开猿节流, 降本增笑, 稳中向好

[iovekkk]

@brader #29 据说之前语雀那次事件，因为无法直接回滚，恢复数据是靠查日志手动一点点恢复的

[brader]

@iovekkk 太惨了

[shicang1990]

@bellymars 地主和资本家都是给钱干活，奴隶主才是现在的老板写照

[zengguibo]

@likooo125802023 不升级哪来的 kpi ，大厂的就是要没事找事，没活找活，不然你年终总结都没东西写

[whp1473]

如果是非常熟悉的，按照大厂的情况，哪怕出事故 30 分钟内也能够处理完成。如果几个小时，甚至十几个小时，肯定是不熟悉或者知道一部分的人接手，然后找各个参与过一些的人问，问着问着发现这个离职了，那个知道点，然后再和代码、日志核对，拿不准尝试修复，因为有些代码细节不了解，比如某个 if 可能是处理历史遗留问题数据的，没处理，又炸了，反复几次好不容易修好。

[bt7vip]

集群系统升级、迁移是一个极其复杂的过程，牵扯到各各部门，不可能完美配合，降本和 ppt 管理把本就脆弱的运维系统搞崩，也是很正常的

[okaysir]

复杂度提升导致易崩溃度上升， 代码/运维等等层面都在堆积屎山，要么跺脚重构(重新从开始堆小粪球)，要么继续缝缝补补，裁员可能是导火索。

[cdlnls]

其实我觉得说 服务崩 和 开猿节流/降本增效 有关，调侃的成份要多一点 (并不是说没有关系，只是没有那么大)。
事故不管怎样都会发生，说 100%避免也不太现实，出不出事故和 是谁处理 / 多少成本 都没有必然的联系， 人 / 机器 都可能会出错，这个是没法完全避免的。而且就算没有裁员，也会有人主动离职，始终会有人离开和加入，想要人员不变动，也不现实，再说，人员即使不变动，服务也不可能 100%稳定。

[duluosheng]

绝对有关，离职交接其实是一笔烂账。有时候你会发现，一些小的功能，看起来不是很重要，但是离职交接没人管，可能就会出大事。最近在公司内部碰到离职交接后，无人看护的服务。

[zzerd]

可能是迁移系统？不想被拆不得搞个 kpi 出来

[x2ve]

我觉得是有关系的，楼上有人说了 经常裁员 势必会引起自保，那就是代码和人有一个能跑的心态。另外，从 0 到 1 的人优化了，交接可不会从 0 到 1 ，这中间的坑小还好说，大了就容易出事。

[lstz]

如果老板天天对你说，你工作有一点不好我就炒你鱿鱼，不仅十足的 intimidating ，还时常在所有人面前 call you out ，你绝对做不好工作。

就算能做好手头的工作，你对下一年是否还在这家公司都存疑，肯定优先考虑跳槽而不是把活干的更棒更稳定

[levelworm]

@likooo125802023 多半是搞安全的扫到了，这个版本可能有重大漏洞所以必须升级

[xinghen57]

有没有可能是国产化？

[littlecreek]

肯定有关系, 系统稳定性是个长期工程, 背后涉及到高可用, 容灾架构, 涉及到代码可读性, 可维护性, 涉及到测试是否覆盖全面, 涉及到变更的时候的流程和规划.....都是些吃力不讨好的东西

如果一个公司天天阴云密布, 员工不知道自己能待到啥时候, 肯定首先自保. 工作的优先级都变了

[magicyao]

每一个变动都会导致出问题的概率提升一点点，然后归于平静。
大规模裁员就导致这个问题概率骤然提升，所以有问题的通常不是裁掉了某个人，而是大规模的裁员导致的连锁反应。
不过这只是概率问题，真正展现颓势的还是出了问题后的处理速度，这里裁员的影响力才是最大的。