clsung is reading

Theme by Anders Norén

實施生成式人工智慧：兼顧速度與安全

本文來自 Mckinsey Implementing generative AI with speed and safety 的讀後筆記，這是我家的 MA 幫忙找到並介紹給我的，這篇其實出版時間早於金融服務的未來：生成式人工智慧與其運營模式革新。

大意： 生成式人工智慧（gen AI）已成為推動企業創新、成長與提升生產力的關鍵動力。麥肯錫的研究指出，gen AI 不僅有機會為全球經濟增加高達 4.4 兆美元的經濟價值，更能提升所有 AI 技術的影響力 15％ 至 40%。然而，如此巨大的潛力自然伴隨著不小的風險，從資料偏差、AI 幻覺、到可能引起的大規模錯誤資訊及對政治和個人福祉的惡意影響，gen AI 的挑戰不容小覷。

這篇文章深入探討了企業如何在迅速採用 gen AI 的同時，確保安全與負責任地進行。文章建議企業採取四個具體步驟來應對與 gen AI 相關的風險，從了解內部風險暴露（inbound），發展各方面的人工智慧風險觀點，到建立治理結構和運營模型，每一步都旨在為企業提供清晰的路線圖，幫助它們在尚不確定的法規環境中穩健前行。

註：inbound 在這裡指的是即使不部署 gen AI，也可能影響組織的風險

主文摘要：

  1. 生成式 AI 的轉型潛力與經濟價值
    • 生成式 AI 為企業提供轉型機會，能夠在創新、成長和生產力提升等方面產生顯著影響。
    • 麥肯錫估計gen AI可能為全球經濟帶來高達 4.4 兆美元的經濟價值，提高所有AI技術影響的 15% 至 40%。
  2. 風險認識與準備不足
    • 許多組織體認到 gen AI 的未來發展機會也正躍躍欲試（63%）；但因伴隨重大風險，仍感到自己對於負責任的部署準備不足（91%）。
    • 風險包括不準確輸出（含幻覺）、訓練數據偏見，以及對政治和個人福祉的潛在負面影響。
  3. 負責任與有效風險管理策略
    • 文章提議四步驟策略：了解內部的風險暴露、發展全面風險觀點、建立治理結構、嵌入運營模型（這就是上一篇有提到的）。
    • 這些策略有助於組織在 AI 監管環境演變時，負責任且有效地捕捉 gen AI 的價值。
  4. 風險類別與管理
    • 將 gen AI 相關風險分為八大類別，包括四個同時也是內部風險源 (inbound) 的安全威脅、第三方風險、惡意使用和侵犯智財權等。
    • 強調組織需定期評估風險暴露和更新風險管理策略以適應技術演進。
  5. 通過 AI 治理在速度與風險管理之間取得平衡 （參考圖五）
    • 一個跨職能、負責 gen AI 發展的小組，至少每月一次會議。
    • AI 指導原則和政策：組織應該開發一套由執行團隊和董事會同意的 AI 指導原則和政策。
    • AI 人才和文化：對負責任的 AI 的承諾不能僅僅停留在執行層面。相反，它需要貫穿整個組織，將責任、能力建設和意識調整到相關角色對技術的暴露程度。應該開發並推出基本的全組織負責任的 AI 培訓，以促進對內部風險動態的廣泛理解，以及如何安全地與技術互動。
  6. 實施 gen AI 的關鍵角色與責任
    • 四個關鍵角色：設計師、工程師、管理員、和使用者，各自承擔不同職責，推進負責任 AI 使用。
    • 建立適當治理結構和人才管理是成功利用 gen AI 的關鍵，幫助組織管理風險並充分掌握技術好處。

圖示：

gen-AI-related risks can be captured in eight main categories
Exhibit 1: 八種 gen AI 風險，其中四種是不論導入與否都會需要考量的
Exhibit 2: 不同的 gen AI 使用情境有不同的風險需要考量
Exhibit 3: 組織可以做 heat map 來衡量各方面的風險重要性
Exhibit 4: gen AI 風險可以在不同的地方做緩解，這裡以 HR 聊天機器人為例
Exhibit 5: 通過 AI 治理在速度與風險管理之間取得平衡

結論： 在擁抱gen AI帶來的巨大潛力時，企業必須同時面對與之相伴的風險。麥肯錫的建議提供了一個實用且系統的框架，幫助企業在探索 gen AI 的無限可能性時，仍能保持負責任與謹慎的態度。考慮到潛在的生產力提升，努力可持續且負責任地擴大 gen AI 的規模對於充分發揮其全部好處至關重要。

