自從寫了〈DevOps 核心元素的考古溯源〉一文，我就很想找個機會，好好闡釋 DevOps 的重要源頭：Lean Thinking。這個願望，在五月初那次兩個小時的〈有了 Agile，為什麼還要有 DevOps？〉演講中實現了。

不過私底下，還有另一個更大的野心：我想從 TOC (Theory of Constraints)（常譯為限制理論或制約理論）的角度，好好審視或詮釋一下 DevOps。

原因之一，這陣子一直浸潤在 TOC 世界中，不知不覺就會拿 TOC 心智框架來檢視萬物。有文為證：

原因之二，DevOps 領域的經典 The Phoenix Project（中譯本《鳳凰專案》）大力推崇 TOC，小說情節中也藉由神秘人物 Erik 之口，直接大辣辣地引用 TOC 方法來解決種種 DevOps 問題——甚至 Erik 還叫主角 Bill 去好好研讀《目標》呢。我想，掌握 TOC，對於掌握 DevOps 應該很有幫助。 1

 

TOC，最為人所知的，就是在《目標》一書所闡釋的「聚焦五步驟」(five focusing steps)。許多人甚至以為聚焦五步驟就是 TOC 的全貌。

不過，在整個 TOC 的知識體系中，更大的寶藏，其實是 Thinking Processes（思維程序；思考方式）。這是高德拉特為了回答《目標》書末揭櫫的三個大哉問，逐漸發展出來的系統化方法：

  1. What to change (應該改變哪些事情)
  2. To What to change (要朝什麼方向改變)
  3. How to cause the change (要如何改變)

可惜的是，深刻掌握 Thinking Processes 並不太容易（尤其是沒有名師指導之下）。難怪 The Phoenix Project 如此評論：

In Dr. Goldratt’s following book, It’s Not Luck, he describes what he called the Thinking Processes, which is a fantastic (but somewhat inaccessible and often very slow) methodology of identifying core, chronic conflicts, capturing the current reality, describing the desired future reality, and various planning techniques to increase the likelihood of getting there successfully.

甚至就連高德拉特在《絕不是靠運氣》書中，也藉由主角羅哥之口，承認有此一困難：

你需要的是：對主題的直覺，及有毅力去執行這套思維方法中的細緻步驟。不是時間的問題，而是如何讓自己投入及執行的問題。

不過，欲速則不達，有時我們還是得 “slow down to speed up”。

尤其是面對深層的糾結。抄捷徑，總有一天要還的。

挑戰

我想拿 DevOps 做實驗，挑戰看看高德拉特的四項宣稱，在 DevOps 領域裡是否依然合用：

  • 我們不應該假設經理人疏忽或無能，應該假設他們陷入一個衝突中，以致於無法正確地經營公司。 《絕不是靠運氣》p.204

  • 人們的腦力沒有問題，錯就錯在人們對現實的認知；最大的障礙是，人們視現實為極端複雜，而實際上是簡單得出奇。對複雜性的崇拜，是完全錯誤的。 《抉擇》p.10

  • 任何情況的背後，其實只有一或兩個核心問題，造成其他不良效應。 《絕不是靠運氣》p.124

  • 我們要找出來、並且解決的是核心問題，不是引致一、兩個不良效應，而是引致所有不良效應的核心問題。 《絕不是靠運氣》p.220

赫然發現，超誇張的，光是用 CRT，就能初步推導出現在已被視為「DevOps 常識」的 CALMS 及 “The Three Ways"。而且，DevOps 的核心衝突，果然就出現在 CRT 的下方。

偉大的高德拉特博士是對的！

整個推導過程的確燒腦，橫跨了好幾天，也正如高德拉特在《絕不是靠運氣》所預告的「你需要的是：對主題的直覺，及有毅力去執行這套思維方法中的細緻步驟。不是時間的問題，而是如何讓自己投入及執行的問題。」

但值得。這次練習，讓我掌握了一項犀利的武器。

發表

整個推導過程，我曾在 DevOps Summit 2016 以〈從限制理論看 DevOps〉為題發表過一次，今晚於 DevOps Taiwan Meetup #2 再發表一次加長版。希望對於推廣 TOC 式的思考方式，以及解決一些 DevOps 難題，有一些幫助。

溫馨小提醒：我推導出來的結論，與你推導的結論，可能不盡相同；這是正常的。尤其這次為了聚焦在 DevOps 論述，CRT 還遺留一些沒有再繼續往下深究的因果關係（如：各自為政、無誘因、失敗代價高、曾失敗過、惰性），真要再往下深究，有很大比例會碰觸到《目標》、《絕不是靠運氣》、《關鍵鏈》一再點出的核心問題：局部成本觀，甚至還會碰觸到《抉擇》談到的「清晰思考四大障礙」。那又是另一個大哉問了⋯⋯

請把重點放在過程，體驗一下，用這一套「可以幫忙建構及溝通常識的思維方法」，藉以「激發、專注及審視你的直覺」是何滋味。

最後，謹以高德拉特《仍然不足夠》的某句話，彼此互勉：

如果你覺得它是「常識」，千萬別忽視它，相反的，要實行它。

 

 

上個月在 DevOps Summit 2016 發表的投影片：

從限制理論看 DevOps

今晚在 DevOps Taiwan Meetup #2 的錄影檔：

感謝主辦人陳正瑋精彩的現場記實，這段話，精準點出我想傳達的意旨：

這場分享個人覺得值得多次回味，對於沒有接觸過高德拉特及 TOC 的人來說，應該是一個很好的魚餌，能讓人稍微一窺這些理論工具並非只是空談，吸引你更深入的了解認識它，甚至學習運用它。

演講提到的幾則工商服務連結：

  1. 箇中原委，我在〈鳳凰項目・私房標題〉一文中有介紹過。 ↩︎