剛接觸航空業時，覺得自己像剛踏上美洲的弗朗西斯科.皮薩羅，或是剛遇見毛利人的庫克船長，彷彿走進了資訊科技的蠻荒之地，隨便播下一顆“現代技術”種子，就能長出一片跨時代的技術森林。與國內行業解決方案提供商交流之後，這種自信似乎得到了印證。一個擁有幾十家航司客戶的產品，代表著行業最高水平，卻不支援外掛化定製，沒使用gitflow管理產品線和業務線，每個客戶的程式碼都是單獨維護的；航班執行全生命週期管控系統不允許當機，卻不具備基本的負載均衡、故障轉移、服務降級，資料庫沒有主從熱備，只有日備份，系統穩定性完全靠祈禱；系統升級沒有回退機制，不支援新老並行，每次升級都是一場勇氣與決心的冒險。正當我擼起袖子，手握網際網路技術的利劍，準備披荊斬棘，收割航空業資訊化的碩果，開心地回答這道天賜送分題時，行業卻問了我另一個問題：這系統安全嗎？航空業對安全的追求深入骨髓，答不好就是送命題。安全是每個中國民航人做每件工作的必答題，值得國人驕傲的是，中國民航局對安全執行的要求和管控遠高於世界平均水平，所以網際網路典型思維，諸如快速試錯、容災，名字都不合法。航空安全問題的邊界在哪裡，可以試著從航天安全切入，關於航天，埃隆.馬斯克當有發言權，畢竟他的公司Space X，領先於NASA，實現了火箭回收重複利用的商業化。Space X的創舉打破了航天技術高深莫測的神話，凡人也可以做出火箭，那麼航空業的安全應該也可以透過我們熟知的技術來解決。NASA，地球上少數幾個可以和Google爭奪人才的機構，是軟體工程的鼻祖，世界上最初的巨型軟體專案就是NASA的專案，這些專案的底線是不能出錯。為了管理龐大軟體專案的複雜性，NASA在實踐中提出了軟體工程概念，用系統化的工程方法解決業務複雜性問題。順便提一句，軟體工程師這個稱謂也是由NASA的“臨時編碼工”瑪格麗特提出來的，在她剛加入這個行業時，軟體還只是硬體的一個部件。既然安全問題說到底是個技術問題，既有的技術實踐依然有效，那麼航空業的資訊化又回到了技術的軌道上。第一個接受安全問題拷問的是執行控制系統，這個系統負責從制定航班計劃，到飛行員資源調配，再到飛機起飛降落管控，乃至航班異常處理（備降/返航/調機），是航司生產執行的中樞系統。如此關鍵的系統，在設計之初，就考慮了平滑上線方案，保持老系統功能可用的條件下，業務分航線逐步切到新系統執行，一旦出現系統故障，可以立刻切回老系統繼續管控航班。這套方案最大的挑戰在於電報系統，電報系統是航司和空管溝通航班排程的關鍵通道，每個航司只有一條專線與空管相連，無法做雙線熱備，是整套系統唯一的SPF（Single Point of Failure）。電報系統透過電報機通訊，傳送摩斯電碼，模擬訊號，據說建國前就在使用了，諜戰片裡那種，這樣的古董系統，偶爾出現亂碼也情有可原吧，但請謹記，航空業不允許出錯，所以這就相當於要求一個Java程式設計師用C寫程式碼，還不許有bug。解決問題的關鍵在於迴歸問題本原，監控系統可用性的最基本策略是心跳檢測，透過定時傳送測試電報給自己，覆蓋了傳送和接收雙向通道的可用性檢測，並結合正常業務電報的收發以及航班疏密，適當減少檢測頻度以節約成本。如何讓新老系統共用一條線路？“Any problem in computer science can be solved with another level of indirection”，封裝電報系統，內部分航線排程，隔離新老系統。同時冷備一條網路線路，預防運營商抽風。做足了準備工作，系統終於要上線了，在釋出準備會上，業務部門突然提出，分航線遷移業務不可行，因為雖然航班管控是按航線組織的，但飛行員是個共享稀缺資源池，如果按航線拆分，將出現飛行員短缺，而且局方不認可系統新老並行方案，局方要求新系統不允許出現故障。中國民航局作為世界上最嚴厲的監管機構之一，事無鉅細地監管著每一家航空公司的生產執行，高度管控可能區域性高效，但整體必然低效，因為整體效率完全取決於管理層，這要求管理層都是超人。這與日新月異的大環境顯然衝突，業內人都在呼喚變革，自上而下的嚴密監管體系制約了個體的創造力，變革只能自下而上透過奇點突破形成裂變輻射的形式發生。我們希望在航空業的探索能夠找到那個奇點，但在此之前，首先要解決業務部門尖銳的問題：局方不認可。備用系統為什麼不被認可？不出故障只能是結果，怎麼能是要求？再次回到問題本原，業務部門反對新老系統並行的真正原因是，不願意在新老系統中錄入兩遍基礎資料，這會增加工作負擔。找到根源，問題就解決了一半，透過自動同步新老系統資料，業務部門只需要錄入系統差異部分資料，不僅規避了大量的重複人工，也保證了資料完整性和準確性。這件事不僅讓我意識到要善於捕捉和發掘業務部門潛臺詞，更讓我明白局方是個重要的第三方，可以是問題的核心，也可以是解決問題的支點。新系統儘量實現自動化，但並非所有資料都能自動採集，有些即便可以自動獲取但仍需人工確認，這些不自動的部分就像人類進化的尾巴，反成了難以忍受的累贅，比如上客時間和加油量等資料的錄入，完全是線下行為，只能人工事後錄入系統。這些遺留的人工，在自動化背景下成了額外的工作，沒有人願意接手。體制是把雙刃劍，可以藉助監管的力量，反推資訊化，統一技術目標與業務目標，形成部門合力，局方對航司各項工作可追溯的要求就幫了忙。所有工作必須可以透過各種工作日誌、工單、審批單、會議紀要等完全還原，尤其當回溯事故/故障的原由，只要還原結果表明不存在人為過失，就可以免責，所以有句行業戲言，“工作做的好，不如記錄記得好”。由此，為了保證資訊流閉環，這些資料理所應當分到了合適的席位人工錄入。當然，在後續迭代中，所有現場人員都會配備資訊終端，這類資訊錄入會簡化成按鈕點選，甚至只需搖一搖，即可完成；而系統本身也將演化成Event Sourcing架構，系統架構適配資訊結構；這些事件、狀態、工序、流程最終沉澱為資料，成為更深層變革的土壤。資料積累是航空業天然優勢，飛機執行資料，從發動機效能引數，到飛行軌跡，到飛行員的每一次操作，從首飛開始完整記錄。每一次故障，即便是空調扇葉螺絲鬆動，都要記錄在案，而每一次修理，更是從使用什麼工具，到每個具體的修理動作，比如登上腳手架，都詳細記錄。這座資料金礦的價值不言而喻，但挖掘起來難度不小，主要原因是專業門檻太高，業務專家普遍缺乏系統意識，技術人員和技術專家就像修建通天塔的工匠。 即便如此，對資料客觀性的認可是共通的，每當雙方各執一詞，無論是立場還是觀念的衝突，只要一方能夠拿出紮實的資料佐證，通常就可以把問題範圍縮小到資料有效性層面。航司生產執行變動成本中，燃油佔了大頭，節油於航司不只是環保問題，更是真金白銀的利潤問題，飛機加多少油不只是個技術問題，更是理念之爭。爭論的兩端，一方是公司要省錢，另一方則是航空公司最舉足輕重的群體——飛行員。飛行員在航空公司是特權階層，享有巨大的發言權，就像網際網路公司裡的程式設計師，不可小覷。從飛機發動機啟動開始，機長是負責航班的第一責任人，如果航班出現了特殊狀況，比如備降或者返航，甚至被迫盤旋等待，油箱裡有油，心裡就不慌。可是飛機的載重是有限的，裝了太多油，機票就只能少賣幾張了，而且油自重也耗油，有時為了降落不超重，還要刻意消耗一些油減重，實在可惜。理論上，航班耗油取決於飛機載重和航線距離，同時受天氣情況（氣溫、溼度、風力）影響，備用油主要看備降場的選擇，傳統計算模型是物理公式，技術上本沒有討論空間，但理論與實踐的差距很微妙，飛行員作為直接實踐者，站在安全的制高點，質疑理論值只需要一個例外。技術手腕如何對抗安全大棒？唯有動用資料的力量。如果預估油量計算模型吸收飛行員實際飛行的資料作為引數，飛行員操作習慣、飛機特性等公式中沒包括的因素，都能涵蓋了。具體方案分為兩個階段：資料積累和模型訓練。積累階段，製作航班計劃計算預估油耗時，選取條件最近似的歷史資料作為錨點，記錄每個航班的實際飛行資料，包括航距、載重、天氣和耗油，進而按照不同飛行階段細分資料，得到更精確的油耗，這個錨點油量也會作為參照值記錄到這次航班的飛行資料中積累一段時間的資料後，比對錨點油量、計劃油量和實際耗油，如果錨點油量比計劃油量更接近實際耗油，那麼這個歷史資料就可以用來修正計劃油量計算模型，累計飛行資料不斷訓練，模型穩定後，就可以直接計算更準確的錨點油量。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562044/viewspace-2665349/，如需轉載，請註明出處，否則將追究法律責任。
