概述
今天主要是從兩個方面去探討DevOps，由於大部分朋友可能更多的是看到了運維這個層面，所以我更多側重的是Dev這個層面，也就是從Dev到運維，因為正好是整個全流程走到這裡，我們看到了一些實踐，也看到了將來的一些機會和趨勢。
一、從業務、系統發展看問題
從業務和系統的發展，我們來看當時面臨的問題和解決的措施，就像程永新老師在企業級運維三板斧所說的，未來不是DevOps，關注方向的可能是AIOps這個層面，也就是說DevOps更要關注的是ADPaas平臺，而在運維則側重更多的是AIOps，就像谷歌的系統是自治的，不需要人為介入，所以運維側是要受到很大挑戰的。
上面是公司的一個基礎組織架構，跟所有互聯網公司，或者一些創業已經過了風險期的公司大致相似，這是標準化的建制，就是說業務和研發、測試、運維都有，是這樣的一個結構。
敏捷與持續集成
第一個過程，剛做敏捷和持續集成，跟所有的創業團隊一樣，內部沒有規範，做事圖快，質量較低。大家在創業公司或者是一些中型公司呆過的話就會知道，基本上沒有走到標準化流程階段，基本上都會存在相同的問題，就是業務和研發對接的管理非常混亂，沒有相對規範的流程。
開發做出來的東西提交測試時沒有太多的責任心（在心理定位上將測試人員當作編碼質量的防護網），裡面Bug非常多。然後上線測試，讓測試做構建，把這個包構建出來，最後交給運維，由運維負責上線。整個過程很亂，比如拷到某一個發版機器上，拷上去以後用文件夾打個標籤交給運維，運維再往線上扔，扔到線上以後就要人肉一段時間，看一看沒什麼問題才回家睡覺。
存在問題：基本上的問題就是，需求側這面項目管理非常亂，研發的交付質量很低，會有很多返工的事。項目上線的週期長，問題非常多。
首先做基於持續集成的改善。從過程管理這個層面，把Scrum引入進來，對Scrum做了一定的調整。實際上最近在敏捷圈子裡吵得非常厲害，各種方法論大家都不服，都認為自己代表了“天意”。但從企業的角度，尤其是我們解決問題的角度，用哪個都無所謂，能解決問題才是根本。所以根據企業當前人員情況對Scrum進行了裁剪，不是什麼都要，明確哪些問題需要用Scrum去做。把Scrum流程引入之後，再用JIRA做需求管理、排期這些事情，然後內部用GitLab去做整個代碼的管理，搭一個服務器，把UT做起來，很快能夠得到好的反饋。這個是非常成熟的套路，如果用強制的方法做的話見效很快，基本上1-2個月就能梳理出來。
存在問題：這時發現還是有一些問題，就是研發到測試的交付物不同源，一致性存在問題（我們後面會講一致性的問題）；測試手工驗證週期還很長，因為它沒有做測試的自動化，即功能測試和性能測試都沒有做自動化；項目上線時間長，因為沒有觸動到運維側。所以這時候我們要做的就是持續交付的第一個版本，我們把它叫做持續交付的1.0。
持續交付1.0
持續交付的1.0做了什麼事？就是現在大部分在40人以下的小團隊要做的——一個交付流水線，其實多數團隊都是這樣做，就是加一個pipeline的插件，部署的腳本寫在Jenkins裡頭，然後把它跟源代碼放在一起，這就是大部分持續交付的事情——加一個pipeline插件。
前的CI還需要做，但Jenkins有了一定的構建能力，並且通過pipeline插件我們可以做多環境的部署，只要構建出來以後一步一步往上推（Promotion），但在UAT到生產這一步需要人工做最後的審批，並不全自動化。
存在問題：什麼問題？持續交付說只構建一次，然後在這個構建的產物上進行驗證和部署，這就需要引入製品庫。但是有些實際上在代碼的生成和驗證的過程中，它都是從版本庫裡頭直接拉代碼回來，不斷地拉代碼，拉了以後再動態地打包，這樣的話會有一些問題。
所以把製品庫引進來，就是拿的東西是第一次就構建成功的東西，然後在這個上面不斷地附加原數據。什麼是原數據？就是經過或沒經過單測，單測的百分比是多少，然後誰去驗證它，這都是跟這個製品有關的一些行為和流程數據，它必須要記錄下來，因為後期的活動可以基於這些數據去做選擇。
- 製品庫：Nexus->Artifactor->自研
整個製品庫過程選擇經過了3個階段，最早的整個項目是用Java來做的，很自然的就用Nexus做私庫，去做製品的構建產物管理。因為它很容易解決依賴的問題，而依賴是很麻煩的事情。因為Nexus支持產品版本，不支持構建版本的追蹤，同時它沒有原數據管理的能力。
所以第二步跟JFrog對接，希望用它的Artifactory，這是用得比較成熟且用得比較多的，目前谷歌、騰訊、阿里也在用。但問題是公司體量不大，而專業版的Artifactory比較貴，負擔這樣的花費有點不划算，跟大家一樣我們想用開源版本的，但社區版的Artifactory不支持多語言，而且它構建版本的支持要專業版，所以沒辦法，我們調研以後自己做，拿什麼做？
很簡單，你可以搭一個類似S3的文件服務，把它放在文件服務上去。第二種方式我們用數據庫去做，有些數據庫實際上是可以去存二進制的大文件的，而且它可以很方便地做Key-Value的元數據管理，但自己研發製品庫的問題在於併發、高可用和快速下發。在規模較小時，這些還不是問題。
它的好處是什麼？加了製品庫以後，我們能保證把構建版本和元數據打上去，在這樣的話我們保證部署的都是同源的，而且一步一步可以在它的部署邏輯裡頭根據元數據經過選擇，就是它沒有經過前面的階段或者到達一定的百分比我是不允許後面的階段看到這個構建產物。
現在整個結構，就是說開發到測試的階段實際上這個牆就沒有了。
存在問題：這時我們發現運維人員需要維護大量的環境，包括應用的部署；第二，構建環境與生產環境的一致性是有問題的。為什麼？比如說構建環境放在Jenkins裡，如果去用它做構建的話，它的環境是定好的，例如JDK1.8，那我所有的東西只能在JDK1.8上去構建，但如果我要裝JDK1.7呢？那就另搭一套環境去做它，比較麻煩。部署邏輯和Jenkins是緊耦合的，因為這些東西我們是在Jenkins裡用腳本編程，而且它沒有快速回滾機制。有些時候實際上是要快速回滾的，不能重新拉代碼版本再部署一次。最後，依然需要大量的人員去做半自動化的測試。
持續交付2.0
- 用配置管理工具（Ansible）管理環境
2.0的持續交付，實際上大部分的機器都是虛機。這時候加上Ansible以後，可以拿Jenkins去管這些集群的環境。
存在問題：這時整個場景裡可以看到，有一部分是應用的業務部署，有一部分是環境的部署、管理，但當真正去實踐時發現有些問題。第一個是需要構建環境和生產環境的版本是一致的，即應用包依賴的版本一致，包括操作系統也是一致的。第二個就是需要構建工具的一致性，就是說，構建時比如說是1.9構建的，回滾時也必須要回滾到1.9進行重建，必須要把這個信息記錄下來。
如果大家讀過谷歌的文章，講他們bazel整個構建系統的話，你會發現它的一個巨大的目標就是要做到一致性，最重要的經驗就是把所有的構建的依賴和構建工具放到版本庫裡進行統一管理。現在用Ansible這個方式去管環境，用Jenkins去構建，不會有什麼問題。但當發現應用包丟了，想重新構建一次時用Jenkins進行環境構建時相對比較麻煩，很難自動化再一鍵構建出來一個。怎麼辦？接下來我們在3.0裡頭會講我們是怎麼做的。
- 測試人員和測試工作的定位
測試的自動化，就是功能測試，還包括測試平臺。這樣的話，測試人員和測試工作的定位需要重新反思一下。
這裡面邏輯是什麼？就是留活不留人，比如說一些用戶的可用性這樣的測試需要人的，但這種工具類型的東西不需要人做測試，用機器做就可以了。所以這時會發現整個流程就留下Dev和Ops了，把活留下了。
- Docker與不可變部署
引入Docker，做基於Docker的不可變部署。Docker有個好處就是在生成一個鏡像時，可以通過描述來聲明其包含的內容，並將整個應用和它的環境打包成一個鏡像，這樣的話，測試驗證了這個鏡像以後，它隨後進行的所有部署都不需要變更，所需要變更的東西只是配置，你可以在啟動這個鏡像時給它加一些不同的配置，但它內部的實現一般是不變的，回滾和前滾都是非常容易的。
既然產品可以運行在Docker上，那麼構建環境能不能也運行在Docker上？肯定能，這時候Jenkins上拉起來去構建實際是在Docker環境裡頭構建，就是在生成一個項目時，給這個項目添加一些元數據：項目的名稱、負責團隊、代碼庫，還會指定這個項目構建的依賴是什麼。
這時它會在內部選擇我們已經打好的基礎構建鏡像，比如到底是選JDK 1.7的Docker還是JDK 1.8的Docker，將來構建是在Docker上構建，就是構建時用Docker做構建環境。這樣的話就簡單了，回滾時拉一個Docker進來就可以了，比Jenkins自己構建容易管理很多，同時你會發現重建的過程也隨之簡單了。
- 運維人員和運維工作的定位
這時，我們開始對運維人員和運維的工作進行定位，因為測試人員已經被我們精簡了，從整個業務流程裡拿掉了。那運維人員是不是也要被我們拿掉？其實不是，我們所做的是把運維的工作簡化了，把不該運維負責的東西拿出來了。應用運維不需要運維團隊負責，最終，產品從需求變成代碼，從代碼到生產，生產上以後監控，出了問題以後修復，這些具體執行都不需要運維介入，研發來做，誰構建誰運營。
那運維管什麼？管基礎設施的運維，甚至是工具的開發，把工具開發的團隊放在運維團隊裡頭。
這時大家看到的就是這樣一個結構，就是研發使用運維提供的兩種工具，第一個是支持工具，可能在還沒有成為一個集成的工具前我們可能有多個工具，比如代碼管理、項目管理、分支管理、構建系統，以及最後的部署和發佈系統。還有基礎設施的東西也是需要運維人員去做的。
- Jenkins承擔了太多職責
這個時候，Jenkins承擔了太多的工作，CI、構建、環境、部署都是放在它這兒，所以每個團隊上來做一個新的部署流水線時，要微調，重寫所有的腳本，這實際上非常浪費時間。我們希望能通過配置，不需要重寫這些東西，也就是把編程性的工作變成配置性的工作。
持續交付3.0
- 關鍵工作系統化
首先，就是要把關鍵的工作做成單獨的系統，把它系統化；對於構建，我們不能再把它作為Jenkins的一個插件，我們需要把它單獨拿出來做一個系統。部署也需要單獨做一個系統，都需要脫離Jenkins做，這樣才好管理，好拿一些關鍵性的數據。於是就演變成這樣一個系統，就是環境管理系統、運行環境、部署流水線、元數據服務的一個簡單結構。
下一步我們要把編程性的工作變成配置性的工作，因為我們不想讓程序員老寫一大堆腳本，而且在專屬系統內可以開展一些更細節的工作，這是什麼意思呢？
實際上你可以看到每一個部分都有很多的實踐要做，比如說部署策略，包括了一些分層測試、環境、流量進來怎麼樣分流，一些精確測試，告警這邊也是一樣的，有很多具體的細節實踐，如果都放在Jenkins裡是非常難做的。
這樣的話軟件開發交付的是什麼？應該是一個運行的系統，那麼這個系統的生成的過程應該是可配置、可重建、可追溯的，而且它的過程是自動化、服務化和可視化的，整個過程都能一目瞭然地看到。
- 自改進體系
報障和事故分析
自改進的體系，這個是偏運維側的東西。第一個報障和事故分析，就是我們的系統到底運行得好與不好？業務運行的好壞怎麼樣判斷？最簡單的就是通過數據判斷。有一個方法就是我們一旦發現一個問題，就要迅速發現、定位、跟進、解決，而且要促進分析，產生改進，積累知識和支撐管理。
整個結構如上圖所示，有智能報障系統、根因分析系統，根因分析系統會產生兩種東西，第一種流程性的改進變成了SOP放在WIKI裡頭，然後項目性的東西反饋到JIRA裡面跟進，即哪一個迭代需要通過系統進行改進。然後系統可以根據指標（閾值）——是3級報障去生成一個COE（事故分析）還是2級報障要生成一個COE，就是谷歌和亞馬遜說的事故總結和分析，但它會有一些數據的分析和呈現。
運營目標和運營數據方面，我們可以看歷史的數據和它的趨勢，整個SLA趨勢是不是在變好。
問題分析實際上是這樣一個結構，如果大家看SRE的話，SRE中的事故分析有五個結構，我們用的是亞馬遜的一套結構，跟谷歌的略有不同，但大致上是相同的，理念也是相同的。
APM、日誌與追蹤
運維側大家都比較熟悉，你會發現研發層面已經順暢，這時系統的運行狀態就是我們需要關注的，這實際上是縱向的和橫向的，縱向是從業務面的，橫向是在系統架構從前到後那麼多機器裡頭，到底哪出問題了，這時就會發現需要三個東西，第一個需要傳統的APM，第二需要日誌的分析，第三需要全鏈路的追蹤能力。
場景化運維：定位到點
全景圖基本上如上圖所示，可以看到左邊是偏研發的，右邊是偏運維的，還有很多的工具在內部運營，比如統一身份的認證，安全掃描和管理，網絡這些東西都需要，一旦運維起來整個業務很多東西都需要工具來支撐。這裡面績效管理、組織人員、郵件列表、技術通訊、項目管理都需要考慮方法。
總結：devops核心的東西實際上只考慮兩個東西。
第一個就是誰構建誰運維，研發要做所有的事，因為他構建這個系統，所以他運維這個系統，但他不運維基礎設施，也不運維工具。
第二個就是領導力，領導力是整個企業的核心價值，從人員的招聘、培養到淘汰，都是基於領導力考慮的。這裡我說幾項領導力，一是責任感，二是執行力，三是學習能力，你要判斷你招來的人是怎樣一個人，能否靠得住，他需要跟你企業價值觀高度吻合和融合。如果你招來一個人能力很強，但不認同你的價值觀，大家就很難到一塊工作。
閱讀更多 波波說運維 的文章
