前两天不是滴滴崩了吗，

那服务崩了你就赶快找人来修是吧，

害，内部IM也崩了...

那就赶紧电话联系运维远程修复啊，

害，vpn也崩了，连不上网啊...

那就赶紧让运维打个车来公司，

哎哎哎不是说了吗！

滴滴崩了，打不了车呀！

前有阿里云，后有滴滴，

为什么最近总有大厂服务崩溃？

而且一崩还是一整天！！！

如果用修楼房来类比软件开发，

那程序员就类比是建筑工人，

那楼修起来之后，

那建筑工人是不是就没用了呀？

那就有了辞退呗，

就有了降本增效、开源节流呗！

但是啊，

软件开发的模式更像是忒休斯之船，

在一艘航行的船上，

一边航行一边修复破损的地方，

如果每破损一个地方，

我们都换一个新的零件，

那等整艘船都修了一遍，

那这个船还是原来那艘船吗？

在往年互联网公司资金充裕的时候，

可以准备冗余的修复人员，

以及更好的修复材料，

那久而久之，

打渔船不也变成了游轮了吗。

但是呢，

现在降本增效就慢慢出现问题了。

一个在公司工作了十年的35岁的老程序员a

被公司裁了，

那这种一般在公司工作了

很长时间的老程序员

有很多原始代码都是他一个人维护的，

他还做了很多个人的小脚本，

就比如说定期清理下内存啊、

备份下数据啊、重启个服务什么的，

等裁员交接的时候A给交接人B说：

“这个事情很重要，你得定期做！

因为他牵扯到公司的什么什么什么”

那之后呢B也被裁员了，

准备交接给C的时候，B给C说，

“这个事情很重要，你得定期做，

因为...因为...说不出来！

反正你定期做就对了”，

后面C也被裁员了，

又需要交接给D的时候，

他又说，

“这个事情你得定期做，别问为什么，

我也不知道，反正就照着做就行了吧”

就这样一代接一代

一轮接一轮的，

久而久之，

这些大的互联网公司

崩不崩溃，

什么时候崩溃，

都只能说...看运气。

说到降本增效，

现在因为很多基础性的人员

不能直接带来利润，

于是动不动就裁员。

但是基础之所以是基础，

恰恰在于它的重要性，

不重视基础，

盲目降本增效，

类似情况只会越来越多！

按照目前降本增效的趋势看啊，

这服务器可能以后还得崩，

那怎么办呢？

滴滴的产品经理冥思苦想，

有了，既然线上的服务可能会崩，

那我们可以做线下的嘛，

让这些滴滴司机开着车，

在大街小巷到处晃，

哎，有客人要坐车的时候，

招招手，那这个车不就停下来了！

好主意！