如何看待2023年年底，阿里云、滴滴打车、腾讯视频等大厂平台相继发生崩溃故障？

如何看待2023年年底，阿里云、滴滴打车、腾讯视频等大厂平台相继发生崩溃故障？

十年互联网大厂从业者，利益相关（前腾讯校招生，前阿里产品，前滴滴产品负责人）来回答一下。
是这样的，我惊讶的不是它们崩溃了，而是它们现在才崩溃。
因为在大厂里面，根本没有人在意这些底层运维任务。
大家都在卷PPT，卷新的项目，卷出成绩的事情。
运维是一个上限较低、下限高的领域，在这个方面，万年无事才是最高的功劳。
正所谓“善战者无赫赫之功”。
但是在领导眼里，万年无事？那要你何用啊？
年终奖，绩效，肯定是给那些在一线开疆扩土的新项目组负责人呀。
长此以往，但凡有能力的，谁还会在大厂里干运维呢？
肯定都跳槽去系统众多缺陷、风控还不完善的的初创公司和业务，做从0到1的事情，更能凸显自己的重要性啦。
那你会说了，难道就没有大牛留下来吗？
有，但是人的天性是会有惰性的。
就好像我们在高速路上开车，长时间保持100公里以上的时速，假设没有别的车，那人很快就会犯困，判断力下降。
运维也是一样——长期无事故，大家会把精力转移到自己的生活上，晋升上，老婆孩子热炕头不香嘛？
归根结底，运维是一个负反馈占主导地位的领域，但是我们又要求不能出现负反馈。
也就是说，这个工作领域的激励扳机是和水平高低成反比的：
干得越好的人，他的成绩中越难出现体现成绩的「负反馈」事件——此乃“上限低”；
干的越差的人，他也不会有好的绩效，因为他的成绩中会充满无法被解决的「负反馈」事件——此乃“下限高”；
那么最后，剩下来的就是能循规蹈矩、当“三旨相公”的员工了——听领导的话，听前人的话，听下属的话。

《宋史·王圭传》：“以其上殿进呈，曰取圣旨；上可否讫，云领圣旨；退谕禀事者，曰已得圣旨也。”

但，现实生活是多变的，工作不会永远在既定的轨道上运行。
一旦有新的元素加入（比如这次滴滴的升级计划），那这种三旨相公类型的员工就解决不了问题了……
后果就是，呜呼哀哉，七八千万张10块钱打车优惠券发出去啦。

我这么说，你懂了吗？
点个赞再走吧～

利益相关：前阿里、字节程序员。
我们程序员还是有用的，很多资本家急着兔死狗烹，兔还没死呢，就急着吃狗肉了。
每天人力就分析某技术团队人力是不是冗余、分析一个老的高薪程序员能不能换成新的低薪程序员来降本增效。。。降本增效后的系统稳定性的锅还不是程序员来背？
现在到处都是技术无用论，是业务主导论、是渠道主导论、是用户体验主导论，一个公司副总二三十，技术出身的两三个，这种情况看起来正常却又后患无穷。
技术性bug大爆发，这也是偶然中的必然。
现在哪个公司哪个大团队一年不背一两个p0事故的，甚至有些公司在考虑修改p0、p1的定义了。。。在这种形势下，还对技术团队降本增效。。。
我把话撂这，现在大多数互联网产品才几年、十几年，随着时间的推移，等一些火爆项目的屎山代码堆积二十年、三十年、五十年之后，越大的项目爆雷的越多，因为它流量大、用户多，根本不可能重写，只能修修补补，一补几十年，不是灾难也是灾难。

崩了就崩了呗，感觉并没有让高层意识到裁人裁错了，裁一个中层他们肉疼，裁底层如行云流水，这种崩得多来点，越多越好，底层们抓住机会啊，显示自己价值的泼天富贵你们接住了吗？

