Published on

DevOpsDays Taipei 2022

多雲整合企業應用平台 DevOps SRE 落地實踐

  • RD 的研發目前的計算已經排到 2025，那在 Operation 上面要如何搭配 ?
  • 相關導入的 pipleline
    • 2019 容器化
      • IaaS (vm) -> PaaS (vm) -> Container k8s -> TSMC k8s (開源版本)
    • 2021 Agile/Kanban
    • 2022 CI/CD Devops
  • ERP 和製造相關本業都還是留在 private，其它的部份都上公有雲，然後中間串接的部份使用DMZ
    • 下載大檔案時，從 32hr 縮短為 3hr

看起來導入公有雲的效益很大，以時間來看差了 10 倍

  • 原本開發好的系統，交回廠區上線時，大多要 3~6 個月，因為資料交換都是用DB的方式，並沒有使用服務的方式

我覺得很多公司的相關系統都還是用這樣子的方式來執行

  • 在原本的組織裡面建立一個戰術團隊 (squad team)，來負責相關新技術的研究跟導入
  • 單體式的服務，原本很多的邏輯都是寫在 DB 的 SP，帶來的後果就是沒有辦法寫測試。後來把常變動的部份抽出來，變成新的服務 (微服務的方式)，新的服務也就是用新導入的 CI/CD 的方式，舊的服務就先不改動

基本上 SP 是可以寫測試的，只是比較麻煩而已，它就是一個黑箱，只要決定好輸入，再來驗證輸出的部份就好

  • 安全性很重要，所以 DevOps 會變成是 DevSecOps
  • 新的服務 (系統) 的部份 (2021 之後)，開始導入 unit test 跟 code review，舊的服務 (系統) 的部份就先不看

基本上就是要開始第一步，以 code coverage 來說就是相對 > 0

  • 2022 開始，從原本的專案導向的方式，轉而改由產品導向的方式來開發

蠻好奇這樣子轉變，在組織上面是不是也有相對應的調整，感覺上對於整個開發流程上面的人是個大轉變

  • 逐年調整 Dev 和 Ops 的比率，現行為 40 : 60，到 2023 年的時候希望可以變成 70 : 30

這裡指的比率應該是原本負責人數的相對比率，有可能都是同一群人，只是調整開發上面的比率

  • 自建的 SRE 平台 202208 上線
  • 在前端方式，有把相關用的元件整理成了 TSMC UI Design System (Reace)

元件化才會統一一致的風格跟加速開發啊

右移測試的實作分享

  • 產品品質，每個人來解釋的角度都不太一樣，尤其是老闆跟開發
  • 產品開發的兩條線
    • Discovery : do right thing
    • Delivery : do thing right
  • 上線前的測試叫 左移測試，上線後的測試叫 右移測試
    • 左移測試 : 愈早的發現問題，可以降低維修 (修改) 成本
    • 右移測試 : 用對的方法和對的時間，有效的找到問題

基本上，這裡的右移測試的說明，我覺得重點在於，如果真的在 PRD 環境發生了一個 BUG 時，該怎麼樣可以比較快速的定位到問題，並且 FIX

  • 常見的右移測試方式
    • Discovery
      • A/B Test
      • Fake Door
    • Delivery
      • Feature Flag / Ring Deploy
      • Telemerty
  • Fake Door
    • 用來測試這個功能是不是真的需要，常見的有 Call To Action 在網頁上做一個購買按鈕，看有多少人按
  • 當沒有辦法模擬客戶的情境的時候，就可以使用 Telemerty 的方式來蒐集相關的資訊
  • Ring Deployment (藍綠佈署)
    • 可以找到不同使用者 (公司) 的相關性問題，不過不代表所有的使用者 (公司) 都會有一樣的問題
    • 原本使用 by company 的方式來 Deployment，為了比較好找到不同的問題，後來改用 by device 的方式，找每一間公司的 5% 電腦來跑

