空軍第六偵察大隊:在中華民國最可能被出賣的時代,穩定台海的基石

空軍第六偵察大隊:在中華民國最可能被出賣的時代,穩定台海的基石

我們想讓你知道的是

從事戰術偵察任務的空軍第6偵照大隊,因為駕駛的一律為無武裝的偵察機,雖然他們從保衛台灣的角度來看貢獻最大,卻最常為人們所忘記。

然而蔡文治也好,李彌也罷,他們或許離中國大陸較近,卻沒有屬於自己的空軍。沒有空軍,不只意味他們沒有辦法保衛自己的空域,還意味著他們無法派出偵察機為美軍蒐集中共的情報。與之相反的是,台灣的中華民國政府不只有空軍,而且中美空軍混合團(Chinese American Composite Wing)的歷史,還證明這支空軍是由美軍親手帶出來的。

包括王德輝在內的初代12中隊飛行員,都曾到美國接受一流的偵察飛行訓練。他們的勇氣、技術與忠誠都是備受美軍肯定的。據王德輝將軍回憶,美國在50年代初期幾乎停止了一切對台灣的軍事援助,可是偵察機卻還是源源不斷地送來,足見美國空軍對第12中隊的肯定。從1952年開始,他們更是幾乎一年接收一款新飛機,換裝速度之快讓人難以想像。

截圖_2021-02-03_下午1_10_40
許劍虹提供
謝翔鶴與沈江田教官駕駛的RF-101A巫毒式偵察機

精銳機種搭配優良技術

第12中隊在大陸時代的主力機種,分別為P-38閃電式戰鬥機的偵察型F-5E及B-25轟炸機的偵察型RB-25。到了台灣之後,美軍從1952年起提供RF-51D野馬式偵察機,增加第12中隊的低空偵察能力。隨著中共將MiG-15戰鬥機投入對偵察機的攔截行動,第12中隊於1954年7月進入噴射機時代,從美軍手中接收RT-33A流星式偵察機。

為了瞭解更多來自海峽對岸機場、港口、車站還有軍營的相關情報,中華民國空軍在美國幫助下擴編戰術偵察中隊的戰力。由原本單獨的第12中隊,擴編為下轄第4與第12兩個偵察中隊的第六戰術偵察大隊。RF-86F與RF-84F等性能更優秀的噴射偵察機,也是在這段時間為中華民國空軍所接收的。後來海峽上空的所有空戰,都是為了保護這些戰術偵察機的原因而爆發。

第四偵察中隊還一度以RB-57坎培拉偵察機為主力,針對中共研發核武的設施執行高空偵照。RB-57後來被證明,並不是一款適合投入於高空偵照任務的機種,所以美國空軍與中央情報局又將更好的U-2提供給空軍第35中隊,於是就有了「黑貓中隊」的誕生。外號「紅狐中隊」的第4中隊,則在接受RF-101巫毒式偵察機後又重新回歸戰術偵察的老本行。

RF-101的使用國相當稀少,中華民國空軍在美國方面安排下,固定維持4架到6架的編制,摔一架補一架。第12中隊方面,也從1965年起接收被稱呼為「飛行火箭」,速度極快又難以駕馭的RF-104G星式偵察機。以上提到的所有機型,都沒有武裝,所以駕駛他們飛入對岸拍照的偵察機飛行員都必須要有高超的飛行技術。

就以服務第12中隊的施龍飛教官為例,他在1958年8月13日駕駛RF-84F飛入大陸執行偵察任務時遭到中共MiG-15戰機攔截。為了確保宋亨霖駕駛的長機能平安飛回台灣,施龍飛志願成為誘餌吸引米格機攻擊,直到他的RF-84F右翼整個被機砲貫穿為止。可施龍飛即便在如此不利的情況下,還是成功駕駛受傷的RF-84F返回桃園降落,他的飛行技術實在是不簡單。

截圖_2021-02-03_下午1_10_53
Photo Credit: 王德輝將軍
從F-5E閃電式到RF-104G星式,王德輝將軍飛過各代中華民國空軍的戰術偵察機

勿忘空軍的偵察英雄

如今空軍第六戰術偵察大隊和第四偵察中隊都已成為歷史,第12偵察中隊仍以第12戰術偵察機隊的名義存在於中華民國空軍的編制之中,仍隸屬於花蓮空軍基地的第5戰術混合聯隊。雖不再被允許飛入中國大陸,以RF-16戰隼式偵察機還有RF-5E中正式偵察機為主力的他們,卻仍是偵測對岸中共軍事行動的第一把交椅。

這裡提到的RF-5E,是由新加坡宇航為中華民國空軍改裝的F-5E中正式戰鬥機偵察型。而F-5E中正式戰鬥機與先前提到的F-5E閃電式偵察機,又是兩款完全不一樣的概念。F-5E閃電式偵察機為洛克希德P-38戰鬥機的偵察型,名字與諾斯洛普公司在60年代打造的F-5E一樣,但前者為螺旋槳機,後者則為噴射機,在此特別給予解釋,以防止讀者們混淆。

而在進入21世紀之後,偵察機的概念與過去也非常不同。所謂的RF-16並非過往意義上的F-16戰鬥機偵察型,不是加了一個R字就從戰鬥機變成偵察機。RF-16指的,其實是加裝了AN/VDS-5 LOROP-EO「鳳眼」偵照莢艙的傳統F-16戰鬥機。與過去駕駛無武裝偵察機執行偵察任務不同之處,在於RF-16仍可掛載少量的響尾蛇空對空飛彈。

不過戰爭模式的調整,卻無法改變空軍從以前到現在都在第一線保衛台灣的事實,而空軍的偵察飛行隊依舊是維護中華民國安全的先鋒。回顧過去72年來的歷史,王德輝表示空軍剛剛到台灣的時候,台灣整體社會風氣還是非常的保守。活潑的空軍總是走在時代的尖端,引領社會潮流的改變。當時的他們,稱得上是全台灣,甚至於整個中華民國法定範圍內最接近天堂,最接近美利堅的一群人。

許多新的觀念,新的科技,乃至於流行文化都是他們帶入台灣的。甚至我們今天習以為常的營養午餐,所有的新概念都是由空軍率先開發出來。今天我們感謝空軍,感謝第六戰術偵察大隊的前輩們為國家做出的貢獻,不只是他們在台海上空與米格機周旋的事跡,還有他們如何給我們的生活帶來了真正有意義的改變。從這個角度上來看,筆者認為他們值得我們2300萬人民的共同尊敬。

責任編輯:彭振宣
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!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。

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


猜你喜歡