（此文章內(nèi)容來自青藍學員：廣州錦高信息科技有限公司  陳兆康）

有幸受青藍老師的邀約，在此談談我學習研究DevOps的一些心得體會。

先說說學習DevOps的初衷吧，其實我接觸DevOps的時間其實并不長，去年年中公司開始確立DevOps為其中一個重點發(fā)展方向時我才開始研究DevOps（在此感謝公司對我的投入支持）。

從那時起開始閱讀一些關于DevOps的文獻著作，其中印象最深刻的要數(shù)Jez Humble寫的《Continuous Delivery》，此神書對作為程序員的我沖擊非常大，對照我們當下大多數(shù)慘不忍睹的IT實踐，我從DevOps的原則及方法論中得到的啟發(fā)甚多。

此后開始參加DevOps中國社區(qū)的線下Meetup，也拜見了社區(qū)中的一些老師，而在今年年初的一次廣州站Meetup中偶爾得到一本書——《DevOps實踐指南》，在書的最后了解到EXIN的DevOps認證體系，也是從那時起開始準備DOF、DOP的認證。雖然我是3月份才在青藍報名學習DevOps，但其實我的備考早已開始。

有時，我們追求一個目標并非只是為了獲取目標本身，更多的是這個過程中所產(chǎn)生的裨益，考試亦然。

在我看來，比起考試及格取得證書更重要的是備考過程的收獲。毫不夸張地說，理解、內(nèi)化DevOps中的思想原理并付諸實踐（而現(xiàn)階段我的實踐經(jīng)驗是比較薄弱的），不單只是對我們的工作方式，甚至對生活問題的處理，乃至個人的思維、心態(tài)的提升都有莫大益處。倘若只是為了應付考試而囫圇吞棗，那將會是莫大的浪費，價值不大的投入我寧可一開始就不做。

在這里講一段我經(jīng)歷過的一件事情，有一次我在線上購物時，收到快遞打開卻不是我下單的產(chǎn)品，當我與售后溝通出處理結(jié)果后，我就琢磨了下這起事故。“任何事故根本原因不在于人，而在于流程系統(tǒng)本身的缺陷”（引用自《DevOps實踐指南》），人因為粗心而導致事故只是一個結(jié)果。

我向客服了解了當時他們是如何管理發(fā)貨的，發(fā)現(xiàn)他們的發(fā)貨管理流程缺少“防呆”措施（工業(yè)設計術語，通過設計出某種限制約束，讓操作者不需要花費注意力或擁有相關經(jīng)驗知識即可無誤地完成操作，比如說特殊造型的插槽接口），便提出了我當時想到的優(yōu)化后的流程及對發(fā)貨管理系統(tǒng)的改進建議。

“底層原理都是相通的”，我越發(fā)認可這句老生常談。DevOps亦然。

圖一是我在頂尖投資家Ray Dalio的著作《原則》中摘錄的關于如何以看待機器的方式來發(fā)現(xiàn)、解決問題的圖解。

（圖1）

圖二是我在大學學習車輛工程專業(yè)時接觸到的質(zhì)量管理中常用的戴明環(huán)。

（圖2）

圖三就是DevOps著名的雙紐線。

（圖3）

盡管源于不同鄰域，細品之下便會發(fā)現(xiàn)這些循環(huán)都是萬變不離其宗的。而DevOps是一門博采眾長學問，就如人要樹立持續(xù)學習、終生學習的觀念一樣，自身仍在不斷發(fā)展。對業(yè)內(nèi)動態(tài)、發(fā)展趨勢保持關注的同時也別忘了挖掘其中不變的道理，誠如《阿里巴巴Java開發(fā)手冊》中所言，“世間眾多設計模式其實就是一種設計模式，即隔離變化點的模式”。

其實去年公司請來了一位DevOps方向的專家，雖然相處的時間不長，但我從他身上獲益不少。

他曾和我建議，搞DevOps最好先從理論入手，搞清楚我們要達到什么效果，以此作為指引方向再去學習使用具體的DevOps工具鏈（如圖三），此時我們就能更好地理解為什么要使用這些工具、如何用好這些工具（避免《DevOps精要：業(yè)務視角》中提到的貨物崇拜、形式主義，不能把手段當目的）。

事實上DevOps并不應該受制于具體的工具，今天熱門的工具，說不定明天就過時了。

從上DOP課程到考完試，大概花了一周多的時間就順利拿到DOP的證書，最后在此感謝青藍以及林偉丹老師的教導。