阿富汗淪陷後,拜登政府有四大問題讓全世界盟邦都要捏把冷汗

阿富汗淪陷後,拜登政府有四大問題讓全世界盟邦都要捏把冷汗
Photo Credit: Reuters / 達志影像

我們想讓你知道的是

從目前危機發生後拜登3次出來面對公眾(兩場記者會和一場訪談)的表現,有4大問題讓全世界的外交專家和盟邦都要捏把冷汗。

文:趙君朔

從塔利班在8月6日攻下第一個省會Zaranj到15日僅花了九天兵不血刃地進入首都喀布爾後,阿富汗的混亂情勢馬上成為全世界的焦點。

台灣因為特殊的安全處境和日益緊張的兩岸情勢對此議題馬上有兩極化的反應:一邊是看到美國狼狽現況馬上大肆鼓吹美國果然不可信的國民黨陣營;一邊是迅速反擊強調台灣和阿富汗處境不同,並在看到美國國家安全顧問蘇利文和拜登在公開談話中先後重申、加碼對台灣的保證而歡欣鼓舞的主流台派陣營。

世人質疑的是決心和做法

事實上,兩邊的反應可能都出現了盲點:國民黨的論述再度凸顯了它們在失去執政地位後對於國際情勢的陌生和一廂情願;台派雖然對國際情勢的掌握相對正確、敏感很多,但這次的疑美論或是說疑拜論,關鍵不在對客觀國際情勢的解讀,而在於美國政府最高層處理阿富汗問題一路暴露的問題,讓人對拜登政府能否繼續扮演好世界警察的角色感到憂心。

的確因為拜登政府的失誤,這場最壞會有美國人淪為塔利班人質、大批替美國、北約工作過的阿富汗人被抓出來清算的危機根本還在進行中,要談後續對區域情勢、美國外交關係和美國國內政治的影響還太早。

從目前危機發生後拜登三次出來面對公眾(兩場記者會和一場訪談)的表現,有四大問題讓全世界的外交專家和盟邦都要捏把冷汗。

1. 他打破了美國領導人遇到外交挫敗的傳統

不管最終責任歸屬怎麼樣,最高層總是抱者「萬方有罪,罪在朕躬」的態度去面對。因此本期《經濟學人》的Lexington專欄中,專欄作者忍不住回顧了艾森豪將軍在諾曼登陸的前夜草擬了一份自責聲明(mea culpa)備用,甘迺迪總統為豬玀灣事件負起了全責,還有杜魯門總統桌上的牌子「責無旁貸」(The buck stops here)。

但到目前為止拜登對阿富汗危機的談話,《美聯社》和《經濟學人》都用了硬凹(defiant)來形容他的態度,把責任全部都歸諸於阿富汗政府和軍隊的腐敗無能。

2. 為了撇清責任,對於美國過去20年在阿富汗的任務也做了並不客觀的陳述

他把美國攻進阿富汗講成只是為了消除恐怖主義的威脅,又說既然這個任務早已經達到,美國當然沒有理由一直留在當地。但實際上美國至少在小布希時期是有個宏大的國家重建計劃,要把阿富汗建設成一個民主、開放、尊重女權的新國家。

就連參議員拜登和兩位同事在2008年2月在喀布爾和阿富汗第一任總統卡札晚餐時,都因為卡札當場完全否認拜登3人提出的貪腐嚴重問題憤而提早離席成為話題。這個拜登親身參與的外交會面軼事本身就證明了美國對阿富汗的關注遠超過反恐議題。

3. 拜登本人對阿富汗第一線情況缺乏掌握,在記者會上說的話很快和下屬機構公布的訊息矛盾

拜登在上周5記者會上說美國人都能順利抵達喀布爾國際機場,但次日美國阿富汗大使館便發出警示表示因為機場外的安全情況堪憂,除非個別美國人有受到美國政府代表的指示,否則應避免前往機場。

其次拜登也表示目前因為反恐任務已經順利達成,阿富汗目前沒有基地組織成員的蹤跡。但國防部發言人隨後就被問到,國防部自己的評估是基地組織早已在阿富汗境內恢復活動,是否和總統說的互相矛盾。國防部發言人只好一臉尷尬的重新解釋國防部的評估和拜登的發言沒有衝突。

4. 拜登還直接宣稱美國並沒有受到盟友的質疑,在阿富汗進行的事就是按照美國的承諾進行,但是最可能成為德國總理接班人的基民黨主席Armin Laschet直言「這是北約成立以來最大所見最大的挫敗」

英國執政黨國會議員、外交委員會主席,曾派駐阿富汗的Tom Tugendhat直接在國會演說中把拜登對阿富汗軍隊缺乏勇氣的批評形容為可恥(shameful)。法國駐美大使館在8月20日也發出一條推文轉達法國總統對拜登的提醒:法美兩國對於阿富汗人負有共同的責任。

RTXG66AZ
Photo Credit: Reuters / 達志影像

紊亂其實其來有自

