從降本增笑，到真的降本增效 - 虎嗅網#
#Omnivore
Highlights#
複雜度是一種成本，因而簡單性應該是構建系統時的一個關鍵目標。 ⤴️ ^571189de
“智力功率” 則是另一個重要的問題。智力功率很難在空間上累加 —— 團隊的智力功率往往取決於最資深幾個靈魂人物的水平以及他們的溝通成本。比如，當資料庫出現問題時需要資料庫專家來解決；當 Kubernetes 出現問題時需要 K8S 專家來看問題；
然而，當你把資料庫放入 Kubernetes 時，單獨的資料庫專家和 K8S 專家的智力帶寬是很難疊加的 —— 你需要一個雙料專家才能解決問題。認證服務和對象存儲循環依賴也同理 —— 你需要同時熟悉兩者的工程師。使用兩個獨立專家不是不可以，但他們之間的協同增益很容易就會被平方增長的溝通成本拉低到負收益，故障時人一多就變傻就是這個道理。 ⤴️ ^8a2f1e42
但組織的默會知識隨著老司機離開而流失，流失到一定程度後，這個系統就已經是期貨死人了 —— 只差某一個契機被推倒引爆。 ⤴️ ^1ec94f76
** 第三點是管理理念與洞察力。** 比如，穩定性建設需要投入一千萬，總會有機會主義的草台班子跳出來說：我們只要五百萬或者更少 —— 然後可能什麼都不做，就賭不會出現問題，賭贏了就白賺，賭輸了就走人。但也有可能，這個團隊有真本事用技術降低成本，可是又有多少坐在領導位置上的人有足夠的洞察力可以真正分辨這一點呢？ ⤴️ ^d92fc421
這不就是狼與香辛料裡面的那個商人說的什麼東西好賣，其實是瞎說的，但是押中了就能分钱，沒中又沒有成本
沒有安全感的問題 ⤴️ ^b97b5eb8
孟子曰：“君之視臣如手足，則臣視君如腹心；君之視臣如犬馬，則臣視君如國人；君之視臣如土芥，則臣視君如寇仇。” ⤴️ ^9aad170b
從降本增笑，到真的降本增效#
本文討論了互聯網大廠的降本增效問題，並指出了降本增笑的現象。作者認為，降本增效需要降低系統複雜度成本和增加管理效能。然而，很多公司在這兩個方面都做得不好，導致服務故障頻繁發生。文章呼籲互聯網平台進行有效監管，並提出了真正的降本增效的重要性。
・💡 降本增效需要降低系統複雜度成本和增加管理效能
・💡 複雜度成本是建立系統時需要考慮的關鍵目標
・💡 管理水平與理念低劣是導致降本增效失敗的原因之一
年底正是衝績效的時間，互聯網大廠大事故卻是一波接一波。硬生生把降本增效搞成了 “降本增笑” —— 這已經不僅僅是梗了，而是來自官方的自嘲。
雙十一剛過，阿里雲就出了打破行業紀錄的全球史詩級大翻車，然後開始了 11 月連環炸模式，在幾次小故障後，又來了一場雲資料庫管控面跨國倆小時大故障 —— 從月爆到周爆再到日爆。
但話音未落，滴滴又出現了一場超過 12 小時的大失效，資損幾個億 —— 替代品阿里旗下對高德打車直接爆單賺翻，堪稱失之桑榆，收之東隅。
我已經替裝死的阿里雲做過復盤了《我們能從阿里雲史詩級故障中學到什麼》：Auth 因為配置失當掛了，推測根因是 OSS/Auth 循環依賴，一改錯黑白名單就死鎖了。
滴滴的問題，據說是 Kubernetes 升級大翻車。這種驚人的恢復時長通常會與存儲 / 資料庫有關，合理推測根因是：不小心降級了 K8S master ，還一口氣跳了多個版本 —— 進而 etcd 中的元數據被污染，最後導致節點全都掛掉，而且無法快速回滾。
故障是難以避免的，無論是硬體缺陷，軟體 Bug，還是人為操作失誤，發生的概率都不可能降為零。然而可靠的系統應當具有容錯韌性 —— 能夠預料並應對這些故障，並將衝擊降低至最小程度，盡可能縮短整體失效時間。
不幸的是在這一點上，這些互聯網大廠的表現都遠遠有失水準 —— 至少實際表現與其聲稱的 “1 分鐘發現、5 分鐘處置、10 分鐘恢復” 相距甚遠。
降本增笑
** 根據海因法則，一起重大故障背後有著 29 次事故，300 次未遂事故以及數千條事故隱患。** 在民航行業如果出現類似的事情 —— 甚至不需要出現真正造成任何後果的事故，只是連續出現兩起事故徵候 —— 甚至都還不是事故，那麼可怕嚴厲的行業安全整頓馬上就會全面展開。
可靠性很重要，不僅僅是對於空中交管 / 飛行控制系統這類關鍵服務而言，我們也期望更多平凡的服務與應用能夠可靠地運行 —— 雲廠商的全局不可用故障幾乎等同於停電停水，出行平台宕機意味著交通運力網絡部分癱瘓，電商平台與支付工具的不可用則會導致收入和聲譽的巨大損失。
互聯網已經深入至我們生活的各個層面，然而針對互聯網平台的有效監管還沒有建立起來。行業領導者在面對危機時選擇躺屍裝死 —— 甚至都沒人出來做一個坦率的危機公關與故障復盤。沒有人來回答：這些故障為什麼會出現？它們還會繼續出現嗎？其他互聯網平台為此做了自糾自查了嗎？它們確認自己的備用方案依然有效了嗎？
這些問題的答案，我們不得而知。但可以確定的是，毫無節制堆積複雜度與大規模裁員的惡果開始顯現，服務故障失效會越來越頻繁以至於成為一種新常態 —— 誰都隨時可能會成為下一個惹人笑話的 “倒霉蛋”。想要擺脫這種暗淡的前景命運，我們需要的是真正的 “降本增效”。
降本增效
當故障出現時，都会经过一个感知问题 — 分析定位 — 解决处理的过程。所有的这些事情都需要系统的研发 / 运维人员投入脑力进行处理，而在这个过程中有一条基本经验法则：
处理故障的耗时 t = 系统与问题复杂度 W / 在线可用的智力功率 P
故障处理的优化的目标是尽可能缩短故障恢复时间 t ，例如阿里喜欢讲的 “1-5-10” 稳定性指标：1 分钟发现、5 分钟处置、10 分钟恢复，就是设置了一个时间硬指标。
在時間限制死的情況下，要麼降本，要麼增效。只不過，** 降本要降的不是人員成本，而是系統的複雜度成本；增效不是增加匯報的談資笑料，而是在線可用的智力功率與管理的有效性。** 很不幸的是，很多公司這兩件事都沒做好，活生生地把降本增效搞成了降本增笑。
降低複雜度成本
** 複雜度有著各種別名 —— 技術債，屎山代碼，泥潭沼澤，架構雜耍體操。** 症狀可能表現為：狀態空間激增、模塊間緊密耦合、糾結的依賴關係、不一致的命名和術語、解決性能問題的 Hack、需要繞開的特例等等。
== 複雜度是一種成本，因而簡單性應該是構建系統時的一個關鍵目標。== 然而很多技術團隊在制定方案時並不會將其納入考慮，反而是怎麼複雜怎麼來：能用幾個服務解決的任務，非要用微服務理念拆分成幾十個服務；沒多少機器，卻非要上一套 Kubernetes 玩彈性雜耍；單一關係型資料庫就能解決的任務，非要拆給幾種不同的組件或者倒騰個分佈式資料庫。
這些行為都會引入大量的額外複雜度 —— 即由具體實現中湧現，而非問題本身固有的複雜度。一個最典型的例子，就是許多公司不管需要不需要，都喜歡把什麼東西都往 K8S 上怼，etcd / Prometheus / CMDB / 資料庫，一旦出現問題就循環依賴大翻車，一次大掛就徹底起不來了。
再比如應該支付複雜度成本的地方，很多公司又不願意支付了：一個機房就放一個特大號 K8S ，而不是多個小集群灰度驗證，藍綠部署，滾動升級。一個版本一個版本的兼容性升級嫌麻煩，非要一次性跳幾個版本。
在畸形的工程師文化中，不少工程師都會以傻大黑粗的無聊規模與高空走鋼絲的架構雜耍為榮 —— 而這些折騰出來欠下的技術債，都会在故障的時候變為業報回來算帳的。
==“智力功率” 則是另一個重要的問題。智力功率很難在空間上累加 —— 團隊的智力功率往往取決於最資深幾個靈魂人物的水平以及他們的溝通成本。比如，當資料庫出現問題時需要資料庫專家來解決；當 Kubernetes 出現問題時需要 K8S 專家來看問題；==
== 然而，當你把資料庫放入 Kubernetes 時，單獨的資料庫專家和 K8S 專家的智力帶寬是很難疊加的 —— 你需要一個雙料專家才能解決問題。認證服務和對象存儲循環依賴也同理 —— 你需要同時熟悉兩者的工程師。==
當系統的複雜度成本超出團隊的智力功率時，就很容易出現翻車性的災難。然而，這一點在平時很難看出來：因為調試分析解決一個出問題的服務的複雜度，遠遠高於將服務拉起運行的複雜度。平時好像這裡裁兩個人，那裡裁三個，系統還是能正常跑的嘛。
== 但組織的默會知識隨著老司機離開而流失，流失到一定程度後，這個系統就已經是期貨死人了 —— 只差某一個契機被推倒引爆。== 在廢墟之中，新一代的年輕嫩驴又逐漸變為老司機，隨即喪失性價比被開掉，並在上面的循環中不斷輪回。
增加管理效能
阿里雲和滴滴招不到足夠優秀的工程師嗎？並不是，而是其管理水平與理念低劣，用不好這些工程師。我自己在阿里工作過，也在探探這種北歐風格的創業公司和蘋果這樣的外企待過，對其中管理水平的差距深有體會。我可以舉幾個簡單的例子：
第一點是值班 OnCall，在 Apple 時，我們的團隊有十幾號人分布在三個時區：歐洲柏林，中國上海，美國加州，工作時間首尾銜接。每一個地方的工程師都有著完整處理各種問題的腦力功率，保證任一時刻都有在工作時間待命 OnCall 的能力，同時也不會影響各自的生活質量。
而在阿里時，OnCall 通常變成了研發需要兼任的職責，24 小時隨時可能有驚喜，即使是半夜告警轟炸也屢見不鮮。在真正可以砸人砸資源解決問題的地方，反而又吝嗇起來：等研發睡眼惺忪爬起來打開電腦連上 VPN，可能已經過去好幾分鐘了。
** 第二點是體系建設。** 比如，從故障處理的報告看，核心基礎設施服務變更如果沒測試，沒監控，沒告警，沒校驗，沒灰度，沒回滾，架構循環依賴沒過腦袋，那確實配得上草台班子的稱號。還是說一個具體的例子：監控系統。設計良好的監控系統可以極大縮短故障的判定時間 —— 這種本質上是對伺服器指標 / 日誌提前進行了數據分析，而這一部分往往是最需要直覺、靈感與洞察力，最耗費時間的步驟。
定位不到根因這件事，就是反映出可觀測性建設和故障預案不到位。拿資料庫舉個例子吧，我做 PostgreSQL DBA 的時候做了這個監控系統，如左圖，幾十個 Dashboard 緊密組織，任何 PG 故障用鼠標點點下鑽兩三層，1 分鐘不用就能立即定位各種問題，然後迅速按照預案處理恢復。
再看一下阿里雲 RDS for PostgreSQL 與 PolarDB 雲資料庫用的監控系統，所有的東西就這可憐巴巴的一頁圖，如果他們是拿這個玩意來分析定位故障，那也怪不得別人要幾十分鐘了。
== 第三點是管理理念與洞察力。==== 比如，穩定性建設需要投入一千萬，總會有機會主義的草台班子跳出來說：我們只要五百萬或者更少 —— 然後可能什麼都不做，就賭不會出現問題，賭贏了就白賺，賭輸了就走人。但也有可能，這個團隊有真本事用技術降低成本，可是又有多少坐在領導位置上的人有足夠的洞察力可以真正分辨這一點呢？==
再比如，高級的故障經驗對於工程師和公司來說其實是一筆非常寶貴的財富 —— 這是用真金白銀喂出來的教訓。然而很多管理者出了問題第一時間想到的就是要 “開個程序員 / 運維祭天”，把這筆財富白送給下家公司。這樣的環境自然而然就會產生甩鍋文化、不做不錯、苟且偷安的現象。
** 第四點是以人為本。** 以我自己為例，我在探探將自己作為 DBA 的資料庫管理工作幾乎全自動化了。我會做這件事的原因：首先是我自己能享受到技術進步帶來的紅利 —— 自動化自己的工作，我就可以有大把時間喝茶看報；公司也不會因為我搞自動化每天喝茶看報就把我開了，所以 == 沒有安全感的問題 ==，就可以自由探索，一個人搞出一整套完整的開源 RDS 出來。
但這樣的事在類似阿里這樣的環境中可能會發生嗎？ “今天最好的表現是明天最低的要求”，好的，你做了自動化對不對？結果工作時間不飽和，管理者就要找一些垃圾活或者垃圾會議給你填滿；更有甚者，你辛辛苦苦建立好了體系，把自己的不可替代性打掉了，立即面臨狡兔死走狗烹的結果，最後被寫 PPT 出嘴的人摘了桃子。那么最後的博弈優勢策略當然是能打出去單幹，能裝的坐在列車上搖晃身體假裝前進直到大翻車。
最可怕的是，本土大廠講究 “人都是可替換的螺絲釘”，是 35 歲就 “開採完” 的人礦，末位淘汰大裁員也不鮮見。如果 Job Security 成為迫在眉睫的問題，誰還能安下心來踏實做事呢？
== 孟子曰：“君之視臣如手足，則臣視君如腹心；君之視臣如犬馬，則臣視君如國人；君之視臣如土芥，則臣視君如寇仇。”==
這種落後的管理水平才是很多公司真正應該增效的地方。