前情提要: 被同事坑一波，就去參加了今年的 DevOps Day。

全部的心得可能分幾次。 每個 Keynote 大都分為兩部分，議程簡介和心得感想

DevOps Day 心得

website 大會共筆

Day1 早上

hackmd

2023臺灣企業DORA關鍵數據大公開

DORA: DevOps Research and Assessment，Google Cloud 後來買下，每年都會發布的指標與報告

官網連結

ithome 做的大調查，主要是給各公司的CTO填寫，政府機關、企業主管等 早上，是Devops台灣的總結，有IT的薪資（或是說投入金額）

重點：投入IT的金額相對降低，但是DevOps的比例有變高

DORA 指標:

  • 團隊開發速度
    1. 部署頻率
    2. 更新准備時間，改版交付時間
  • 軟體品質和穩定度
    1. 平均復原時間(MTTR)
    2. 變更失敗率

全球的發現: 符合高接、菁英的團隊變多了 台灣:去年2022的初階團隊變多，2023拿來與之相比沒有太大意義 總體而言: 跟全球比還是落後一點，

特別發現: 政府機關投入金額非常高，資安相關議題還有雲元生系統建置相關的專案

心得:

因為沒有以往參與的經驗，對這些數字沒有什麼概念，不過DORA的指標倒是可以參考的事項，對於國外，或是受調查的團隊都達到菁英其實還滿驚訝的，不過聽完兩天之後，可以理解我們自己的團隊，與可以達到地團隊的差異。

Ruddy 老師的撈叨

標題是寫人工智慧下的開發者經驗，但有點對不上人工智慧，聚焦在開發者經驗。

官網連結 共筆

重點:

  • 雜談現狀:
    • 新興 AI 的應用正在 hype 的階段, 接下來會慢慢邁入成熟階段
    • AI 時代來臨, 突然有全世界的知識, 你要做什麼?請一定要思考這個問題

加速開發速度?

  • 影響Release的速度是什麼:
    • 公司的文化
    • 誰形成文化? 開發者 Dev
  • Dev Experience –> DevX
    • 只開發者與執行軟體磣品服務相關的工具、平台、流程和人員之間的所有互動
    • 公司提升這些就可以增加 release 更快

DevX

  • DevX 理念
    • 開發者體驗即是平台 -> DevX平台
    • 開發者體驗即是導師制 -> 由 mentoring開始
    • 開發者體驗即是學習 -> 新手到專家的途徑
    • At last but not least
    • 強化開發者社交平台：Git 與開發者模式

改善團隊的開發者體驗

  • 不要犠牲品質
  • 要形成一個平台來幫助工程師開發
    • 有好的共同知識庫
    • 有好的團隊、mentor制度
  • 降低負荷
    • 降低工程師的認知負荷：減少開會等等
    • 如果時限已經壓下來，肯定不能完成的話，減少工作量
    • Speed Model / 調整組織
  • 如何協作: 交付模式 (跨團隊)
    1. 跟他一起協作（成本超高）
    2. 寫service API (普遍)
    3. 引導式：什麼都不要做,用文件（成本最低、但是聽起來最需要好的文化）
  • 「專注」對開發很重要
    • 提供環境(物理)和流程

因為太多太雜,建議可以看共筆

心得：

  • 以talk來說，有點太雜太散
  • 減少工作真的是大快我心 XDD，本來以為講者會提出沒有聽過的解決辦法，但就是讓PO去減少工作量
  • 降低認知負荷對我是一個新的概念和觀點，讓我重新評估滿多事情
  • 我們公司的環境滿不符DevX的，但在我們的團隊內，應該可以想辦法實現部分理念
    • 增加文件
    • 從各種層面降低認知負荷: 工作量、Deadline、會議
    • 持續交流技術、coding mentor協作(PR)

架構師也要DevOps

從沒聽過架構師，酷東西

官網連結 共筆 講師fb貼文

