系統工程師的 DevOps 實踐之道
系統思考 (Systems Thinking)，一是門需要刻意練習的技藝！趁著在新竹敏捷之旅 (Agile Tour Hsinchu 2018) 和高雄敏捷之旅 (Agile Tour Kaohsiung 2018) 上台分享的機會，凍仁試著使用因果循環圖 (Causal Loop Diagram, CLD)，來述說兩年來的 DevOps 實踐心得。
本次主題，可說是一年前的〈從一個人的 DevOps，到一個 DevOps 的團隊〉分享沿續。那時是介紹凍仁從大學以來習得的 DevOps Tools 技藝，以及現實中的 DevOps 團隊。
▲ 於 Agile Tour Taichung 2019 分享〈系統工程師的 DevOps 實踐之道 (3/e)〉的投影片。
喜愛 Linux 的凍仁，大學畢業後，成了一位系統工程師 (System Engineer)。 P.6
以前的凍仁常常每天都在打火，救火工作 (Recovery work) 多到讓人懷疑人生。
三年前的凍仁，告訴自己不該再這麼繼續下去，於是踏上了 DevOps 學習之旅。 P.8
在這段旅程中，《鳳凰專案》一書幫了凍仁不少忙，想深入了解 DevOps 的伙伴，還請一定要抽出時間看過它。
談到 DevOps，凍仁喜歡先用狹義和廣義的 DevOps，來說明什麼是 DevOps？
1. 狹義的 DevOps：把開發 (Dev)、維運 (Ops) 和基礎建設 (Infra) 的工作流程打通並優化。
2. 廣義的 DevOps：除狹義的 DevOps，還包含了商業投資 (Invest)、需求 (Request)、使用 (Use) 和價值 (Value)，並藉由不斷的循環持續改善 (Continuous Improvement)。 P.13
3. BizDevOps：凍仁也很喜歡 Ruddy Lee 老師的分享的 BizDevOps，其全名為 Business DevOps，意指要 Business 放在 DevOps 之前，從商業的角度看 DevOps。包含了三步工作法、限制理論、學習型組織、系統思考、CALMS 等等。 P.14
本次，凍仁將會藉由系統思考這項技藝，分享自己團隊的 DevOps 實踐心得。
在開始之前，先來看看前人怎麼說系統思考。
系統思考，又稱為系統思維和系統科學 (Systems theory)，其包含了不少流派。凍仁目前所學習的技藝為系統動力學 (System dynamics) 的因果循環圖 (以下簡稱 CLD)。對凍仁而言，它是一項用因果關係，推導要素間的關係和結構，進而從整體看見系統行為、找出槓桿解的高深技藝。
▌ 在《The DevOps Handbook》出版前，曾有一派人馬認為三步工作法的 Flow，即為系統思考。
除了三步工作法外，《鳳鳳專案》還提到另一個很重要的觀念 － 四種工作類型。
IT 部門的工作，大致可分為業務專案 (Business projects)、IT 內部專案 (Internal IT projects)、變更工作 (Changes) 和計劃外工作 (Unplanned work / Recovery work) 等四種工作類型。相較於業務工作，其它三種工作常被忽略且不被重視。 P.19
試著把四種工作類型的要素連接起來，得到了具有 3 個增強迴路 (Reinforcing feedback loop) 的 CLD。
以目前的 CLD 來看，一旦業務工作待辦量增加， IT 內部專案工作量和計劃外工作發生率會跟著增加，變更工作品質則會降到谷底。
在 IT 內部專案工作量居高不下的情形，大家或許會想靠加班解決！？可提升加班時數，雖能降低 IT 內部專案工作量，但也會降低變更工作品質、提升 IT 內部專案工作量，甚至還會提升計劃外工作發生率，治標不治本！
《鳳鳳專案》作者透過埃瑞克．里德 (Erik Reid) 告訴我們：「要好好保護變更工作！因為當變更出了差錯，就得動用更多的人力、物力和資源救火，最後影響到業務專案的工作進度。」 P.28
凍仁心想，只要提升變更工作品質、降低計劃外工作發生率，就可以建立與企業雙贏的工作環境，提早下班！
回頭看看 CLD，只要提升變更工作品質，就可減少 IT 內部專案工作量和計劃外工作發生率。加上此為增強迴路，它會像滾雪球般越滾越大的有效減少 IT 內部專案工作量。 P.31
一開始，我們常藉由手動組態管理來完成工作。但這會降低協作力、提升人為失誤率、降低變更工作品質、降低工作完成量。當工作完成不了，IT 內部專案工作量又將提升。
一旦變更工作品質下降，計劃外工作發生率也會跟著上升，再次增加 IT 內部專案工作量。
為了降低人為失誤率、提升變更工作品質，凍仁開始記錄每次的變更，並從過往的經驗中學習。
原先，我們使用 Redmine 和網頁版的 Excel 記錄各種變更，但這都不比白板 (Whiteboard) 來得直覺有用。把變更寫在白板上，除了可把資訊可視化，還能與團隊一起討論、即時同步部署狀態。待部署完成後，再一項項記錄在 Redmine 上即可。
▌ 數個月後，待發佈 (release) 流程和部署工具較完善了，才只使用 Redmine 記錄變更；但遇上較複雜的變更工作時，凍仁還是會拉出白板輔助。
為更進一步地降低人為失誤，我們還會在進行重大變更時，使用兩人結對的 Pair System Administration。雖會多消耗一人的工時，但兩個人一起操作系統，可有效降低人為失誤，真的很划算！
▌ 身為一位 Linux 系統管理員，精神不好時，還請千萬不要亂下指令，尤其是用到 root 權限的指令！
有跑 Scrum 的團隊，還可以藉由在每日的站立會議 (Stand-up meeting) 裡提問，來降低團隊的人為失誤。例如：今天有要更改開發環境 (development environment) 的資料庫 (database) 架構嗎？預計幾點開始進行？需要什麼樣的協助？
為了獲得 Ansible 自動化組態的能力，我們得先學習原有的架構流程、撰寫 Ansible Playbooks，才可用它來減少 IT 內部專案工作量。可學習和撰寫 Playbooks 都需要時間，所以畫上了延遲時間 ≠ 的符號。
學習安裝 (setup) 和部署 (deployment) 流程之前，得先請團隊伙伴撰寫文件 (documents) 以分享這些內隱知識 (tacit knowledge)。有時，還得先改過文件，看得懂上面寫什麼，才有辦法撰寫 Playbooks。
▌ 俗話說的好：「工程師最喜歡的就是看文件，最討厭的就是寫文件。」
現在，凍仁比較喜歡藉由 Pair Programming 的方式，將熟悉 Ansible 的同事和知曉安裝流程的同事配對，兩人一起完成 Playbooks。除了可省下撰寫文件和學習的時間，還可加快撰寫 Playbooks 的速度。
導入 Ansible 組態，可提升團隊的協作力。當協作力上升，Ansible 組態的能力也會跟著上升。此外還可降低預演組態變更成本、降低人為失誤。
導入 Ansible 組態後，原本的增強迴路，都成了平衡迴路 (Balancing feedback loop)。也就是當 IT 內部專案工作量上升後，變更工作品質會跟著提升、計劃外工作發生率則會下降。可說是本次推演的根本解啊！
對照手動組態的增強迴路，當 IT 內部專案工作量上升後，會讓變更工作品質下降、計劃外工作發生率提升。
從這個 CLD 可以得知「組態管理，欲速則不達」的現象。
Ansible 雖可提升變更工作品質，但無法有效抑制計劃外工作發生。礙於時程考量，凍仁導入了自己最熟悉的監控工具 － Zabbix。透過監控提升系統掌握度，進而降低計劃外工作。
想像一下，在一個將近百台機器的環境裡，若沒有監控工具輔助，要怎麼即時得知整個系統的狀態？又要怎麼在第一時間進行修復問題呢？
各位若對 Zabbix 有興趣，不妨看看凍仁先前分享過的「簡單易用的 Zabbix 監控服務」一文。
為提升系統掌握度，凍仁還曾用便利貼和膠帶貼出一面「便利貼架構牆」。雖然剛開始有些辛苦，但把系統架構可視化後，看到自己的團隊和其他團隊站在這面牆前討論、分享系統架構時，就令人感到欣慰啊！
▌ 當發生例外狀況 (outage) 時，我們只需一個轉身、一個回頭，就可以用最快的時間，討論哪邊的服務出了問題，以及任務分派等等。
系統基模，是系統思考者的強大工具之一，底下凍仁將用它進行本次 CLD 的分析。
來自《第五項修練》的建議：眼光凝聚在長期焦點。如果可能的話，完全摒除那種短期對策。除非短期對策只是用來換取時間，以尋求更妥善的長期解決方案。
1. 當我們選擇提高加班時數對策時，短期雖可減少 IT 內部專案工作，但長期下來會造成人為失誤率提升、變更工作品質下降、計劃外工作發生率提升等後遺症。
2. 當我們選擇增加手動組態對策時，短期雖可減少 IT 內部專案工作，但長期下來會造成協作力下降、記錄變更下降、從過往學習下降、人為失誤率提升、變更工作品質下降、工作完成量下降等後遺症。
3. 當我們選擇增加手動組態對策時，短期雖可減少 IT 內部專案工作，但長期下來會造成協作力下降、人為失誤率提升、變更工作品質下降、計劃外工作發生率提升等後遺症。
來自《第五項修練》的建議：將注意力集中在根本解。但如果問題急迫，由於根本解的效果受時間滯延影響，在進行根本解的過程中，可暫時使用症狀解來換取時間。
手動組態的短期看似立即有效，但使用得越多，Ansible 組態的根本解能力可能會萎縮，並造成協作力下降之副作用。
來自《第五項修練》的建議：不要去推動「增強 －－ 成長 －－ 環路」，應該要除去 (或減弱) 限制的來源。
Ansible 組態雖可藉由提升協作力來成長，但它同時也被 IT 內部專案工作量的要素抑制。要想讓 Ansible 組態能力成長，我們應該要降低加班時數、降低手動組態次數和減少工作完成量。
感謝授予這些技藝給凍仁前輩們，此次主題分享，對凍仁而言是個極大的挑戰！經過這次上台分享的刻意練習，自己對系統思考的掌握度也有所提升。
從四種工作類型到自己的 DevOps 實踐，最後成了一個系統。這得耗費不少的時間、心力和腦力才有辦法達成。來日若有機會，再推出 3.0 版，述說自己的 Agile 實踐心得，不過那應該會是明年年底之後的事了。
在此跟各位讀者打個預防針，以上的兵棋推演，是凍仁自己的思維模型，還有改善空間。若有哪邊寫不好的地方，還請留言告知。
最後，預祝大家 2019 年新年快樂！
系統思考學徒
凍仁翔
Mon Dec 31 03:45:10 CST 2018
本次主題，可說是一年前的〈從一個人的 DevOps，到一個 DevOps 的團隊〉分享沿續。那時是介紹凍仁從大學以來習得的 DevOps Tools 技藝，以及現實中的 DevOps 團隊。
▲ 於 Agile Tour Taichung 2019 分享〈系統工程師的 DevOps 實踐之道 (3/e)〉的投影片。
前言
喜愛 Linux 的凍仁，大學畢業後，成了一位系統工程師 (System Engineer)。 P.6
以前的凍仁常常每天都在打火，救火工作 (Recovery work) 多到讓人懷疑人生。
三年前的凍仁，告訴自己不該再這麼繼續下去，於是踏上了 DevOps 學習之旅。 P.8
「人生苦短，我們需要 #DevOps。」— 凍仁翔 (@chusiang_lai) December 21, 2018
"Life is short, we need DevOps."
- Chu-Siang Lai, A Linux System Engineer.
▍https://t.co/58w09F8Cne#quote
在這段旅程中，《鳳凰專案》一書幫了凍仁不少忙，想深入了解 DevOps 的伙伴，還請一定要抽出時間看過它。
 |
