限制理論 (Theory Of Constraints)在DevOps方面的應(yīng)用
一、定義
限制理論 (Theory Of Constraints),簡寫為TOC。任何系統(tǒng)至少存在著一個(gè)限制,否則它就可能有***的產(chǎn)出。因此要提高一個(gè)系統(tǒng)(任何企業(yè)或組織均可視為一個(gè)系統(tǒng))的產(chǎn)出,必須要打破系統(tǒng)的限制。任何系統(tǒng)可以想象成由一連串的環(huán)所構(gòu)成,環(huán)與環(huán)相扣,這個(gè)系統(tǒng)的強(qiáng)度就取決于其最弱的一環(huán),而不是其***的一環(huán)。相同的道理,我們也可以將我們的企業(yè)或機(jī)構(gòu)視為一條鏈條,每一個(gè)部門是這個(gè)鏈條其中的一環(huán)。如果我們想達(dá)成預(yù)期的目標(biāo),我們必須要從最弱的一環(huán);也就是從瓶頸(或限制)的一環(huán)下手,才可得到顯著的改善。換句話說,如果這個(gè)限制決定一個(gè)企業(yè)或組織達(dá)成目標(biāo)的速率,我們必須從克服限制著手,才可以更快速的步伐在短時(shí)間內(nèi)顯著地提升系統(tǒng)的產(chǎn)出。
二、簡介
限制理論(TOC)是美籍以色列人高德拉特(Eli Goldratt)博士從物理學(xué)領(lǐng)域引進(jìn)到管理學(xué)領(lǐng)域形成的,它是Theory Of Constraints的簡稱,最初它作為一個(gè)物理學(xué)原理使用,一個(gè)簡單的原理存在,它是指物理系統(tǒng)的最薄弱環(huán)節(jié)決定整個(gè)系統(tǒng)的產(chǎn)出或者效率,它在物理設(shè)計(jì)中經(jīng)常使用到。1984年,高德拉特博士出版了他的***本小說《目標(biāo)》,書中運(yùn)用約束的相關(guān)理論幫助一個(gè)工廠廠長在較短的時(shí)間內(nèi)實(shí)現(xiàn)了扭虧為盈,不僅很好的處理了企業(yè)的發(fā)展問題并且很好的解決了家庭中的矛盾。在高德拉特的不斷努力下,該書很快暢銷美國,并得到了相關(guān)管理專家的好評,從此,TOC開始非常流行。高德拉特博士在以后的實(shí)踐中,將該理論從生產(chǎn)領(lǐng)域逐漸擴(kuò)展到銷售領(lǐng)域,以及企業(yè)的其它管理領(lǐng)域。繼目標(biāo)以后,高德拉特又出版了《決不是靠運(yùn)氣》和《關(guān)鍵鏈》等書籍,將該理論形成了一個(gè)完整的體系,并發(fā)展成為一種思維模式。約束理論在美國應(yīng)用很廣,美國生產(chǎn)和庫存管理協(xié)會(huì)非常關(guān)注約束理論的發(fā)展,稱其為“約束管理”,并成立專門的約束理論研究小組。該小組認(rèn)為:TOC是管理理論和管理工具的結(jié)合,它把企業(yè)在實(shí)現(xiàn)目標(biāo)的過程中現(xiàn)存的或者潛伏的制約因素叫做“約束”,通過逐個(gè)識(shí)別約束和消除這些因素,使得企業(yè)的改進(jìn)策略和改進(jìn)方向更加明確化,從而幫助企業(yè)實(shí)現(xiàn)其目標(biāo)。
三、應(yīng)用在DevOps方面
DevOps的實(shí)施是面向復(fù)雜系統(tǒng)的,尋找瓶頸和限制約束的領(lǐng)域有下面四個(gè)。
上圖源于:http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
1. 每個(gè)領(lǐng)域的評價(jià)因素
對每個(gè)領(lǐng)域里面可能的瓶頸分層次的考察和剖析
2. 瓶頸的分析方法
以上是Dev到Ops的方向里,關(guān)于“交付到生產(chǎn)環(huán)境”領(lǐng)域的評測案例;里面分析的點(diǎn)是:使用相同的代碼來為應(yīng)用搭建開發(fā)、測試和生產(chǎn)環(huán)境。
- Tools Layer : Deploys/Day
- Process Layer : Number of Change Requests/Day
- People Layer : People Involved per deploy
評估以上場景的時(shí)候,需要找出能夠在TPP三個(gè)層面可以度量的數(shù)據(jù)。當(dāng)然可以加入DevOps流程中的其它相關(guān)指標(biāo)。
3. DevOps積分卡
從每個(gè)領(lǐng)域的若干評估點(diǎn)上,既可以看到整體的成熟度矩陣。這也是DevOps落地點(diǎn)選擇的一種選取方式。問題越大的領(lǐng)域,應(yīng)該是最應(yīng)該改善,***改善的方面,由于它能立刻看到效果;但是也要考慮到業(yè)務(wù)產(chǎn)出,也要考慮它的投入風(fēng)險(xiǎn);綜合看:應(yīng)該選取有對業(yè)務(wù)價(jià)值產(chǎn)出有明顯幫助,且風(fēng)險(xiǎn)合理的領(lǐng)域。
4. 內(nèi)外循環(huán)
- 內(nèi)循環(huán):Automate - Measure 這2個(gè)領(lǐng)域組成了DevOps優(yōu)化改進(jìn)的內(nèi)循環(huán),組織中的技術(shù)債務(wù)主要存在于這個(gè)循環(huán)中。
- 外循環(huán):Culture - Share 這2個(gè)領(lǐng)域組成了DevOps優(yōu)化改進(jìn)的外循環(huán),組織中的社交債務(wù)主要存在于這個(gè)循環(huán)中。
四、總結(jié)
DevOps是一種狀態(tài),任何組織的任何產(chǎn)品都是一個(gè)復(fù)雜系統(tǒng),任一時(shí)刻都至少存在一個(gè)約束。DevOps是讓我們始終處于持續(xù)識(shí)別瓶頸和優(yōu)化系統(tǒng)的狀態(tài)中。
【本文為51CTO專欄作者“劉征”的原創(chuàng)稿件,轉(zhuǎn)載請通過作者微信公眾號“DevOps教練”(MyDevOps)獲取授權(quán)】