織雲是何方神聖？

今天是開發者專場，我在這裡給大家分享一下騰Devops流水線的應用實踐。我來自騰訊的社交網路的運維團隊，做了十幾年的運維，目前我們把多年積累的運維能力實現了產品化，就是我們今天要講到的織雲平台，其中包含了很多我們在建設DevOps過程中的構想和思考，如何讓企業能夠更接近DevOps，讓每一個企業IT人員，工具系統能夠產生它的價值。

織雲這款產品，其實從去年就已經走出騰訊，跟很多的企業有合作，像貴州的智慧小區、宏立城，還有上海的華通銀行、內蒙古的金谷銀行、深圳的港交所等等。但是為什麼大家聽的比較少，因為當時所有的方案都是私有化的，就是專門針對客戶的場景給他定製一體化的運維平台。

DevOps為何如此神奇？

今天主要有三個方面的內容和大家聊一下。一開始，先跟大家分享一下騰訊的DevOps實踐是怎麼做的。下圖是一個企業IT價值鏈的流勢圖，提到Devops肯定要提精益，因為DevOps是基於精益理論在上面構造出來的。

精益裡面強調了一點，價值要流動，必須要由一條鏈承載，這就是我們今天聊的DevOps的流水線。任何一種開發模式，像瀑布式開發或者是敏捷開發都有一條鏈承載的，這條鏈大同小異，都長成這個樣子。因為任何一款互聯網產品從需求搜集，提出需求，到開發、編碼、測試、到最後交付到運維手中發布，並為保證高可用做監控、告警，做修復等一系列的動作，再到搜集新的需求，把這條鏈反饋到產品中，這條鏈大家可以認為流轉速度越快，代表企業的IT能力就越強。這就是為什麼Devops在2009年被提出來之後大受歡迎的原因，因為它提供了一種技術實踐的方法，讓我們找到了一種可以依託的實現的技術，讓我們企業IT的價值鏈流轉加快。 以傳統行業的案例舉例，以前可能應用的發布一次可能就需要一個月、甚至半年，現在我們為什麼能夠做到每周發布，每天發布呢？其實就是這條鏈來決定的。

Devops的組成，其實也是按照這條鏈，只是把剛才那條鏈扁平化了。在完整的Devops當中應該包含了我們怎麼做計劃，包括我們做產品設計的時候，要用最小可行產品， 要管理需求，可能有一些敏捷的方法，你的需求怎麼描述，你的用戶故事、用戶地圖怎麼寫，在做設計和開發的時候，要怎麼樣保證代碼的質量穩定可靠等等一系列問題，最後到如何發布，發布完以後，如何監控。今天發布的騰訊這條流水線的對應的工具，包括了TAPD、tGit、GIS和織雲，今天我會重點給大家介紹一下織雲作為最後一環的持續部署的效率和質量，經過了騰訊這麼多海量業務的洗禮，我們的方案會是怎麼樣的，也希望通過我們方案的介紹，會給大家一些啟發。

騰訊的DevOps實踐

在騰訊內部，我們會把一個需求從概念變成特性需求，變成可以供開發人員理解的具體開發需求，然後一步步的走到我們的生產環境中，就是下面這張圖圖。圖中把我們今天發布的所有產品都涵蓋了，就是TAPD。 產品人員、開發人員錄入需求，這個需求經過評審，分解成一個個的直接開發實現的特殊功能，存放在騰訊內部，然後會進入到持續集成的階段，做自動化的編譯、集成、自動化測試、代碼的近態掃描。 如果有一些不合規範的代碼，或者合併了某個分支以後，主幹測試就通不過了，則通過CIS解決，這些解決以後，就會形成一個製品庫，所有的製品庫會和織雲系統進行一個對接，織雲系統拿到製品庫之後，就會按照騰訊標準的發布、管理的方案，把我們的製品、軟體發布到生產環境，進而去做灰度，做上線的一個過程。

