DevOps與傳統的融合落地實踐

內容來源：2017年5月6日，王津銀在「DevOps&SRE 超越傳統運維之道」進行《DevOps與傳統的融合落地實踐》演講分享。IT大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

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

摘要

在雲計算、大數據等技術顛覆性趨勢繼續在應用經濟下發揮做用的同時，DevOps也已經穩健地在業務思惟方式中佔有一席之地。那麼DevOps與傳統如何融合落地，王津銀帶來了他的實踐經驗分享。

嘉賓演講視頻及PPT地址：t.cn/RajmlOX

DevOps的全局理解

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

DevOps與ITIL的對比融合

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

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

DevOps自動化與ITIL規範之間的融合

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

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

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

• 第三種是敏捷發佈流程。

從軟件研發模式看DevOps

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

隨着研發模式的變化，各個角色在裏面所承擔的工做量配比也在發生變化，研發愈來愈重要。

DevOps的落地經驗談

1、理念與價值先行

強調五點理念：

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

二、整合開發和運維的能力，成爲一個協做的團隊。

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

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

五、不影響安全性、兼容性和性能。

2、頂層設計與全局規劃

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

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

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

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

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

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

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

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

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

3、Start Small，從小作起

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

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

切忌貪大求全。

4、構建IT元數據平臺，驅動IT平臺間整合

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

5、痛苦的事情優先解決

由於運維的角色不少，最終的能力管理過程也很是多，因此必定要經過角色加場景，最後才能導出應該構建什麼樣能力管理的平臺。運維自動化滲透在每一個角色和場景裏。做業和調度的能力屬於一種底層平臺化的能力，這個能力應被上層各個子系統使用。

6、工具也是一種文化

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

工具也是一種文化，經過它，咱們能夠構建各類各樣的原子工具把咱們的能力進行拼裝起來，而後在各個場景下使用。

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

7、組織二次元，加羣落地力

我認爲這裏面其實要把它變成一種虛擬組織的形式，因此我把它作了一個改進。把中心的角色去掉了，並用技術化的思惟作了一個拆分。但這一塊強調技術的能力，要經過持續交付平臺團隊來構建一個持續持續交付的、端到端的DevOps的平臺堅守中心化的原則，和技術、組織架構徹底保持一致。不改變現有的組織結構，經過技術的一些手段來增強組織的映射能力。

8、價值拉動，而非事務驅動

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

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

9、平臺+插件=服務能力產品化，和組織一致

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

從DevOps的角度來講，必定是交付流水線的平臺，IT端到端的調度。整個插件的適配層是插件的協議標準，把開發者、測試者和運維的能力，全經過插件放到交互流水線裏。這裏不少插件的標準能夠認爲是做業平臺和調度平臺的能力。

10、自動化別人，先自動化本身

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

11、持續交付是DevOps落地的最佳實踐

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

12、IT運營管理驅動Ops能力建設

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

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

十3、構建面向應用的最強管理驅動力

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

應用的運行必定依託於資源。應用的變動等於資源的變動。應用的狀態等於資源的狀態。

最終對應用的整個狀態的評價和衡量就是對於資源的評價與衡量。狀態裏面分紅智能監控、數據分析。監控面向問題，數據分析面向整個的服務、數據可視化。

十4、構建面向應用的最強管理驅動力

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

十5、構建指標，驅動DevOps落地

1.變動時長

2.服務恢復時長

3.發佈頻率

4.變動失敗率

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

個人分享到此結束，謝謝你們！

推薦文章

• 靈雀雲首席架構師邵明岐：教育行業轉型DevOps實踐

• 美團雲DevOps專家雷雨：美團點評數據中心基礎服務框架

近期活動

• 直播+福利 | 當AI趕上大數據——ArchData技術峯會
  

• 直播 | 餓了麼&極光：前端技術綜合實踐（文末有飯票）
  
• 直播 | K8S GeekGathering上海站【文末有電影票】