owned this note   changed a year ago  
Linked with GitHub

架構師也要 DevOps - 談服務模型的持續交付 - Andrew Wu

歡迎來到 DevOpsDay Taipei 2023 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口：https://hackmd.io/@DevOpsDay/2023
手機版請點選上方 按鈕展開議程列表。

講師提供的資訊連結:

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

共筆: 從這裡開始寫

前言

選擇這個題目投稿的動機…

  • 體驗一下，實際上老闆想要的 "商業模型" 是什麼東西… ?
  • 商業模型，決定了產品服務的樣貌
  • 技術模型，決定了背後系統的樣貌
  • 持續將商業模型，對應到技術模型，就是架構師的日常任務

讓團隊對其同樣的商業目的進而收斂建模, 再建立成技術模型

  • 商業需求 > 商業模型 > 技術模型 > 收斂成簡單的模型
  • API 是個商業模式

BizDevOps

  • 業務需求，對應系統需求，再抽離出模型

Biz <-> Srv 是一個循環, 這裡要從商業模型抽象化出技術模型的重點
Srv <-> Dev <-> Ops是另一個循環

敏捷團隊中的架構師，該扮演什麼角色?

架構設計是一開始就要先看到全貌, 而不是蓋到哪裡才想到哪裡
進而持續循環細化設計
有些事情要事先規劃好

Ref: Role of Architect in Agile Development

範例 - 老闆想要 (聽) 的商業模型..

  • 有門市銷售領域
    * 疫情影響了實體門市的業績
    * 開始發展出 app 與 錢包支付
  • 有線上銷售領域
    * 線上銷售與社群平台的整合
    * 廣告模式、整合
    * 多方整合後，其價值回饋到消費者上

BizDevOps，由商業需求建立技術模型

  • 系統與系統之間，會有資料的傳遞，相對就有 API 需求
  • 把需求抽象化出模型
  • 持續調整模型，趨近商業需求。
  • 商業需求，要知道核心價值是什麼，能正確的進行模型設計。

讓模型能被驗證: 用 OOP 來建立技術模型

  • 抽象化，描述主要商業目標，隱藏一切不相關的細節
    * ( ex: 使用 Kubernetes 算不算 "不相關" 的細節? ) ( 架構師腦容量有限… )
  • 降級的技巧
    * 降級，是指講者對於“抽象化”的另一種說法
  • 將模型對應到程式碼
  • 簡化到 200 ~ 500 lines of code； 能驗證邏輯的情境, 用 unit test 對應

由模型來驗證監控指標

  • 降級技巧的進階應用
  • 已經可以讓你跑完商業流程跟設計邏輯的驗證，這驗證能否進一步拿來驗證維運?
  • 拿同樣的技巧，應用在改善維運機制的設計
    * 正確的設計模型，就能知道應該關注的指標為何。
  • 模型除了拿來改善 Dev, 也該要能拿來改善 Ops
    * Dev 端要從模型開始，推行 API First … , 而 Ops 端也應該要從模型開始，推行 Metric First …

Sim = Stimulation

零售業的全通路領域地圖

O2O

OMO

庫存整合更有效益

老闆講了14頁的商業模型和受眾以及商業競爭力, 甚至彼此之間怎麼整合來達成目的
但離寫成程式還很遠, 但架構師就是在分析跟抽象畫這些, OMO場景下能分成人, 場域, 貨品來劃分領域

建模的流程

  • 設計
  • 驗證
  • 持續交付 : 這點是今天分享的重點

思考: 會員註冊的功能，你看到的核心價值是什麼?

抓到目的後, 將註冊重點的會員資料定義出狀態圖, 狀態的轉移會搭配對應的行為, 甚至也能找出調用行為的角色.
不讓第三方把資料拿走，但改版要外包

06-1. 對照組, 採用 CRUD 設計出來的 API Spec

行為不只有CRUD 四隻API

你要看透事物的本質，精準 (且毫不多餘) 的用模型來表達你的構思。

2. 讓模型能被驗證: 用 OOP 來建立技術模型

Tech model -> POC的過程
架構師最重要的就是建模(modeling)和抽象化(abstraction)的能力,
交付時持續地確保交付的東西是正確的.
只要能設計成code, 就有辦法去驗證, 但設計時要降低認知負擔(找出邊界).

大型系統設計的複雜度:

最基本的模型，就是 Entity + Operation + State Machine ( Life Cycle )
更細緻的模型分析，首推 DDD ( Domain Driven Development ) 的方法論

工程師往往做了很多最佳化, 但未必有對其商業需求,雖然符合規格也通過了測試.
換句話說就是缺乏因應商業走勢來變化的彈性 => 會形成技術債

