林佳龍喊公開名單49家客運業者承諾春節不鬆綁「七休一」,工會批夢話

林佳龍喊公開名單49家客運業者承諾春節不鬆綁「七休一」,工會批夢話
Photo Credit: 中央社

我們想讓你知道的是

范光明指出,客運司機14休1、15休1是不能說的秘密,而且司機員不足的問題平日就存在了,連假期間怎可能就獲得解決。

(2019年1月30日17:30,李秉芳更新)

連續9天的春節假期就在這個週末,為了因應連假疏運需求,勞動部應交通部與客運業者要求,日前公告客運業者在連假疏運期間能適用7休1鬆綁,還趕在農曆春節前實施,引發工會勞團抗議,新上任的交通部長林佳龍也不認同,在臉書上公開表態不同意,並要求公路總局多方宣導客運業照7休1規範而行。

林佳龍表示,他理解客運要提高疏運量,排班需要彈性,但安全不容打折,他不贊成讓司機長時間駕駛,並要求公開採用「10休1」鬆綁方案的業者資訊,保障消費者知與選擇的權利。結果今(30)日公路總局宣布,轄下49家客運業者,「全數呼應部長期盼」,全數未鬆綁7休1,不會出現10休1的情況。

公路總局的聲明中指出,客運業者皆回應交通部長的期待,將依循原本7休1規定排班,各客運公司安排駕駛勤務時,會考量各駕駛員的身心健康狀況,合理安排班表,公路總局也會確實監督所有客運業者遵守相關工時規定。

公路總局說明,在春節期間行車工時監督方面,將分成事前、事中、事後3個階段進行督導,包含事前要求業者先提報駕駛人出勤表,每日下午5時再提報次日更新的出勤表;事中會透過公路客運動態資訊系統,查核當班駕駛人的工時、休息時數是否符合規定,動態系統也會在每名國道客運駕駛員單日最高駕車時數前1小時自動發出警告,通知業者與監理人員預作因應。

然而對此結果工會感到不以為然,《蘋果日報》報導,台灣汽車客運產業工會理事范光明表示,現在規範業者要先經過勞資會議後,向公路總局提出申請,公路總局還會把10休1的業者名稱公布出來,「請問誰敢申請?」

范光明指出,客運司機14休1、15休1是不能說的秘密,而且司機員不足的問題平日就存在了,連假期間怎可能就獲得解決?公路總局說轄管的49家公路客運業者會以《勞基法》原規範之7休1排班,根本就是在說夢話。

國光客運總經理吳忠錫表示,當初客運業者提出在春節期間可以放寬到10休1的排班機制,是希望排班執行更有彈性,但每家公司都有專業的排班制度,會依照政府規範、實際運能需求來排班調度;目前的調度排班是還沒有需要提出申請10休1的排班方式。

首都客運總經理李建文表示,首都客運主要營運的是市區公車,春節期間市區公車反而是淡季,因此司機員的排班會比平日更有彈性,但還是肯定交通部跟勞動部針對司機員排班方式的放寬;未來若有需要時才會申請,但原則上就是維持7休1。

對於內閣「不同調」,《蘋果日報》報導,勞動部長許銘春受訪時表示,交通部願正視客運業長時間駕駛問題,客運業者司機若都能7休1、有充分休息,勞動部也樂見。因9天連假等於所有可放寬的客運業者都未實施放寬,許銘春說,若交通部與客運業者都沒有需求,「也可來申請廢止7休1適用行業。」

因今年春節9天連假是罕見長假,而所有客運業者都未申請7休1鬆綁,許銘春說若9天連假都沒來申請,「3、4天連假還要鬆綁就說不過去」,若交通部願正視客運業人力不足問題,勞動部也會幫忙解決。

(以下文章刊登於2018年1月5日)

(中央社)勞動部昨(4)日預告,汽車客運業在年節、紀念日或國定假日,因應公眾生活便利所需等情況下,可以鬆綁七休一,但限定最多連續工作9天,且不得連續4天以上單日工時超過11小時。

為了配合春節疏運,勞動部預告客運業在年節、紀念日或國定假日,因應公眾生活便利所需等情況下,可以鬆綁七休一。(行政院公報

勞動部官員表示,經過勞資政學代表審慎研議後,認為汽車客運業駕駛員年節期間的工作時間,的確跟公眾生活便利息息相關,但仍應重視勞工健康及道路安全,建議交通需提配套措施,並加強監督、檢察機制。

勞動部官員說,經過交通部研議後,決定客運業在例假調整期間,最多連續工作9天,且鬆綁期間,司機單日工時不得超過12小時,也不得連續4天以上工作超過11小時。

自從《勞基法》修法於2018年3月上路,勞動部同年2月就公布第一波21種形態,15個行業通過「鬆綁七休一」,因為基於「時間特殊」、「地點特殊」、「性質特殊」及「狀況特殊」等原因適用14休4的例外工時,也就是可連上12天班不違法。同年7月又預告第二波,新聞媒體、屠宰業等10行業於國外採訪或是因應防疫措施時,可列入鬆綁勞基法七休一適用範圍。

勞動部官員指出,預告期約10天,這段時間還會再聽取外界意見,並且會在春節前對外公告,讓這次春節的交通疏運不會受到影響。

對此,台灣汽車客運產業工會理事范光明表示,勞動部此舉根本無視目前司機超時工作、未依規定發加班費的現況,接下來鬆綁七休一,只會讓駕駛在春節期間冒更高風險,因此工會下週將到法院控告勞動部長許銘春瀆職。

他說明,駕駛人員長時間開車,體力負荷本來就重,過去還曾經發生客運司機連續上班,導致心肌梗塞發生車禍的事件,若是過年期間再鬆綁七休一,工時恐怕更長,對駕駛來說是很大的負荷,萬一出了事恐無人負責。

國光客運總經理吳忠錫表示,資方也很在乎疲勞駕駛的問題,也不可能冒著乘客跟駕駛的生命安全要求駕駛上路,因此會自律遵守法規,讓駕駛有足夠休息時間。

2017年2月,「蝶戀花旅行社」承辦的武陵農場賞櫻團發生嚴重翻車事故,造成33死。同年10~12月,大台南公車發生4起車禍,其中多為司機駕駛公車時身體不適,釀成1名心臟病死、3傷的悲劇,其中一位蔡姓司機未依《汽車運輸業管理規則》休息10小時,確定是「疲勞駕駛」。

2018年4月,國道1號發生車禍,國道公路警察局2名員警和大貨車駕駛共3人,在路肩遭另一輛大貨車追撞,3人當場死亡,調查後發現肇事司機已連續上22天班,加班時數更高達66小時。

根據交通部的統計,分心與疲勞駕駛占交通事故原因達兩成,2016年更多達2,304人次疲勞駕駛而肇事,造成2675人次傷亡。交通部道安會執秘謝銘鴻直言,疲勞駕駛高風險不亞於酒駕。

勞動部部長室僅回應,客運業的七休一例外草案,目前尚在預告期間還未定案,對於社會各界的聲音與建議,都會列入參考。

新聞來源:

核稿編輯:楊之瑜


猜你喜歡


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

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


猜你喜歡