航空公司系統是怎樣煉成的?

技術瑣話發表於2019-11-22

航空公司系統是怎樣煉成的?

剛接觸航空業時,覺得自己像剛踏上美洲的弗朗西斯科.皮薩羅,或是剛遇見毛利人的庫克船長,彷彿走進了資訊科技的蠻荒之地,隨便播下一顆“現代技術”種子,就能長出一片跨時代的技術森林。
與國內行業解決方案提供商交流之後,這種自信似乎得到了印證。一個擁有幾十家航司客戶的產品,代表著行業最高水平,卻不支援外掛化定製,沒使用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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章