今年3月份，就是春節那段時間，GitLab有一個很著名的故障，就是他們的一個操作人員在測試環境和生產環境多終端切換的時候，在生產環境敲錯了一個命令，結果把生產庫全刪掉了。然後也是花了很長的時間才把代碼恢復。這裡面其實說明了一個問題，首先不考慮技術的因素，先思考一個問題，如果一個經驗不深的同事入職了，把一個很重要的任務交給他，他會不會一個發布把網站都發沒了。如果一個經驗之深的人做這個事情，可以拍胸口說他絕對不會出錯，因為可能過程中有很多坑，這些坑沒有辦法通過配置、通過系統、通過規範流程描述出來，那這樣把它交給一個新人，不熟悉的人，就會有可能有問題。

我很喜歡用一句話來總結這個問題是怎麼產生的，這句話就是文檔即過期、離職即消失，我們在經營一個企業的技術體系的時候，通常喜歡依賴於文檔，文檔可以幫我們記錄很多事情，但是無法記錄他的經驗，而且可能他留下的文檔經過兩周的版本迭代也不適用了。那麼，下面，我就給大家介紹一下怎麼站在運維的角度解決這些問題。

在騰訊內部執行DevOps是有一個標準的執行的規範，就是每個產品需求怎麼樣一步步變成一個編碼過程，變成一個可交付的製品，放在我們的生產環境之後，會配套給這個製品什麼樣的監控，什麼樣的運維以及什麼樣的效率和質量支持，而這其實就是由我們這條流水線決定的。這條流水線要解決的幾個問題，就是不能因為人的經驗而流失。例如，有可能有一個開發人員經驗很資深，知道做這一步一定要測試，但換了一個新人，他不知道或者老員工因為工作繁忙，忘了交待新員工，從而使得不該發生的故障發生了。那麼，我們怎麼解決這個問題呢？下面，我們一起看一下騰訊的應用架構怎麼保證對每一款業務、每一個架構的可運維性的保障。

應用架構的可運維性

Devops有一本很著名的著作被稱之為紅寶書，就是《持續交付》這本書，作者是Jez Humble，中文譯者是喬梁，現在是騰訊公司的高級顧問。這本書有8個原則，就是一個純概念的東西，可以指導我們怎麼做好整齊的一個流水線規劃，為軟體的發布創造可重複和可靠的一個過程，可重複、可靠，背後意味著什麼？意味著我們要有一個很強的體系，如果每個對象都長的不一樣，怎麼可靠、可重複呢？因此，我們得按場景進行自動化，把所有的東西都納入版本控制，將幾乎所有的過程都進行自動化，為什麼？大家仔細想想。如果大家是開發人員，有沒有想過你拿什麼樣的製品去發布到生產環境，或者你們有運維的同事的話，是不是就是丟一個壓縮包給他，讓他發布？站在精益的角度，這些其實就是浪費。

那麼，當我們去規劃持續交付、持續部署的系統，要怎麼規避這種浪費呢？通俗的講，就是怎樣創建一個可靠、可重複的過程？實際上，這就是要求要標準化我們的發布，不能夠讓發布的動作隨著人的經驗而發生改變，它必須要依靠一些可靠的、可以被重複執行的腳本。我不清楚在座有多少同學是做運維的，其實做運維，或者做技術都會有一個問題，就是往往別人交接了一個小系統或者小架構，或者小腳本給你，你拿到的第一件事，看看代碼，心中默念幾句髒話，寫的太爛了，類似的，你會跟你的老闆說，給我一周的時間，我重構它，然後周而復始。對於運維的崗位，也經常發生這種事情，為什麼？A同學寫了一個發布的工具，寫了一個發布系統，B同學來了，發現跟他的思維模式完全不一樣，重構，重構，重構，時間全部浪費掉了，然後我們的企業一直都沒有得到最終的價值，為什麼？其實我們退一步想，為什麼寫這個工具？開發也好、運維也好，我們在企業的價值都是為了讓企業能夠創造更大的商業價值，而不是彼此的不斷地重構、不斷地重複造一些輪子。所以，基於Devops持續交付的原則，我們希望能夠找到一些突破口。

