波士尼亞與赫塞哥維納分離主義衝突加劇,巴爾幹半島「歐洲火藥庫」恐再次引爆

波士尼亞與赫塞哥維納分離主義衝突加劇,巴爾幹半島「歐洲火藥庫」恐再次引爆
10月初,民眾上街抗議塞族共和國總統多迪克(Milorad Dodik)領導的政府貪腐無能|Photo Credit: AP / 達志影像

我們想讓你知道的是

目前波赫的塞族共和國態度強硬,並稱若西方國家打算插手干預,他也會尋求「塞爾維亞盟友們」的協助。此舉極有可能是壓垮該區脆弱和平的最後一根稻草;更可能讓早有「歐洲火藥庫」的巴爾幹半島,再次成為世界強權角力的代理戰場。

文:王國仲

美國資深官員11月16日指出,美方正密切關注波士尼亞與赫塞哥維納(以下簡稱波赫)的政治危機。他並警告當地民族分離主義領導人,如果試圖「撕裂這個飽受戰火摧殘的多民族巴爾幹國家」,美國已準備好相對應的制衡手段。

波赫民族衝突持續,歐洲火藥庫恐再次引爆

隨南斯拉夫聯邦解體,波赫在1992年宣布獨立。當時,由塞爾維亞支持,企圖建立單一民族國家,最終重回塞爾維亞懷抱的塞裔族群(約占總人口的30%),與希望正式獨立成為新國家的克羅埃西亞(港譯「克羅地亞」)人與波士尼亞人(分別約占總人口20%與40%),因為民族、理念與宗教等種種不同,產生強烈齟齬。

1992年2月底,波赫針對獨立議題舉行公民投票。由於塞爾維亞族群選擇抵制投票(因此投票率僅有63.4%),高達99.7%的投票者支持獨立。美國、歐盟與聯合國等重要國際組織與國家,也陸續於同年4、5月正式承認波赫獨立地位。對此結果極為不滿的塞爾維亞族群決定訴諸武力行動,波赫內戰因而爆發。

從1992年4月開始,直至北約、聯合國維和部隊等介入調停,內戰在1995年12月結束為止,共造成至少10萬人死亡、超過200萬人(超過總人口數的一半)流離失所。

停戰後的和平協議,將波赫分為兩個實體——「波士尼亞與赫塞哥維納聯邦」與「塞族共和國」,雙方分別維持高度自治,僅在國防、司法體制與稅務等議題上採取共同方針。不過,民族衝突問題並未徹底獲得解決。

塞族共和國至今並未放棄脫離波赫的理念。共和國總統、波赫主席團塞族代表與民族分離主義者多迪克(Milorad Dodik),已取得塞爾維亞、俄羅斯等國支持,於2021年10月宣布即將退出中央國家機構,更要在11月底前正式成立屬於自己的軍隊和司法系統。

目前多迪克態度強硬,並稱若西方國家打算插手干預,他也會尋求「塞爾維亞盟友們」的協助。此舉極有可能是壓垮該區脆弱和平的最後一根稻草,重新爆發大規模衝突;更可能讓早有「歐洲火藥庫」的巴爾幹半島,再次成為世界強權角力的代理戰場。

美方制裁成效不彰,觀察家批評西方國家「未盡應有責任」

美國國務院顧問喬磊(Derek Chollet)剛於11月18日結束波赫訪問行程。在為期三天的拜訪中,他和波赫各派高階領導人會晤,希望解決自1995年底血腥內戰結束以來的最大政治危機。

喬磊接受《美聯社》訪問時表示:「我們呼籲波赫各領導人,將國家利益置於一己之私之前……如果他們執意走上分裂、背離中央政府的道路,我們將運用各式工具懲罰此類行為。」

喬磊在訪問中提到,加大制裁力道也是可能的手段之一。由於持續否認內戰時期違反人權等犯行,且多次試圖阻撓、破壞和平協議,多迪克自2017年以來就名列美國的制裁黑名單,據稱美國國務卿布林肯(Anthony Blinken)也正在評估加大制裁力道與範圍。