以前在一次饭桌上，听父辈们聊职场的事儿，不过在场的都是老板再不济也是领导级别的，视角很有意思，给大家来说说。
其中一个叔叔讲了这么一件事，他开的小公司那年有段时间业绩很差，倒不是公司自己的问题，而是行业的问题，当时普遍不景气。办法嘛，文雅点就是开源节流，大白话就是裁员。
他想的是让二把手三把手负责裁员（背锅，外加上那段时间他在附庸风雅到大城市学什么MBA），虽然说让其他人负责裁员，但大概裁谁，他心里是门儿清的，新照进来的苦力实习的底层肯定基本都得收拾东西走人，老员工裁一部分，小领导里面裁一个（据说这人得罪了他）。
实习的那部分员工，本身就是一块海绵里的水，干最底层的活儿，打着学习的名义，但公司和他们双方都知道，真学会了本来也该跑了，毕竟公司一个萝卜一个坑。公司业绩好的时候打打杂，不好的时候肯定首当其冲得卷铺盖走人。
老员工里裁一部分，这个叔叔的意思是肯定是裁干活不利索的。
小领导里面那个，我敢说除非那段时间业绩特别好，不然的话即使业绩平平他迟早也得走人。
但裁员的结果很有意思：那个小领导走人了，实习生也都按照计划走人了，但是，老员工里出了问题，没有按照我这个叔叔的预期来：好几个他认识而且觉得干活利索的被裁了，而有几个老油条， 留在了公司。
他心里门儿清，但对这事儿什么也没说。事实上，后来公司业绩回暖订单多的时候，我这个叔叔还专门打了感情牌又把那几个被裁但是干活好的老员工又挖回来了一部分。
懂职场的看到这儿大概就明白了，不明白的我来解释下吧：

• 负责决策的大领导其实对真实情况是有了解的
  
• 但决策和执行在层层架构的企业中错位也是常见的
  
• 裁员别说目的是什么，但肯定会和站队斗争挂钩
  
• 最苦逼的是真正干活的，干活的往往没空和“关系”这事儿有密切互动，吃亏就吃亏在这里
  
• 当企业只通过裁员来解决问题的时候，往往裁员会被执行成“目的”，而非手段
  
• 小企业胜在灵活，裁员出岔子也能调头，但大企业的大会放大一切问题
  

所以再回过头来看大厂的这些问题，也就很好理解了，职场没有什么新鲜事儿。

大型互联网应用基本可以认为就是一个熵增理论的最好例子
太复杂了 高度依赖运维
你以为看上去很稳定的一个系统 可能需要每个礼拜一跑一个脚本清一清数据，每个礼拜二再跑个脚本检查各个依赖，每个礼拜三再跑个别的什么脚本检查别的什么东西，每个月再定期更新乱七八糟依赖
然后降本了 故意的也可能无意的也可能 离职时候忘了交接一个运维的任务，或者交接的不清楚， 然后某个脚本没有跑，某个地方存储炸了，某个地方依赖过期了，导致连不上另外一个依赖，然后系统崩了
崩了之后重启还不一定有用，缓存没预热，系统没做好fail fast的处理，突如其来的海量请求直接往数据库压，然后数据库就死给你看，然后再尝试重启，再挂，这时候再想着给数据库做纵向升级，基本半天过去了
表面看上去固若金汤的系统，背后可能都是草台班子
别问我咋知道这么多，作为Azure MySQL的PM，负责的还是Maintenance的feature，看了太多客户的和我们自己的事故报告了。。。
<hr/>补充聊一下评论区非常热的两个点

• 自动跑这些脚本
  
  
  
  • 大家有没有想过，这些脚本，可能本来就是某些自动化任务的产物，然后啥时候跑这个脚本，有时候理由说出来挺搞笑的，可能是为了某个feature去清理数据，但是又有可能影响生产，最后发现每周某一天这个feature用量比较少，就去跑一下这个脚本，跑之前检查下相关telemetry
    
  • 还有些脚本，最常见了，出了个bug, 但是修bug又要排期，只好短期用个脚本workaround一下，发现这个workaround挺好，那这个bug就不修了吧，久而久之，这脚本就在那儿了
    
  
  
• 离职交接不够仔细
  
  
  
  • 很多人觉得离职时候是一堆paper work签一下，我知道你有这些脚本了就ok了，但是问题在于，光知道了还不够，好一点的人会告诉你，为什么会有这个脚本，一般人就告诉你，什么情况下，跑哪个脚本，就ok了，没有演练，交接结束，等到出问题的时候，新人第一次跑这个脚本，嘎了，发现这脚本咋还重启机器啊？然后全部完蛋
    
  
  

上面这些都是大家摸鱼这么多年面对运维可能看到过的场景，草台班子确实很草台班子，但是没办法，这就是大型互联网应用的命，熵增不可避免
另外非常有趣的一件事，对于工具类，系统类应用（比如Oracle数据库，Visual Studio, 甚至于各种库），他们也有一堆屎山，但是这类应用出问题的概率小很多，因为这些应用实际上不是运维在守着，而是茫茫多Unit Test在守着，互联网应用由于要快速迭代，Unit Test数量显而易见是不如这些工具类系统类应用的。
<hr/>补充一个非常黑色幽默的彩蛋：刚刚阿里云的电销打电话给我来推荐阿里云套餐附带各种折扣了