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