前兩天不是滴滴崩了嗎，

那服務(wù)崩了你就趕快找人來修是吧，

害，內(nèi)部IM也崩了...

那就趕緊電話聯(lián)系運(yùn)維遠(yuǎn)程修復(fù)啊，

害，vpn也崩了，連不上網(wǎng)啊...

那就趕緊讓運(yùn)維打個車來公司，

哎哎哎不是說了嗎！

滴滴崩了，打不了車呀！

前有阿里云，后有滴滴，

為什么最近總有大廠服務(wù)崩潰？

而且一崩還是一整天?。?！

如果用修樓房來類比軟件開發(fā)，

那程序員就類比是建筑工人，

那樓修起來之后，

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

那就有了辭退唄，

就有了降本增效、開源節(jié)流唄！

但是啊，

軟件開發(fā)的模式更像是忒休斯之船，

在一艘航行的船上，

一邊航行一邊修復(fù)破損的地方，

如果每破損一個地方，

我們都換一個新的零件，

那等整艘船都修了一遍，

那這個船還是原來那艘船嗎？

在往年互聯(lián)網(wǎng)公司資金充裕的時候，

可以準(zhǔn)備冗余的修復(fù)人員，

以及更好的修復(fù)材料，

那久而久之，

打漁船不也變成了游輪了嗎。

但是呢，

現(xiàn)在降本增效就慢慢出現(xiàn)問題了。

一個在公司工作了十年的35歲的老程序員a

被公司裁了，

那這種一般在公司工作了

很長時間的老程序員

有很多原始代碼都是他一個人維護(hù)的，

他還做了很多個人的小腳本，

就比如說定期清理下內(nèi)存啊、

備份下數(shù)據(jù)啊、重啟個服務(wù)什么的，

等裁員交接的時候A給交接人B說：

“這個事情很重要，你得定期做！

因為他牽扯到公司的什么什么什么”

那之后呢B也被裁員了，

準(zhǔn)備交接給C的時候，B給C說，

“這個事情很重要，你得定期做，

因為...因為...說不出來！

反正你定期做就對了”，

后面C也被裁員了，

又需要交接給D的時候，

他又說，

“這個事情你得定期做，別問為什么，

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

就這樣一代接一代

一輪接一輪的，

久而久之，

這些大的互聯(lián)網(wǎng)公司

崩不崩潰，

什么時候崩潰，

都只能說...看運(yùn)氣。

說到降本增效，

現(xiàn)在因為很多基礎(chǔ)性的人員

不能直接帶來利潤，

于是動不動就裁員。

但是基礎(chǔ)之所以是基礎(chǔ)，

恰恰在于它的重要性，

不重視基礎(chǔ)，

盲目降本增效，

類似情況只會越來越多！

按照目前降本增效的趨勢看啊，

這服務(wù)器可能以后還得崩，

那怎么辦呢？

滴滴的產(chǎn)品經(jīng)理冥思苦想，

有了，既然線上的服務(wù)可能會崩，

那我們可以做線下的嘛，

讓這些滴滴司機(jī)開著車，

在大街小巷到處晃，

哎，有客人要坐車的時候，

招招手，那這個車不就停下來了！

好主意！