| ▲ 若您還未看過《鳳凰專案》一書，可以先閱讀凍仁先前的介紹文。 |
DevOps 是什麼？
談到 DevOps，凍仁喜歡先用狹義和廣義的 DevOps，來說明什麼是 DevOps？
1. 狹義的 DevOps：把開發 (Dev)、維運 (Ops) 和基礎建設 (Infra) 的工作流程打通並優化。
2. 廣義的 DevOps：除狹義的 DevOps，還包含了商業投資 (Invest)、需求 (Request)、使用 (Use) 和價值 (Value)，並藉由不斷的循環持續改善 (Continuous Improvement)。 P.13
3. BizDevOps：凍仁也很喜歡 Ruddy Lee 老師的分享的 BizDevOps，其全名為 Business DevOps，意指要 Business 放在 DevOps 之前，從商業的角度看 DevOps。包含了三步工作法、限制理論、學習型組織、系統思考、CALMS 等等。 P.14
本次，凍仁將會藉由系統思考這項技藝，分享自己團隊的 DevOps 實踐心得。
系統思考是什麼？
在開始之前，先來看看前人怎麼說系統思考。
「系統指的是由相互聯繫、相互作用的要素 (或部分) 組成的具有一定結構和功能的有機整體；準確來說，要素 + 結構 = 系統。從系統的角度觀察研究客觀世界的學科，就是系統科學。系統科學主要研究系統的要素，結構，和系統的行為。」
- 系統科學 | 维基百科
「系統並不僅僅是一些事物的簡單集合，而是一個由一組相互連接的要素構成的、能夠實現某個目標的整體。從這一定義可見，任何一個系統都包括三種構成要件：要素、連接、功能或目標。」
- Donella H. Meadows，《系統思考 Thinking in Systems》
系統思考，又稱為系統思維和系統科學 (Systems theory)，其包含了不少流派。凍仁目前所學習的技藝為系統動力學 (System dynamics) 的因果循環圖 (以下簡稱 CLD)。對凍仁而言，它是一項用因果關係，推導要素間的關係和結構，進而從整體看見系統行為、找出槓桿解的高深技藝。
▌ 在《The DevOps Handbook》出版前，曾有一派人馬認為三步工作法的 Flow，即為系統思考。
四種工作類型 (4 types of Work in IT)
除了三步工作法外，《鳳鳳專案》還提到另一個很重要的觀念 － 四種工作類型。
IT 部門的工作，大致可分為業務專案 (Business projects)、IT 內部專案 (Internal IT projects)、變更工作 (Changes) 和計劃外工作 (Unplanned work / Recovery work) 等四種工作類型。相較於業務工作，其它三種工作常被忽略且不被重視。 P.19
 |