金融服務的未來：生成式人工智慧與其運營模式革新

本文來自 Mckinsey Scaling gen AI in banking: Choosing the best operating model 的讀後筆記

大意： 在數位轉型的浪潮中，生成式人工智慧（Gen AI）正成為推動金融服務創新的關鍵力量。從自動化客戶服務到提高交易安全，Gen AI 的應用正在重塑金融業的各個方面。本文探索了 Gen AI 如何在金融服務領域發揮作用，並著重分析成功實施 Gen AI 所需的運營模式架構。

主文摘要：

  1. Gen AI 在金融服務業的影響： 生成式人工智慧正改變著金融服務業的遊戲規則。透過加強聊天機器人，金融機構能提供無縫且個性化的客戶體驗。此外，Gen AI 的應用在防範詐騙和提升交易監控效率方面展現出顯著優勢。自動化的程式碼開發和報告總結不僅加快了工作流程，也為高價值任務釋放了人力資源。
  2. 關鍵成功因素－運營模式 ( gen AI Operation Model)： 選擇合適的運營模式是實現 Gen AI 成功的關鍵。一個有效的運營模式應當能夠協調人才、技術和數據資源，並確保風險控制和變革管理得到充分考慮。
  3. Gen AI 運營模式的架構：
    • 高度集中化模式使得快速決策和資源配置成為可能，有利於初期的快速開發和部署。
    • 集中領導，業務單位執行模式則結合了中央指導和分散執行的優點，促進了跨部門的協同和創新。
    • 在業務單位領導，中央支持的架構下，業務單位能夠更靈活地探索 Gen AI 應用，同時仍受到中央團隊的技術和政策支持。
    • 高度去中心化模式則完全賦權給業務單位，鼓勵創新但需要更多的協調努力以避免重覆工作。
  4. 實施 Gen AI 運營模式的決策檢查清單： 成功實施 Gen AI 要求金融機構在策略、領域、部署模式、資金、人才、風險和變革管理等多個方面進行精確的決策，這包括確定哪些業務領域最能從 Gen AI 中受益，以及如何平衡內部開發與外部合作伙伴的角色。：
    • 策略與願景：明確誰將定義 Gen AI 策略，以及這一策略是在企業層面還是業務單元層面制定。
    • 領域與場景：確定誰將負責界定 Gen AI 應用領域及具體場景。
    • 部署模式：決定是作為“接收者”（從供應商購買針對性解決方案）、“塑造者”（整合供應商的廣泛解決方案）還是“創造者”（開發內部解決方案，重塑核心業務）。
    • 資金：設定投入發展 Gen AI 的資金來源，這將取決於選擇的運營模式是集中化還是分散化。
    • 人才：界定實施 Gen AI 所需的技能，並通過招聘、培訓或外包等方式來獲得這些人才。
    • 風險：確定誰負責定義風險防範措施，以及是否需要調整現有框架來應對 Gen AI 特有的風險。
    • 變革管理：執行變革管理計劃，以確保企業內部對 Gen AI 的成功採納。
  5. 未來展望與挑戰： 隨著 Gen AI 技術的進步，金融服務業將面臨持續變化的挑戰和機遇。金融機構必須不斷適應新的技術發展，並在其運營模式中保持靈活性，以便快速響應市場和技術的變化。同時，培養和吸引頂尖人才將是實現長期成功的另一關鍵因素。

圖示：

Four archetypes have emerged for using gen AI in financial services, and the highly centralized approach is showing the best results.

可能的爭論點： 金融機構採用不同的運營模式來實施 Gen AI，包括高度集中的運營模式、集中領導但由業務單位執行、業務單位領導但中央支持，以及高度去中心化的模式。每種運營模式都有其潛在的利弊。雖然數據顯示，在 Gen AI 的早期階段，選擇集中式運營模式的金融機構顯示出更大的進步（約70%），這類機構已將 Gen AI 案例推進至生產階段。但實施集中式運營模式時，可能會遇到戰略規劃、資金機制和人才配置方面的分歧和障礙。儘管集中式模式能有效推動 Gen AI 案例的發展，但也需要克服這些挑戰。

