創建於2019/4/28 最後更新於2020/4/16
關鍵詞：法則，規則，捷徑，災難，劫難
提綱：
- 人間法則零：手中無刀，但心中要有刀
- 人間法則一：捷徑充滿荊棘
- 人間法則二：儘早統一規格
- 人間法則三：災難錦囊
- 自建法則 法則長存
法則零：手中無刀，但你的心中要有刀
軟件工程和技術領域裏雖說法無定法，需求和流程隨便怎麼做都可以，但也並非可以天馬行空恣意妄爲，稍不留意就可能天塌地陷牆倒屋塌，釀成不可收拾之慘劇。下面我就說道說道。
2020年1月底2月初，首都醫科大學附屬復興醫院出現醫護人員感染新冠肺炎事件，最終累計確診34人，既有醫護也有患者和家屬，原因也非常“感人”：一位有武漢接觸史的老太太，本來屬於“新冠肺炎疑似病例”在發熱門診看病，但卻突發奇想，通過院領導的關係，託關係找心內科ICU主任韓某，愣是從防護森嚴的發熱門診病房轉進了雲淡風輕的心內科ICU，結果橫掃一片。
我一直說，工程師團隊和醫護團隊都是專業領域機構，管理方式有相似之處。那麼在這個案例裏，管理者犯了什麼錯誤？心中無原則！
心中無原則，會有一百萬種死法。
原則！專業團隊的管理者心中一定要有原則，你有了原則，才能要求大家“講政治，守規矩”！同樣，在做設計的時候，先把設計願景、設計分階段目標、設計原則寫下來，在此基礎上畫地爲牢再做設計推演，莫要天馬行空恣意妄爲。手中無刀，心中有刀。
法則一：捷徑充滿了荊棘
外行總覺得軟件開發有捷徑，有銀彈。還是那句話，有一百萬種死法等着您呢！
XDD
話說時間回到2019年12月20日，波音公司設計研製的載人飛船“星際客機（CST-100Starliner）”正要從卡納維拉爾角發射，執行它的第一次飛行測試任務。按照計劃，飛船將在這次無人試飛中將與國際空間站對接，爲宇航員送上聖誕禮物。但是就在與火箭分離後，飛船上的一個關鍵設備出現了異常，可以簡單理解爲飛船的一個時鐘錯誤，讓飛船誤以爲自己正處於提升近地點的變軌過程中。在預設程序裏，變軌是需要很高精度的姿態和軌道控制的，因此飛船的 48 臺姿軌控發動機開始瘋狂工作，在短時間內消耗了大量燃料。由於“星際客機”消耗了過多的燃料，與國際空間站的對接試驗不得不取消，原定於12月28日返回的飛船不得不提前到12月22日返回地球。
2020年2月28日，調研報告終於出來了，波音公司承認，星際客機軟件系統的程序存在嚴重缺陷。這份報告顯示，飛船和火箭助推器的時鐘不一致（運維同學可能會心一笑，這真的是非常經典的基礎維護錯誤），而飛船的 Mission Elapsed Timer 提前輪詢了火箭助推器的時間，從而提前開始了錯誤的計時並進入了錯誤的軌道。
這些明顯的錯誤完全可以被提前測試出來。於是調查小組對測試的流程進行了檢查。他們發現軟件測試走了捷徑：波音公司縮短了對該飛行器軟件的關鍵測試，他們將整個飛行過程分成了幾個小單元分別進行測試，但最後卻沒有做完整的、端到端的集成測試，即沒有進行時長爲 25 個小時的整體測試。
NASA 載人航天業務負責人道格·洛夫羅表示，波音公司的問題是“根本性的”和廣泛的“軟件過程故障”。波音的這種軟件質量控制，還不知道會導致系統中到底存在多少個 Bug，“到底只有這兩個還是會有幾百個”。
看到這裏，你會不會擦一擦頭上的汗欣喜道：幸好這只是無人飛船，而且還只是第一次執行飛行任務而已，有則改之，無則加勉嘛。
更可怕的還在後面呢。
彭博社曾指出：波音 737 MAX 把軟件系統外包給了印度外包公司 HCL 和 Cyient 的軟件工程師，比起美國正職軟件工程師每小時 35 至 40 美元的工資，印度外包的時薪只需要 9 美元，便宜了四五倍呢。更進一步，波音的分包商與供應商同樣選擇將工程外包到印度，降低成本以保證利益最大化。一位前波音軟件工程師在 2015 年表示，企業將裁掉 90% 經過了熟練培訓的員工，用“外包”來代替他們，從而縮減開支。
軟件外包絕對不是“一包了之”，它是一個需要發包方和承包方高度協作的過程，貼身服務週期長，可變因素太多太多，這使得發包方和承包方都同時面臨極大風險。我們見識過太多的外包失敗案例，不差波音這一個。
波音的 787 型飛機計劃 70% 使用外包，最終導致了延期三年還交付不了，波音表示：“我們同時在技術、工具和供應鏈上做了太多改變，超出了我們的管理能力”。
哪有什麼捷徑啊？只有外行領導的一廂情願而已。
1999年 NASA 當年發射了兩艘火星探測器，心想這下總是雙保險了吧。結果，一個失聯，一個在火星墜毀。咋回事呢？也是同樣的鍋：集成測試做得不好。
第一架名叫火星氣候探測者。1999年9月23日失聯於地球太空。
RCA報告這麼寫道：
它的飛行系統軟件使用公制單位“牛頓”計算推進器動力，而地面人員輸入的方向校正量和推進器參數則使用英制單位“磅力”，1磅力=4.4482216152605牛頓，導致探測器進入大氣層的高度有誤。
在該探測器的悲劇中，軌道模型來自於屬於政府部門的NASA（採用公制單位如米和釐米等），而飛行控制軟件來自於私營承包商洛克希德·馬丁公司。
洛克希德·馬丁公司的碼農們沒有按照飛船工程的接口規範設計軟件，而是習慣性直接使用了英制單位，大禍在上天前就已經註定。
（圖2 當時的諷刺漫畫 Remember the Mars Climate Orbiter incident from 1999，
左邊宇航員背上是NASA，右邊是Lockheed，即洛克希德）
第二架名叫“火星極地着陸者”。1999年12月3日墜毀於火星表面。
（圖3 火星極地着陸者號登陸火星藝術效果照）
RCA報告執筆者無奈地寫下：
RCA類型：缺乏集成測試！
有一個甲小組測試探測器的腳落地過程（leg fold-down procedure），即探測器的三個着陸支架如果觸地了，制動發動機就會提前關機。
有一個乙小組測試飛船着陸過程的其他部分。乙小組總是在開始測試之前重置計算機、清除數據位。
這兩個小組的工作都沒什麼問題，但就是沒有合在一起測試。
沒想到着陸支架伸展出來的這個動作產生了意外的信號，制動發動機以爲已經觸地了，於是在探測器距離火星表面還足足有40米的時候就提前關機了。咔咔，蛋碎。
最後說一句，圖快懶省事兒，不做集成測試，不做迴歸測試，尤其是涉及軟硬件的，您真的會死得很難看。
法則二：儘早統一規格，別讓雜草到處長
技術團隊人多了，就會分好多組，併發幹活，人上一百，形形色（sai）色（sai），如果沒有居中協調人，比如一個 CTO 或者 大 PM，就很可能會各自爲戰，完全取決於技術 Leader 的喜好和意識。這會有什麼問題呢？
這裏有一個經典故事：阿波羅13號。很多人可能都看過這部據真實事件改編的電影。
1970年4月，阿波羅13號發射升空之後，液氧貯存罐意外爆炸，指令艙和服務艙失去了兩個氧氣罐中所有的氧氣，所幸宇航員沒有受到影響。面對這種情況，NASA 不得不放棄原定的登月計劃，改爲以順利返回地球即生還爲最重要目標。經過緊張計算，地面指揮中心發現可以借用登月艙的資源保證宇航員生存，所以原本設計供兩名宇航員使用兩天的登月艙需要容納三名宇航員生存四天，但這樣就會存在極大的風險，宇航員可能窒息而死。
果不其然，登月艙的二氧化碳氫氧化鋰過濾罐不堪重負，好在天無絕人之路，指令艙有備用的過濾罐。這時候才發現，登月艙和指令艙的過濾罐由不同供應商提供，所以一個接口爲方形，一個接口爲圓形，並不兼容。
（動圖1 電影《阿波羅13號》中尋找解決二氧化碳問題的片段）
天上和地上只能同時想辦法，在“每一克重量都極寶貴”的飛船上想出辦法來解決這個問題……
（圖4 宇航員們臨時拼裝的二氧化碳過濾裝置，工程師們將其戲稱爲“郵箱”）
當然，燒腦大戰之後，最終還是成功地解決了這個問題，如上圖所示。
技術 Leader 們，平常多聚會多碰頭吧，很多東西從文檔上根本看不出來，只能靠當面多溝通多交流，纔會發現這種潛在隱患……
法則三：災難錦囊，大恩不謝
災難我們見得多了//不愧是老兵～
每臨大事有靜氣，不信今時無古賢//但是我們每次都慌得不行～
關鍵是每次災難都不一樣//它不重樣誒，你待我何～
（圖5 北京有家飯館，樓裏掛了一塊匾，上面寫着四個字：何事驚慌)
如果災難真的來臨，我們該怎麼辦？
在著名的“4英寸發射”事件中，Christopher Kraft 給航天任務定下的第一法則：如果你不知道發生了什麼，那你就什麼也不要做（If you do not know what to do, don't do anything）。
在這次阿波羅12號飛船升空遭雷擊的事故中，宇航員本來可以啓動逃生程序的，但關鍵時刻他們想到了這條原則，所以什麼也沒有做，最終在指揮中心的 Aaron 給出了著名的經典的明確的指令：“try SCE to AUX”，登月行動得以順利進行。
作爲對比，1960年10月24日，前蘇聯發生了與“4英寸發射”類似的航天事故，結局則要慘痛許多。
那麼讓我們看看發生了什麼？
1960年，前蘇聯發射火星探測器，前兩次都失敗了，如果第三次再失敗，就必須再等兩年纔會出現行星連線的機會。
火箭此時已加註了燃料，但還是有些問題，爲了不錯過發射時機，爲了報答赫魯曉夫去年提拔自己爲炮兵主帥的知遇之恩，聶傑林元帥毅然決然地拒絕了拜科努爾發射現場總指揮延期發射的忠告，堅持要求在發射臺上對火箭進行全面檢查。
總工程師只得違規准許對各個不同系統並行檢查，而不是按照規定一項一項來。
聶傑林希望趕在國慶節前發射，能省的步驟就省，即使這樣，災難發生前工程師們也連續工作了72個小時，爲了趕時間工程師們在裝滿燃料的火箭底下檢查點火系統，一個燃料泵有燃料泄漏，電路也有一些短路，搞定之後，他們卻已經沒有時間重新檢查，因爲元帥已經到了。參謀總長索科洛夫建議暫緩發射，但聶傑林斥責他是懦夫，索科洛夫一氣之下離開基地，反而他因此倖存了下來。
聶傑林本人親臨現場督戰，原本按照規定，所有不直接參與發射準備工作的人員都應到地下水泥掩蔽部去，但聶傑林卻坐在火箭不遠處的凳子上，可謂是盡心盡力。發射場主任兩次懇請他轉移到安全地方，他都置之不理。
可惜的是，火箭雖然叫“二炮”，但它畢竟不是炮。
（圖6 拜科努爾發射中心爆炸現場）
這枚火箭的第二級火箭有自己獨立的時鐘，它按原計劃點火了，結果引發整枚火箭爆炸，3000度以上的火海吞噬了發射場，跟聶傑林一塊坐在火箭旁邊的幾十名將校級火箭專家、技術人員當場團滅。聶傑林燒得連點灰燼都沒有留下，只找到半塊被燒焦的元帥肩章和已經熔化了的辦公保險箱的鑰匙。這些東西后來都被裝進骨灰盒，安葬在克里姆林宮的宮牆下。
（圖7 拜科努爾發射中心爆炸後）
切換到我們的場景，如果你已經完全容器化了，那麼災難發生的時候，系統運維工程師拍馬趕到之後，一定是：
- 重啓相關應用；
- 如果不行，先流量切換多活機房，保證服務正常提供；
- 目標只是分鐘級最快速度恢復，保證SLA四個九！
- 不需要做任何其他事情，
- don't do anything，
- 不要寄希望於工程師短時間內定位問題，不需要的～
- 先恢復服務！除此之外的任何事情可能都是奢望，甚至是干擾。
自建法則 法則長存
不，沒有什麼法無定法，技術的世界裏一定是有法則的，否則你會死得很難看，別指望我來救你，我救都救不贏。
通過本次講座，我想強調的是，You！Leaders！一定要通過層層疊加的“Rules”建立起本能反應，一遇到類似的事情，應激般的就知道該怎麼設計，怎麼行動，怎麼救火。
而這些“Rules”是經歷了血與火的洗禮鑄造的，每一條都有來由有去路。
比如說，我在2018年定義的 DevOps 新八榮八恥，每一條都是血肉長城：
- 以隨時可擴容、可縮容、可重啓、可切換機房流量爲榮，以不能遷移爲恥。
- 以可配置爲榮，以硬編碼爲恥。
- 以系統互備爲榮，以系統單點爲恥。
- 以交付時有監控報警爲榮，以交付裸奔系統爲恥。
- 以無狀態爲榮，以有狀態爲恥。
- 以標準化爲榮，以特殊化爲恥。
- 以自動化工具爲榮，以人肉操作爲恥。
- 以無人值守爲榮，以人工介入爲恥。
如何自建法則？
從錯誤中學習錯誤！
『學校裏學習最好的學生可能往往是那些最不善於從錯誤中學習的人，因爲他們已經習慣了把錯題當成失敗的代名詞，而不是把犯錯看成學習的機會，這反而成爲他們進步的主要障礙。走入社會之後，聰明的人必須善於擁抱自己的錯誤和不足，從而能遠遠超過那些與他們水平相當，但更自負的同學、同輩。』
這也就是爲什麼平凡人可爲非凡事的緣故！
『不要患得患失，要朝着目標努力前行。要自省自警，別人對你很到位的批評，是你能得到的最寶貴的建議。想想看，你的滑雪教練告訴你，你摔跟頭是因爲你滑行中的重心移動不對，此時你要是認爲他在責罵你，你該多麼愚蠢和低效。同理，你的上司，我，也可能會指出你工作中的缺點，有則改之，繼續努力就是了。』
等有一天你依據本能（也就是你自建的法則）行事的時候，你就會體會到我的良苦用心了！
-EOF-
推薦閱讀：
系統問題應當如何排查？看看NASA著名的“10釐米發射”吧，2019，https://mp.weixin.qq.com/s/zhyu4OXXSJjsde_MmdavXA
try SCE to AUX，挽救登月的傳奇指令【修訂版】，2018，https://mp.weixin.qq.com/s/xhhg259Fd4s5XE_Fjqc3eA
“阿波羅“登月中的工程管理一瞥，2018，https://mp.weixin.qq.com/s/-u0TtSBA5EynVpTkuSVdog
《阿波羅8號，NASA的驚險大躍進》，2019
俄國內德林飛彈事故，2017
細數半個世紀以來折戟火星的“登陸者”，騰訊太空，2016，https://mp.weixin.qq.com/s/ltfItsUQtOKHMwhaRFboDw
關於數據庫‘狀態’字段設計的思考與實踐，2017，https://www.jianshu.com/p/03522e3938c0
交互水深 10 | 以 [ 訂單狀態 ] 爲例，聊聊產品策劃的八字法則，2018，https://zhuanlan.zhihu.com/p/35199144