前段時間滴滴的故障相信大家都知道了。

中斷業務 12 小時定級為 P0 級故障一點都不冤。

故障回顧

網上有傳言是運維人員升級 k8s 時，本來計劃是從 1.12 版本升級到 1.20，但是操作失誤選錯了版本，操作了集群降級到低版本。

從下面滴滴技術的博客中也可以看到滴滴的升級方案：

滴滴為了降低升級成本，選擇了原地升級的方式。首先升級 master，然后升級 node。我們一起看一下 k8s 官方架構：

img

master(官網圖中叫 CONTROL PLANE) 節點由 3 個重要的組件組成:

cloud-controller-manager:負責容器編排;

kube-api-server:為 Node 節點提供 api 注冊服務；

scheduler：負責任務調度。

Node 節點向 kube-api-server 注冊成功后，才可以運行 Pod。從滴滴的博客中可以看到，采用原地升級的方式，升級了 master 之后，逐步升級 Node，Node 會有一個重新注冊的過程，不過既然選擇這個方案，運維人員應該反復演練過，重新注冊耗時應該非常短，用戶無感知。

但是 master 選錯版本發生降級時，會把 kube-api-server 污染，Node 節點注冊 master 失敗，又不能快速回滾，這樣 Node 節點被集群認為是非健康節點，上面的 pod 被 kill 掉，服務停止。

集群隔離

這次故障大家討論的話題還有一個比較熱門的就是 k8s 集群隔離，因為多個業務比如打車業務、單車業務同時掛，說明都在一個集群上，沒有單獨建集群來做隔離，這可能也是博客中說的“最大集群規模已經遠遠超出了社區推薦的5千個 node 上限”的原因。

當然也有可能當時野蠻生長的時候，為了快速上線開展業務，就多個業務建在了一個集群上，后來可能也有過拆分的想法，但發現業務上升空間已經很小，現有集群可以維持，所以就擱置了。

拆分成多個集群好處很明顯，業務隔離，故障隔離，可靠性增加，就拿這次升級來說，先升級一個不太關鍵、業務量也比較小的集群做試點，升級成功了再逐個升級其他集群。

但缺點也很明顯，運維復雜度增加，成本增加。

升級方案

工作這些年，也參與過一些大規模的平臺重構，但原地升級真的是沒有接觸過，主要原因就是架構師們不太愿意選擇原地升級的方案。而他們主要出于下面考慮：

業務系統原地重構升級，不像推翻重做能夠更徹底地升級改造；

考慮對業務影響最小，一般是要通過灰度發布漸進地把流量切過去；

替換升級的方案，更能展現團隊的產出。

對于滴滴這樣的大公司，相信運維團隊大咖如云，無論采用哪種方案，肯定都是經過反復驗證的，或許不要選錯版本，原地升級也沒有問題。

降本增效

看了微博上滴滴道歉的留言區，好多人猜測這次事故的原因是降本增效，裁掉了一線高成本的運維，保留了成本低的新人。

從數據上來看，出于降本增效的目的，滴滴這兩年確實少了很多人，但我不相信這是造成事故的直接原因。

在快速增長的階段，確實需要投入大量的技術人員來建設系統。但國內互聯網規模也基本見頂了，一個業務經營這么多年，不會再有爆發式地增長，系統也已經非常穩定。這樣的背景下，公司確實用不了這么多技術人員了，留下部分人員來維護就夠了。

所以，無論哪家公司，降本增效是業務穩定后必定會經歷的階段。想想滴滴這次 12 小時故障的損失，能比養 1000 個技術人員的成本高嗎？

對于我們研發人員，如果有機會進入快速增長的公司，那就抓住機會多掙錢，被裁員的時候平常心看待就可以了，想在一家公司干到退休太難了。同時也要看到自己給公司帶來的價值，千萬不要認為我們技術厲害就比那個 PPT 工程師更有價值。

總結

本文根據網上流傳的滴滴故障的原因，分析了升級方案和降本增效。

最后，又快年末了，希望大家都能維護好自己的系統，不要發生嚴重故障影響自己的年底考核。