Devops是數字化轉型在IT領域的一個最佳實踐

現在IT的新概念越來越多，要掌握這些概念不容易，但如果從概念的發端開始研究，理解第一性原理，也許能更好的理解這個概念的本質，從而更好的與既有的知識體系進行融合貫通，這樣才能記得牢，用得好，學習之道大致如此吧。

在我剛開始接觸Devops的時候，也是不太能理解其本質，因為Devops的實踐大多發生在OLTP領域，而自己一直從事OLAP的工作，當公司很多人開始談SCRUM、談CI/CD的時候，自己也是一臉懵逼，覺得跟自己的資料工作隔著十萬八千里。

現在自己開始從事數字化轉型等相關工作，需要能夠充分利用雲的優勢來助力企業應用和業務發展，這就是雲原生，而云原生配套的敏捷開發模式，就是Devops。

然後我去刨根問底了DevOps，才發現DevOps與自己從事的資料治理、數字化轉型都在解決同樣的問題，只是領域不一樣而已，但底層邏輯是相同的。

談到DevOps，就必須從敏捷和精益開發說起，因為DevOps借鑑了其中的方法和理念，並發展和完善了它們的實踐體系。

1、敏捷軟體開發

敏捷概念在2001年出現，一方面源於傳統方法變得臃腫笨重，另一方面則是進入網際網路時代後，軟體業對響應變化和創新的要求迅速升級，行業需求是敏捷的最好助推劑。

敏捷宣言釋出後，敏捷成為了一場運動，其中Scrum和極限程式設計在實踐上最為成功，影響最大。它們都是迭代和增量的軟體開發框架，區別是Scrum只包括管理實踐，而極限程式設計則同時涵蓋工程和管理實踐。

但是，早期的敏捷專注的還是研發交付階段，似乎跟部署和運維談不上關係。

2、精益產品開發

精益思想最早源自生產製造領域，根源於豐田在產品製造中管理和工程實踐。精益思想將精益定義為：有效組織人類活動的一個新的思維方法，目標是消除浪費，以更多地交付有用的價值，包括有5個原則：

1、定義價值：站在使用者的視角定義什麼是價值，並把它描述為具體產品或服務;

2、識別價值流：識別和對映創造價值的流程步驟，消除不增加使用者價值的步驟和活動;

3、讓價值持續流動：讓使用者價值在流程步驟中流動起來，是它們持續、順暢地流向終端使用者;

4、使用者價值拉動：由使用者價值拉動流動，避免不帶來使用者價值的浪費;

5、精益求精：不斷重複1到4步，追求完美的價值和價值流動，消除過程中所有浪費。

在這個抽象層次上，精益思想超越了其誕生的製造業，深刻影響了各個行業，這其中也包含產品開發，事實上，主流的敏捷開發方法都直接受到了精益思想的影響，遵循精益的基本原則。

與此同時，精益產品開發作為獨立的實踐體系快速發展，聚焦兩個方面的目標：價值交付過程和價值本身。

第一：關注價值交付過程，比較有代表性的是“精益看板方法”，從關注資源的使用效率，轉變為關注價值的流動效率，從區域性最佳化轉向端到端全域性最佳化。

第二：關注價值本身，比較代表性的是”精益創業“，把價值的探索和發現融入產品交付過程，提出了”開發-測試-學習“迴圈，第一步即最小可行產品;第二步基於最小可行產品收集反饋並獲得測量資料;第三步用資料驗證假設並加以調整，持續探索商業模式和產品功能設計。

3、Devops的誕生

敏捷和精益社群都還只是關注開發側的實踐和行為，運維並沒有成為他們關注的重點，但是從價值的角度看，開發和運維才構成相對完整的IT價值鏈，當然更完整的還包括業務。

在傳統IT組織下，開發團隊和運維團隊之間的訴求不同，開發團隊(尤其是敏捷團隊)追求變化，運維團隊追求穩定，雙方存在利益衝突，部門牆由此建立，這不利於IT價值的最大化。為了彌補開發和運維的鴻溝，需要在文化、工具和實踐方面的變革，DevOps正式登上舞臺，DevOps的理念開始流行，其相關工具和實踐也快速發展，期間以容器化和自動編排排程為代表的雲原生技術出現也極大加速這一程式。

Kim等人總結了Devops實施的三步工作法：

流動原則：聚焦 IT 系統的整體價值流，全域性最佳化，保證價值從左(上游)到右(下游)的快速流動;

反饋原則：建立從左到右的反饋迴圈，並縮短反饋週期和放大反饋效果。這樣，就可以更快的響應和理解內外部客戶，並即時獲取改進所需的知識;

持續的實驗和學習原則：建立承擔風險、持續實驗並從錯誤中學習的文化，在不斷的嘗試中精進能力，並提高系統的韌性。

Kim等人認為，這三步工作法是其他一切DevOps流程、實踐的價值和哲學根基，稍作研究，就能夠覺察，DevOps三步工作法是精益原則的翻版。

我讀完這一章節的時候，才恍然大悟，原來挺IT的DevOps起於這麼樸實的思想，這個思想大家都在用，因為它是非常底層的東西，即流程的高效運營。

而數字化轉型的核心是什麼，可以看看華為數字化轉型的這篇文章《華為董事陶景文：任何不涉及流程重構的數字化轉型，都是在裝樣子!》，講的就是流程和價值，核心觀點如下：

1、任何不涉及流程重構的數字化轉型，都是在裝樣子，這句話就是在說，數字化轉型一定先不是以技術為核心的，更主要是生產關係的調整，這個跟Devops的第一條，精益思想的第二條，第三條原則相符。

2、數字化轉型一定是業務戰略驅動的，一定是先折騰業務，業務站位越高，可能的效果就越大，不要為了轉型而轉型，這個跟Devops的第一條，精益思想的第一條原則相符。

3、資料要實時反饋，不光是在事後的統計報告發揮價值，而且可以在預測、分析、過程的干預和事後的回溯，全過程更加充分的發揮價值，這個跟Devops的第二條，第三條，精益思想的第二，第五條原則相符。

企業為實現價值創造，從輸入客戶要求開始到交付產品及服務給客戶獲得客戶滿意並實現企業自身價值的E2E(端對端)業務過程就是業務流。業務流天然存在，適配業務流的流程會帶來價值提升，是優秀作業實踐的總結和固化，推廣流程的目的是讓不同團隊執行流程時獲得成功的可複製性。

我們數字化的有很多階段，從線下到線上，從線上到線上，再從線上到智慧，所有這些都是圍繞流程開展的，我們最終的目的就是基於資料驅動讓流程全域性最優，從而創造更高價值。

DevOps只涉及IT條線的一個流程重構，而數字化轉型針對的是所有條線跟業務價值創造相關的業務流的重構，這些業務流的重構需要有文化、工具方面的支援，正如DevOps需要的那樣，可以這麼說，Devops是數字化轉型在一個領域的最佳實踐。

我現在在做的資料治理，其中最核心的一個工作就是流程重構，主要圍繞資料從產生、匯聚、處理、開放和消費這一系列流動的最佳化和重構來推動資料要素高質量的流轉。

理解了這三者在底層相通的邏輯關係，就可以產生1+1>2的效果，比如我知道數字化轉型需要經歷線下、線上、線上、智慧等四個階段，就可以將這種演進策略複製到DevOps領域，而如果直接看DevOps的各種專業書籍，會被各種“術”的操作晃得看不清楚方向;又比如DevOps為了做好協同，讓運維提前介入軟體設計評審，那我在資料治理的時候也可以如法炮製，將資料字典的編制要求前置到系統立項和設計階段。

希望於你有所啟示。