「以過勞養過勞」的24小時超商,其「便利性」是建立在何等的壓迫之下?

「以過勞養過勞」的24小時超商,其「便利性」是建立在何等的壓迫之下?
Photo Credit: Reuters / 達志影像

我們想讓你知道的是

為了省下大夜班的薪資,許多加盟者都自己硬著頭皮撐下大夜班的人力缺口,換來自身日積月累的過勞身軀,不過日前日本針對便利商店取消24小營業的研究發現,超商提早打烊,收入可能反會增加。

文:Tân Kuàn-Lîm(國立政治大學勞工研究所學生,前台灣勞工陣線協會實習生、國會助理實習生)

台灣與日本是兩個全世界便利商店密度最高的國家之一,現代人們的生活已經很難完全脫離全年無休的便利商店服務,但最近在日本吹起了一道檢討旋風。

日本7-Eleven東大阪門市取消24小時營業

在日本大阪府東大阪市的某間7-Eleven門市負責人的妻子去世,以至於他連續數個月工作時間都已經超過16個小時。在不得已情況下縮短營業時間後,便收到總部要求解除契約以及賠償違約金1700萬日圓(約合新台幣480萬元)。

根據朝日新聞報導,便利商店加盟店工會理事長酒井孝典在記者會上控訴:「門市負責人一般的工作時間,以勞工的標準來看,已經長到可以被認定為過勞死的程度。是要珍惜人命、還是重視連鎖店的形象,希望總部可以認真思考此事。」

雖然日本7-Eleven總公司在事件剛開始提出違約金賠償的要求,然而最新消息總公司也表明,已向該負責人提出更換成允許縮短營業時間的契約方案。此案件也成為了日本重新檢討24小時制營業的必要性。

日本超商的人力縮編潮

日本全家便利商店在加盟店面臨少子女化下的缺工環境與凌晨來客數減少的背景下,自今年3月起只要加盟店事前和總部達成協議、就可依加盟主自行的判斷來縮短營業時間。其總公司也於今年2月份宣佈組織精簡之自願離職方案,有1025人將在3月底將自願離職。據了解,其中約7成為門市指導員等在門市現場的員工,縮減數佔整體員工比重約1成。

另外,日本超商7-Eleven,於2019年10月份宣佈將關閉或遷移約1000間門市外,並在旗下連鎖超市伊藤洋華堂(Ito Yokado)和SOGO西武百貨(SEIBU SOGO)裁員約3000人。目前約有2200間的7-Eleven門市也希望能縮短營業時間;此數量相當於全國門市的一成多。

RTS2TQPA
Photo Credit: Reuters / 達志影像

而在日本市佔率第三名的超商Lawson,其擴增展店計畫也將急踩剎車。在2019年度(2019年3月至2020年2月),店鋪的增減數量與上個年度相比將會正負相抵形成零成長。Lawson面對深夜營業的議題,在橫濱市磯子區設立了深夜自助結帳機來作為應對勞動力短缺的對策。其主要在午夜00:00到清晨5:00販賣菸酒和微波食品,客人需要使用QR碼進行身份驗證系統才能進入購買,可以現金自助結帳或智慧型手機結帳進行付款。和其他兩家超商不同的是Lawson目前將保持營業時間為24小時,而不是縮短營業時間。

日本7-Eleven取消24小時營業後:利潤上升,過期食品沒增加

根據日本經濟雜誌Diamond的追蹤調查,7-Eleven在調整營業時間為早上6:00點至晚上00:00後商店的銷售額雖然略有下降一成。但是由於減少了深夜的高額勞動成本,最終縮短營業時間反而增加了加盟者的總體利潤,其增長幅度最高來到30萬日圓。而在未售出的食品和過期食品報廢的成本則沒有明顯變化。

調查指出,在來客數方面,超商雖然在深夜和清晨關閉期間銷售和來客數量有所下降,但是在凌晨6點開門後,透過通勤高峰時間的營業額提昇,其整體營業額幾乎與調整之前相同。

此外,白天的來客數量和營業額沒有太大的變化。到了晚上,營業額和來客數比24小時營業增加了更多。根據據店主說明,由於客人事先瞭解凌晨不營業,所以有著「如果不早點買超商就會關門」的心理,晚上的銷售和顧客數量皆有所增加。

觀察日本的調整營業結果,不難看出實際上在特定情況下取消24小時營業的超商利潤,可能會比維持原樣還來得高出不少。此外,在加盟店長勞動樣態上,更將近有三成數量的加盟業者每天工作超過12小時,且更有半數的加盟者年薪未達500萬日圓的。由於僱用環境日漸嚴苛,在提高深夜工資仍舊少人應徵的情況下,多數加盟者只好自己硬著頭皮每天努力撐下大夜班的人力缺口,雖然滿足了總公司的營業需求,但換來的則是自身日積月累的過勞身軀。

RTR3C7CB
Photo Credit: Reuters / 達志影像

台灣的便利商店態樣,其實不必「以過勞養過勞」

在台灣的深夜11點到12點,一群人加班工作到凌晨的資訊業工程師剛下班,他們早已錯過便當店的正常營業時間,飢腸轆轆的工程師只好轉向24小時營業的便利商店尋找食物。先不論超商的微波食品營養和口味如何,此時又要有另一群人們來滿足這些深夜下班者的服務需求——他們就是紅著眼在上大夜班的超商店員。

恰恰正是這個「以過勞養過勞」的服務模式,造就了台灣24小時全年無休的超商勞動樣態。其提供的「便利性」究竟是建立在何等的壓迫之下才得以達成的?超商店員從最早的商品結帳,一路進化到十八般武藝都必須精通,包含泡咖啡飲料、寄貨取貨、送洗衣服、影印掃描、壓霜淇淋……等等。超商店員的技能一再的增加,但薪資卻是一路貼著基本工資的地板在走。

反觀上述的日本案例,日本的高齡化和少子女化發展在前,24小時超商營運者面臨的人力短缺及深夜來客數減少,都是台灣即將面對的議題,更不需要談店員台灣過勞和大夜班的勞動權益受損的問題,也必須一併檢討。歐美大部份國家的商店和百貨公司也都是早早關門,其GDP和營業額也不見得比較少。因為他們知道有品質的服務是需要長時間的休息來養成。不是為了所謂的「便利性」來犧牲勞工的日夜生活循環,進而影響勞工身體與心靈上的健康,造成服務品質和效率降低。

我們應該思考的,是台灣的每一間超商真的都需要24小時營業嗎?隨著科技和勞動權利意識的發展,若我們多數人都能團結爭取到正常的工作時間和充足的休閒與睡眠時間,特殊需求可以透過無人販賣機滿足,實際上也不需要有人們犧牲自己紅著眼、拖著疲憊不堪的身軀來為我們服務了。

延伸閱讀

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


猜你喜歡


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

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


猜你喜歡