架構

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

廣告
廣告

剛接觸航空業時,覺得自己像剛踏上美洲的弗朗西斯科.皮薩羅,或是剛遇見毛利人的庫克船長,仿佛走進了信息技術的蠻荒之地,隨便播下一顆“現代技術”種子,就能長出一片跨時代的技術森林。

與國內行業解決方案提供商交流之后,這種自信似乎得到了印證。一個擁有幾十家航司客戶的產品,代表著行業最高水平,卻不支持插件化定制,沒使用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架構,系統架構適配信息結構;這些事件、狀態、工序、流程最終沉淀為數據,成為更深層變革的土壤。

數據說話

數據積累是航空業天然優勢,飛機運行數據,從發動機性能參數,到飛行軌跡,到飛行員的每一次操作,從首飛開始完整記錄。每一次故障,即便是空調扇葉螺絲松動,都要記錄在案,而每一次修理,更是從使用什么工具,到每個具體的修理動作,比如登上腳手架,都詳細記錄。

這座數據金礦的價值不言而喻,但挖掘起來難度不小,主要原因是專業門檻太高,業務專家普遍缺乏系統意識,技術人員和技術專家就像修建通天塔的工匠。

 即便如此,對數據客觀性的認可是共通的,每當雙方各執一詞,無論是立場還是觀念的沖突,只要一方能夠拿出扎實的數據佐證,通常就可以把問題范圍縮小到數據有效性層面。

航司生產運行變動成本中,燃油占了大頭,節油于航司不只是環保問題,更是真金白銀的利潤問題,飛機加多少油不只是個技術問題,更是理念之爭。爭論的兩端,一方是公司要省錢,另一方則是航空公司最舉足輕重的群體——飛行員。

飛行員在航空公司是特權階層,享有巨大的發言權,就像互聯網公司里的程序員,不可小覷。從飛機發動機啟動開始,機長是負責航班的第一責任人,如果航班出現了特殊狀況,比如備降或者返航,甚至被迫盤旋等待,油箱里有油,心里就不慌。可是飛機的載重是有限的,裝了太多油,機票就只能少賣幾張了,而且油自重也耗油,有時為了降落不超重,還要刻意消耗一些油減重,實在可惜。

理論上,航班耗油取決于飛機載重和航線距離,同時受天氣情況(氣溫、濕度、風力)影響,備用油主要看備降場的選擇,傳統計算模型是物理公式,技術上本沒有討論空間,但理論與實踐的差距很微妙,飛行員作為直接實踐者,站在安全的制高點,質疑理論值只需要一個例外。

技術手腕如何對抗安全大棒?唯有動用數據的力量。如果預估油量計算模型吸收飛行員實際飛行的數據作為參數,飛行員操作習慣、飛機特性等公式中沒包括的因素,都能涵蓋了。

具體方案分為兩個階段:數據積累和模型訓練。積累階段,制作航班計劃計算預估油耗時,選取條件最近似的歷史數據作為錨點,記錄每個航班的實際飛行數據,包括航距、載重、天氣和耗油,進而按照不同飛行階段細分數據,得到更精確的油耗,這個錨點油量也會作為參照值記錄到這次航班的飛行數據中

積累一段時間的數據后,比對錨點油量、計劃油量和實際耗油,如果錨點油量比計劃油量更接近實際耗油,那么這個歷史數據就可以用來修正計劃油量計算模型,累計飛行數據不斷訓練,模型穩定后,就可以直接計算更準確的錨點油量。

原文鏈接:https://mp.weixin.qq.com/s/nCAsYaDsge0MQbJOJStmGA

最干貨的java+分布式技術公眾號,兼及研發管理。本號專家陣容:螞蟻金服右軍、易寶CTO陳斌、米么金服總監李偉山、奧琪金科首席架構曲健、螞蟻金服高級技術專家張翔、美團高級技術專家楊彪等。

史上最全Oracle數據泵常用命令

上一篇

Cache 和 Buffer 的區別在哪里?

下一篇

你也可能喜歡

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

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
双色球常规走势图 浙江20选5走势图开奖 三分彩 体彩 1分11选5开奖结果 中国足彩网即时赔率 14场胜负 即时比分球探比分下载 宁夏11选五走势图 教你玩杭州麻将 吉林麻将玩法 cba季后赛比分情况 26选5开奖结果