我們提出了「四步走」，就是我們的業務要從一開始就能夠去讓它的架構盡量規範，為什麼？站在開發人員的角度，要實現自己價值，就是要把產品需求實現，就是把產品需求變成一個個功能、特性，編碼的時候，要完成這種功能的邏輯實現。

但是，如果站在架構高可用，還有可運維性的角度去思考這個問題，僅僅完成功能的開發是不夠的，還需要一些非功能的，一些站在可調度、可容災，高可用角度的需求，這在DevOps里有一個專業名詞叫「非功能需求」，這種非功能需求和功能需求怎麼融合在一起，都放在開發編碼階段，讓它實現，這是一個問題。最後當進入到運維的領域，怎麼讓統一架構和運維規範朝著標準化操作方向發展，然後在逐步往自動化，甚至更遠的智能化方向發展，這是我們要解決的關鍵問題。我們下面就來探討一下怎麼落地和怎麼實現。

其實所有的互聯網業務的架構，我們都可以看成是上面這張圖。我們從用戶說起，用戶有終端，無論是PC還是手機，會通過我們運營商提供的網路，訪問到提供服務的內網，如果是雲的話，就有可能訪問到騰訊雲的網路，還有可能是一些雲主機。在這些網路里，如果大家按照微服務架構設計的話，存在接入服務、接入層、邏輯層、數據層，剛才張興華老師跟大家分享摩拜的架構，按照騰訊架構的思路去給它重新規劃的時候，架構層次非常清晰，接入層做什麼，接入層承載的是海量的服務，只需要協議的兼容， 轉發給後面的邏輯層處理，邏輯層強調高並發的吞吐，QPS是多少，然後完成所有的邏輯計算，最後是數據究竟怎樣落地，用KV還是用SQL。

在騰訊，我們提出了盡量把架構做成框架化、組件化、無狀態、分散式。用一個詞，就是盡量往微服務靠。怎麼樣做到這一點？我給大家舉兩個實踐。在騰訊我們是怎麼樣把服務做成框架化的。我這裡舉的是騰訊內部在使用的一個邏輯層名字叫SPP的計算框架，這個框架有什麼特點呢？大家其實可以想一下，任何一個互聯網服務，如果是分散式架構，其實在服務之間通常都有一個調用。那麼，騰訊這麼大一個體量，如果每一個開發人員都要寫一個微服務給別人使用，或者要調用別人的話，這裡面有很大一部分工作將是重複勞動，為什麼？因為每一個服務網路收發請求這部分功能都是公共的，怎麼樣提高開發效率或者怎麼樣保障統一框架的訴求呢？

所以，我們提出了像上圖這樣的一個邏輯層的計算框架，這個計算框架幫助開發人員去通過框架的層面實現網路的請求收發。開發人員只需要很簡單的寫一個動態鏈接庫，把業務邏輯寫在動態鏈接庫，當一個進程載入的時候，會自動載入這部分的業務邏輯，而當這部分業務邏輯真正使用收發請求的時候，就直接調用API就可以完成了。這樣當開發人員在接到不同業務需求的時候，都能很快的實現。