所以就總統本人談話看來,他明顯都對情況缺乏掌握。在上上周阿富汗情勢一瀉千里的幾天,他幾乎都在大衛營度假,並歡慶他一心想推動的1.2兆美元基建計畫在參議院獲得跨黨派的支持通過。

雖然《Defense One》雜誌揭露早在今年3月後參謀首長聯席會議主席米利便提醒拜登如果美軍在阿富汗減少到2500人以下,塔里班會迅速得益於此情況。後有7月13日美國駐阿富汗大使館22名美籍員工聯名透過警示管道(dissent channel)提醒美國要盡速開始撤退人員因為阿富汗政府很可能迅速潰敗,但這些聲音似乎都沒有被拜登的國安外交團隊最高層重視。

除了國務卿布林肯對於第一線傳來的緊急警告沒有給予足夠的重視,長期跟隨拜登的年輕國家安全顧問蘇利文也是難辭其咎。畢竟阿富汗的局勢不僅限於外交層面而是需要經過他的統合分析後給拜登建議,這也是為什麼他是第一個國安外交團隊出面在白宮記者會上回答種種提問的官員。

但根據川普時期的美國駐德國大使也代理過3個月國家情報總監Richard Grenell的看法,蘇利文很可能是根本不重視從第一線傳回來的最新情況,只是按照自己原來坐在辦公室裡想當然爾地擬好的白皮書來執行撤軍,才會弄到今天這種局面。

此外還有一號人物的角色也很值得玩味,那就是也被賦予外交重任的副總統賀錦麗竟然在此危機當頭的時刻照原定計畫出訪東南亞。而阿富汗危機爆發的一周以來,她也沒有承擔任何的角色,只是在危機剛爆發的時候對媒體表示,當拜登在4月做出全面撤軍決定時,她是留在房內的最後一人,但現在出事了,她卻躲得遠遠的不發一語。

這和她在日本、韓國元首前來白宮訪問時都是由她先接見,更早之前她也曾打破慣例,直接和法國總統馬克宏、加拿大總理杜魯道通話都形成強烈對比。

至於軍方在此危機中的角色更尷尬了,在8月18日由國防部長和參謀首長聯合舉行的記者會,先是國防部長承認了目前沒有足夠兵力能離開機場安全區到進入喀布爾市內把要撤離的美國公民護送到機場。

再來參謀首長米利則是點出沒有一份他讀到的情報資料評估能準確預測阿富汗政府會在11天內就潰不成軍(這和前面提到米利三月發出警告其實是矛盾的),而根據《CNN》記者的觀察,兩人在國防部記者會上的神態都很彆扭(uncomfortable)。

RTXG23KK
Photo Credit: Reuters / 達志影像

拜登與他的國安團隊都還沒進入狀況

綜合上面對拜登本人的講話還有整個國安外交團隊要角的敘述就能看出,至少在對外事務上本屆美國政府的運作出了很大的問題,處理阿富汗撤軍時的表現更和拜登政府標榜的多邊主義、團結盟邦、好好運用外交手段等口號形成強烈對比。

結果就是北約盟邦都被弄得措手不及,連日本都在請英國幫忙撤出一部分僑民後,23日召開的國家安全會議會正式決議,同天晚上要派出一架軍機前往阿富汗撤出在國際組織工作的日本僑民。

進一步看,美軍完全撤出把阿富汗留給神學士後對區域情勢和大國關係的影響當然還有很多值得討論之處。但因為美國這幾個月來處理的失誤造成眼下短期內要在911事件20周年前徹底離開的目標背道而馳。不但加派了兵力前往阿富汗,在8月24日要臨時召開的G7會議中,英國首相強森也要和拜登商討延長美軍和北約駐留期限到8月31日之後的可能性。

除了操之過急反而達不到目標,每天傳出來的地面混亂情況讓美國成為世界笑柄外,為了處理阿富汗亂局,布林肯國務卿只好和中俄兩國的外長通電話,尋求幫忙穩定阿富汗局勢。這讓美國在尋求和中共建立交往新框架的談判中等於又給了中共籌碼,也讓人更懷疑拜登政府是否真的能對中共維持和川普一樣強硬的態度。

總之一場原本被認為不算外交軍事重頭戲的小規模撤軍現在竟然變成類似好萊塢電影《亞果出任務》、《黑鷹計畫》所描繪的災難場面實在令人始料未及,現在只能盡可能的應變。美國政府已經要根據法令徵用6家民間航空公司的飛機來進行救援,希望在後面的撤退過程中不要有任何重大傷亡傳出,才能避免這場危機蔓延到美國國內並再度打擊美國的國際形象。

也希望拜登政府經歷此重大考驗能痛定思痛,重新檢討整個國安外交團隊的運作而不能只是在逼問下做出動聽的保證,之後又沒有實際行動或是一樣的執行不利。如果持續這種等級的表現一定會引起部分盟友敵人普遍的不信任,也是想混水摸魚的獨裁者們作亂的最好時機,也讓America is back的豪語變成笑話。

延伸閱讀

本文經思想坦克授權轉載,原文發表於此

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


猜你喜歡


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

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


猜你喜歡