西安居民封城日記:食物短缺又不給採買,做核酸是唯一可以下樓的理由

西安居民封城日記:食物短缺又不給採買,做核酸是唯一可以下樓的理由
Photo Credit: Reuters / 達志影像

我們想讓你知道的是

一座擁有1300萬人口的城市,不缺資源,何況封城後還有很多的物資捐贈,但是為什麼就這麼難於到需要的人手中?病危者、滯留者,在這樣的一刀切的停擺背後該如何挑戰生存?

文:小法(西安封城居民)

朋友發來微信:「嗨,怎麼樣?還好吧?我看西安封城了……」這是西安封城後的第二天。

2021年12月24日晚上,馬路上原來的車水馬龍聲已經聽不見了,從樓上窗戶望下去,一排排昏暗的路燈照耀著乾枯的樹枝,幼稚園、學校大門緊鎖,商店、超市、餐廳閉門謝客,冷冷清清,慘澹黯然,一切靜謐地令人喘不過氣,隔離居家的日子已經開始……

封城之前

大家都在紛紛議論,西安雁塔曲江那邊發現了COVID-19(嚴重特殊傳染性肺炎、新冠肺炎、武漢肺炎)感染病例,已經隔離了相關人員,因「清零」政策使然,會不會封城啊。

我打電話給雁塔那邊經常去的餐廳,想確認一下是否正常營業,過去吃飯。老闆說:「前天已經讓關門了,因為附近社區發現感染病例,整個社區的人拉去集中隔離,這條街都封了,也不知道啥時候能開。」

街上,戴口罩的人多了起來,人們形色匆匆,公交上的人也少了。市內有很多免費的核酸檢測點,排很長的隊,有些單位和商業大樓要求必須有48小時核酸證明才可以准入,很多人都需要做核酸方便工作或出行。

12月21日,人們開始蜂擁至超市商場,囤積米麵、蔬菜、水果等食品和生活的必需品。22日晚,很多超市、商場和便利店的各種食品和衛生紙等日用品被搶購一空,人們擔心一旦封城,採購會成為難題。

這一天,我收到很多人的資訊,有家人和朋友的,都讓我也買點吃的囤著,以防萬一。但是,工作原因我還沒有時間去採購,同時也覺得家裡還有些餘糧,情況應該沒那麼嚴重,也就沒太在意。

啟動封城

12月23日零時,西安市決定實施疫情防控提級管理,全面加強管控措施,解除時間另行通知。封城開始。

各社區實行封閉式管理,每戶家庭每兩天由一人外出採購生活物資,其他家庭成員除在疫情防控、城市運轉保障、居民生活密切相關行業工作外,一般不外出,外出需持單位、社區開具的證明。

我拿著公司的證明,出了社區。街上零零星星的車,寥寥無幾的行人穿著厚衣服,戴著口罩,步伐匆忙沉重。穿防護服的工作人員和志願者在街頭的核酸檢測點堅持工作,排隊的人已經非常少了。

到了公司樓下,保安不讓上樓,說是上面說了,不能進去你趕緊回家吧。我說去辦公室取個東西,馬上回。保安勉強同意,讓快取快離開。電梯和辦公樓裡空空如也,非常安靜。進了辦公室,看了看我養的小金魚,順道給換了水,給那幾盆花澆了水,取了電腦就下樓離開了。

回去路上,想著去附近菜市場或者便利店買點東西。市場、飯館都已經關閉了,街上只有零星的幾個賣菜的,買菜的人也不多,於是趕緊買了些土豆、蘿蔔、白菜、青椒和番茄等。賣肉的鋪子也關的差不多了,好不容易看到一家開著,買了些肉。家裡還有一整袋米和麵沒拆封,應該夠吧,這樣想著就到了家。社區保安看到我買了那麼多東西,說「你這是去採購還是去單位啊?」因為我拿的單位證明出去的,我無語,懶得爭辯,平時他挺和藹可親的……

朋友打來電話,他是民生保障部門的,有通行證,說我需要啥他可以幫我帶過來,我表示感謝,請他注意防範,說有需要會聯繫他。

RTS42WH1
Photo Credit: Reuters / 達志影像

飲食不日常

過了兩天,又接到通知任何人不得以任何理由出門。管控措施再度加強。

親朋好友都紛紛來電,最關心的就是吃的夠不夠。因為當時家裡的米麵都是十斤裝的,我開始有些不淡定了,家裡四口人,這能撐多久啊!

於是開始找網上的店鋪,各種群裡發的好多購物連結和老闆的微信名片,說是可以買米麵油和菜。點開連結下不了單,要麼沒貨要麼送不了。加了微信名片,人家說必須50份以上的訂單才給送。這下真有些慌了,我開始心裡計算家裡的食品能撐多久。

12月29日政府新聞發布會的直播,評論區被「買菜難」攻陷,結果乾脆關閉了評論。

第二天,看到政府免費送菜的消息。好吧,那我們等等。慢慢地,看到曲江、雁塔、碑林等區的圈友已經開始在朋友圈曬政府送的菜,大家看上去很開心。我們繼續等待,沒抱太大希望,因為全市配送物流全部停擺,靠基層人員配送,那得需要更長的時間。三天后,社區物業通知下樓領菜,於是我們第一次領到了政府的免費菜:兩個土豆、一棵白菜、一根蘿蔔、兩根蔥、兩個洋蔥、一個蓮花白(高麗菜)。

米麵油和水果還是得想辦法購得。社區群裡有人說他在鮮超上班,大家可以接龍訂單,隨後送到社區,於是興高采烈地跟著接龍,有各種菜和水果,都是套餐配好的,一份89元,也還算合理。下單後,第二天貨車送到了社區門口,大家排隊按訂單領取,這下心裡踏實多了,不是因為買到的東西,而是覺得還有採購的可能。

第二天準備再買點時,這個鮮超不給送了,說我們社區物業認為他們的核酸不在有效範圍內。我暈,心裡七上八下。

緊接著社區通知,聯繫好了隔壁的超市,第二天11點在社區後門排隊採購。他們的貨車開進了社區,社區門趕緊關上了,大家排著隊,間隔一米,戴著口罩我們終於買到了麵、油,其他還有各種菜和水果,還有優酪乳。

老人們常說,家有糧心不慌,這次是真真切切體會了一把,千真萬確呢!

這時,一位好久沒聯繫的朋友發來資訊,說兒子剛到西安找工作,跟別人合租的房子,現在就剩幾包速食麵了,能否支援一些吃的。我馬上聯繫,他說沒有儲備食物,有賣菜的,但是房子裡沒有炊具啥的,沒辦法做飯,之前都是在外面吃或叫外賣,現在外賣也叫不上,剛到西安也人生地不熟的。


猜你喜歡


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

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


猜你喜歡