雖然有了統一的計算框架，但像類似的計算框架在騰訊內部其實還有很多。那就遇到了一個問題，就是服務和服務之間的訪問，路由怎麼決定？大家有沒有考慮過一個問題，當A服務訪問B服務，B服務是一個集群有10台機器，有1台機器故障了，如果用配置的形式訪問，在一個配置裡面寫一個IP地址訪問，很有可能A服務發一個配置，重啟一下進程，才可以把B服務故障的IP去掉。但是，大家試想一下，在騰訊這種海量業務的情況下，QQ有5萬多台伺服器，微信應該也接近5萬台，這兩個業務已經10萬台了，整個騰訊，超過50萬台伺服器，騰訊有70萬台的物理機。這麼大體量的設備壓力，沒有辦法做到任何一個IP掛了，我們都有人能夠去處理，都發一個配置去變更。但是當我們引入了一個軟路由服務之後，就幫助我們很好的解決了這些問題。下面一台機器，當主調程序訪問被調程序的時候，會通過API問路由服務從而得到一個服務ID，通過這個服務ID，去訪問被調服務，被調服務要做的是什麼？只要通過維護好這個ID後面映射的那一個IP，就可以做到主調和被調中間的路由解耦，主調服務通過每一次請求都會調用一次這個名字，假設被調服務是十個IP，每一次請求，API都會隨機返回任意一個IP，在一定的時間段內，所有請求的成功率、延時積累下來，在下一個請求，主調程序再去請求L5 API的時候，L5就知道下一次返回一個最優的IP，就是成功率最高的IP，從而實現被調服務如果出現了任何問題，只要不是整個集群都掛掉，都可以實現自決策的負載均衡。路由服務目前也跟著織雲一起開放了，大家如果需要使用的話，也可以免費使用軟體的路由服務。

基於框架的能力和組件的能力，我們慢慢找到了一些規律，那就是可以把很複雜、業務形態各異的業務架構，逐步的通過規劃和不斷地架構演進、迭代，將千人千面的業務架構長成千人一面。在每一個架構層級我們都有相應的解決方案，可能都不需要部署在哪裡，圍繞著這個方案做很多關於自動化、高可用、質量、監控、告警等等操作。

騰訊織雲的持續部署的架構實踐

最後一個部分介紹一下基於騰訊DevOps實踐以及可運維性得出的一個運維方案，就是騰訊織雲的持續部署的架構實踐。下圖是騰訊織雲的功能的一覽表，這裡代表騰訊織雲從下會管理到IaaS層，目前騰訊對很多私有雲的客戶基本實現了從專線、網路設備負載、CPU、內存，還有虛擬或是實體的物理機實現了全盤接管。對於一朵雲還是跨雲，也都可以接管，並且在接管以後提供了一系列的組件，如監控信息、日誌、路由服務等，都可以提供。基於此，我們上面會有CMDB，就是配置管理。

現在談論自動化運維，都會涉及到一個核心的功能模塊，就是配置管理，我們必須要把這個架構用配置描述出來，包括基礎工具、持續部署、架構組件、監控、報警、質量，因為在DevOps中，很強調一點就是一定要把價值鏈閉環，任何東西不是發布出去就結束了，發布完才是真正的開始，我們基於發布出去的特性，通過用戶的主動反饋以及技術日誌分析出來的結果，進行相應的優化。例如為什麼北京的用戶量是最大的，但是北京的訪問延時卻不是最優的，那我們有什麼優化的方法？其實很多初創型的公司都不知道在一些特定的場景中應該怎樣分析，分析什麼樣的數據。但在騰訊，我們面對互聯網的業務相對比較全面，無論是對技術日誌分析的經驗，還是日報的分析，以及哪幾個欄位應該重點分析，像這些很細節的點，我們都有豐富的經驗，並且可以給用戶很好的建議，並把這部分成熟的運維經驗和我們的系統一起輸出。基於此，我們認為有必要講一講自動化和監控如何做。

為什麼把自動化和監控放在一起說？因為我一直認為一個企業業務質量的問題，或者說效率的問題，不能孤立的來看，就像我們收到一條告警，為什麼會有告警？我們應該深層次的挖到根源，有可能由於某個變更引起的，有可能是由於某個不規範操作引起的，這就說明了如果我們沒有去記錄那部分操作的信息，無論監控怎麼做，天花板就已經在這兒了。所以，我們提出一體化運維的概念，這就是我們織雲平台的功能。

