美中正在爭鬥,國民黨與藍媒們卻不斷扮演「圍魏救趙」的棋子

美中正在爭鬥,國民黨與藍媒們卻不斷扮演「圍魏救趙」的棋子
Photo Credit: Reuters/達志影像

我們想讓你知道的是

中共的動機,就是透過統戰讓國民黨扮演圍魏救趙的馬前卒,在美國面前宣稱台灣對「中國夢、發大財」存有期待,而背後的目的就是要營造出「台灣的中國人不這麼認為,因為他們熱愛祖國」的形象。

就歷史的軌跡與制度慣性觀察,中共只要在政治上出現危機或陷入險境時,就會屢次操作「軟硬策略」藉以維繫其政權正當性。

硬的一手,即是透過戰爭邊緣策略與動員民族主義轉移內部的權力矛盾,這可從建政1958年大躍進災難發動第二次台海危機、文革高潮時爆發中蘇珍寶島衝突得到解釋;軟的一手,則是做對手的政治工作,經由統戰分化、激化內部矛盾關係,讓自己得以從困境中從容脫身——西安事變之後喊出的「抗日民族統一戰線」、《反分裂國家法》通過後所推動的第三次國共合作都是典型。

直言之,中共的各項政治作為,為了符合其「聯合次要敵人打擊主要敵人」、「以明天敵人對付今天敵人」的統戰邏輯,冷戰時期對外多以「和平共處五原則」作為號召,結合廣大第三世界國家孤立美蘇兩大強權;內部多以「中國人不打中國人」情感訴求,將國民黨做為打擊敵人的工具,在不同階段都能取得巨大效果。

美國已經看破中共套路,國民黨卻仍傻傻的當「馬前卒」

諷刺的是,美國已經從昔日的幻想中清醒,重新界定美中關係的性質後,認清習近平政權是民主政治與開放社會最大的威脅;反觀國民黨不僅未從歷史中得到教訓,反而還以此為榮且沾沾自喜。在民進黨兩次執政過程中,先前有連戰訪中開啟國共第三次合作的前例,現有高層提議簽署和平協議與韓國瑜訪中的回饋,當下在中共銳實力與假新聞的攻勢下,部分新聞媒體人在紅頂商人的穿針引線下再度成為統戰樣版。近日由旺旺中時報業集團與北京日報報業集團舉辦的「兩岸媒體人北京峰會」,正在上演前述驚心動魄的劇情。

當下美中經貿大戰方興未艾,卻已經對中共帶來了一連串的衝擊與骨牌效應。經濟衰退除了影響其國家治理能力外,更造成各項尖銳的社會矛盾,為黨內劇烈的權力鬥爭埋下伏筆。為了避免各類黑天鵝與灰犀牛的危機頻繁出現,中共堅信國民黨這張統戰牌在關鍵時刻必然發揮作用。

RTS1J47E
Photo Credit:Reuters/達志影像

中共的動機不難理解,就是透過統戰讓國民黨扮演圍魏救趙的馬前卒,對外宣稱台灣的民主體系與民意對於「中國夢、發大財」存有期待,同時也反制美國與西方世界對其意圖改變國際體系、破壞民主人權、運作銳實力介入各國政治、違反貿易自由化各項指控,目的再簡單不過:營造出「台灣的中國人不這麼認為,因為他們熱愛祖國」、「他們擁護中央的一國兩制台灣方案」的形象。

這樣的思維可從中共全國政協主席汪洋「台灣當局連兩年後的事都保證不了」、「美國不會為台灣和中國打仗,如果打,打得贏中國嗎?」的語境中一窺究竟。

對外虛張聲勢的狂言,附和的媒體其心可議

這樣的狂言,顯然與劉鶴在美國談判的處境、或外交部發言人跳針言行成為對照組,除了是裝腔作勢與吹口哨壯膽外,也難掩自卑引發自大心的態度。客觀來說,作為「一國兩制政協化」的最高統戰機構,汪洋怎樣都得把場面給撐下來,但是這種政治正確反成了中共的包袱,否則官媒為何將其講話秒下架呢?

面對汪洋此般虛張聲勢的言行,與會台灣媒體人竟然大笑附和,這種病態心理已經不是「斯德哥爾摩症」足以解釋。

對於藍營人士來說,明年奪權勝選的目標早已超越台灣的民主價值,為了確保打敗民進黨,他們可以縱容韓國瑜此般政治人物在議會質詢的醜態,默認其所高舉的一中各表早被「一國兩制台灣方案」所取代的窘境,無視中國透過假新聞介入台灣政局的事實,忽略中國目前踐踏人權箝制新聞自由的惡行。在威權國家討論媒體角色本身就是一件笑話,除了彼此的政治需求外,只剩下商業利益的分配罷了。

FullSizeRender_6
Photo Credit: 翻攝自中天電視台

何清漣在其著作《紅色滲透:中國媒體全球擴張的真相》一書中,提出「制度套利者」的概念就是深刻與生動的描述。所謂「制度套利者」,是指這些人明知道共產黨政權剝奪人民的言論自由、出版自由等權利,卻利用自己身處西方社會,由政治制度保障的言論自由這一便利,幫助宣傳紅色極權政治,以此建立聲望並獲得名利。

面對台灣輿論的種種質疑,這幫媒體人自然有一套理所當然的官方說詞或個人遁詞,推動善意交流或研究中國對台策略也好,追求兩岸和平互動新聞交流也罷,提醒這些握有文化霸權的筆桿子們,公民社會下的台灣民眾並不蠢。

延伸閱讀

責任編輯:丁肇九
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