結論： 生成式人工智慧為金融業帶來了前所未有的機會和挑戰。通過選擇和實施適合自身組織結構和文化的運營模式，金融機構能夠最大化 Gen AI 的潛力，從而在競爭激烈的市場中保持領先地位。面向未來，靈活且前瞻性的運營模式將是引領金融服務機構走向成功的關鍵。

心得： 初期的中央集權對於金融業的成功有其必要性，但隨著技術成熟，在各業務單位應也有發展各自專門領域 Gen AI 的需求，那麼在這兩個條件都成立的情況下，運營模式朝向更聯邦化的方向的發展，更能發揮其效果。

Linode VPS 漲價

最近，我收到了 Linode VPS 服務下個月開始的漲價通知，這不是個好消息。上次 lke cluster 升級多收費的事件後，我就決定縮編我的服務，以節省一些開銷。這次剛好又是一個觸發點，不如就降到沒有漲價的 1GB 版本，當然另一方面也是這麼久了發現我似乎也用不到多大的。

以超過複數台 node 的使用量來說，都使用 1GB 的方案看來是省了很多（就是省了漲幅啦）。我仍然繼續使用 Linode 的 VPS 服務，但現在我更加關注資源的使用情況，並更加珍惜每一分每一秒的資源。也不知道哪天什麼火又燒過來，做好一點點準備總是好事。

改用 vim-plug 更新 vimrc

用了快十年的 vimrc 是從 vgod 那裡 fork 過來的，不過一直都沒空玩 ruby ，所以也一直覺得不太好用。尤其原本需要用 sub-module 的方式更新 plugin 更是有點累了，提不起心力去整理。最近終於想更新了，在看了網路上大家的使用經驗，大概就有 Vundle 或是 vim-plug 是比較怡人的（比較適合我的）。

最後選了 vim-plug ，因為文件格式對我胃口，也不是什麼特別的理由，但換了之後覺得 vimrc 目錄有輕量化的感覺了。

Helper module to generate JWT for LINE OAuth2 v2.1

LINE Messaging API 最近一個比較重大的變更是 access token 新版的發放方式（v2.1），同時也配合 OAuth2 。比較不同的點是它是用 JSON Web Token (JWT) 去取 access token，這樣的好處是如果今天 Provider 本身（也就是付錢的人）請開發商開發 bot ，他並不需要把 channel secret/access token 都給開發商（這通常也暗示你要把開發人員加到 bot admin 去，當然也可以不這麼做，就是麻煩了點）。

改用 JWT 的好處在於開發商只需要知道 channel ID 以及 Provider 幫他申請的一組 Assertion Signing Key （RSA 加密的），對 Provider 來說資訊的保護層級就提高了，終止合作只要把這組 Assertion Signing Key 砍掉就好，不必重新申請 channel access token 且/或 channel secret。

但相反地，開發商沒有 long-lived channel access token，新版的 OAuth2 認證方式使用 JWT 產生的 access token 最長只有 30 天的限期，期限到了之前要再生，某種程度造成程式開發上的困難（安全與方便通常不是站在同一邊的），原本的邏輯上要多加處理 token expiry 。

對於 API 變動來說，可以分為兩部份來看。其一，是 JWT 的取得；其二，是 access token 的取得。前者並沒有直接呼叫到 LINE Messaging API server ，所以在開發 SDK 的時候，可以先著重在已有 JWT 的情況下與 server 端做申請/列出/撤銷 access token 的行為。這部份也提出了 pull request (PR) 在等待官方團隊的審核。

Web interface for generating JWT

而 JWT 的生成就比較麻煩了，在看官網的介紹時發現做 JWT 沒有想像中那麼容易。（中間省略一段心路歷程）最後就是決定自己開發工具來幫助生成 JWT 。

clsung/line-oauth2-helper 名字有 “OAuth2” ，實則沒有關係，是用來生 JWT 的，但因為這生出來的 JWT 也只能讓 LINE OAuth2 v2.1+ 使用，所以才取這個名子。

執行的方式看 README 即可，若是一般 go 開發者使用，那 go get github.com/clsung/line-oauth2-helper/cmd/line_jwt 最快，若是系統沒有 go 的，可以考慮用 docker 的版本（若是都沒有的，請按上一頁離開）：docker pull clsung/line-oauth2-helper:stable。

