猶如「狼來了」的緊急事態宣言,象徵菅義偉政權與國民信任關係一刀兩斷

猶如「狼來了」的緊急事態宣言,象徵菅義偉政權與國民信任關係一刀兩斷
Photo Credit: AP / 達志影像

我們想讓你知道的是

本來最講誠信的日本人,現在在如同「戰時」狀態的宣言下也面臨道德觀念崩壞。但究其實,緊急事態宣言本身就無強制法律效力,日本沒有類似中央疫情指揮中心的強制機制,終究還是會面臨人性考驗。

最後宣言再度延長

日本首相菅義偉在8月17日晚間,再度宣布延長目前實施中的緊急事態宣言至9月12日。不僅如此,菅義偉內閣還追加7個府縣,總共13個都府縣為緊急事態宣言的實施區域,此外還再度追加10個縣,共計16個道縣為「防止疫情蔓延等重點措施」的對象,近6成的自治體被列為防疫對象。

本次的緊急事態宣言,是日本政府發布的第四次宣言,從7月12日起實施到8月22日,但隨後菅義偉又延長到8月31日,最後又再延長到9月12日,如果真的到時如期結束,東京都等區域將會發布宣言滿兩個月。

菅義偉在記者會上重申「給國民大眾這麼大的辛苦,我們也是心很痛苦」,並表示宣言能否解除,會視「守護國民健康生命的醫療體制能否確保」作為前提,包括疫苗施打狀況、重症病患人數與病床利用數等來決定是否解除。

不過對大多數東京都與首都圈居民來說,宣言發布時間如同「狼來了」一樣,雖然政府一直勸導少出門、少接觸,但是東京都等長期處於緊急事態宣言下,也出現很大的「自肅疲勞」。政府所設定的各項約束也都漸漸開始不再遵守,看不見疫情的盡頭下,反而讓許多人開始覺得「不如就出去吧」。

而在宣言宣布的隔天8月18日,全日本逼近2萬4000人確診,再度刷新最高紀錄。除了東京5386人外,大阪2296人、兵庫與愛知縣等都超過1000人,都是最高紀錄。讓人對9月12日疫情能否靠口說的「宣言」減緩,再度打上問號。

總裁選前最後一搏

根據多位日本政府高官跟媒體們透露,原先的延長方案中,也有「9月下旬」等不一樣的時程,最後菅義偉親自選了「12日」。這個日期除了是剛滿兩個月外,也被普遍認為背後有其政治考量。

2020年9月15日當選自民黨總裁後,菅義偉隨即走馬上任擔任首相重組內閣。作為前首相安倍晉三第三任期後半段的收尾,這一年菅義偉只被認為是安倍晉三基本路線延續者。然而,菅義偉的總裁任期將在9月30日結束,加上10月21日眾議院議員任期屆滿,是否要提前解散國會等,先前的總裁選舉時機就格外重要。

按照現在的9月12日時程,如無意外,日本媒體普遍預估可以在17日發布總裁選舉告示,順利地話可以在29日進行總裁選舉投開票,9月底時順利繼續接棒。

國會解散也有民意浮動的考量,比較壯士斷腕的是在總裁選舉前,菅義偉就先解散國會,然後先押後總裁選舉時程,不過這就要是疫情能否有顯著改善。相對保守的則是總裁選舉後,國會再解散,只是人氣低迷的菅義偉,能否繼續掌權,不確定的因素較多。

最保守的方案,就是先選完總裁,然後也等到眾議員法定任職屆滿的10月21日後自動進行國會選舉。這也是所有方案中最被動的,而且最重要的關鍵,還是要看疫苗施打能否普及,這也是菅義偉政權目前的唯一浮木。

RTXFPJ57
Photo Credit: Reuters / 達志影像

疫苗供給抵擋醫療失衡

根據日本NHK統計,在8月18日全日本施打新型冠狀疫苗的時間點,已經有50.3%的民眾(約6400萬)至少施打一劑,38.8%(約5000萬)的民眾施打完兩劑。日本政府預估在10月底、11月初,全日本的人都可以施打完兩劑,如果到時進展順利,對於自民黨來說會有正面效果。

根據《朝日新聞》引述官邸幹部話也表示「首相最近常說8月底過後氛圍就會轉變了」,主要原因也是在8月底後施打兩劑疫苗的國民也會破四成,如果有了基礎群體免疫,對於社會整體氛圍對疫情的不安也會開始減緩。

特別是日本規制改革擔當大臣河野太郎,也在16日接受日本電視台節目訪問時明確指出,未來疫苗將會「追加施打」第三劑,他並表示「施打兩劑美國輝瑞、美國莫德納疫苗的人們,都將會有(第三劑)相當充足的數量。」雖然目前疫苗的到貨率都不完全,但是這句話明顯是要先說給日本國民作為安定民心用。

另一方面,緊迫的醫療現場狀況仍為獲得舒緩,日本總務省消防廳在17日公布數字,顯示上一週有3361件是「救急搬送困難」狀況,意即發生緊急狀況,救護車載了病患卻無法找到醫院收治。當中,跟疫情有關的就佔了1679件,千葉縣更發生找不到醫院收治,五天後患者只能在家中死亡的悲劇。

道德觀念出現崩壞?

日本的確診狀況雖然在奧運舉辦後出現大幅激增,不過相比之下,東京的人流卻不減反增,甚至在開閉幕式當天,主場館的國立競技場附近也都充斥著人潮,假日時的各地景點也是人流不斷。

對於飲食業者來說,緊急事態宣言下縮短營業時間跟不能賣酒精,對營收是無情打擊。事實上,從這次7月開始的緊急事態宣言後,就有不少店家「棄守」開始在店面賣酒精,營業時間也回歸正常。雖然要面臨政府徵收30萬日幣「過路費」的變相懲罰,但對店家們來說,能守住業績跟顧客已經是最重要事項。

目前仍在恪守政府規範的,多數是大型連鎖居酒屋與餐廳,畢竟企業規模愈大,責任也愈大。但這也顯示出中小型的居酒屋店面,面臨沒生意就要斷炊的現實,類似「既然政府每次都說最後的宣言,然後每次都食言,繼續延長」、「超過40%反對奧運還硬要舉辦,那我也不想考量政府了」的聲音開始出現。

這也一定程度說明,目前政權跟國民之間的信任出現一定程度的裂解。本來最講誠信的日本人,現在在如同「戰時」狀態的宣言下也面臨道德觀念崩壞。但究其實,緊急事態宣言本身就無強制法律效力,日本沒有類似中央疫情指揮中心的強制機制,終究還是會面臨人性考驗。

而這樣的不信任如果難以癒合,往後也會投射到人民對政府的政治信任,甚至「一刀兩斷」。緊急事態宣言廉價感化的結果下,是否國民還會願意給菅義偉政權、甚至是自民黨再一次執政機會,今後政治布局變數將會愈來愈高。

延伸閱讀

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


猜你喜歡


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

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


猜你喜歡