BizDevOps

  • 將業務需求(Biz)加入 DevOps
  • 這部分不太深入，可以找其他資源(有另一場講座)

為什麼需要架構師?

  • 以零售業為範例，介紹場域內的人物。(引用來源)
    1. 社群平台+平台->通訊＋門市
    2. 網紅+平台 -> 通訊＋門市
    3. 網紅＋購物平台＋訂單平台->門市＋Uber社群
    4. 人＋場域＋貨物
  • 因為有上述這麼多的關係，電商、零售平台如何整合這些人?
  • 釐清系統(零售平台)該有的範圍以後，建立模型，並且設計系統
    • 找到狀態圖:狀態、操作、事件
    • 找到角色
    • 找到行為

介紹這個職位需要做什麼事

  • 架構設計是一開始就要先看到全貌，而不是蓋到哪裡才想到哪裡
  1. 由商業需求建立技術模型
    • 建模的重要性，把所有東西建模
    • 把商業抽象化成為模型
      • 我的認知：把知識變成模組縮小化
    • 建立成模型 → 狀態圖 → 開成spec
  2. 如何驗證模型:用OOP來建立技術模型
    • Model as Code. 把模型 ⇒ 降級、抽象化 ⇒ POC code 才可以驗證
    • 大型系統設計的複雜度
      • 面對複雜多變的需求，卻又期待 API 規格能穩定長久使用，其實是兩個互相衝突的目標
      • 找出背後的領域模型(Domain Model)
      • 基本模型: 狀態 cycle
      • 進階: 首推 DDD 的方法論
    • 為什麼模型很重要?
      • 客戶：幫我拿掉一個按鈕
      • 工程師：不知道拿掉很麻煩嗎？（可能用了很巧妙的方式達到spec）
      • 中間是兩邊 biz model 跟 tech model 的 gap，所以才要交給模型師
    • OOP降級法
      • 把 remote service 降級成 local service，類似這樣的做法
      • 把整個過程(模型)寫成一個OOP
  3. 要如何系統化的監控
    1. 系統的監控(CPU, API call)有做了，但是我想要最近1秒的交易量呢？
    2. 從biz model的角度可以monitor嗎?
    3. 降級: 維運監控 ⇒ 從CSV報表開始
      1. 用CSV方式，製作pivot
      2. 用pivot來模擬維運(Ops)、商業想要看哪些 metrics
    4. 開發時就預先提出metrics，實作出來

Next step

如果想要成為架構師，可以做

  • 會一種語言，前後端、平台、資料庫，隨時做好建立模型
  • 熟練 需求 ⇒ 模型 ⇒ 驗證

如果想要這樣的團隊

  1. 各產品線/部門都要有上述的人才，具備這些技術
  2. 培養團隊的tech lead，具備模型溝通能力，有能力降級模型，還原成技術規格 → POC

心得

  • 這個職位好特別!!! 公司滿需要有這種職位的人，最好可以理解domain 跟工程師的合作
    • 但在目前的框架下有點太困難了，因為domain各自持有很重、而且會把原本不是domain的東西製作成只有該單位才可以理解的方式實在是有點難以理解
  • 不能有這種職位、但可以借鏡，在完成一個龐大的系統前，應該要有一個人、會議或是團體可以理解全部的需求、並且可以規劃整體的架構才不會造成開發的負擔
  • 另外他也有提到 「面對複雜多變的需求，卻又期待 API 規格能穩定長久使用，其實是兩個互相衝突的目標」，這個真的是現在遇到的狀況的完美縮寫
  • 最近也面臨需求的問題，有許多biz跟tech的gap，導致很痛苦，團隊也意識到有許多東西是要事前規劃好的，才不會一直改規格，又因為改規格壓迫更多開發時間。架構師是一個可以借鏡的思考方式，可以從 user, biz 角度先找到重要的價值，才不會system design 與 biz model 不和，形成痛苦巡環。

(last edit 10/25)