DevOps與傳統的融合落地實踐

內容來源：2017年5月6日，王津銀在“DevOps&SRE 超越傳統運維之道”進行《DevOps與傳統的融合落地實踐》演講分享。IT大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。

閱讀字數：2786 | 7分鐘閱讀

摘要

DevOps的整體框架首先是一連串工程實踐的組合，其次它關注的是整個業務和生命週期的管理。另外它還是以經營思想作為基礎，強調自動化拉動式的管理。

ITIL面向整個管理過程，規範優先，效率偏低，成本偏高。DevOps則是面向IT運營過程，是一個執行能力的自動化。

ITIL是以離線任務的管理為主要特徵，但DevOps今天已侵入到線上服務。

根據我們的實踐，在傳統行業互動過程中，我們的產品跟ITIL產品做對接時得出了三種模式。

• 第一種模式是線上服務開通流程。

• 第二種是重大變更流程。

• 第三種是敏捷釋出流程。

第一種是瀑布流的模式。然後就是敏捷研發的模式。隨著新的業務形態出現，就要強調端到端能力的整合。這就是今天要講的DevOps的軟體研發模式。

隨著研發模式的變化，各個角色在裡面所承擔的工作量配比也在發生變化，研發越來越重要。

強調五點理念：

1、通過持續的服務交付價值鏈打破孤島。

2、整合開發和運維的能力，成為一個協作的團隊。

3、端到端持續交付流程的變革。

4、對新的應用和服務，加快且縮短實現價值的時間。

5、不影響安全性、相容性和效能。

我把DevOps整個體系分成了六個維度加一個文化。六個維度包含了組織、過程架構、工具和基礎設施以及度量。

組織：首先必須打破組織之間的隔閡，其次DevOps組織要面向產品而非專案的協作文化。

過程：輕量級流程和自動化工具的完美結合，確保企業的高度敏捷性；自動化為先，而後再流程。

架構：架構又分成應用架構、基礎架構和資料架構。應用架構和基礎架構這兩點是比較明確的。應用架構講的是微服務架構，基礎架構是講標準化基礎設施。

工具：把質量成本和效率這幾者維度同時兼顧，具備可落地化。

基礎設施：虛擬化到容器化的平臺。

度量：度量體系能不斷驅動能力優化。

在縱向的維度上，把能力評估分為五個等級，這個五個等級參考CMI。

Quota定義了namespace中能利用的最大資源，而BatchJobController算的值則在中間來回浮動。

基於某個角色和某個場景去進行從小做起。

基於某個系統或者某個功能域來實施匯入。

切忌貪大求全。

因為要縮小範圍，CMDB在下一個版本的名字將改成IT資源管理平臺。縮小範圍後，只管理基礎設施和應用的資源。基礎設施的資源屬於資產狀況。當資產狀況管理起來之後，再從應用的視角看到底用了哪些資源，把這兩層維度強關聯起來，再在應用上層構建應用的各種管理場景。由它來進行進一步驅動CMDB的流轉，在應用這個維度上才符合高頻的特徵。CMDN是IT運營平臺的核心後設資料。

因為運維的角色很多，最終的能力管理過程也非常多，所以一定要通過角色加場景，最後才能匯出應該構建什麼樣能力管理的平臺。運維自動化滲透在每個角色和場景裡。作業和排程的能力屬於一種底層平臺化的能力，這個能力應被上層各個子系統使用。

作業管理和排程管理是一種平臺級的能力，不需要對它進行場景化的理解，只要認為在自動化的構成要素裡面有個原子化的事物，同時要有一個排程引擎去編排這個原子化的事物，有兩個要素就夠了。基於這兩者的能力，面向角色和場景收斂去歸類。

工具也是一種文化，通過它，我們可以構建各種各樣的原子工具把我們的能力進行拼裝起來，然後在各個場景下使用。

好的經驗一定要通過自動化的手段去去沉澱，而不是通過文件去沉澱。工具是真正推動變革的有效手段。

我認為這裡面其實要把它變成一種虛擬組織的形式，所以我把它做了一個改進。把中心的角色去掉了，並用技術化的思維做了一個拆分。但這一塊強調技術的能力，要通過持續交付平臺團隊來構建一個持續持續交付的、端到端的DevOps的平臺堅守中心化的原則，和技術、組織架構完全保持一致。不改變現有的組織結構，通過技術的一些手段來加強組織的對映能力。

經營核心的準則就是以家客戶的價值流作為驅動。

在識別整個價值流的時候要看哪些是無效的活動，哪些是不增值的活動，還有哪些是給客戶產生價值的活動。

產品一定要有一個平臺化的思維。這個平臺化思維有個邊界的，不能跨越這個邊界。同時要去適配各個公司的現狀，怎樣把公司現有的一些能力外掛化進來。

從DevOps的角度來說，一定是交付流水線的平臺，IT端到端的排程。整個外掛的適配層是外掛的協議標準，把開發者、測試者和運維的能力，全通過外掛放到互動流水線裡。這裡很多外掛的標準可以認為是作業平臺和排程平臺的能力。

一定要先自動化自己的能力再去自動化別人，千萬不能越界。自動化是一個由點到線再到面的過程、一個逐步覆蓋更多角色的過程，還是一個環境逐步覆蓋的過程。

持續交付是DevOps的最佳工程實踐，以部署流水線為基礎，以快速交付為目標。

應用上線之後運營過程該怎麼去覆蓋合併，我把它分成幾個階段，人工運維、平臺化運維、孵化運營和智慧化運營。

運維也分為運營階段的劃分、目標的劃分、覆蓋的場景是什麼、達成的收益是什麼、需要的資源有哪些。

應用在今天是變得越來越重要，雲的形態底層把能力服務化，那麼應用怎樣去抽象成三個維度，一是資源的維度，二是動作的維度，三是狀態。

應用的執行一定依託於資源。應用的變更等於資源的變更。應用的狀態等於資源的狀態。

最終對應用的整個狀態的評價和衡量就是對於資源的評價與衡量。狀態裡面分成智慧監控、資料分析。監控面向問題，資料分析面向整個的服務、資料視覺化。

應用在今天是變得越來越重要，雲的形態底層把能力服務化，那麼應用怎樣去抽象成三個維度，一是資源的維度，二是動作的維度，三是狀態。

1.變更時長

2.服務恢復時長

3.釋出頻率

4.變更失敗率

合理的指標驅動構建的是不同的組織，高效能的組織、中等效能組織和低效能的組織。

我的分享到此結束，謝謝大家！