通過平台功能的介紹，我們來看一下日常織雲能管那些運維對象。這裡有一個詞，我們很注重非功能的規劃，織雲這個平台先天性帶這運維的理念，對你的每個發布的發布目錄，發布日誌，應該要怎麼放，我們都會給用戶最好的建議，為什麼給這個建議？因為當日誌寫滿目錄的時候，會自動觸發一些工具，可以在得到授權的情況下自動幫你清掉。當然，可能現在不能隨便做這件事，因為前一段時間網路安全法剛出台一條，任何人員不能擅自刪除記錄。基於這一點，我們一直再尋找一些要怎麼樣通過一個很強的規划去把我們的運維對象慢慢減少，減少運維對象的意思不是說不運維，而是例如我有一個Web服務，有一些開發團隊選擇Apache做它的Web Server，有一些開發團隊用Agents，有一些用INS，有些開發團隊覺得那三個都是不好的，我要自己寫一套，你還有一百個開發團隊，他都覺得前面的不好，他都要寫一套，而這個時候就需要統一的一套Web服務，而不是多套，這就是減少運維對象。我們希望通過統一框架的提供，讓大家都不要再去糾結這種問題，讓我們的企業架構不要失控，這是我們的一個初衷。

為此，我們的CMDB配置管理包含了兩大部分，一部分是基礎配置，還有另一部分是應用配置。基礎配置有什麼用呢？進入了企業內部環境的所有資產的信息，包括企業有多少台伺服器，序列號是什麼，廠商是什麼，這些信息都屬於基礎配置信息。這些信息有什麼用呢？最直接的用處，就是運營成本馬上可以通過CMDB得出，比如每個月成本的開銷是怎麼樣的。CMDB會記錄下分布信息、運營配置，拿運營配置來舉例，運營配置裡面有很多個欄位，包括設備的負責人、設備的狀態、響應級別。記錄了這些信息以後有什麼用呢？剛才秦俊老師介紹織雲的時候提到一點，我們強調的是先有規劃，再有操作，有規劃之後，我們的操作就可以根據規劃來做更多、更自動、更智能的動作，例如我們一開始已經把我們的企業的業務架構分成不同的層次，而不同的層次由於它的容災能力、容錯能力不一樣，有可能會被分成響應級別最低的以及響應級別最高的。響應級別最低的，如果出了問題，可以直接用雲的彈性收縮的能力進行修復或者直接銷毀，再上一台，這樣就可以把我們的效率提高，這其實就是DevOps，不然DevOps就流行不起來，它必然是通過很多自動化的過程，讓開發和運維的變得更高效，開發效率得到提升，才得以流行起來的。

再舉幾個案例，還是以資產對應的資源配置舉例。資源配置代表什麼，資源代表了我們的製品，就是我們的軟體包，二進位文件，配置的文件、環境管理的腳本，或者更高級一些的，都會定義成資源，這個資源用作當我們要操作某個業務功能或者服務需要擴容，或者需要全新部署的時候，這些資源就會被配置化的描述起來，我們的運維繫統可以自動的理解，並幫助你做這樣一個發布，而不是有一個業務要部署。比如，經驗豐富的同志就知道有一個配置必須要發，但是換了一個經驗欠缺的就有可能發少了一個配置，或者少改了一個配置，這是很致命的，如果沒有做灰度測試就發布上去，業務就可能受損。我們基於CMDB的配置，把對運維體系中要納管的對象基本都進行納管，最後通過業務編排，有了一個資源，然後是傳輸、執行。把這一系列的鏈條做成一個可靠、可重複的過程。我們得出自動化運維的方案，就是統一規劃、標準化、配置化、自動化、監控，不能漏了監控，通過我們的流程引擎把它串起來。

統一規劃要做什麼？就是要把我們的全流程理順。開發、測試、運維怎麼對接？標準化，架構可運維性是不是可以描述出來的？我們的非功能規範是什麼？我們的系統可不可以承載非功能規範？以前和很多同行交流過，非功能規範都有，但是大家不執行而已。比如，談到配置化的話，要把什麼東西描述出來，然後自動化，你能做什麼自動化。談到監控，自動化以後怎麼保證無人值守是可靠的，或者哪怕不是自動化，每一個發布，怎麼度量你的發布是正常的？發布完成後，經驗豐富的知道要看哪幾個指標，經驗不豐富的就看漏了一個，出了問題都沒有辦法排查，大家一頭霧水。而通過我們的工具編排，這些都會變成一條條可以去重複使用的一個流程，我們稱之為工具鏈。