AP_21275649638870
Photo Credit: AP / 達志影像

不過,總部位於塞拉耶佛的非政府組織「Bosnian Advocacy Center」負責人錫迪克(Ismail Cidic)認為,縱使美國加大制裁力道,實質影響仍然有限:「如果美國希望制裁能有更大成效,他們必須把歐盟拉進來一起實施,畢竟多迪克與其合作夥伴的事業,多和歐洲或俄羅斯有關。」

德國曾呼籲向多迪克實施制裁,但未獲太多歐盟國家響應,僅有荷蘭、盧森堡、比利時與捷克明確表示贊成。批評者認為,美國和歐盟並未負起「應有的責任」,導致波赫問題在1995年內戰結束後不僅沒有獲得解決,反而更加嚴重。

德國智庫Democratization Policy Council高級研究員巴蘇納(Kurt Bassuener)認為,大西洋兩岸的國家都「不願承認政策錯誤」,也並不是真心想解決波赫問題。他表示,歐盟遲遲未能協助波赫正式加入歐洲國家陣營,導致其擴張政策失敗,更給了俄羅斯等其他行為者有機可乘。

長期關注巴爾幹地區情勢的分析師與記者拉塔爾(Srecko Latal),也在《紐約時報》撰文指出,縱使西方各國的努力對維持巴爾幹地區的平衡與和平至關重要,他們對前南斯拉夫的解體卻「反應遲鈍」,儘管在後續數十年中投入大量資源與人力協助重建該地,美國和歐盟的解決方案也時常是「短期且草率的」。

隨著注意力轉向阿富汗與伊拉克,美國在21世紀後對波赫的關注日益減少,並將重要任務移交歐盟,目標是讓波赫作為歐盟成員,加入西方陣營行列。不過,受限於歐盟成員內部的種種問題與分歧,別說成為會員國,波赫至今連歐洲單一市場都未能加入。

西方國家的舉措失當,的確導致波赫情勢日益惡化。舉例而言,多迪克原是一位自由主義者,更受到美國支持,卻在對西方國家的承諾遲遲無法兌現後轉向民族主義,並在俄羅斯默許、撐腰之下轉趨極端。遭到西方「拋棄」的波赫各族群也各自轉向土耳其、波灣各國,甚至中國等希望分一杯羹的境外勢力求助,使當地的權力分配情況更顯複雜難解。

波赫仍須負最大責任,美國認為仍有轉圜餘地

當然,局勢至此,波赫本身仍必須負上最大責任。當地政治人物與媒體多把分化其他族群、製造仇恨作為創造聲量的主要手段,多迪克也並非唯一一個激進民族主義領導人——以信奉伊斯蘭教為主、人數最多的波赫族群長期以來激烈鼓吹建立統一的波赫;克羅埃西亞人則爭取建立屬於自己的民族自治區。

若多迪克持續推行獨立司法、軍隊計畫,將明顯破壞得來不易的和平協定。克羅埃西亞民族領導者則可能會以試圖恢復內戰前的自治範圍作為回應;波赫穆斯林們也將不計一切代價(包括拿起武器)保衛屬於自己的權利。再加上外國勢力推波助瀾、提供資源和武器,波赫局勢甚至比1992年時還更為險峻。

儘管火藥桶上的導線似乎已被點燃,喬磊認為情況還沒有到無法挽回的地步:「我們仍相信有機會可以挽回這一切。不只是美國,歐洲的盟友也這麼認為。我們必須做出許多困難的決定,不過美國會竭盡全力,避免最糟糕的事態發生。不只如此,我們更要努力達成更佳的結果:把波赫推回歐洲-大西洋夥伴關係的正軌之上。」

延伸閱讀

新聞來源

責任編輯:羅元祺
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