逐漸步入「少子高齡化」的台灣,終得面對日本盛行的「孤獨死」危機

逐漸步入「少子高齡化」的台灣,終得面對日本盛行的「孤獨死」危機
清潔人員整理孤獨死亡者的居家環境|Photo Credit: Shutterstock / 達志影像

我們想讓你知道的是

目前台灣政府也在研擬一連串措施防止人口老化加速外,另一方面,在未來的這段期間,台灣勢必會出現如同日本般「孤獨死」的危機,加強社會關懷勢必要做。

大阪市一天三人孤獨死

台灣在近年來,開始出現「孤獨死」這樣的名詞,這個原先來自日本的詞彙,就字面上來看,即是獨居老人在未受到照料與關懷下,一個人獨自在住處內死去。這十年來,孤獨死在日本逐漸成為社會文明議題,在日前的日本《每日新聞》大阪版中,就公布數字顯示,單單在2017年一整年,大阪市區域就有1101人死於「孤獨死」,其中男性更高達8成,有871人。

孤獨死的每個個案中,多數是死後1週到1個月間被發現,較快的是在死後四日到一週內被發現。驚訝的是,死後一個月以上的案件雖然不多,但是誇張的場合上,有的人死後一年四個月,都化成白骨後才被發現,顯示日本的社區連結與人情都逐漸淡薄。孤獨死不同於一般社會案件,有仇殺或情殺的可能,警察一般都以自然死亡處理,因此在這幾年來被重視後,才有較完整地數據統計。

以年齡層來說,60歲以上的族群雖然是孤獨死的主要層級,約佔八成,但是40至50歲的年齡層也開始逼近兩成,這幾年有逐漸年輕化的趨向。奇怪的是,有24例的孤獨死是明明家中有其他人居住,卻依然一個人過世,顯示家人在家中被「孤立」的情形,逐漸成為日本的社會現象。大阪市的職員初步估計,一天之內平均約有三人是孤獨死的情形,顯示日本的市町村連結度與社區政策都必須要更加充實。

追尋孤獨死者蹤跡

追尋孤獨死的蹤跡,近來也變成日本媒體的議題。日本《朝日新聞》就推出「你到底是誰?」的專欄連載,追尋這些孤獨死的人,其中有些沒有家人親屬的人,媒體則帶著他們的遺物,去追尋他們過去是過著怎麼樣的生活?當初是抱著什麼樣的夢想來到大城市?對於來到這邊,一輩子幾乎回不到家鄉幾次的人來說,他們的夢想是否真的達成了?

「對不起啊,對不起啊」,2018年底時,大阪府內豐中市的一間木造民宅中,房東太太在清掃房間時,忍不住口中念念有詞。她的房客日前在這間木造房屋內病死,一個月後才被發現,當時惡臭難聞,榻榻米的地上留下一大團黑影,是屍體腐敗後濕水滲透進入藺草間的痕跡。該80多歲的男性在被發現時,除了身份外,僅有19張從年輕到老的照片可以還原他的生活。

採訪團隊隨後找到,這位老人是來自南方鹿兒島縣奄美群島的加計呂麻島,17歲時曾在沖繩(當時琉球群島)那霸參與戰後的房屋建設。團隊特別飛到當地,詢問對他還有印象的人,慢慢拼湊他的生活。他在奄美群島回歸日本本土後,抱著到都市闖一闖的決心,來到大阪闖天下。在高度經濟成長期,該男參與了大阪萬國博覽會的基礎建設,當時的街上天天缺勞工,他的臉上意氣風發。

一人終老歸鄉無望

《朝日新聞》探訪許多當地的建設公司,然而因為該男過世時年事已高,幾乎沒有記得他的同業。不過他家中尚有一件遺物——平成20年2月15日開工的安全帽,顯示71歲的他當時,依舊要過著有一餐沒一餐的日子。就在雷曼風暴隨後席捲全世界後,該男似乎就沒有工作記錄,隨之而來的孤單、老年也隨之而來,最後他必須過著社會局接濟的生活。

shutterstock_204523819
Photo Credit: Shutterstock / 達志影像

日本採訪團隊調查細密,在最後還去拜訪他常去的餐廳,店主成為該男在生前最後的依賴,也是最親密的人。店主跟採訪團隊稱,該男去該店時,通常沒錢,只能點350日幣的便宜日本酒,偶爾有點錢就買菸抽。店主回憶:「我覺得他很寂寞,嘴巴常喊著『好想回奄美啊』,沒想到他的夢想再也無法實現了」。一輩子來大阪打拼,將人生奉獻給這座城市,卻只能孤老而終。

採訪團隊後來多方聯繫下,找到該男兩歲大的哥哥,他們兄弟年輕時曾一起在建築地工作過,後來哥哥結婚後,就跟弟弟漸漸疏遠了。晚年時,哥哥曾多方關心弟弟生活,但弟弟只表示生活還可以,哥哥不用操心。「其實他過著怎樣的生活,我也不是很瞭解」,哥哥有點後悔,在弟弟喪禮時拼命找花籃,但因為太晚得知消息,趕工不成最後無法送達,葬禮則是用國家與該城市補貼金額的「福祉葬」簡單了事,「弟弟的葬禮好寂寞......」,他跟記者如此說。

日本加強社區聯繫

44歲的大阪府知事吉村洋文,在11月14日的記者會上對孤獨死的增加表示:「高齡男性跟社會不接觸的比例有愈來愈高的趨勢。希望他們參加地方的祭典等社區活動,來增加跟社會的接觸,希望未來的地區自治體都能以這樣的前提而努力」。日本目前也在思考所謂「2040問題」,意即在那一年時,許多戰後嬰兒潮的人群都將超過80歲,日本預估,到時超過65歲的人口將達到4000萬,占比達到三分之一。

殘酷的是,台灣也將在未來逐漸步入如日本般「少子高齡化」的情形中。根據內政部在2018年的統計,台灣超過65歲的老年人口已經來到14%,未來20年的老化將持續加速,等到2040年時,台灣的老年人口將僅次於日本及韓國。目前台灣政府也在研擬一連串措施防止人口老化加速外,另一方面,在未來的這段期間,台灣勢必會出現如同日本般「孤獨死」的危機,加強社會關懷勢必要做。

另外在日本,現在也推出所謂「銀髮分讓住宅」,建造銀髮社區。裡面不只有大浴池、圖書館、麻將館外,還設立24小時的小醫院、代辦小型行政業務等。而前述這些遊樂設施,正是想加強老人間的社區聯繫。不過,日本現在安養住宅費用仍是偏高,加上入住規定也多,不一定每個銀髮族都能適應。在2040年前尚有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。

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


猜你喜歡