自從去年在〈有了 Agile，為什麼還要有 DevOps？〉及〈從限制理論看 DevOps〉兩場演講中，分別以 lean thinking 及 theory of constraints (TOC) 兩個角度探討 DevOps 之後，心中一直有個願望：想再從「系統思考」角度探討 DevOps。
畢竟，「系統思考」算是名門正派，「學習型組織」更是我從研究所時代就心嚮往之的目標。當時買的《第五項修練》第一版，還一直在我的書架上最尊榮的位置呢。
不過，想將它應用到 DevOps 場域上，我還不太有把握。畢竟系統思考的重要思維工具 CLD (causal loop diagram)，比一般因果推理的思維工具，多了變量 (variable) 及時間滯延 (delay) 觀念，燒腦程度更甚於 TOC 的 CRT (current reality tree)。
想法，就這麼擱置了。
直到今年初，接連聽了呂毅老師一場演講（在組織教練中看見系統性模式）及兩天 LeSS 課程，被老師用 CLD 貫串全場的氣勢，以及推廣系統思考的熱情所感動，決定回到初衷，勇於接受挑戰。
於是，重拾《第五項修練》，重新咀嚼系統基模，研究如何以淺顯的方式解釋 CLD。我也嘗試搭配 LOOPY 這個有趣的軟體，降低 CLD 學習門檻。最後，從 DevOps 中挑選熱門的話題 microservices 作為箭靶，以增進實用性。萬事俱備，結果就是以下的演講。
DevOps Taiwan Meetup #8 (2017-10-26).
從系統思考看 DevOps：以 microservices 為例
活動簡介：
台灣第一次舉辦的 DevOpsDays Taipei，涵蓋許多精彩的文化與技術議題。
大會中，許多講者不約而同提到「系統思考」的概念，這是什麼？許多講者也提到 microservices 的重要性，但為什麼許多人想導入，卻鍛羽而歸？
此演講以系統思考的 causal loop diagram 角度，探討 microservices 常見的導入誤區：意外的敵人 (accidental adversaries) 及捨本逐末 (shifting the burden) ，並根據系統基模角度提出對應的槓桿解。
希望你聽了之後，能夠初步掌握系統思考的切入點，也對於 microservices 導入，多了一分把握。
提醒：建議先複習一下 Andrew Wu 在【DevOps Taiwan Meetup #4 (2017/02/22) ／ 這一夜讓我們來聊聊 Microservices】的內容：
投影片：
從系統思考看 DevOps：以 microservices 為例
實況錄影：
這場演講，開宗明義就說了：只探討「動態性複雜」，不探討「細節性複雜」。因此，刻意不著重在 microservices 技術細節。正好現場有兩位深富 microservices 實務經驗的高手，就順便 cue 他們幫忙回答技術提問。
感謝 andrew 幫忙回答資料儲存問題：
交易處理是 RDBMS 強項，不過 RDBMS 先天就跟 microservices 不大搭，分散式的環境下要有別的處理方式。
非交易的資料可透過 Message Queue 等等非同步的方式來達成最終的一致性。如果範圍切割得夠小，也許你仍然可以在單一服務內繼續用 RDBMS 的交易控制。如果交易被迫得被分散在兩個服務之間，那麼分散式交易的機制就必須確實實作（例如 2 phase commit 之類的技巧）。
感謝 jini 幫忙回答 transaction 問題：
但在金融交易時，若該 domain object 一定要在同一個 transaction context 時，那麼該服務就不該被切割。此外，有某些狀況也許可以切割，類似客戶與訂單的關係，這部份就可以用 async 加上 status 來處理，甚至有一個 batch 來 review 最終一致性。
最後，希望這種「系統思考」角度，對大家在導入 DevOps 的過程中，有些許幫助。更進一步，朝向學習型組織邁進。
演講最後推薦的幾本書，別忘了要去看喔！