本文根據陳能技老師在〖2016 Gdevops全球敏捷運維峰會廣州站〗現場演講內容整理而成。

講師介紹

陳能技，DBAplus社群原創專家，新炬網路首席DevOps專家。14年開發測試與質量架構經驗，擅長DevOps及APM、Docker、持續整合、持續交付在企業中的落地實施。著有《軟體效能測試診斷分析與優化》、《軟體自動化測試成功之道》、《深入淺出效能測試與LoadRunner實戰》等書。

大家好，我是來自新炬網路的陳能技，很高興能跟大家分享我對DevOps的一些思考和經驗。最近幾年我接觸的很多傳統企業，像移動運營商、航空、政府企業、電網等跟我們所說的全球化、國際化的DevOps之間還是有一定差距的。所以，今天也很高興看到不少企業的同仁來到現場，一起探討DevOps，探討傳統企業的轉型，分享一些傳統企業如何跟上主流研發模式和運維模式的建議。

本次演講將包括以下幾部分：

分享之前，先看幾個數字。

這些是來自亞馬遜Apollo平臺的資料。過去一年中亞馬遜推送了5000萬個部署，每分鐘達到95到100個。平均的部署時間是11.6秒，速度非常快，但光快也不行，還要快、準、狠，我們看到最後一項，部署失敗停機率僅為0.001%，這些才是開發運維應該達到的一種高度。

當然有些企業可能會說，我們的速度不需要很快，但我覺得這是一個標杆。近日我看到一個Oracle的新聞，講到Oracle目前在往雲大量的落地。在我看來，Oracle的雲相比亞馬遜的雲在IaaS這一層可能有它的一些優勢，但如果從前端應用的部署、交付應用的效率上來說，也未必能達到剛才提及的那些高度。

因此，要怎樣才能達到這樣一個目標呢？這是我們今天要談論的問題。

我們在不斷地尋找一些方法、手段，以及工具和技術來嘗試達到這個高度，以求快速地交付應用、快速地部署。早些年為了讓開發跟上業務需求變更的速度，新炬網路當時找到了敏捷開發，這讓傳統的採用瀑布模式的企業通過敏捷轉型，在應對需求變更上達到了一定的效果，但仍然不夠，所以我們還在不斷地尋找。

從上面這張圖，可以看到近幾年DevOps正處於技術發展曲線的頂峰，也就是說2015這一年，大家喊得非常多，都說要做DevOps、要做轉型，但這是否又是一個概念的炒作呢？從歷史的發展來看，雲端計算、大資料剛出現時，大家也認為是在炒作。確實，IT領域有一個毛病，就是每隔三五年就會更換一批概念或名詞，然後各家的廠商也紛紛說我們在做這一塊的東西，傳統的工具廠商像做軟體測試工具的、做開發工具的會說我們有DevOps平臺，傳統的做一些運維服務的也會說我們在搞DevOps，各家都有各家的一些說辭和想法，那究竟什麼是DevOps呢？

我們認為DevOps不是一個簡單的概念，要充分理解DevOps，得從開發、運維碰到的諸多問題出發去想。先前敏捷開發的出現，實際是彌補了業務需求頻繁變更與開發、測試之間交付的差距。現在如果一個企業做的研發還是傳統的那種瀑布模式的，都不好意思拿出來說了，他們都會說我們在做敏捷的轉型，或者說已經有部分實現了敏捷開發的模式。但敏捷不能完全解決開發運維一體化的問題，這時離你快速地、無差錯地交付應用還有很長的一段距離，所以DevOps的應運而生，正是用來彌補這第二個差距。

因此，DevOps不是單純的敏捷開發和提高效率，也不是單純把生產模式引進來。DevOps發展到了今天，有它的一些基礎，像早先不斷在發展的與敏捷相關的實踐中的持續整合、持續交付，以及持續交付當中涉及到的自動部署，當然還有一些較新的基礎，像Docker。這些基礎在不斷地完善之後，DevOps自然而然就出來了。我們認為，現在的DevOps會去整合已有的敏捷開發、持續交付、ITIL等東西，這當中也囊括了精益的管理思想。

下面談談我自己對DevOps的理解。

我認為DevOps存在著一些本質性的東西，把DevOps拆開來看，Dev是開發這一層的，而Ops是運維方面的，如果開發運維要走向一體化，首先這意味著原先傳統的開發運維不是一體化的，是割離的。因為開發這邊會有自己的一些訴求，同等的，運維這邊也會有自己的需求。打個比喻就是，在足球場上踢足球，開發像是帶球的前鋒，不斷地進球，不斷地運動，不斷地改變，它強調對業務需求頻繁的響應。而運維，更像是正好一個球過來，擋住它不讓它射，不讓它上線，最好一年都不要有變更，這是運維固有的一些思維。反觀現在，隨著業務變更的速度越來越快，如果IT的能力跟不上，就會被競爭對手拉下一大截距離。因此就需要強迫我們的開發跟運維做到一體化，緊密地去做協調、協作，這樣才能提高效率。以上是我個人對DevOps的理解。

