2018-12-31

系統工程師的 DevOps 實踐之道

系統思考 (Systems Thinking),一是門需要刻意練習的技藝!趁著在新竹敏捷之旅 (Agile Tour Hsinchu 2018)高雄敏捷之旅 (Agile Tour Kaohsiung 2018) 上台分享的機會,凍仁試著使用因果循環圖 (Causal Loop Diagram, CLD),來述說兩年來的 DevOps 實踐心得。

本次主題,可說是一年前的「從一個人的 DevOps,到一個 DevOps 的團隊」分享沿續。那時是介紹凍仁從大學以來習得的 DevOps Tools 技藝,以及現實中的 DevOps 團隊。


▲ 於 Agile Tour Kaohsiung 2018 分享的「系統工程師的 DevOps 實踐之道 (2/e)」投影片。

前言


喜愛 Linux 的凍仁,大學畢業後,成了一位系統工程師 (System Engineer)。 P.6

以前的凍仁常常每天都在打火,救火工作 (Recovery work) 多到讓人懷疑人生。 P.7

三年前的凍仁,告訴自己不該再這麼繼續下去,於是踏上了 DevOps 學習之旅。 P.8

▲ 若您還未看過《鳳凰專案》一書,可以先閱讀凍仁先前的介紹文

DevOps 是什麼?


談到 DevOps,凍仁喜歡先用狹義和廣義的 DevOps,來說明什麼是 DevOps?

1. 狹義的 DevOps:把開發 (Dev)、維運 (Ops) 和基礎建設 (Infra) 的工作流程打通並優化。 P.10

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 裡的正相關 (Positive correlation) 與負相關 (Negative correlation)。
▲ 為提升簡報易讀性,凍仁改用「實線」和「虛線」表示正相關負相關

以目前的 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。雖會多消耗一人的工時,但兩個人一起操作系統,可有效降低人為失誤,真的很划算!

▌ 身為一位 Linxu 系統管理員,精神不好時,還請千萬不要亂下指令,尤其是用到 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 的團隊
「系統思考的四堂課」與「萬人敵」

相關連結:
新竹敏捷之旅 2018 (Agiletour Hsinchu 2018) | KKTIX
系統工程師的 DevOps 實踐之道 (1/e) | Speaker Deck
系統工程師的 DevOps 實踐之道 (1/e) | SlideShare
高雄敏捷之旅 2018 (Agile Tour Kaohsiung 2018) | KKTIX
系統工程師的 DevOps 實踐之道 (2/e) | Speaker Deck
系統工程師的 DevOps 實踐之道 (2/e) | SlideShare
系統工程師的 DevOps 實踐之道 (2/e) | HackMD

延伸閱讀:
System Thinking 工作坊參加心得筆記 | Kodofish
Agile Meetup 新竹 - 系統思考工作坊 心得 | Ykhorizon
系統思考 - 實戰工作坊心得分享 | Lin Chi
系統思考的四堂課 | 軟體架構・絮語


資料來源:
《第五項修練:學習型組織的藝術與實務》

6 則留言 :

  1. 詳細閱讀,真的是很棒的經驗分享!

    回覆刪除
    回覆
    1. 謝謝支持!😇 讓我們一起 DevOps 吧!!!🚀

      刪除
  2. 實學後實做,很棒的分享

    回覆刪除
    回覆
    1. 在「學習金字塔」一說裡,要可把一項技藝「教授他人」、「立即運用」,才算真正學會。這也是為什麼凍仁這次的上台分享,會挑戰用「系統思考」來述說的主要原因。

      ▌ 學習金字塔 | IT 人一定要知道的寫作技巧
      ▌ - https://speakerdeck.com/chusiang/writing-skills-for-information-technology?slide=84

      那段準備投影片的日子,可是每天都燒腦燒到不行呢!

      刪除

喜歡這篇文章嗎?歡迎在底下留言讓凍仁知道。😉