用 line_jwt 執行的話，預設生出來的 JWT 需要在 30 分鐘內去 access LINE server ，而生出來的 access token 會在 30 天後過期，要細部調整的則建議就使用 docker / web 的版本。若是要接在程式碼當 API 呼叫的，也可以參考 cmd/ 下的程式自行開發。

2019 LINE Developer Day – Face Recognition Check-in Mechanism

人臉辨識是近年來非常流行的技術，如今幾乎已是深度學習的天下了，而這門技術的應用上，現在還是非常的火紅的話題。這次參加的 LINE DevDay，就採用人臉辨識當做報到的機制。

2019/11/20 報到現場實況

而在第二天，也安排了議程來說明 LINE （NAVER）是如何開發、設計與導入到 LINE DevDay 2019 會場的報到流程。

Speaker: Seungyoun Yi

由於我們自己也有在研究人臉辨識，也有用在 check-in 上（我們叫刷臉打卡），所以在第一天報到的時候，就有特別注意一下偵測的時間，以我報到的經驗，大約花了3~4秒（兩天都是），並沒有像官方宣稱的不到一秒，但搭配一直轉圈圈的 UI ，也並不會讓我感覺到等很久。實際體驗的時候， iPad App 上的圈圈會跟著你的臉部範圍動，所以可以推測時間是花在臉部特徵擷取（Facial feature extraction）或是特徵比對上。既然講到此，我們就先由講者的第二段（Face Engine）說起。

Face Recognition Pipeline

人臉辨識目前的作法都是 1) 偵測人臉 2) 對齊人臉 (alignment) 3) 臉部特徵擷取 4) 人臉特徵比對 。通常步驟 1/3 是相對容易的，而 2/4 就比較難了。 2 的問題是人臉的角度通常不會剛剛好，要正確定位眼鼻口眉毛並不是像一張面膜一樣貼上去就好（為了說明方便，實際上不是去定位這個是眼睛這個是嘴巴）。而 4 的問題在於，當資料庫愈大的時候，需要比對的資料就更多，計算量也就更大，要在短時間就做完，沒有硬體（如 GPU ）的幫忙，通常就要在演算法上鑽研很深才行。所有會需要上線深度學習模型的團隊，都會想辦法去做 model size reduction/compression (without losing too much accuracy)， NAVER 團隊同樣地也花了不少時間在做深度學習模型的優化。團隊的目標就是在行動裝置（也表示不見得有 GPU ）上能達成即時的人臉辨識：Our standard is real-time in mobile CPU environment。由投影片的 16~55 頁有團隊的實驗成果，在此並不贅述。不過不像 Clova team ，並沒有看到團隊的論文發表，不太確定實際的成果為何？

臉部辨識如何改善報到流程效率

回頭來講臉部辨識應用，不外乎 1:1 、 1:N 的應用場景，而即時辨識的場景對於 UX 的要求更是重要，對於刷臉報到來說，如果節省等待時間、辨識時的過場畫面（不會讓人感到不耐煩）、辨識不出的解決流程，其實這考驗主辦單位的場控能力，有 UI 呈現的地方，就會需要排演 SOP 。這次的報到入場我覺得還蠻順的，但是也可以感到 LINE 官方對於這個的重視，許多工作人員也跟在旁邊引導。

由演講可知，講者也是在第三段接著討論臉部辨識的核心實作到服務應用。這次的報到是有 App 的，配著投影片也可以看出是 Client/Server 架構的，由 Client (App) 負責做 Feature Extraction ，接著再傳到後端 Server 做比對。

如何讓臉部辨識成功率大增，可以由 UI/UX 來調整

由上面幾張投影片可以了解透過好的 UI/UX 設計，可以降低錯誤率，為什麼呢？因為對於臉部辨識引擎本身，它就是 API 有傳進來的臉部特徵就會去比對，如果前端的介面設計是什麼都往後面丟，那整體的效果就不會太好了，所以實務上不需要處理太多 corner case 的情況，就是把這些可能會出錯的，由前端的 UI/UX 來避免。當然，這不是說 UI/UX 就不用寫程式，像上面寫的眨眼偵測啦，或是角度，那些也是要開發程式的。以 LINE 在這次 DevDay 之前，也是做了幾次實地測試（Field Test），可以感覺出來他們是愈來愈有信心了。

已經有不少經驗了

照舊，放上一張圖當結尾（雖然我認為還要加上 UI/UX 才更恰當）。

Goal of AI

2019 LINE Developer Day – Project Management and Agile

