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),來負責相關新技術的研究跟導入
  • 單體式的服務,原本很多的邏輯都是寫在 DBSP,帶來的後果就是沒有辦法寫測試。後來把常變動的部份抽出來,變成新的服務 (微服務的方式),新的服務也就是用新導入的 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 的交易是個可以討論的議題,有 2PCSaga 的方式,如果原本系統是使用 DB 的話,這點就比較簡單的可以達到
    • 就跟上面討論的一樣,API 在幕等性上面的設計問題
  • 除了要持續改善之外,還要看見全貌,才不會只有做到侷部的最佳化

為 DevOps 插上商業的翅膀

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

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

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

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

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

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

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

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

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

後記

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

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