抽象化後降級設計, 將各種架構選擇的重要元素，都先抽象化成基本程式語言就能表達的層次，並且先在腦袋建立好 "對照關係"
因為降級了設計, 不用真的準備好所有的環境, 能寫個簡單的POC串接流程做驗證.

Message Queue引用的思考

也許要的不是message queue,而是messaging的管理

3. 由模型來模擬驗證監控指標

Tech model -> Sim維運

開始之前，試著自己回答這幾個問題:

  • 呈現一堆主機與性能監控

我心裡理想的業務監控，應該是這樣:

系統指標 + 監控系統 => 成熟可靠的監控方案
商業指標 => 大部分都是跑報表，或是 RD 自行開發的監控 "功能"

透過降級設計, 快速將資料呈現成指標後, 確定這些指標是不是自己未來在營運環境上想看到的圖表, 甚至能跟運維團隊講解這些與業務行為的掛鉤.

指標在系統已經上線後, 要再測量採集會有難度.
但能透過建模, 抽象化, 降級, 早期就能察覺到這指標的需要性.

Metric First: 盡早確認監控，維運才能順利


建模日常, 在找出模型的認知/職責邊界進行模型切割


每個區塊都是一個模型, 都有附上文章連結

模型的最大價值：

  • 能夠明確抽離出需求、分界

可探討的問題？

降級之後，是否能夠再升級呢？

Q & A, 歡迎留下問題, 演講結束後可以找我聊聊.

留在這邊的問題, 我這一週內都還會過來回覆, 單純的意見回饋也歡迎~

Andrew WuOct 4,2023 17:50
活動過去一個多禮拜了，問題我就回覆到這邊了喔 (這段期間我每天都還有來詢一次)。之後還有問題的話歡迎到我的 facebook 粉絲專頁留話跟我聯絡 :

Alvin
Q: 想詢問 Andrew，身為工作經驗約 3 年的菜鳥後端工程師，要怎麼在日常開發過程中，訓練今天提到的一些架構師的能力與觀點？例如建模、降級。或是對於這種初階工程師，想要往架構師邁進的話，有什麼從現在開始、可以在日常中應用的技巧或是思考方式？感謝

路人請供小建議

  1. 先從本身負責的服務去思考其他相依服務、上下游，如何讓他們使用你的功能時，具備清楚與易使用，站在服務與服務的邊界去改善兩者的互動
  2. 建模、降級的部份先從原本的服務完全去除有關data persistence(如資料庫)的影響，使用簡化的類別模擬相關作業後仍然可以運作並與互動，再逐一剔除與本核心業務非直接相關的服務

William Yeh
也可以試著強迫自己，只用 clean architecture 最內的兩圈來設計（entities + use cases），這樣就容易達到初步的建模 + 降級。

Andrew WuTue, Sep 26, 2023 13:30 PM
架構師要面臨的挑戰是 "廣度" + "深度" 都要兼具，說實在不是件能速成的事情。昨日的分享我有提到多次，基礎是重要的，而且要熟練，否則你的認知負擔會處理不了 (抽象化不夠，你就有太多細節要溝通)。抽象化跟降級是你不得不做的動作。

我的建議跟 William Yeh 一樣，先從小規模你已經熟悉的案子 (甚至是半成品都可以) 回過頭來重建模型，並且驗證看看。簡單的模型其實狀態機就能搞定了，DDD 也不用太早接觸，沒有足夠基礎就去碰這種流程框架，其實你會掌握不到重點的。掌握好 State Machine, 確保你的 Entity / Database Schema 到位, 你的 API / Service / Command 等等也都到位，再開始思考更大範圍的問題。

最後，別把架構師當作你必要的發展方向，不是每個工程師最終都要變成架構師的。高度抽象化的副作用，是你無法顧及太多細節。你會少掉很多親手把東西蓋起來的樂趣，所以我會建議你至少每個領域 (語言、前後端、資料庫等等) 都至少有一個專精的程度時，再考慮往架構師發展。你在特定領域已經夠深，你才有本錢發展廣度 (而且人家要能服你才算數)。

Alvin (原 PO)
感謝各位大大的回答與建議～

thanks

共筆聊天室：

  • 講者有事先提供簡報，很讚！推推推推推！

講者語速適中又平穩，nice

商業建模是否就要談到 DDD，再來 OOA/D？
果然提到 DDD 啦！

蔡學鏞大現在好像都是在企業當顧問？蠻久買看到新文章了

痣

還好樓上不是貼聖物的照片

Select a repo