【國際大風吹】上海封城未平、北京疫情又起,中國為何不計代價都要「清零」?

【國際大風吹】上海封城未平、北京疫情又起,中國為何不計代價都要「清零」?
Photo Credit: Reuters / 達志影像

我們想讓你知道的是

北京在勞動節前夕疫情升溫,封控措施蠢蠢欲動,但上海封城已經重創經濟與民心,為何中國政府仍堅持看似得不償失的清零政策?答案或許與下半年的中共20大有關。

台灣的COVID-19疫情最近一路飆升,不過在疫苗覆蓋率夠高的考量下,政府防疫政策逐漸轉向與病毒共存。在此同時,中國仍然是全球極少數堅持清零政策的國家。

一線大城上海,從3月底以來實施封控,到現在已經超過1個月,終於有部分地區微解封,但4月一整個月傳出醫療系統崩潰、民生物資匱乏等等亂象,甚至還發生確診但是還活著的75歲老人,竟然被放進屍袋,差點被送去火化的荒謬事件。

但上海疫情還沒解除,首都北京也在勞動節前夕傳出疫情上升。北京會封城的可能性,頓時掀起一波恐慌情緒。儘管截至5月5號,北京沒有封城,但不禁讓人質疑,連一個病例都不能容忍的政策,目前為止帶來什麼樣的代價?中國政府又為什麼這麼堅持要動態清零呢?

上海封城陰影下,北京疫情升溫中

五一勞動節前後,中國有長達五天的連假,本來是旅遊度假的旺季,北京街頭卻顯得有些冷清。原來,就在連假開始前一晚,北京突然宣布,連假期間,包括電影院、健身房等等,娛樂場所暫時關閉,娛樂表演也暫停,餐廳只能外帶不能內用,而且出入公共場所、搭乘大眾交通工具,都必須持有48小時內的核酸檢測陰性證明。連假之後,也要有48小時內陰性證明才能回去上班。

我們本來想去一些地方旅遊、去玩,然後現在看到病毒特別嚴重,就可能待在家裡,或者在家裡做一些體操活動

北京8歲市民 鍾姓女童

北京突如其來改變規定,打亂大批民眾的放假計畫。社群平台上出現困惑、錯愕,甚至憤怒的情緒。

有人質疑上個公廁也要做核酸嗎、有人擔心檢測點大排長龍,非常掃興,也有人罵這就是封城,只是換個說法而已。在收緊政策之前,北京在六天內出現100多個病例。擔心上海的景象在北京重演,有民眾開始囤積物資,也有人瘋搶冰箱冰櫃,甚至有人想開車到外地躲封城。不過也有人認為北京政府警覺心夠,應該可以避免疫情擴大。

相信北京政府肯定不會說,像上海那種,可能因為有一些管控,一開始可能因為鬆懈,而引起發生(封城)

北京市民

然而,北京疫情在連假期間卻持續升溫,從4月22號起,每天的新增病例都微幅增加,到了5月5號已經累積500多起病例,其中200多例出現在最繁榮的朝陽區,官方下令全區盡可能在家工作。為了避免病毒流竄,也先後關閉64個地鐵站。官方表示,這波疫情確診數已經超過兩年前北京疫情首次爆發的新發地市場群聚,形勢相當嚴峻。

上海等地封城代價高昂,重創民心與經濟

如果北京也走到封城這一步,衝擊將難以想像。上海2500萬人面對超過50天的封控生活,大量人口搶不到民生物資而被迫挨餓、蔬菜水果價格飆漲好幾倍、需要急救的病患延誤搶救時機,甚至傳出不堪隔離的大學生跳樓結束生命,都累積了大量民怨。

除了直接衝擊民眾生活,經濟活動陷入停擺的隱形傷害也相當可觀。上海、吉林、江蘇等大城,封控區的服務業營收大幅銳減之外,很多製造業停工也已經造成供應鏈問題。中國國家統計局4月30號公布,4月綜合PMI、也就是可以反應製造業景氣的採購經理人指數,下跌了6.1個百分點,來到42.7%,創2020年3月以來的新低。

換句話說,最近這波疫情對企業生產經營的衝擊,已經跟2020年初疫情剛爆發的時期差不多了。

人民銀行貨幣政策委員會委員王一鳴,2022年第一季經濟成長,無法達成原本預期的5%以上,主要是因為疫情多點爆發以及俄烏戰爭影響,而這些因素會持續到第二季,讓經濟面臨比較大的下滑壓力,必須有效控制疫情,才有機會達成中國全年經濟成長5.5%的目標。

為了穩住經濟,上海在疫情還沒完全清零之前,就實施復工、復產,深圳直接向市民發放消費券,甚至被壓抑已久的房市管制措施,也獲得放鬆。

堅守清零,只為讓西方難堪與連任總書記?

目前中國流行的COVID-19病毒以Omicron變種為主,雖然傳染力強,但重症率和死亡率比之前的變種要低。從歐美到亞洲的新加坡、南韓等國家,紛紛從去年開始,放鬆管制措施走向共存。與其不計代價追求清零,中國是不是該考慮稍稍放鬆管控呢?官方並不認為。

我國是人口大國,地區發展不平衡,醫療資源總量不足,如果放鬆疫情防控、放任病毒傳播,勢必在短期內造成大量人群被感染,進而出現大量重症和死亡病例

中國國家衛健委副主任 李斌

研究中國政治和社會的英國牛津大學教授藍夢林指出,從2020年疫情爆發以來,領導人習近平就一直堅持清零政策,目的是展現政府把人民的健康擺在第一位。

如果中國能壓低重症和死亡數,更能夠跟西方民主國家有所區別,尤其在美國疫情死亡人數直逼百萬的此刻。為了證明這件事,政府甚至不肯進口西方製造的mRNA疫苗。然而,Omicron讓疫情難以完全撲滅,也讓強力封控手段既代價高昂,又顯得徒勞無功。「政府盡力保護人民」這套說法,在上海封城這段時間,引發前所未見的質疑聲浪。

RTS7JUAT
Photo Credit: Reuters / 達志影像

旅美中國時事評論員鄧聿文則是指出,習近平在上海封城爭議最大的4月份,儘管依然強調疫情必須清零,卻完全沒有在任何公開發言中提到上海,沒有試圖安慰怨聲載道的上海人。鄧聿文認為,這不代表他沒有處理上海防疫工作,但卻是有意識的跟上海保持距離,避免捲進這個爛攤子。他的動機應該跟今年下半年俗稱「20大」的中國共產黨全國黨代表大會脫不了關係。

外界普遍預期,即將在秋天舉行的中共20大,將會推出新一任的中國領導團隊。其中,從2012以來已經擔任10年總書記、也就是最高領導人的習近平,在2018年修憲廢除國家主席之後,很可能會打破慣例,尋求第三段中共總書記任期。

加州克萊蒙特麥肯納學院的中國專家裴敏欣教授認為,長期封城帶來的經濟損害和民怨,應該不至於影響習近平追求第三任總書記的目標,但可能會打擊他的政治地位。中國歐盟商會主席伍德克則預估,在20大之前,習近平不可能放鬆清零政策,以免打臉過去兩年來以防控疫情為傲的政府立場。但為了維持顏面而反覆嚴格封控,恐怕也代表社會面和經濟面的衝擊將持續下去。

延伸閱讀

【加入關鍵評論網會員】每天精彩好文直送你的信箱,每週獨享編輯精選、時事精選、藝文週報等特製電子報。還可留言與作者、記者、編輯討論文章內容。立刻點擊免費加入會員!

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


猜你喜歡


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

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


猜你喜歡