<b></b>
（點選底部“閱讀原文”擷取陳能技演講完整ppt）
講師介紹
陳能技，dbaplus社群原創專家，新炬網絡首席devops專家。14年開發測試與品質架構經驗，擅長devops及apm、docker、持續內建、持續傳遞在企業中的落地實施。著有《軟體性能測試診斷分析與優化》、《軟體自動化測試成功之道》、《深入淺出性能測試與loadrunner實戰》等書。
大家好，我是來自新炬網絡的陳能技，很高興能跟大家分享我對devops的一些思考和經驗。最近幾年我接觸的很多傳統企業，像移動營運商、航空、政府企業、電網等跟我們所說的全球化、國際化的devops之間還是有一定差距的。是以，今天也很高興看到不少企業的同仁來到現場，一起探讨devops，探讨傳統企業的轉型，分享一些傳統企業如何跟上主流研發模式和運維模式的建議。
本次演講将包括以下幾部分：
什麼是devops
devops能力融合四大核心實踐
開發運維一體化paas平台建設四要素
一、什麼是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平台建設4要素
下面按照一般的實踐，簡要地看一下建立這樣一個有持續傳遞能力的paas平台，具體要完成哪些事情。首先，我覺得第一個要考慮的一定是工具的整合，因為人很多時候能力的實作需要依賴工具，開發的能力需要開發的工具，測試的能力需要測試的工具，同樣，運維如果缺少了工具，就沒法幹活了。
這個圖是國外的一個廠商仿照元素周期表制作的一張devops周期表，非常龐大。在這樣一張表中，有各種各樣的工具，比如一些源代碼配置管理、持續內建、測試的工具，也有資料庫、ci、日志、安全、監控、雲服務等工具，一共分為15個大類120個工具。面對紛繁衆多的工具，建立一個适合自身企業開發運維一體化平台時，工具的融合變成了首要考慮的前提。況且現在很多的傳統企業，本身已經有一堆的工具了，這時是把它全部替換掉，改用一些開源的，或者是重新買些商業的或是基于它再做些整合，所有這些都需要考慮到。
第二點，要考慮到三大核心基礎架構設計。第一個是配置管理的架構設計，這裡包括兩個方面，一個是源代碼配置管理，一個是環境配置管理。第二個是自動化架構的設計，包括從開始的代碼編譯一直到能夠部署環境這個流程如何讓它實作自動化，這裡通常會借鑒持續內建的做法。接着，整個制度的流程做好了之後，結合你的環境配置管理，就可以生成一個mof。mof算是一個通用的标準，對不同的平台來講，雲平台、做自動部署的平台或者docker，它都是以一些标準的描述好的方式做好。以上三點是做paas平台時必須考慮的。
另外，除了工具，做一個平台的建設，還需要考慮流程規範化的問題。按照我目前所接觸到的大多數傳統企業，其實他們的配置管理、測試、環境的部署、資料的管理等大部分都還是在比較初級的狀态。是以，首先我們自己要找準本身處于哪個位置，我該整合哪些工具，整合哪些能力，往高一點級别的能力又該如何去發展。
最後還有一個大家尤其是傳統企業或多或少會忽略的問題。回想一下，傳統企業相比網際網路企業，是否在devops轉型以及早先的靈活開發轉型中碰到了更多問題？這其中的原因很大程度是因為傳統企業往往有n多個部門，這些部門之間又是割離的，因為沒有部門會攪亂自己的利益關系或利益訴求。在這種情況下，缺乏了一些通用的平台能夠跨越部門的流轉。
這裡有個所謂的康威定律，也就是說你最終的産品架構好壞，是由你的組織架構的溝通模式決定的，不能是割離的，否則無論産品也好，事情也好，都很難高效率地完成。是以，devops平台的建設裡面，還必須考慮的一點，就是團隊組織架構。拿角色來說，有些角色可以是沿用之前的，有些則可能需要做一些适當的轉型。再比如傳統的測試，應該更靈活一點，應該更加往自動化的方向去發展。
當然了，不同的企業應該有不同的組織架構，諸如小型的企業，扁平化的組織可能會更加适用。而大型的組織架構，矩陣型結構會較為合适，得有業務條線、開發運維以及多種不同服務的能力。
當你有了人，有了團隊，流程能夠自動地流轉，也借鑒了一些新的技術、工具，那是否就搞定devops的問題了呢？還不一定。
這個圖是剛剛講到的關于devops轉型必須考慮的幾個次元，總結一下：
從人的角度來看。必須考慮清楚開發、qa和運維這三個角色的能力融合，以及在一個平台上做溝通協作的事情。
從流程的角度來看。流程很多，在轉型時要先考慮比較容易實作、關鍵的流程，比如持續內建、自動化測試、技術架構（像代碼的品質管控）這些關鍵而易行的流程，不要一上來就說我要做單元測試。
從技術的角度來看。很多傳統企業都是比較怕接觸一些新的技術和工具，像docker出來的時候，這是個什麼東西，我要不要去用，都很猶豫。有時候甚至連要不要去嘗試都沒有去想。
最後從文化的角度來看。關于devops，每個人都有自己的看法，好比盲人摸象一樣，各家都各有成言定論，但要往devops成功轉型，文化是一定要建起來的。是以我們在一些企業推行這件事情時，也會去組建devops的推行小組，就像先前我們做靈活開發的時候，會有靈活教練這些的誕生。當devops發展到一定的階段，也一定會有這些東西。
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-10-14</b>