通過本次講座，我想強調的是，You！Leaders！一定要通過層層疊加的“Rules”建立起本能反應，一遇到類似的事情，應激般的就知道該怎麼設計，怎麼行動，怎麼救火。 而這些“Rules”是經歷了血與火的洗禮鑄造的，每一條都有來由有去路。 等有一天你依據本能（也就是你自建的法則）行事的時候，你就會體... ...
創建於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（採用公制單位如米和釐米等），而飛行控制軟體來自於私營承包商洛克希德·馬丁公司。 洛克希德·馬丁公司的碼農們沒有按照飛船工程的介面規範設計軟體，而是習慣性直接使用了英制單位，大禍在上天前就已經註定。法則二：儘早統一規格，別讓雜草到處長
技術團隊人多了，就會分好多組，併發幹活，人上一百，形形色（sai）色（sai），如果沒有居中協調人，比如一個 CTO 或者 大 PM，就很可能會各自為戰，完全取決於技術 Leader 的喜好和意識。這會有什麼問題呢？ 這裡有一個經典故事：阿波羅13號。很多人可能都看過這部據真實事件改編的電影。 1970年4月，阿波羅13號發射升空之後，液氧貯存罐意外爆炸，指令艙和服務艙失去了兩個氧氣罐中所有的氧氣，所幸宇航員沒有受到影響。面對這種情況，NASA 不得不放棄原定的登月計劃，改為以順利返回地球即生還為最重要目標。經過緊張計算，地面指揮中心發現可以借用登月艙的資源保證宇航員生存，所以原本設計供兩名宇航員使用兩天的登月艙需要容納三名宇航員生存四天，但這樣就會存在極大的風險，宇航員可能窒息而死。 果不其然，登月艙的二氧化碳氫氧化鋰過濾罐不堪重負，好在天無絕人之路，指令艙有備用的過濾罐。這時候才發現，登月艙和指令艙的過濾罐由不同供應商提供，所以一個介面為方形，一個介面為圓形，並不相容。法則三：災難錦囊，大恩不謝
災難我們見得多了//不愧是老兵～ 每臨大事有靜氣，不信今時無古賢//但是我們每次都慌得不行～ 關鍵是每次災難都不一樣//它不重樣誒，你待我何～- 重啟相關應用；
- 如果不行，先流量切換多活機房，保證服務正常提供；
- 目標只是分鐘級最快速度恢復，保證SLA四個九！
- 不需要做任何其他事情，
- don't do anything，
- 不要寄希望於工程師短時間內定位問題，不需要的～
- 先恢復服務！除此之外的任何事情可能都是奢望，甚至是干擾。
自建法則 法則長存
不，沒有什麼法無定法，技術的世界里一定是有法則的，否則你會死得很難看，別指望我來救你，我救都救不贏。 通過本次講座，我想強調的是，You！Leaders！一定要通過層層疊加的“Rules”建立起本能反應，一遇到類似的事情，應激般的就知道該怎麼設計，怎麼行動，怎麼救火。 而這些“Rules”是經歷了血與火的洗禮鑄造的，每一條都有來由有去路。 比如說，我在2018年定義的 DevOps 新八榮八恥，每一條都是血肉長城：- 以隨時可擴容、可縮容、可重啟、可切換機房流量為榮，以不能遷移為恥。
- 以可配置為榮，以硬編碼為恥。
- 以系統互備為榮，以系統單點為恥。
- 以交付時有監控報警為榮，以交付裸奔系統為恥。
- 以無狀態為榮，以有狀態為恥。
- 以標準化為榮，以特殊化為恥。
- 以自動化工具為榮，以人肉操作為恥。
- 以無人值守為榮，以人工介入為恥。