近十年來（其實應該超過十年了），敏捷開發逐漸在軟體工程中佔有一席之地，這個的定義大概就是如果有人說他做軟工的，那你可能會回一句「所以你對 Agile 應該很熟吧」

Speaker: Minoru Yokomichi

在 LINE DevDay 的第二天下午，有個議程也是在分享 LINE 內部是如何進行專案管理的。講者所在的部門很特別，稱作「Effective Team and Delivery Department」，由名稱可以看出來這個部門的重心。通常接著的關鍵字就是 Project Management 、Product Management 、 Agile 或 Scrum，果然講者的背景也是如此，不過多了 Engineering ，這也是符合 LINE 的企業文化。

To make “Teams” and “Delivery Processes” more effective

左邊的子部門 Delivery Management Team 中，是由一群 TPM (Technical Project Manager) 組成的。 LINE 的文化認為 Project Management 對於 Product delivery 是很重要的，但 Project Manager 這個角色並不是那麼地被需要；也就是說，LINE 的 TPM 負責的並不只是 Project Manager 這個角色任務。

產品開發的三環相扣

上圖可以看出他們對於產品開發中，對於 Product/Project Management 與 Development 各自的角色工作定義，一般而言對於前兩者的角色也就是稱為 PM (Product Manager/Project Manager) ，而後者就包含了 Engineer / QA 。

LINE 的 TPM 組成
彼此工作是有區隔，但沒有明確界限

而講者藉由 R & R 的示意圖，說明 PM/Eng 雖然工作是有各自的職責，但在實際上的產品開發合作上，卻不會那麼壁壘分明。當彼此的界限模糊的時候，就不容易有事情掉在地上沒人做的時候了，不過以我自己的經驗，我認為要達成這個目標，除了企業文化能支撐之外，團隊的成員心態也非常重要。而心態的養成，也與主管甚至高階主管的支持有非常大的關係。以這個角度看，也許 LINE 做的很成功？（因為沒有在 LINE 任職，有些內部衝突是看不到的）

談完了左邊的，接著拉到右邊的子部門 Lean & Agile Team。在這方面， LINE 的 Agile 也奉行「Be Agile, not just do Agile」，以落實 Agile 的價值與原則為主，而非一昧採用其方法論。

支持性的工作為目標

整個部門工作重心是以 Support 其他部門為主，這中間包括了提供訓練、協助解決問題以及建立內部跨域的社群（這點就跟目前很多的社群 meetup 是一樣的意思）。

簡介完了之後，搭配而來的就是實際例子，講者是以 LINE News 的產品開發為例，但我想組織圖應該是可以通用的。

初始的組織圖

通常一間大公司的組織也就大概長的像這樣子，這類的組織特性是有管理者們層層把關，做一個既有產品的優化是很容易的，因為管理者（或是資深的老鳥）可以靠著過去的經驗來判斷；但若是產品還在初期的階段，從這個角度看上去，就是看到層層的山頭了。

從組織圖迭代的演變，我們可以看得出來，工程師永遠是最好騙講話的（笑）。目前看起來，左方的管理群們一時之間是很難拆開的，這個我想工作個十年的人大概都可以理解是怎麼一回事吧（茶）。

接下來，講者也介紹了以前述三個核心為本的，各式各樣 LINE 提供的 Training / Workshop / Team Building / Community ，這些建議直接連到投影片去看。個人覺得這些文化養成雖然不見得能讓 LINE 變的強大，但是很有機會能讓 LINE 變的偉大的。

最後，放一張 Product Management 的 global view 為結尾（其實我不知道為什麼寫了個 Thailand 卻什麼都有啊）

Global view of LINE Project Management

2019 LINE Developer Day – Hadoop Cluster Federation With 2k+ Nodes

上週以 LINE API Expert 的身份參加了今年於東京台場舉辦的 LINE Developer Day 活動。其中有一場硬底子的分享我覺得蠻值得一提的，簡單一句就是用 Hadoop 在上層做 Cluster Federation ，總共管理了超過二千個節點。

2019 DevDay 100+PB Scale Unified Hadoop Cluster Federation With 2k+ Nodes
100+PB Scale Unified Hadoop Cluster Federation With 2k+ Nodes

之所以講硬底子，因為 LINE 工程師在進行這個擴展/遷移節點的過程中，遇到的問題有送 upstream patch 回原本的專案 repo （簡單列一下投影片有提到的，照看起來應該還有不少）：

