科技為長輩賦能的第一哩路:專業第三方,化學習阻力為助力

科技為長輩賦能的第一哩路:專業第三方,化學習阻力為助力
示意圖,非當事人照片|Photo Credit: Kimberly B.@Flickr CC BY-ND 2.0

我們想讓你知道的是

龍吟研論過去四年針對兩岸222位50歲以上的中高齡受訪者研究,發現科技學習的問題不僅台灣的長輩會遇到,中國的長輩也不例外。對於這群長者來說,在這個萬物皆連網的時代,學會使用科技,意味著擁有與外界溝通、應用各種連網產品及服務的主導權,象徵著生活自立的重要意涵。

對於年輕人來說,任何科技疑難症向Google大神求救即可輕鬆解決。但對於長輩來說,上網不一定是件簡單的事,更遑論遇到問題時,在網路上找到正確的解答。

龍吟研論過去四年針對兩岸222位50歲以上的中高齡受訪者研究,發現科技學習的問題不僅台灣的長輩會遇到,中國的長輩也不例外。對於這群長者來說,在這個萬物皆連網的時代,學會使用科技,意味著擁有與外界溝通、應用各種連網產品及服務的主導權,象徵著生活自立的重要意涵。但科技學習對於他們來說並非輕鬆容易——不太會操作、不敢亂點亂按、不知道用什麼關鍵字搜尋……都是他們時常遇到的問題。

子女態度與長者期待有落差 成為學習的阻力

面對這些問題時,長輩優先求助的對象往往是自己的子女。但是這些第一線救火子女們的態度及行為,時常與長輩最重視的自尊有落差,成為長輩在學習科技上的阻力:

1. 時間落差:難以及時處理

當長輩遇到問題時,難以從正在工作中的子女即時得到解答,只能獨自忍受卡關的挫折。

2. 理解落差:難以有效溝通

對於與子女不同住的長輩來說,需要透過電話溝通問題。在缺乏畫面的情況下,子女不一定能清楚了解長輩的疑問,而長輩也未必能明白子女的說明。

3. 態度落差:難以耐心說明

子女預期長輩能馬上學會,但對於不熟悉、甚至第一次接觸科技產品的長輩來說,不容易一次牢記所有內容。子女若無法同理長輩需要多些時間消化吸收,難免不耐煩,讓彼此都不好受。北京32歲的女性表示:「晚輩教長輩時,長輩如果沒有馬上學會,晚輩會有一點點焦躁的情緒在裡面,長輩會覺得你沒有用心教我,晚輩會覺得我的時間很寶貴,這個時間如果在公司工作的話,一個小時時薪是多少,我已經教了你兩個小時。」因此對於重視面子的長輩來說,在不願忍受兒女臉色的情況下,學習態度積極的長者會尋求外援解決問題,但態度消極的長者,則陷入學習的停滯期,甚至放棄學習。

對於子女來說,難以及時、有效、心平氣和地解決一個又一個長輩遇到的科技疑難,也讓他們備感無奈。對於重視自身便利的台灣的兒女來說,他們的無奈來自於遠水救不了近火的困窘;對於肩負教導使命感的中國兒女來說,它們的無奈則來自被動承擔父母的問題。

專業第三方解決急迫重複問題 化學習的阻力為助力

如何將長者學習數位科技的阻力化為助力?並同時化解子女的無奈?將教導任務外包給專業的第三方,是值得思考的方向。他們能隨侍在側,解決長者急迫性問題,也能耐心教導,處理長者重複性問題。對於寧願花錢不願受氣的長輩來說,可顧全自尊,同時獲得正確解答;對於想幫忙卻幫不到位的子女而言,能化解滿腹的無奈。

1.真人/線上客戶服務:客服人員可以隨時回應長者的問題,面對非血緣關係的長者,沒有情緒負擔,能更加有耐心地教導。廣州62歲的阿姨表示:「希望現在遇到什麼問題,馬上問線上客服,他就指點我,就不用等到媳婦回來。及時,不要拖長,不要耽誤這樣,都好。」

2.遠端桌面、視頻或人像投影:如同面對面教學,教導者可以具體了解長者遇到的疑難雜症,長者也可以明確理解解決問題的操作步驟。

3.教學影片或內建教學助手:將常見使用問題錄製為教學影片;或設計步驟引導App,偵測長者的操作動作,隨時給予下一步的指導。

不論是何種形式的教學服務,第三方業者都需要注意與長者建立信任關係,並保障長者的個人資訊。

科技扮演賦予長者能力的重要角色,但要真正發揮賦能的精神,關鍵是長者要有學習數位科技的能力。當長者的學習從被動轉換為主動,才是實現賦能的開始。

備註:龍吟研論採一對一深度訪談方式,2013-2016年在兩岸六大城市(台北/台中/高雄/北京/上海/廣州)訪談超過1600位年齡橫跨20-65歲的先驅消費者,從中描繪未來需求樣貌與變遷路徑。

活動訊息

《智榮基金會龍吟研論》將於2018年1月25日舉辦國際論壇,特邀麥可波特創立的ICHOM副總裁談「價值醫療」、日本國立長壽醫療研究中心副院長談「身心強化」。再聚焦台灣在地經驗,各方陸續展開自主研發回應台灣長者生活所需,分享在組織裡突破限制的眉角,初探市場碰到的挑戰,打造華人高齡社會新解方!

  • 活動名稱:2018龍吟趨勢論壇:無齡.現在進行式
  • 活動時間:2018年1月25日(四)9:00-17:30
  • 活動地點:台北市信義區菸廠路88號(誠品生活松菸店B2表演廳)
  • 報名網址:更多詳細的資訊請見報名網頁

本文經智榮基金會龍吟研論授權轉載,原文刊載於此

責任編輯:潘柏翰
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