這裡以新設備上架舉例，如果新採購回來一台設備，或者在雲上通過控制台購買了幾台機器，那者幾台機器要怎麼管？以騰訊內部的流程來說，我們會先測試一下連通性，把密碼入庫，許可權回收，初始化成一個可以直接給業務使用的狀態，包括應該裝什麼應用、系統用戶是什麼等，然後把它的狀態改成待分配。待分配有什麼好處呢，別人可以看到現在的Buffer池有多少，容量多大，自動化程序就可以從待分配這裡拿機器，去上線，去擴展節點，類似這些，然後划到Buffer池，待使用。實際上，每個企業要開展正常的生產環境的管理工作都需要很多不同的流程，我們提供了編排的流程，或者說改一下狀態，監控系統在做監控告警的時候就會根據這個狀態來決策，究竟是直接不告警，還是直接打電話告警，還是發一個統計信息。

應用案例

我這裡給了一個案例，假設我們在做自動化部署的一個過程，總共六步，申請設備、獲取資源、發布、質檢、測試、灰度、上線。我們把每一個步驟的最原始的操作總結出來，一步步的串列做完。每一家企業都有一個工具流，因為金融行業可能基於監管的需求，沒有辦法完全自動化，就在某一步加一個發郵件，領導說到這個郵件點一下鏈接，這個流程繼續在走，是授權在做。或者停下來看指標怎麼樣，再點下一步再繼續做，我們其實都是支持這種不同的過程。

下面再舉一個自愈案例。這個自愈案例講的是在某幾台伺服器上跑一個應用程序，這個應用程序是以進程埠提供服務，進程掛了怎麼辦，按傳統的思路掛了就告警，告警就處理，但是用了我們這個運維管理的體系，在安裝包開始，並且它的這個動作完成之後，會自動的給我們CMDB對應的業務註冊的配置信息，我們拿到這個配置信息，會生成監控服務依賴的一個監控的配置文件，我們會下發到具體的每個監控agent那裡，監控agent拿到說，原來我在這個IP上執行，是要保證這幾個進程都在的，監控agent就會每分鐘PS，當它發現不在了，就會調用進程重啟，去把它拉起來，從而使進程繼續可以自動的去修復。類似這種場景其實還有很多，我只是舉了進程監控的這個案例。從這裡可以看出，通過這些集中的規劃，統一的管理，可以使我們運維的效率的到很大提升。

下面還有一個案例，就是自動擴容的案例。今天早上在主會場提到了一個案例，就是人民日報加天天P圖的那個軍裝照，那個軍裝照整個背後支撐的就是織雲，我為此還發了一篇公關文，就是8億人曬軍裝背後的運維技術。就是講的今天這個主題，在我們騰訊這邊，因為社交業務經常會由於一些不同的事件，有可能今天是「520」，不發一個紅包給我，就好像不愛我。當有這些事件，對互聯網業務來說，表象就是像這種圖，流量來了，我突然搞一個推廣活動，流量一來，怎麼辦？傳統的思路只能人去處理，但是如果你有一套很完整的運維體系，並且思路很清晰的話，其實我們是會這樣的。當流量一來，我們的後台決策會基於容量來決策，是不是需要緊急的觸發一些自動化的流程來修復這個問題。所以，我們會收到一些簡訊或者微信，QQ消息的提醒，告訴我們說有一個業務，流量陡增，但我可以幫你自動調用這個流程，你可以先等等，然後就7×24小時幫我們支撐好服務。當流量突然增加，我們會自動的增加容量，大家可能會說，如果是一些原生雲的服務，可以用彈性伸縮，但是彈性伸縮只基於母機的一個性能的前提下，但我們還可以跨母機的增加更多的資源。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！