| ▲ 一般老闆、PM 只會看到冰山上頭的業務專案，卻忽略了海水下方三種工作。 |
試著把四種工作類型的要素連接起來，得到了具有 3 個增強迴路 (Reinforcing feedback loop) 的 CLD。
 |
| ▲ 為提升簡報易讀性，凍仁改用「實線」和「虛線」表示正相關與負相關。 |
以目前的 CLD 來看，一旦業務工作待辦量增加， IT 內部專案工作量和計劃外工作發生率會跟著增加，變更工作品質則會降到谷底。
 |
| ▲ Power by LOOPY - http://s.drx.tw/4ToW. |
在 IT 內部專案工作量居高不下的情形，大家或許會想靠加班解決！？可提升加班時數，雖能降低 IT 內部專案工作量，但也會降低變更工作品質、提升 IT 內部專案工作量，甚至還會提升計劃外工作發生率，治標不治本！
《鳳鳳專案》作者透過埃瑞克．里德 (Erik Reid) 告訴我們：「要好好保護變更工作！因為當變更出了差錯，就得動用更多的人力、物力和資源救火，最後影響到業務專案的工作進度。」 P.28
凍仁心想，只要提升變更工作品質、降低計劃外工作發生率，就可以建立與企業雙贏的工作環境，提早下班！
回頭看看 CLD，只要提升變更工作品質，就可減少 IT 內部專案工作量和計劃外工作發生率。加上此為增強迴路，它會像滾雪球般越滾越大的有效減少 IT 內部專案工作量。 P.31
瓶頸 1：人為失誤
一開始，我們常藉由手動組態管理來完成工作。但這會降低協作力、提升人為失誤率、降低變更工作品質、降低工作完成量。當工作完成不了，IT 內部專案工作量又將提升。
一旦變更工作品質下降，計劃外工作發生率也會跟著上升，再次增加 IT 內部專案工作量。
為了降低人為失誤率、提升變更工作品質，凍仁開始記錄每次的變更，並從過往的經驗中學習。
原先，我們使用 Redmine 和網頁版的 Excel 記錄各種變更，但這都不比白板 (Whiteboard) 來得直覺有用。把變更寫在白板上，除了可把資訊可視化，還能與團隊一起討論、即時同步部署狀態。待部署完成後，再一項項記錄在 Redmine 上即可。
▌ 數個月後，待發佈 (release) 流程和部署工具較完善了，才只使用 Redmine 記錄變更；但遇上較複雜的變更工作時，凍仁還是會拉出白板輔助。
為更進一步地降低人為失誤，我們還會在進行重大變更時，使用兩人結對的 Pair System Administration。雖會多消耗一人的工時，但兩個人一起操作系統，可有效降低人為失誤，真的很划算！
▌ 身為一位 Linux 系統管理員，精神不好時，還請千萬不要亂下指令，尤其是用到 root 權限的指令！
有跑 Scrum 的團隊，還可以藉由在每日的站立會議 (Stand-up meeting) 裡提問，來降低團隊的人為失誤。例如：今天有要更改開發環境 (development environment) 的資料庫 (database) 架構嗎？預計幾點開始進行？需要什麼樣的協助？
瓶頸 2：導入 Ansible 自動化組態工具
為了獲得 Ansible 自動化組態的能力，我們得先學習原有的架構流程、撰寫 Ansible Playbooks，才可用它來減少 IT 內部專案工作量。可學習和撰寫 Playbooks 都需要時間，所以畫上了延遲時間 ≠ 的符號。
學習安裝 (setup) 和部署 (deployment) 流程之前，得先請團隊伙伴撰寫文件 (documents) 以分享這些內隱知識 (tacit knowledge)。有時，還得先改過文件，看得懂上面寫什麼，才有辦法撰寫 Playbooks。
▌ 俗話說的好：「工程師最喜歡的就是看文件，最討厭的就是寫文件。」
現在，凍仁比較喜歡藉由 Pair Programming 的方式，將熟悉 Ansible 的同事和知曉安裝流程的同事配對，兩人一起完成 Playbooks。除了可省下撰寫文件和學習的時間，還可加快撰寫 Playbooks 的速度。
導入 Ansible 組態，可提升團隊的協作力。當協作力上升，Ansible 組態的能力也會跟著上升。此外還可降低預演組態變更成本、降低人為失誤。
導入 Ansible 組態後，原本的增強迴路，都成了平衡迴路 (Balancing feedback loop)。也就是當 IT 內部專案工作量上升後，變更工作品質會跟著提升、計劃外工作發生率則會下降。可說是本次推演的根本解啊！
對照手動組態的增強迴路，當 IT 內部專案工作量上升後，會讓變更工作品質下降、計劃外工作發生率提升。
從這個 CLD 可以得知「組態管理，欲速則不達」的現象。
瓶頸 3：降低計劃外工作
Ansible 雖可提升變更工作品質，但無法有效抑制計劃外工作發生。礙於時程考量，凍仁導入了自己最熟悉的監控工具 － Zabbix。透過監控提升系統掌握度，進而降低計劃外工作。
想像一下，在一個將近百台機器的環境裡，若沒有監控工具輔助，要怎麼即時得知整個系統的狀態？又要怎麼在第一時間進行修復問題呢？
各位若對 Zabbix 有興趣，不妨看看凍仁先前分享過的「簡單易用的 Zabbix 監控服務」一文。
為提升系統掌握度，凍仁還曾用便利貼和膠帶貼出一面「便利貼架構牆」。雖然剛開始有些辛苦，但把系統架構可視化後，看到自己的團隊和其他團隊站在這面牆前討論、分享系統架構時，就令人感到欣慰啊！
▌ 當發生例外狀況 (outage) 時，我們只需一個轉身、一個回頭，就可以用最快的時間，討論哪邊的服務出了問題，以及任務分派等等。
系統基模 (Systems Archetypes)
系統基模，是系統思考者的強大工具之一，底下凍仁將用它進行本次 CLD 的分析。
飲鴆止渴
來自《第五項修練》的建議：眼光凝聚在長期焦點。如果可能的話，完全摒除那種短期對策。除非短期對策只是用來換取時間，以尋求更妥善的長期解決方案。
1. 當我們選擇提高加班時數對策時，短期雖可減少 IT 內部專案工作，但長期下來會造成人為失誤率提升、變更工作品質下降、計劃外工作發生率提升等後遺症。
2. 當我們選擇增加手動組態對策時，短期雖可減少 IT 內部專案工作，但長期下來會造成協作力下降、記錄變更下降、從過往學習下降、人為失誤率提升、變更工作品質下降、工作完成量下降等後遺症。
3. 當我們選擇增加手動組態對策時，短期雖可減少 IT 內部專案工作，但長期下來會造成協作力下降、人為失誤率提升、變更工作品質下降、計劃外工作發生率提升等後遺症。
捨本逐末
來自《第五項修練》的建議：將注意力集中在根本解。但如果問題急迫，由於根本解的效果受時間滯延影響，在進行根本解的過程中，可暫時使用症狀解來換取時間。
手動組態的短期看似立即有效，但使用得越多，Ansible 組態的根本解能力可能會萎縮，並造成協作力下降之副作用。
成長上限
來自《第五項修練》的建議：不要去推動「增強 －－ 成長 －－ 環路」，應該要除去 (或減弱) 限制的來源。
Ansible 組態雖可藉由提升協作力來成長，但它同時也被 IT 內部專案工作量的要素抑制。要想讓 Ansible 組態能力成長，我們應該要降低加班時數、降低手動組態次數和減少工作完成量。
後語
感謝授予這些技藝給凍仁前輩們，此次主題分享，對凍仁而言是個極大的挑戰！經過這次上台分享的刻意練習，自己對系統思考的掌握度也有所提升。
從四種工作類型到自己的 DevOps 實踐，最後成了一個系統。這得耗費不少的時間、心力和腦力才有辦法達成。來日若有機會，再推出 3.0 版，述說自己的 Agile 實踐心得，不過那應該會是明年年底之後的事了。
在此跟各位讀者打個預防針，以上的兵棋推演，是凍仁自己的思維模型，還有改善空間。若有哪邊寫不好的地方，還請留言告知。
最後，預祝大家 2019 年新年快樂！
系統思考學徒
凍仁翔
Mon Dec 31 03:45:10 CST 2018
站內連結：
★ 從一個人的 DevOps，到一個 DevOps 的團隊
★ 「系統思考的四堂課」與「萬人敵」
相關連結：
★ 台中敏捷之旅 2019 (Agile Tour Taichung 2019) | KKTIX
★ 系統工程師的 DevOps 實踐之道 (3/e)| Speaker Deck
★ 系統工程師的 DevOps 實踐之道 (3/e) | SlideShare
★ 高雄敏捷之旅 2018 (Agile Tour Kaohsiung 2018) | KKTIX
★ 系統工程師的 DevOps 實踐之道 (2/e) | Speaker Deck
★ 系統工程師的 DevOps 實踐之道 (2/e) | SlideShare
★ 系統工程師的 DevOps 實踐之道 (2/e) | HackMD
★ 新竹敏捷之旅 2018 (Agiletour Hsinchu 2018) | KKTIX
★ 系統工程師的 DevOps 實踐之道 (1/e) | Speaker Deck
★ 系統工程師的 DevOps 實踐之道 (1/e) | SlideShare
延伸閱讀：
★ System Thinking 工作坊參加心得筆記 | Kodofish
★ Agile Meetup 新竹 - 系統思考工作坊 心得 | Ykhorizon
★ 系統思考 - 實戰工作坊心得分享 | Lin Chi
★ 系統思考的四堂課 | 軟體架構・絮語
資料來源：
★ 《第五項修練：學習型組織的藝術與實務》
詳細閱讀，真的是很棒的經驗分享！
回覆刪除謝謝支持！😇 讓我們一起 DevOps 吧！！！🚀
刪除讚!
回覆刪除謝謝支持！🤟
刪除實學後實做，很棒的分享
回覆刪除在「學習金字塔」一說裡，要可把一項技藝「教授他人」、「立即運用」，才算真正學會。這也是為什麼凍仁這次的上台分享，會挑戰用「系統思考」來述說的主要原因。
刪除▌ 學習金字塔 | IT 人一定要知道的寫作技巧
▌ - https://speakerdeck.com/chusiang/writing-skills-for-information-technology?slide=84
那段準備投影片的日子，可是每天都燒腦燒到不行呢！
此 Blog 文串連 Google Photo 的圖片曾失效一陣子，已在 2019/04/03 手動修復。
回覆刪除而 KaLUG 星球那邊的文章，也已請 Shawn Wang 學長協助更新。:D
▌ https://kalug.linux.org.tw/planet/chusiang/20181231_devops-practice-of-system-engineer.html/
附上 Agile Tour Taichung 2019 分享的第 3 版投影片連結。
回覆刪除→ https://speakerdeck.com/chusiang/my-devops-tour-2-dot-3
受益良多，只能挑個小小的錯字：
回覆刪除s/身為一位 Linxu 系統管理員/身為一位 Linux 系統管理員/
感謝偵錯，已修正完畢。😇
刪除