二、DevOps能力融合4大核心實踐

新炬網路通過這幾年的實踐經驗發現，做DevOps的轉型，很關鍵的一點就是能力的融合，對此我們提出了一個DevOps能力矩陣模型。它涉及到了三個角色，分別是開發、QA、運維，這三個角色加上管理的視角，比如說我要去度量，強調我的過程是可控的，同時也會運用到一些工具和手段。

從這兩個維度出發，我們就會發現有些不同的能力出來了，這些能力按照傳統的模式是一定要割離的。舉個測試的例子，做一個單獨的測試，像效能測試，傳統的話會交給QA。QA測試完了交給運維時，發現開發的環境、運維的環境是不一樣的，尤其資源是不一樣的，就導致了QA做完的一些測試結果、效能的指標，到了運維這邊不適用、不認可。

那要如何解決這些問題？必須做一些能力的融合。有沒有一些工具或技術是兩者能夠去共享的，比如說環境是否能夠達到一致，診斷分析效能的工具能不能通用，開發、測試這邊用的一些術語運維這邊能不能聽懂，運維監控以及運維收集到的一些資料能不能及時反饋給開發這一層，這些能力都需要融合。並且，在這個融合當中，我們不斷強調這個能力要能傳遞和共享，比如說我們從提出需求到開發、測試、部署、上線一直到運維，這些能力如何在這些流程中不斷地流轉、價值傳遞，減少浪費，提高效率，這就涉及到了精益管理的思想。

經過這兩年的一些初步的摸索和實踐，同時也借鑑了國外一些先進的理念，新炬網路提出了DevOps能力融合4大核心實踐。

這4大實踐總的分為兩大塊，一塊是從開發往運維這一側能力的傳遞，包括將開發延伸至生產中，這講的是持續整合和交付、自動化部署。也包括將開發嵌入到IT的運維中，比如像APM這類工具，能讓我們把一些效能診斷分析如業務流程程式碼和SQL的執行效率診斷、瓶頸分析等能力傳遞給運維，實現業務呼叫鏈的效能監控，快速定位瓶頸所在。

另一塊是從運維到開發這一側，也有兩大實踐，第一個是向開發中加入生產反饋，而且這個反饋應該是視覺化的，要精準一些資料，像監控、運維的資料，而不像傳統的方式，當運維暴露了一些故障，開發去要這些資料還要走什麼流程，好像這些運維資料是什麼祕密，從而降低開發排故的診斷分析難度，節省排故時間。第二個是將IT運維嵌入到開發中，例如在開發階段就嵌入規範化的日誌輸出、儲存的標準做法，運維過程中要看這些日誌資料能不能及時地反饋給開發，並通過日誌分析定位開發的程式碼問題，開發這邊能不能嵌入一些日誌的輸出在生產環境做一些除錯診斷。

這些實踐都是企業在日常運維中可以選取的，你可以選取我現在的主要能力是建立持續整合體系，或者加快自動部署的能力。如果你認為效能對於企業的應用來講是最關鍵的，那就把一些效能的資料在開發過程診斷出來，或者在運維過程中去收集和發現，同時還要實施實時的監控和日誌的收集。

通過這種能力的融合，我們發現基本上都能夠取到你想要的資料。開發能夠通過一些日誌分析和診斷程式缺陷，運維可以快速地去定位故障，降低故障恢復時間，提升SLA。而運營也能夠綜合地對業務日誌進行分析及挖掘，有效實現產品及企業的運營，實現商業價值。安全人員可以通過對海量安全日誌的分析，過濾出安全事件，查詢隱患。

我們新炬網路提出的基於DevOps能力的矩陣模型認為，開發、QA、運維三者能力的融合是最為關鍵的。開發到運維的管理過程的交叉融合是基礎，但要把DevOps真正的落地實施，工具化、平臺化的東西也必不可少。有些傳統企業其實已經有在用一些工具，像一些配置管理、專案管理、效能測試的工具，但往往都是零散的、沒有去整合過的工具。沒有整合就意味著你的能力是沒有辦法去傳遞。每個部門都有自己的一套工具和平臺，但關鍵是這些資料能不能共享出來。

要建立一個DevOps平臺，最終你要實現的肯定是一個視覺化的、資料共享的，然後是自動化的，很多流程不需要人工干預，可以自動流轉。比如一個應用包從程式碼編譯到構建出來部署到一個環境中，經過自動的測試，再部署到準釋出環境，這應該是一個自動的流程。最後，它還應該是一個智慧化的，即能夠很快地定位出整個生產的環節，包括程式碼交付到運維這整個環節，哪些地方是存在浪費的。

