不是都自動駕駛嗎,飛機師為什麼會累?

不是都自動駕駛嗎,飛機師為什麼會累?
photo credit: REUTERS/Guillermo Granja/達志影像

我們想讓你知道的是

這次華航機師的罷工事件,主要訴求就是「8小時以上飛時3人派遣,12小時以上飛時4人派遣」,各種人數到底差在哪裡?既然飛機都可以自動駕駛了,機師怎麼會累呢?

文:華航現職張姓副機長

什麼是疲勞航班?昨天試著用一般人能理解的文字解釋了理論上的部分,今天來說說比較實務上的經驗,以及一般人對這個職業的認知誤解。

畢竟,理論這種東西就和所有專業必須讀的書一樣,打開書就想睡覺,講太多怕各位看了只想直接上一頁跳出,今天,我想多談談飛行員工作面對什麼壓力,以及為何會疲勞。

一樣,文章出發點是我在飛行的747機隊,其它機隊操作模式與派遣方式我沒經歷過無法做評論。

同樣是機師,開貨機和客機的疲勞程度就很不同

在這間公司(編按:華航)的747機隊,客機及貨機都需要飛,而兩種機型飛行員要面對的心理壓力是不一樣的。

第一,客機和貨機駕駛艙在本質設計上有點不一樣。為了顯而易見的航空保安因素,客機的駕駛艙和客艙是用一扇強化門隔開,飛行員除了使用廁所和輪休,或有特殊情況時,航行過程中是不會走出那扇門的。貨機駕駛艙和上層客艙間沒有用強化門隔開,只有一條用來遮光的門簾,平時貨機除了組員之外,會載的乘客絕大多數都是自己公司員工,或是跟著特殊貨物一起的隨機人員(如載運馬匹時的飼育人員),因此航空保安的要求沒有客機來得嚴謹。

為什麼要說這個?試想一趟8小時飛行時間的航程,飛行員不可能8個小時屁股都黏在椅子上不起來,總會想要疲累時起來走一走,洗洗臉,動一動試著趕跑瞌睡蟲。客機因為不能隨便開門離開駕駛艙,能活動的空間只有小到可憐的一點點,想上廁所時,如果當場只有兩位飛行組員在駕駛艙位置上,必須電請一位客艙組員進入駕駛艙,飛行組員才能去上廁所。請這位客艙組員進來不是來幫忙開飛機的,而是在有任何突發狀況時這位客艙組員可以從內把駕駛艙門打開,讓在門外的飛行組員能進入。有興趣可以Google一下德國之翼9525航班事件,就能了解這個規範的必要性。

由於客艙組員也有他的工作要做,所以去廁所的飛行員都不喜歡拖太久,趕快完事趕快回駕駛艙讓客艙組員能回到其職位上。而貨機就沒有這個狀況,沒有強化門沒有客艙組員,也有足夠空間可以自由行走活動,我飛貨機通常是在駕駛座上坐一個小時就會逼自己起來到上層客艙走動約10分鐘,然後再回座繼續執勤,藉此減輕疲勞程度。

640px-China_Airlines_Boeing_777-300ER_Premium_Economy_Class
Photo Credit:KCS CC BY 4.0

第二,客機載了滿滿的乘客和客艙組員,飛行員承擔不起讓任何一位受傷的責任,同時也因為人員多就會有各種狀況發生。機上生病、酒醉鬧事或是大多數人還有印象的,前陣子友航發生的乘客要求客艙組員幫忙擦屁股事件,每一件事都是在考驗飛行員的判斷與決策能力。該繼續前往目的地還是找地方預防性轉降?每一個決定都是幾百萬(台幣)的營運成本,公司買單不買單都要看這個決定的合理性。

舉個例子,我們機隊某個飛往歐洲的航班,發生過在西伯利亞上空乘客生病的緊急醫療狀況,飛行組員在全盤考量後決定回頭轉降至日本北海道新千歲機場。熬大夜的航班遇到這個狀況,做的決定讓公司損失可觀的營運成本,但人命關天誰也承擔不起讓乘客在航機上過世的風險。

航行途中遇到亂流時,客機的處置和貨機也有點不同。持續的亂流輕則影響到乘客的舒適度,重則可能造成乘客或組員受傷或死亡,不得不謹慎,因此飛客機時遇到亂流飛行員都會盡可能避讓。貨機的好處是沒有乘客,飛行員對亂流已是司空見慣,忍受程度高,除非是嚴重到可能對飛機結構有危害,不然飛行員大多數處置沒有像客機那樣緊張急迫。

第三,飛貨機有什麼心理壓力?試著問問自己,你願不願意在自己的車上裝滿爆裂物、腐蝕化學物質、輻射物質、易燃物品、有毒物質、高感染性生物物質、臭氣沖天的牲畜等等貨物?航運界公認的危險物品,現代科技產品都會用到的鋰電池,也是貨機的常客。鋰電池之所以危險是因為它一旦點燃後無法被貨機上的滅火系統撲滅,只能馬上迫降別無它法。

它容易點燃嗎?我不知道,但我知道莫非定律(Murphy's Law)說凡事可能出錯的事就一定會出錯⋯⋯。鋰電池已經被大多數貨運航空拒絕載運,也因此其利潤高,還是有公司肯載運。拿到艙單看到滿滿的鋰電池真的不知道該哭還是該笑。有興趣可以Google 發生在2010年9月3日的 UPS6航班事故

即使貨機的班型比較疲累,但我是比較喜歡飛貨機的,單純是個人喜好。

非幾小時派遣幾人?為的其實就是「再安全一點」

「8小時以上飛時3人派遣,12小時以上飛時4人派遣」。2人派遣、3人派遣跟4人派遣的差別在哪裡?其實就是一句話,疲勞控管。

我先說說飛到現在我感受過最疲累的航班經驗。那是我剛完成航路訓練後的第3趟飛行,5天班,一整趟的航班任務是桃園機場出發到東京成田機場,成田到夏威夷,夏威夷回成田,成田回桃園。4個航段每一段都只有兩個飛行組員,我和機長兩個人。

第一天第一段很正常,桃園機場飛成田機場,台灣時間下午快3點起飛,3小時的飛時,抵達時是台灣時間約晚上6點。

第二天第二段成田機場飛夏威夷,台灣時間晚上7點半起飛,約7小時的飛時,抵達時間是台灣時間第三天深夜2點半,通關後接車到飯店大概已經是台灣時間快早上4點了。

生理時鐘是這樣,熬了一夜很累的時候是睡得著,但睡不久。我在台灣時間的早上可能11點起來,出門覓食活動,還是很累得回飯店睡覺,可是這個午睡不敢睡久,因為一旦睡久晚上就睡不著了,必須設鬧鐘逼自己只能睡1到2個小時,這樣晚上任務前還能再盡量小睡一下。話是這樣說,但因為白天一直睡,晚上躺下去根本睡不著,翻來覆去煎魚煎老半天可能只能熟睡1到2個小時,就得起床開始打包準備了。


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