鄭昀：技術人間自有法則在

時間 2020-04-19

標籤技術人間自有法則欄目快樂工作简体版

原文原文鏈接

建立於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 新八榮八恥，每一條都是血肉長城：

以隨時可擴容、可縮容、可重啓、可切換機房流量爲榮，以不能遷移爲恥。
以可配置爲榮，以硬編碼爲恥。
以系統互備爲榮，以系統單點爲恥。
以交付時有監控報警爲榮，以交付裸奔系統爲恥。
以無狀態爲榮，以有狀態爲恥。
以標準化爲榮，以特殊化爲恥。
以自動化工具爲榮，以人肉操做爲恥。
以無人值守爲榮，以人工介入爲恥。

如何自建法則？

從錯誤中學習錯誤！

『學校裏學習最好的學生可能每每是那些最不善於從錯誤中學習的人，由於他們已經習慣了把錯題當成失敗的代名詞，而不是把犯錯當作學習的機會，這反而成爲他們進步的主要障礙。走入社會以後，聰明的人必須善於擁抱本身的錯誤和不足，從而能遠遠超過那些與他們水平至關，但更自負的同窗、同輩。』

這也就是爲何平凡人可爲非凡事的緣故！

『不要患得患失，要朝着目標努力前行。要自省自警，別人對你很到位的批評，是你能獲得的最寶貴的建議。想一想看，你的滑雪教練告訴你，你摔跟頭是由於你滑行中的重心移動不對，此時你要是認爲他在責罵你，你該多麼愚蠢和低效。同理，你的上司，我，也可能會指出你工做中的缺點，有則改之，繼續努力就是了。』

等有一天你依據本能（也就是你自建的法則）行事的時候，你就會體會到個人良苦用心了！