下面按照一般的實踐，簡要地看一下建立這樣一個有持續交付能力的PaaS平臺，具體要完成哪些事情。首先，我覺得第一個要考慮的一定是工具的整合，因為人很多時候能力的實現需要依賴工具，開發的能力需要開發的工具，測試的能力需要測試的工具，同樣，運維如果缺少了工具，就沒法幹活了。

這個圖是國外的一個廠商仿照元素週期表製作的一張DevOps週期表，非常龐大。在這樣一張表中，有各種各樣的工具，比如一些原始碼配置管理、持續整合、測試的工具，也有資料庫、CI、日誌、安全、監控、雲服務等工具，一共分為15個大類120個工具。面對紛繁眾多的工具，建立一個適合自身企業開發運維一體化平臺時，工具的融合變成了首要考慮的前提。況且現在很多的傳統企業，本身已經有一堆的工具了，這時是把它全部替換掉，改用一些開源的，或者是重新買些商業的或是基於它再做些整合，所有這些都需要考慮到。

第二點，要考慮到三大核心基礎架構設計。第一個是配置管理的架構設計，這裡包括兩個方面，一個是原始碼配置管理，一個是環境配置管理。第二個是自動化架構的設計，包括從開始的程式碼編譯一直到能夠部署環境這個流程如何讓它實現自動化，這裡通常會借鑑持續整合的做法。接著，整個制度的流程做好了之後，結合你的環境配置管理，就可以生成一個MOF。MOF算是一個通用的標準，對不同的平臺來講，雲平臺、做自動部署的平臺或者Docker，它都是以一些標準的描述好的方式做好。以上三點是做PaaS平臺時必須考慮的。

另外，除了工具，做一個平臺的建設，還需要考慮流程規範化的問題。按照我目前所接觸到的大多數傳統企業，其實他們的配置管理、測試、環境的部署、資料的管理等大部分都還是在比較初級的狀態。所以，首先我們自己要找準本身處於哪個位置，我該整合哪些工具，整合哪些能力，往高一點級別的能力又該如何去發展。

最後還有一個大家尤其是傳統企業或多或少會忽略的問題。回想一下，傳統企業相比網際網路企業，是否在DevOps轉型以及早先的敏捷開發轉型中碰到了更多問題？這其中的原因很大程度是因為傳統企業往往有N多個部門，這些部門之間又是割離的，因為沒有部門會攪亂自己的利益關係或利益訴求。在這種情況下，缺乏了一些通用的平臺能夠跨越部門的流轉。

這裡有個所謂的康威定律，也就是說你最終的產品架構好壞，是由你的組織架構的溝通模式決定的，不能是割離的，否則無論產品也好，事情也好，都很難高效率地完成。所以，DevOps平臺的建設裡面，還必須考慮的一點，就是團隊組織架構。拿角色來說，有些角色可以是沿用之前的，有些則可能需要做一些適當的轉型。再比如傳統的測試，應該更敏捷一點，應該更加往自動化的方向去發展。

當然了，不同的企業應該有不同的組織架構，諸如小型的企業，扁平化的組織可能會更加適用。而大型的組織架構，矩陣型結構會較為合適，得有業務條線、開發運維以及多種不同服務的能力。

當你有了人，有了團隊，流程能夠自動地流轉，也借鑑了一些新的技術、工具，那是否就搞定DevOps的問題了呢？還不一定。

這個圖是剛剛講到的關於DevOps轉型必須考慮的幾個維度，總結一下：

• 從人的角度來看。必須考慮清楚開發、QA和運維這三個角色的能力融合，以及在一個平臺上做溝通協作的事情。
• 從流程的角度來看。流程很多，在轉型時要先考慮比較容易實現、關鍵的流程，比如持續整合、自動化測試、技術架構（像程式碼的質量管控）這些關鍵而易行的流程，不要一上來就說我要做單元測試。
• 從技術的角度來看。很多傳統企業都是比較怕接觸一些新的技術和工具，像Docker出來的時候，這是個什麼東西，我要不要去用，都很猶豫。有時候甚至連要不要去嘗試都沒有去想。
• 最後從文化的角度來看。關於DevOps，每個人都有自己的看法，好比盲人摸象一樣，各家都各有成言定論，但要往DevOps成功轉型，文化是一定要建起來的。所以我們在一些企業推行這件事情時，也會去組建DevOps的推行小組，就像先前我們做敏捷開發的時候，會有敏捷教練這些的誕生。當DevOps發展到一定的階段，也一定會有這些東西。

文章出處：DBAplus社群