研發哲學第五條：一定要有後備方案
鄭昀 20181109
#哲學 #災備 #devop
過去的九月和十月，厄運接踵而至：
大大小小連續幾次事故。
阿里雲華北機房網路抖動。
網某銀行支付通道抖動。
銀聯支付通道抖動。
某IDC機房出網流量丟包嚴重長達幾十分鐘。
我冷眼旁觀
我們第一時間不能確認到底是什麼故障，
近期沒有版本釋出，
資料庫/RDS沒有慢查，
所有應用正常，
各個機房的出入流量並無大的起伏，
我們甚至不能第一時間明確異地雙活的哪一個機房才是正常的，
從釘釘群裡聽上去全國都有問題（其實只是某個機房概率性網路問題），
以至於無法下決定切換多活機房流量。
結合研發哲學第三條：『這個世界沒有什麼救世主』，
我們終於深刻地認識到研發哲學第五條：
『一定要有後備方案。』
是的，只有你自己能救自己。
如果只有一個機房，即使是阿里雲，也必死無疑。
如果只有一個支付通道，必死無疑。
如果只有一條線路，必死無疑。
事實一再證明我在2017年就未雨綢繆地指出如下事實是何等英明（XD）：
『
分散式系統的維護者總會反覆問自己：
我們的系統什麼情況下會掛？假如機房掛了怎麼辦？假如一個城市停電了怎麼辦（洪水，海嘯，地震，滑坡，……）？業務高峰期怎麼降低災難影響？
所以，很多網際網路公司都會在多個城市同時支撐商戶和使用者交易，並且能做到在一個城市所有機房癱瘓的情況下，能夠在幾分鐘內恢復（或者繼續新的）所有的交易。
小朋友會問，機房真的會掛嗎？
請先閱讀一下我寫的《 ofollow,noindex">經歷不可抗力是一種什麼體驗 》，瞭解一下什麼是 too young too naive。
然後我們再來回顧一下：
A，2017年1月，公有云 UCloud 公司正在開年會，結果在他們北京B可用區的資料中心外3公里處，架空光纜線杆因卡車撞倒導致光纜斷裂，工程師在年會現場緊急處理。
B，2015年6月21日上午9點到10點之間，一些使用阿里雲香港資料中心的使用者發現服務出了問題，此後阿里雲公告稱由於運營商電力問題造成香港機房故障。因為供電系統故障導致資料中心大樓整體斷電，並觸發消防報警。根據當地的消防規定，必須徹底排查隱患並完全消除後，才能獲准進場做電力搶修。直至當晚21點22分機房正式恢復穩定供電，阿里雲立即執行既定預案逐項恢復服務，21點32分安全防護服務恢復正常，各項服務陸續恢復，截至23點39分全部服務恢復。
C，2015年9月1日，阿里雲官方釋出致歉公告，稱“因雲盾安騎士server元件的惡意檔案查殺功能升級觸發了bug，導致部分伺服器的少量可執行檔案被誤隔離”，但造成影響無法估量。
D，2016年7月6日，上午10點22分，阿里雲華北2地域可用區A由於網路裝置出現異常，導致部分產品訪問受到影響。故障持續約1小時。
E，2016年10月11日，下午16點40分，阿里雲華東一區部分伺服器故障，導致網路上部分網站無法執行。
F，2018年6月27日，阿里雲工程師團隊在上線一個自動化運維新功能中，執行了一項變更驗證操作。這一功能在測試環境驗證中並未發生問題，上線到自動化運維繫統後，觸發了一個未知程式碼bug。錯誤程式碼禁用了部分內部IP，導致部分產品訪問鏈路不通，進一步導致一些客戶訪問阿里雲官網控制檯和使用部分產品功能出現問題。
災難，總是在你意料之外。
所以對於技術高階幹部來說，必須回答這個問題：如果單機房物理不可訪問，你怎麼辦？
』
是的，你得給自己一個災備通道，
一個後備方案，
最後一條讓你起死回生的路。
p,s,:
雲縱/禧雲的研發哲學
鄭昀 創建於2015/2/27 最後更新於2015/3/25
關鍵詞： 哲學、規則、套路、傳承
提綱：
-
Don't make me think
-
If it hurts, do it more and often
-
這個世界從來沒有什麼救世主
-
沒有苦勞，只有功勞
一，Don't make me think
大家都知道，技術人員從事的是創造性工作，加之是單核處理器，我們的上下文切換非常困難，被打斷後從新進入“神遊”狀態往往需要十幾分鍾。尤其是研發經理，承擔更多的責任，線上線下的問題都要照顧到，還要解答內外的各種諮詢，工作時間碎片化嚴重。我們（包括系統）給出的資訊，一定要足夠簡練，一目瞭然，讓人很容易克服焦躁情緒，啪啪地就處理了，或者啪啪地二次分發出去。 不要讓無用的資訊折磨這些人。
其次，技術人員是“世界”的構建者，不得不做大量瑣碎且枯燥的工作，其中，相當大比例的工作是重複性的，如修改配置檔案適配不同環境，如打包。
重複的工作一方面容易出錯，尤其是在通宵上線時，另一方面消磨人的耐心和鬥志。 我在《職場培訓第五期：職場的真相》中講過解題思路：『 要摒棄單純依靠員工之間互相提醒、依靠個人認真細緻來規避相同錯誤的固有思路，鐵打營盤流水兵，靠人終歸是靠不住的，最好靠遵循規則的機器 』。
王淮在《以 Facebook 為案例剖析科技公司應有的工具文化》一文中談及，基本理念就是 凡是被很多人不斷重複的好習慣，要將其自動化，繫結到工具之中，以"Don't make me think"的方式來推廣最佳實踐（best practice） 。
基於以上原因，我們認為， 凡是被不斷重複的過程，將其工具化，繫結到自動化流程之中，減少不必要的心智負擔 。
這也就是過去幾年裡我們一季季地推進持續整合（Continuous Integration，CI）的原因，把我們的經驗教訓變成可重複的規則，融入工具中，融入自動化流程中，而不是一代一代口口相傳。
好了，在舉具體的例子之前，讓我們大聲讀出這幾條 Slogan：
-
Don't make me think!
-
減少不必要的心智負擔！
例項一：
Exception 日誌分析郵件是我們非常重要的工具，是我們的寶貴財富。每天凌晨 Python 指令碼定時分析各個工程的 Exception 日誌，按異常型別歸類，用郵件 Push 到研發經理桌面上，它充分體現了我們的哲學： 自動化是王道。
但如果看到郵件內容後，研發經理仍需要費一番功夫才能搞明白這是什麼異常，而我們往往沒有足夠的時間，我們就會嫌麻煩，就會下意識地放過這個 Exception，甚至不再看日誌分析郵件和報警郵件，那麼“Exception 日清日結”就會淪為一句空話，等攢到每天數以千計 Exception 時已經失去了清理的慾望。
我們都知道，電商的購買流程每增加一個互動環節，就多了一道門檻，使用者最終成單轉化率=流量入口UV數×步驟1轉化率×步驟2轉化率×步驟三轉化率×……，同樣道理，我們要儘量把條理清晰、一目瞭然的報警郵件和 Exception 日誌分析郵件推到大家面前， 操作越少越好，我是在幫你，不是給你找麻煩。
例項二：
Yahoo! 的 Combo Handler 的出現就符合本哲學，阿里還因此出了一款外掛 nginx_concat_module。前端工程師可以釋出便於閱讀的原版 JavaScript 和 CSS 檔案，只要模板檔案裡做一個特殊宣告，多個檔案就能通過伺服器端的外掛合併且壓縮，配好之後從此不需要再考慮 Minimize HTTP Requests、壓縮和混淆了。
例項三：
頁面上所引用的 CSS 背景圖片可能需要做到 CSS Sprite 圖裡，然後在 CSS 裡寫偏移量，每增加一個 CSS 背景圖片，這些操作都要來一遍。
也許這是不必要的心智負擔，因為機器可以自動做。假如我們引入 Gulp，就可以自顧自地在指定 folder 裡放一張張 CSS 背景圖片，CSS 裡寫好宣告，然後讓 Gulp 這個前端構建工具自己把 folder 下的背景圖片合併為一張大的 CSS Sprite 圖片，並且它自己修改 CSS 裡的背景圖片地址和偏移量宣告，不需要為此每次費心費力。
二，If it hurts, do it more and often
我們不能死於聽天由命和漫不經心。
工程師為什麼會聽天由命？
-
因為線上日誌裡的異常實在是太多了，處理不過來。
-
因為異常太多了，淹沒了致命異常，以至於服務掛得死死的才發現問題已經存在N久了。
-
因為明天就要提測了，程式碼合併衝突還有幾千個。
-
每到常規版本提測時就心裡打鼓，合併個程式碼都得預留兩天時間。
-
因為畫時序圖好煩，所以複雜系統的資料流轉靠“心算”、靠文字描述。
-
人腦容易有思維死角，一個考慮不到，系統就防不住併發提交和重複提交。
-
……
因為已然集腋成裘，所以做事前我們各種糾結和牴觸，於是找各種理由拖延。
怎麼辦？
我在《職業化的7個細節》裡講到， 如果一件事做起來很煩，那就把它拆成很多塊兒，每天做一點，每次做一點。
例項一：
以程式碼合併為例，如果每天早上到公司後，從開發主線合到自己的私有分支上，每天都做，那麼等你向測試分支提測時，合併衝突是不是就少很多？
例項二：
如果你覺得畫時序圖（或泳道圖）麻煩，要麼是你不會用 visio，要麼是你想不清楚呼叫時序。你應該立即從手頭的功能開始畫時序圖，多練習，以後畫時序圖、業務流程圖只是分分鐘的事兒。用 excel 也能做泳道圖啊。
很多工程師覺得寫設計文件好煩，不開設計評審會的話就不寫。我是這麼做的：
-
我動手做一個系統，肯定已經大致想清楚了物件的定義、大致的設計模式；
-
也就有了一大堆的類檔案（空的）以及目錄結構；
-
每個類檔案我都先寫類功能定義、處理流程、資料型別定義，blabla 一大堆註釋。反正寫程式碼之前也得想明白這些事兒，那就直接寫成註釋；
-
最後，把這些註釋摘出來，配上各種圖，一篇設計文件就搞定了。
所以我從來不會為寫概要設計和詳細設計煩心。
三，這個世界從來沒有什麼救世主
這個哲學我過去幾年裡一而再再而三地講。在《職業培訓第五期：職場的真相》中，我說：過去幾年裡，我們深深地體會到，從來就沒有什麼救世主，要創造人類的幸福全靠我們自己，不要指望有什麼人能救我們，只能絞盡腦汁闖陣。
為什麼？
技術團隊是網際網路公司裡最認真最專業最實操最靠譜的一群人，如果我們凡事都要指望別人給我們解決方案和思路，指望別人比我們更認真，那這個公司就危在旦夕了。
所以，我在2012年的飛行研討會上丟擲兩個 Slogan：
-
拋掉幻想，勇敢面對！
-
直面白刃戰！
例項一：
飛行研討會上我說：
遇到問題，立刻跟進去Debug
——主管不能僅僅說一些似是而非的官話套話
——主管要投入白刃戰
————我黨向來是副職打仗下到主攻第一線
————縱隊副司令到主攻師，副連長打仗帶尖刀排
——圍觀不能救中國
主管都不出手，指望工程師救你啊？
例項二：
對歷史因果關係、系統呼叫、業務邏輯和資料流轉，甚至系統裡的髒資料，最瞭解的人莫過於我們。怎麼可能指望上游部門有一個人橫空出世，洞悉所有細節，告訴我們該如何設計和實施呢？
是你的終歸是你的，躲不過去的。
基於這個哲學，我們衍生出兩個 Slogan：
-
不要等死！
-
向前邁半步對接！
四，沒有苦勞，只有功勞
早年間，侯小強曾經說過： 如果你在職場，需要有三個好習慣，1，能馬上做的事情馬上做。2，每個事情要有始有終。3，要有這個習慣思維，沒有苦勞，只有功勞。但如果沒有極其努力，通常也不會有功勞。
延續著這個思維，我們過去幾年裡反覆強調： 沒有結果就沒有意義 。不要期望公司因為你和小夥伴們有苦勞而寬容你們沒有產出，這是一個商業公司。
例項一：
一些內部研發課題，由於不像主站那樣直面消費者的壓力，所以工程師會做得不夠商業。就算功能 okay 了，但總缺少一股精細範兒， 讓我們這些老手渾身難受，遲遲不能投入商業應用。這就屬於典型的“沒有結果”，沒有在指定時間到達指定戰場。
例項二：
以下幾個徵兆會被我判定為“只有苦勞，沒有功勞”：
-
如果沒有結合前面幾個哲學，沒有定期審視自己的工作，沒有找出痛點並用工具解決痛點，而是低水平重複再重複。累是很累，加班也加了。
-
同樣的錯誤一而再再而三地犯，技術團隊因此忙於四處救火，料理髒資料。
以上就是我這四年來總結的研發哲學。我認為，我們團隊應該把這些理念結結實實地變成新老員工的“本能”，用哲學來指導我們的行事方式，保證不管我們換了多少人，始終能前後一致。對現代中國曾經有一個說法“每隔十年亂一次”，Why？大抵是十年後掌權的那幫人，不記得十年前發生過什麼，傳承都丟了，躊躇滿志，滿懷熱情再錯一遍。我吐。
-over-
歡迎訂閱我的微信訂閱號『老兵筆記』，請掃描二維碼關注：