我覺得決定佈署給誰這點，還蠻重點的，才會有辦法找到相關問題，跟 A/B Test 我覺得很像，要如何把你的使用者分群來作測試

  • 如果收到相關的監控數據太多的話，真正的問題很容易被忽略，這個時候就可以找特別的群體來 monitor 就好，例如找出最慢的 5% 來 monitor (P95)
  • 產品發佈後，之後的上線由 Support(客服) 來負責上線

這點真的很特別，把上線的時間交由客服來決定。不過，如果以客服是比較了解客戶的人，讓它來更新，我覺得也沒有錯。這裡指的客戶是 2B 不是 2C

走過 DevOps 風雨的下一步

  • 如果把 DevOps 分發三個部分 : 文化、流程、工具，大部份的人 (公司) 都只注重在工具上，用來解決自動化的問題上面
  • DevOps 是敏捷的延伸 (產物)
  • 製造業的老闆
    • RD 硬體相關的花費就是投資
    • 員工教育訓練就是浪費

這點我覺得不只是製造業吧，很多行業的老闆都是一樣 XD

  • 很多敏捷 / DevOps 相關的名詞本來就是從製造業來的，所以製造業本身就已經是有 (運行) DevOps
    • 例如 : Lean、Kanban、TOC

這點說的真是有道理，只是反向回去，大家就覺得怪怪的 XD

  • DevOps 本身並沒有明確的定義流程、和相關的實作，不過因為製造業的關係，比較喜歡有 SOP，而且會從 KPI 的角度來思考問題。這也導致於為什麼使用工具會是大家的第一個要導入 (改善) 的，因為只要會使用工具就會有 KPI (比較好衡量)

這點也是跟第一點相呼應，不過我覺得不只是製造業，很多地方都是這樣，找可以打 (比較好打) KPI 的東西先導入，其它的東西就再等等

  • 如果導入 DevOps 而沒有敏捷的話，那絕大部份還是沒有辦法因應 (面對)變化
  • 如果只有完成自動化的部化，會讓大誤以為就可以應付所有的情況 (主要是上面提到的變化)，基本上，軟體的生命週期很長，不是只有 CI/CD 而已

基本上這兩點也是呼應一開始的第二點的部份，DevOps 跟敏捷要相互搭配才會得到最大的效益

  • Dev + Ops，重點在於開發要有維運的思維，維運要有開發的思維，不一定是要同一個人，或是同一個團隊，重點在於分工，而不是這個人的角色

我覺得這段的觀念講的很好，重點在於是否具有相關的思維，而不是你的角色是誰

  • 賽車看的結果是最短時間，而不是最短路徑，最短路徑不一定是最短時間，有的時候要繞一點遠路才會是最短時間

看筆記忘記了這段要表達的意思 XD，不過，在程式重構上有的時候的確是沒有辦法一步就達到最後想要的樣子，中間要多幾個步驟才有辦法達到想要的樣子

  • Agile (思維文化)、DevOps (團隊流程)、SRE (工程技術) 三位一體密不可分，少了其中一塊效益就會受影響
  • 講師之前的相關簡報 Database in DevOps
  • DB 在 DevOps 的重點
    • DB 要放入版控
    • DB 要有監控
    • DB 原本的 SP 邏輯要抽到應用程式

我覺得 DB 的版控真的很重要，不然根本不知道是誰改的，為什麼要改，SQL Server 的 DB project 很好用。SP 的部份，大家一直在提

  • 商業與工程的需求都是同等重要的，可以用 80 : 20 的法則來安排工程的需求 (解決技術債)
    • 技術債沒有被清零的一天，必須要有效的管理
      • 例如現在因為量還不夠大的 DB 效能調整，等到量到一定程度的時候，問題就又會浮出來

我覺得很有道理，如果一直欠債不還 (不寫測試也算)，有一天這個債務就會來壓垮你，而大多數的 PM/PO 都只會觀注在商業的需求上面

