如果你在路上遇見了DevOps，干掉它！
本次的分享不談技術(shù)只談?wù)勏敕?。我從?IT 行業(yè) 41 年了，這 40 年的經(jīng)驗并不是說我就是權(quán)威、專家，但在洞察這方面做得更好些。
1980 年代，當時 IT 除了被發(fā)展出來，很多的是一些項目的管理，實際上我們也做了很多的項目，有很強的能力掌握項目。
1990 年的時候我們開發(fā)了很多的系統(tǒng)，如開發(fā)一個專業(yè)的管理系統(tǒng)。2000 年的時候，就有敏捷這一概念，從 2000 年開始我們就說 DevOps。
可以看到這上面有四大轉(zhuǎn)變，從傳統(tǒng)轉(zhuǎn)變到現(xiàn)代，憑借 40 年的經(jīng)驗，我是非常認真的在思量，DevOps 對于我之前所看到的所有的變革，是一個顛覆性的變革，而且前景非常好。
大家都是 DevOps，實際上我想關(guān)注 IT 這個事情到底發(fā)生了什么？我希望我的洞察和一些看法能夠激發(fā)大家相關(guān)的靈感。比如說上圖你可以看到是只鳥，你還可以從另外一個角度來看。
下面的內(nèi)容我會給到大家一些不同的視角去看干掉 DevOps 的要點：
DevOps 沒啥用，除非你能夠在一個全局性的視野下，將其與業(yè)務(wù)建立創(chuàng)造性的合作。
這個要點是非常重要的，我再強調(diào)一下，就是和業(yè)務(wù)共同創(chuàng)造價值的情況下才有用。這是非常重要的觀點，這樣的話 DevOps 才會有用。
下面將以四塊內(nèi)容來闡述：
- 探討 DevOps。
- 向業(yè)務(wù)執(zhí)行層 ”兜售” DevOps。
- 發(fā)現(xiàn)最薄弱的環(huán)節(jié)。
- 采用正確的態(tài)度。
探討 DevOps
盲人摸象的故事大家都知道的，對于 DevOps 來講，他們所摸到的都是一樣就是 DevOps。
如果大家在談?wù)?DevOps 的時候需要謹慎，他們說的真的是一個 DevOps，還是只是一個市場行為？
我們要真正知道 DevOps 的價值，如果說不是盲人而是六個業(yè)務(wù)盲人和 IT 來摸這個大象時，他們所關(guān)注的是什么呢？
是投資回報率（ROI）。我的想法是希望將我們的 DevOps 和 ROI 能夠緊密地結(jié)合，這其實也是一個目標。
我們來用一個簡單的框架來闡述，比如說 IT 行業(yè)有行業(yè)的指引，做得更快、更便宜，然后提供更好的 IT 服務(wù)，這是 IT 人員所做的事情，他們通過這個方式來提供 IT 的服務(wù)。
同時我們給商人提供更好的信息系統(tǒng)信息服務(wù)，幫助他們達成商業(yè)的目標，這個模型是比較簡單的。商人認為是一種投資，所以他們想要投資的回報。
讓我們把它分解一下，如果我們只看 IT 的話，它包括開發(fā)和運維，并且是非常高的精度。
如果說我們看一下商業(yè)，就是需求和使用，這是一個非常高的簡單的系統(tǒng)，能夠具體化 IT 的要求，同時它能夠使用系統(tǒng)，這一點是非常高層的模式，還需要繼續(xù)更詳細的探討。
接下來看一下價值鏈，看從一個商業(yè)的角度或者是一個信息的角度，因為商業(yè)需要業(yè)務(wù)、信息、應(yīng)用和基礎(chǔ)設(shè)施。在最開始的時候做投資的話，需要在信息科技上和解決問題上做投資。
為了做投資他們需要具體化需求，知道要去做什么，要去研發(fā)體系等，開發(fā)需要基礎(chǔ)，設(shè)施需要平臺，需要工具來做項目。運維也需要平臺也需要基礎(chǔ)設(shè)施，也需要工具來提供更好的信息系統(tǒng)，也包括應(yīng)用。
如果我們想一想敏捷的話，在價值流中敏捷在哪兒呢？它其實是在信息應(yīng)用和商業(yè)之間搭起了一座橋梁，這些是可以實現(xiàn)的目標。
關(guān)鍵詞是潛在的可實現(xiàn)的，它不是已經(jīng)部署過的實現(xiàn)的而是潛在的，需要你去部署。
現(xiàn)在是在生產(chǎn)當中的，你看一下信息體系，它其實就是運作，這一點非常好，我們的信息體系也是在運作當中，那壞消息是我們不能產(chǎn)生任何價值。
因為一直到現(xiàn)在為止，沒有人應(yīng)用這些信息體系，沒有人創(chuàng)造價值，這個領(lǐng)域是我們稱之為 IT 信息服務(wù)流程。
使用者使用這樣一個系統(tǒng)，希望生成價值。他們希望價值和商業(yè)的價值是一樣的，所以我們有一個圈，就是價值圈。
非常感興趣的一點是使用者如何使用你的信息體系，你認為他們能夠有效地使用信息體系嗎？
經(jīng)常我們的使用者并不是有效地使用信息體系，所以不會產(chǎn)生足夠的價值。如果我們能夠想到限制理論，最薄弱的點在哪里呢？你就可以去想想，投資是不是夠好？是不是正確地把握了需求？能不能正常使用？
我們遇到了一個非常有趣的觀點，那就是 DevOps 的定位。一般提到 DevOps 都不太知道所指的是什么？它怎么把研發(fā)和運維聯(lián)系在一起呢？
我們應(yīng)該是 DevOps If，那就是基礎(chǔ)設(shè)施的運維或者是業(yè)務(wù)的運維，我認為這是狹義的定義，只是聚焦在需求、開發(fā)、基礎(chǔ)設(shè)施、持續(xù)交付、持續(xù)部署。
但是 DevOps 可以應(yīng)用在更寬廣的概念上，去包括商業(yè)與 DevOps 的范圍。
因為 DevOps 的原則是能夠讓你更好更多創(chuàng)造更多合作，這是 DevOps 更寬廣意義上的概念。
當大家談到 DevOps 的時候，他們到底談的狹義的 DevOps，還是廣義的 DevOps 都是正確的。
我推薦兩本書，《鳳凰項目》和《Devops Handbook》，《鳳凰項目》已經(jīng)翻譯成中文了，《Devops Handbook》會在今年年底翻譯成中文。
《Devops Handbook》這本書與鳳凰項目一脈相承，他們有一些原則有一些技術(shù)實踐，能夠幫助你快速部署工作流，進行測試，進行部署。
同時還能幫助你實現(xiàn)***的可靠性、可用性和安全，有敏捷、信息系統(tǒng)的穩(wěn)定性，這個其實就是 DevOps 的全部內(nèi)容，不僅僅是開發(fā)還有運維。
《Devops Handbook》這三位作者 John Willis、Patrick Debois、Gene Kim。
我認為三位作者能夠?qū)懗觥禗evops Handbook》，是能夠讓你非常信任他們，因為他們知道自己在寫什么，讓你言之有悟的。下面列舉一些：
DevOps Handbook 原則和技術(shù)實踐：
- DevOps 的 3 種途徑。
- 快速工作流。
- 快速、頻繁、良好的反饋。
- 持續(xù)學(xué)習(xí)和實驗。
- 將信息安全、變更管理和合規(guī)集成到日常工作中。
DevOps Handbook 技術(shù)實踐：
- 開發(fā)。
- 運維。
- 基礎(chǔ)設(shè)施。
- 平臺
- 管道(pipeline)
- 工具
DevOps Handbook 原則：
- 工作可視化，進行中的工作(WIP)， 批量大小，轉(zhuǎn)移(handoffs)，限制，困難，浪費。
- 問題，知識，質(zhì)量，下游優(yōu)化。
- 關(guān)于改進、擴散、彈性、安全、學(xué)習(xí)、文化的制度化。
從而我們可以進行持續(xù)的程序的開發(fā)、程序的運維，然后持續(xù)的交付和持續(xù)的集成等。
這個是用于持續(xù)集成、持續(xù)交付部署當中的一些實踐。
這個是廣義的應(yīng)用，可以看到這當中所涉及到的業(yè)務(wù)是很多的。在 IT 這個部門當中你可以采用更多的價值并且提高你的速度、可靠性，還有個人的可靠度和提高業(yè)務(wù)的功能性。
DevOps 是有經(jīng)濟效益約束理論，還有敏捷的延伸。當時是有這些原則和技術(shù)實踐，這上面有三種途徑，同樣的也是一個耦合的架構(gòu)。
它可以利用在小的團隊當中，也可以用于狹義和廣義上面。同樣的有自動化、精益、衡量和分享。還有文化，這也是非常重要的一部分。
向業(yè)務(wù)執(zhí)行層“兜售”DevOps
這是典型的高層的對話。怎么說服 CEO？你必須要說商業(yè)上的話，必須說 MBA 聽得懂的話。
接下來說說商業(yè)上可用的話，我們要了解 DevOps 的收益，一個是 DevOps 的報告，一個是 Dora 的有關(guān)于轉(zhuǎn)型的報告。
我還是強調(diào)一下，就是快速交付更可靠、更便宜的信息服務(wù)，這是關(guān)鍵點。
首先我們看看 IT 系統(tǒng)，如何利用 DevOps 來提升這些相關(guān)點。來看看這當中關(guān)鍵點，如有用的功能性。
從 DevOps 的特點來說，比如說好用點是什么？好用性、可靠性和安全性，這是我們的業(yè)務(wù)目標。
也可以從速度上來看，排個優(yōu)先級，哪個工作先做，哪個先產(chǎn)生價值，這是我們需要考量的問題。***是成本，包括開發(fā)和運維的成本。
與商業(yè)相比我們在 IT 上面應(yīng)該花多少？我們需要縮減成本，縮減成本的途徑呢？
這只是一個內(nèi)部的 IT 行為，不能提供信息的功能性，但是可以提高支付保障性以及降低成本。降低 IT 成本在一定程度上可以降低企業(yè)的成本。
如果我們能夠繼續(xù)提高快速交付和新功能研發(fā)的話我們就能快速進入市場，將產(chǎn)品和服務(wù)打入市場，通過內(nèi)部行為來加速企業(yè)內(nèi)部的變化，來降低運營的成本。這就是 MBA 語言，CEO 所說的話。
如果想要提到保障性使用的效率的話，提高了穩(wěn)定性，信息系統(tǒng)的穩(wěn)定性就提高了，從公司的層面來看能夠減少生意的干擾，無形中減少了生意的開支。
如果顧客也參與其中的話，我們也會提高客戶的滿意度?？蛻舻臐M意度對 CEO 來說是非常重要的，這也是 MBA 的語言。
如果我們能夠把企業(yè)放一起的話，其實就能提高信息系統(tǒng)的功能性，取決于不同的功能你可以去建立更多提高銷量的可能，保持高的價格。
通過在客戶忠誠度上進行投資，可以保持高價，提高客戶的滿意度。同時也給你的產(chǎn)品和服務(wù)提供更好的反饋，減少運營的成本，降低風(fēng)險。
現(xiàn)在我們學(xué)了一點 MBA 的語言，那為什么要在 DevOps 上投資，而不是投資在別的領(lǐng)域呢？
以 MBA 的行話來說，我們可以避免崩潰，更好地面向市場，更少的業(yè)務(wù)中斷。
向業(yè)務(wù)高管“兜售”DevOps 有用并且好用、快速交付，別跟業(yè)務(wù)高管提 IT 收益、成本、風(fēng)險。
發(fā)現(xiàn)最薄弱的環(huán)節(jié)
- 在開始 DevOps 時，文化阻力將導(dǎo)致重大失敗。 —- Gartner
- 組織變革問題遠比新技術(shù)投資更具挑戰(zhàn)性。—- CIO.com
邊”做”邊”學(xué)”邊”改”，在業(yè)務(wù)沙盤游戲中團隊：
- 通過”工作可視化”減少混亂。
- 通過”識別和減少限制”提升工作流。
- 通過”小的迭代和快速反饋”避免宕機和返工。
- 通過”持續(xù)實踐和學(xué)習(xí)”改進。
最薄弱環(huán)節(jié)，到底是商業(yè)上還是 IT 還是之間的協(xié)作？
如果是在 IT 上，是交互的速度不夠嗎？還是有一些有疑惑的地方，大家不能好好合作？
DevOps 能夠幫助你們解決這些問題，但是改變并非一時，尤其是文化的改變。
我們?nèi)绾巫瞿軌驇椭约焊淖儭⒏镄鹿ぷ鞣绞侥?？鳳凰項目有一個游戲可以借鑒下，可以用商業(yè)模擬的方法，來幫助大家優(yōu)化工作方式。
如果你的業(yè)務(wù)部是最薄弱的環(huán)節(jié)呢？如果做投資？如何細化需求？如何保護信息？
我們就需要找到他們進行解決，我們有一個 BISL 模型能夠幫助商人提高和改進自己的工作方式。
如果最薄弱的環(huán)節(jié)是到合作呢？合作是很簡單的以及人與人合作的流程。因為人不是機器，業(yè)務(wù)與 IT 需要得到協(xié)作的建議，這樣雙方才能獲得好的合作。
發(fā)現(xiàn)你最薄弱的環(huán)節(jié)，在最薄弱的環(huán)節(jié)上工作，組織文化很重要，變革不容易，邊做邊學(xué)邊改。
采用正確的態(tài)度
當我說干掉 DevOps 的時候，有很多人都會把爛西紅柿扔向我，他會非常生氣說我不喜歡 DevOps，要干掉 DevOps。
當我說干掉 DevOps，我想的是禪語、佛陀。一個年輕的僧侶一直想要找到佛陀，但是他認為他找到佛的時候，大師卻說你其實沒有找到，殺死佛繼續(xù)找。我認為這與 DevOps 的觀念是一樣的。
如果你在路上遇見了 DevOps，干掉它。因為你不會找到真正的 DevOps，你需要繼續(xù)實習(xí)、繼續(xù)實踐，這才是 DevOps 的真意。
Mark Smalley，ASL BiSL 基金會大使。當下的興趣愛好： 數(shù)字化企業(yè)、IT 運作模式、IT 價值、IT 與業(yè)務(wù)關(guān)系、共同創(chuàng)造價值、多學(xué)科協(xié)作、處理復(fù)雜問題。