各式的服務，各式的資料

幾年前還「只不過」是一個即時通訊軟體的 LINE 。時至今日，LINE 本身的服務量已經是愈來愈大了，開始嘗試提供各式各樣的服務，想當然而所有的資料格式欄位（以 SQL 的角度來看）各有不同。

2k 個資料節點，存了超過 100PB 的資料

看起來很棒，實際上對於 Data Platform 部門的工程師則不然，如果羅馬不是一天造成的，這些服務與資料並不是同時打造好提供給大家使用的，這是日積月累的使用記錄，加上服務系統迭代更新後，產生的資料。可以參考去年的演講，那時候的資料看起來還沒有這次的一半多。所以理想與現實的差距，造就了 10 座以上的 HDFS Clusters ，在系統維護與軟體更新上都拉大了難度與時間。各個 Cluster 的版本不一，能提供的 API 以及工具也無法統一。最後工程師們決定整頓一下，一統公司內的 Hadoop 江湖（想想一次可以送 job 在 2k+ node 上跑，想到就…..）

目標: 「一法度衡石丈尺，車同軌，書同文字。」

當然改變不是一蹴而就，當年（應該是每年）留下來技術債也是要還的（OS: 砍掉重練就不用了…），工程師們決定邊開飛機邊改引擎 （…）。所以定了幾個 Criteria ，包括 Minimum Downtime、Incremental Migration 以及最重要的 High Security Level/Minimum Risk 。

講者簡介了幾種他們一開始規劃的想法，比如建一個新的，然後把所有的資料往裡面搬。這個當然是一個理想但不實際的方法，除非你不在意 downtime 、不在意相容性、不在意因此要多買一倍的儲存空間。另一個進階的想法則是把最大的 cluster 再擴大，然後把其他的 cluster 整合進去，這個遇到的問題是實務面的：最大的 cluster 沒有使用 Kerberos；有兩個非常大的 cluster 是有頻繁的用戶存取的；整合完， Hadoop 還是需要再更新。最後方法就採用了 HDFS Federation 架構來解決這個問題，基本上利用 HDFS Federation 可以有 multi-namespace 的特點，來支援後續的 data/service migration 。

Start small, Iterate fast.

但即使如此，在實作上還是運到了一些問題，有經驗的工程師聽到這裡大概也可以猜出來，各 cluster 原始的版本相容性會直接地影響到 merge 的成果，在這中間的過程中踩了不少雷，也因此提出 patch 增強（或修正） upstream 原有的功能。而這些的修改，都是在一邊更新 cluster 並作適度的 ETL 時，同時間也能讓原有的系統能夠持續運作，我想這點要對 Data Platform Dept. 的工程師及架構師們致敬。

最後放上一張我認為很能代表這場演講的投影片。

In short words, you do this and achieve that…. (amazing)

20190628 Chatbots Meetup 10

受 Evan Lin 邀請，6/28 參與演講了 Chatbots Meetup 10 的第二場，分享如何在 Google Cloud Run 上部署 LINE Bot 的經驗談。(好像拖稿很久了)

因為時間的關係，到天瓏書局時已經開場講到一半啦。就錯過了 Evan Lin 的 Write Image Proxy Server for LINE Bot in Go。就座的時候，LINE API Expert – Caesar Chi 正在介紹 LINE@ 2.0 offline to online ，分享如何透過 LIFF + Push 機制，讓廠商能更有效率的省錢轉換，並且也跟會眾們分享在官方帳號 2.0 轉換後的衍生想法。

接著就是我上台分享 LINE Bot on Cloud Run: 使用 line/line-bot-sdk-go ，本來是想介紹 LINE Bot on GKE ，不過準備的時候發現會需要花點時間講 K8S ，就不好講 LINE Bot 開發了，所以選了一個我也沒用過的 Cloud Run 來試看看。詳情就直接看投影片吧，然後順便把 source code 整理一下放上來。

最後閃電講，直接貼共筆的圖好了 :Q 我覺得 Evan Lin 的講解比較詳細，哈哈，偷懶一下。

Fix: Unit “containerd.service” has failed

When I upgraded yum packages, docker service had stopped. So I check the system status try to figure out the root cause….

After google ‘Subject: Unit “containerd.service” has failed’, we can find a related github issue. It seems to be a containerd problem than a docker problem, and here’s the fix: (the following shows the before and after)

Older Posts