DevOps 潮流下的 API First 開發策略

  • 思考功能上是先有 UI 還是先有 API ?
  • AWS 2002 Api 備忘錄
  • 內部團隊是不是有用 API 溝通的能力
  • API 的目的在於交付最後資料的價值
  • API 的生命周期
    • 建立 -> 發表 -> 實現 -> 維護 -> 除役
  • API 規格 Contract First 的方式開發，先 mock API，確保規格是對的，因為已經有假資料 (mock server)，所以可以直接跟使用者作需求確認

這一段我覺得就是使用 BDD 然後 ATDD + TDD 的方式開發是一樣的，不過，如果沒有用這樣子的方式開發，的確需要講師講的這樣

  • API 的相關事件跟狀態改變的轉移，需要有系統的去作設計，可以在寫程式之前就先列出來相關的資料，跟使用者確認
  • API 的安全性，在使用者正常的使用下，是不是會影響原來的資料
    • 異動狀態
    • 異動資料
    • 取得個資 / 機密資料
    • 列舉大量資料

基本上這段在講的是，如果是正常的使用，會不會有其它安全性的問題沒有考慮到，導致於發生上面列出來情況。另外一個點就是 API 的幕等性

  • 安全性的設計
    • 車票 : 不記名，拿到票就可以坐車
      • 適合用在對外的 API
    • 識別證 : 上面會有身份，決定這個人可以用那些服務
      • 適合用在對內的 API

我覺得這裡還有 API 的流量跟認證的方式需要考慮

  • API 的交易是個可以討論的議題，有 2PC 跟 Saga 的方式，如果原本系統是使用 DB 的話，這點就比較簡單的可以達到
    • 就跟上面討論的一樣，API 在幕等性上面的設計問題
  • 除了要持續改善之外，還要看見全貌，才不會只有做到侷部的最佳化

為 DevOps 插上商業的翅膀

  • 系統出了問題，影響的範圍
    • 多少使用者受到影響 -> 人
    • 損失了多少金額 (跟第一點有相關) -> $
  • 2B 的 SaaS 服務，多租戶架構影響範圍是所有的客戶，如果客戶是全球的話，基本上沒有時間可重啟服務來解決問題

我覺得基本上就是要 24x7 的運行，雖然講者是在 2C 才提到 24x7

  • 借鏡業界大神的經驗，服務要 99.9 可用，問題的處理時效要 15 min 內解決
  • 當沒有辦法知道現在系統相互依賴的關係時，可以爬所有系統上面的 process log，了解系統服務之間的關係，找到相對應的脆弱點
  • 每個人都要有相關的商業思維，如果今天線上出事了，公司會怎麼樣 (會賠多少 $)

基本上就是跟第一點相乎應

  • 線上問題需要先作問題分類，然後再依問題分級處理，最後是 議題追蹤
    • 分級處理
      • 人工解 -> SOP
      • 技術解 -> 自動化 (發現 root cause 之後再往下)
      • 根本解 -> 改到好
    • 議題追蹤
      • 每周會議檢討
      • 事件全貌的釐清
      • 案件追蹤

我覺得一般比較容易忽略的是，議題的追蹤上面，是不是有辦法把整個事件的全貌都記錄下來，以了解是那個環節出了問題，是不是有解決到 root casuse，另外一方面，是不是可以給末來發生類似的事件作個參考

  • 為什麼大多感受不到技術債要馬上還的需求，因為慢點還的話死不了，不會出什麼問題

我覺得這點跟前面一個議程的工程需求那點很像

  • 有辦法使用數據來解釋現在系統的效益，有沒有辦法看到相關的趨勢的情況，是不是有在惡化

後記

好久沒有參加大型的活動，可以發現近年來的 DevOps 跟一開始大家談的方向有很大的差別，現在已經比較少在談敏捷相關的議題，大多都是回歸到工程的本質，然後在不同產業導入 DevOps 也變的多樣性

寫上來的筆記也只有我覺得比較有參考的幾場演講，一些有去聽不過沒有比較特別的點就沒有列出來，有興趣的人也可以去看當天共筆，有些文字是我理解 (整理) 後寫出來的，不一定完全是當時講者講出來的，也可能跟你認知的有出入，這也是正常現象