《神雕俠侶》當中,楊過遭遇斷臂之禍,卻因禍得福,巧遇神雕,進而造訪獨孤求敗的劍塚:

劍魔獨孤求敗既無敵於天下,乃埋劍於斯。嗚呼!群雄束手,長劍空利,不亦悲夫!

劍塚埋了三柄長劍:

  • 無名利劍:「凌厲剛猛,無堅不摧,弱冠前以之與河朔群雄爭鋒。」
  • 紫薇軟劍(缺):「三十歲前所用,誤傷義士,不祥,乃棄之深谷。」
  • 玄鐵重劍:「重劍無鋒,大巧不工,四十歲前恃之橫行天下。」
  • 腐朽木劍:「四十歲後,不滯於物,草木竹石均可為劍。自此精修,漸進於無劍勝有劍之境。」

讀了這一段「前輩神技,令人難以想像」的描述,我一直有種感嘆:

--- Quote: 2016-08-22 Tweet


所以,繼七月份〈從限制理論看 DevOps〉演講之後,再接再厲,嘗試將 TOC 思維運用到【導入 Docker:障礙與對策】這樣的主題身上。箇中的心路歷程,在〈請循其本〉及〈與導入 Docker 有關的 UDE〉兩篇文章都有著墨。

Docker 這主題,涉及層面和之前的 DevOps 演講不太一樣。為此,我又反覆研讀幾份 TOC 文獻:

讀了一輪,演講內容準備好了,對 TOC 的認識又更深化了。

所以,好的思維模式,真的要多加練習,越磨越利呀。

這樣,才會成為屬於自己的玄鐵重劍。



其中,高德拉特在仍然不足夠前言〈發揮資訊科技的真正威力〉提出的六則大哉問,很值得在評估任何資訊科技時,好好自問。

拿來套用在 Docker 身上,我們可以這樣思考:

一、電腦系統科技的真正威力是什麼?

直接引述高德拉特給的通用答案:「減輕面對的某項限制」。

這也呼應到「TOC 聚焦五步驟」當中的第四步驟:鬆綁 (elevate)。


二、科技到底減輕了什麼限制?

從 Docker slogan "build, ship, run any app, anywhere" 來看,Docker,甚至更廣義的 container 技術,減輕的限制,就是 app 的 dependency 及 isolation。這項限制一旦減輕了,其他種種 DevOps 環節就一個個經歷骨牌效應。

這就是 Docker 令人敬畏的地方。

不過,在還沒有 Docker 存在的時代,我們是怎麼與「app 的 dependency 及 isolation」這項(舊)限制和平共處呢?或者更直接反問:我們舊的 DevOps 規則、流程、隱含假設,有哪些是因應舊情境、舊限制而生的(或者是⋯⋯早已麻木了)?那些舊的規則,又有多少是值得翻出來重新檢討的?

「當一個人被一個問題困擾很長一段時間,即他的任何嘗試都無法解決該問題時,那麼,一個保護機制就啟動了。經一段時間後,這個問題在他眼中再也不是問題了,只是一項他必須接受的生活事實而已。」《醒悟》

也引述高德拉特給的通用答案:「沿用那些幫助我們適應(舊)限制的(舊)規則,
後果就跟限制仍然存在無異。」


三、限制寄生在什麼規則中?

直接引述高德拉特給的通用答案:「局部效益規則」。

在還沒有 Docker 存在的時代,我們是怎麼與「app 的 dependency 及 isolation」這項(舊)限制和平共處呢?就是 Dev 與 Ops 各自為政的穀倉效應。


四、我們現在應該採用什麼規則?

既然 Docker 鬆綁了「app 的 dependency 及 isolation」這項舊限制,鬆綁了「局部效益規則」這項舊規則,那麼,我們就該認真思考「局部效益規則」的反面:「整體效益規則」,將 Dev 與 Ops 一條鞭對待。


五、鑑於規則的改變,科技也要作出什麼改變?



六、怎樣主導這場變革?

直接引述高德拉特給的通用答案:「要成功,就必須解決他們最大的制約因素。」

那麼,什麼是導入 Docker 的「最大制約因素」呢?

以我的觀點,就是我演講中點出的核心衝突:「為什麼別人認為
有高度需求,而我們卻不這麼認為?」

面對核心衝突,勇敢追求雙贏解,才是主導這場變革的正面態度。

共勉!



這次在 Container Summit 2016 發表的投影片:


演講錄影: