講師簡介
楊利東
十年運維老兵，目前負責織雲 QQ 資料和關係鏈的後臺運維工作。
經歷過農牧場、廣點通廣告業務的大爆發後臺支撐以及運維服務體系、架構優化和自動化運維的發展、成熟過程，對海量運維服務體系建設以及自動化體系建設方面有豐富的經驗和獨特的思考。
分享一個老生常談而又古老的話題—自動化運維。
騰訊織雲的自動化體系包含了非常非常多的內容，上圖可見。我的同仁對織雲的內容進行過分享的，如組件、基礎運維、架構、調度、監控、AI、算法等方方面面的內容。
我要分享的是紅色框框的部分內容。像包管理，我會給大家講解我們的包是什麼，不是LV，也不是愛馬仕。
還會分享一下業務CMDB配置管理和自動化流程。在這過程中會給大家分享下我們遇到的坑，和我們的想法以及經驗，希望能給大家帶來一些靈感和觸動，我的目的就達到了。
我做了很多年的運維工作，以前做過農牧場運維，也做過廣告業務運維，現在主要是負責QQ的密碼、資料、關係鏈的運維工作。上面是我所要分享的三大塊內容。
1. 講一講我們的故事
在迅猛發展的情況下，大家可能會遇到各種問題，發展過程中運維承擔著很大的壓力。
比如說研發團隊成長非常快，很快招了很多研發，這個需求就相應的變得非常多還急需，而且他們不一定採用同樣的框架，以及自己的編碼習慣和組件可能也不一樣。
作為運維人員，可能通過某些手段說服了老闆給你加人，新招了兩個運維小弟，發現這兩個運維小弟能力上可能不一樣。
在日常的溝通交流和腳本管理開發上肯定會受到影響，因為大家對技術點、腳本、架構理解肯定是不一樣的。包括現在很多人員會涉及到出差、工作交接和離職。
最後可能又花一點精力把老闆說服了，做運維優化，從業界選擇了很多大名鼎鼎的運維方案，但是又可能不一定推得動，可能研發人員不配合，想法雖好落地困難。
先吹兩個牛，第一個是全民曬照片，全民18歲，短時間圖片上傳量達到平日晚高峰的4倍，我們幾小時擴容上千臺設備。第二個是QQ紅包，兩週內我們大概搞定800個模塊接近3萬設備的上線，用來支持春節紅包的活動。
2.包管理系統的來世今生
在講包管理和運維方案之前，要講一下研發組織結構。一個公司自從誕生之日起，一定是研發同學把環境部署好，基本上該做的東西做完了，老闆說兼任運維兼不動了，需要招專門的運維了，這時你才被招進來填坑的。
我們對應什麼樣的組織結構下容易用什麼方案解決？
第一種是中心型的。一個研發負責人統一集權管理，進行統一框架下的開發。
在這種框架下很多東西很好做，這種情況下有一個要求，要求研發負責人先知先覺，在公司創業之前或者剛開始就選好這個東西，或者你有強大的改造意願、改造能力，過程中發現有問題你去改，要能改得動才行。
第二種是多中心型。這是我們今天重點介紹的，在面臨著多中心型，各個部門在負責不同的產品研發，有可能他們之間會採用同一個組件、也有可能不會，但是他們對環境要求大體一致，不會千差萬別。這種情況下可能誕生標準型、效率型。
第三種是離散型。剛才說環境大體一致，如果環境不一致就離譜，這時候就會有工具型運維體系。
當我們面對人員方面的問題，首先要有一個概念和指導思想，整個方案的優化過程一定是漸進型的，不是一下就能一步到位的。
又輕鬆、又低成本、又節約時間、又能搞得定的方案是沒有的。
大家看一下我們的過程，第一步是做包管理，後面隨著設備的增加我們做了SPP框架組件，然後做了名字服務、調度能力，後面做了CMDB資源、鏡像、條帶化、自動化流程，最後做了數據銀行、智能運維。這是模塊化的交付過程，比較契合企業的發展狀況。
一下把AI的運維方案交給一個只有10臺服務器的公司有用嗎？沒有用的。有人問我，我們公司應該怎麼做？我說要根據具體情況來，不要說哪個火哪個潮流就用哪個，這是沒有用的。
當有非常多的開發天天來問你重啟命令、操作和維護等等這些問題的時候，會讓你非常頭大，這些問題非常簡單，會讓運維陷入到重複性勞動而又沒有什麼價值的工作中。
我們的包管理系統就是為了解決上述問題，這是運維必須要承擔的，又特別不容易有產出的一種工作，也是最麻煩的一件事情。當時想到是統一研發框架，像谷歌這樣的公司已經有這樣的開源的方案了。
對於我們多中心型的團隊，搞定一個團隊就不容易，搞定多個團隊更加困難，開發同學忙於自己的業務。
後來我們就想到了統一管理框架。做這個事情的出發點是為了優化運維管理，其目的是管理，千萬不要過度的讓開發去改底層代碼，這是不太現實的。因此我們就把文件目錄和腳本功能進行梳理。
這是梳理後的效果圖。那麼包到底是什麼呢？我給包做了一個簡單概念，包就是為了完成一組特定功能的文件的集合。
根據包的功能的不同，列出目錄的規劃，比如 Admin 做功能上的重啟、清理文件，Conf 是配置文件，Log 是日值文件，Client 是插件。這樣的一種把文件規範劃分的做法，讓所有的包看起來都長得差不多。這聽起來很簡單，實際情況遠遠不止這樣，請往下看：
文件管理
把前面劃分完之後我們就採到坑了，當時負責廣告運維，這是一個現金流的業務，分分鐘就多少錢，我要卸載一個IP的某個包，發現誤選擇了所有IP，結果發現所有IP的包都被刪除了。後來我在包的後置腳本加了軟鏈，再也不擔心包安裝後沒有軟鏈的問題了。真是幫忙解決了大問題。
還有一個大坑就是公共文件。多個程序一定會訪問同一個文件，我們現在就遇到，QQ空間有一個公共文件達到上千行的配置，為了管理這個公共文件我們還做了開發系統，做了各種鎖，總之非常複雜，在這種情況下還經常出事故。
進程管理
這種東西經常帶來誤殺，會把其它進行誤殺掉，鑑於此就做了這樣的一種模式。
我們有一個進程自監控的功能，對於有死機或者業務進程收到了不正常的請求，進程被掛掉了，就需要自啟動功能。
我們怎麼做的呢？現網每3分鐘 PS 一下，去找這個包裡面的進程有沒有在，如果它在就自然什麼都做了，如果不在，就需要在標記位裡問一下，如果標記位允許它在，就要做拉起，失敗則告警。
如果它不在，標記位也不在，那就什麼也不做了。
為什麼會有“標記位”這個東西存在呢？懂架構的人知道，這是一個非常複雜的，為了維護這個標記位，我們做了幾十的版本，各種加鎖和各種保護在裡面。
產生這個東西是因為產品決定的，包在用戶用的時候有一種需求是安裝完了並不啟動，可能依賴一些其他文件或者其他的環境，我還沒有準備好，啟動的時候也啟動不了，每次都會報錯，因此就不啟動了。
我們有一個“安裝後是否啟動”的標籤，如果不希望啟動，你把這個拉起了，用戶期望以外的事情就發生了，這是不允許的。所以我們做了這個“標記位”，在啟動的時候才顯示，如果不啟動就不寫這個。
版本管理
產品的迭代是非常非常頻繁的。這個例子裡面有100多個版本，版本管理我們是怎麼做的？版本之間的區別是通過描述進行的。聽起來很專業，一旦描述錯了怎麼辦？我們有辦法。
這裡有三個問題：
存儲1000個包，100個版本，存下來就是9.5T。
100個IP版本升級，那麼傳輸消耗是12000M還是2000M？
如果上面升級出問題了，我們趕緊回饋，這時候回饋的網絡傳輸消耗是多少？
這是我們的方案。調用 Diff 函數來進行下載，緩存的僅僅是變化了的文件，也就是不同的文件，速度非常快。我們這裡有4萬多個包，60多萬個版本，包存量3T。
文件級 diff 到底是怎麼回事？左邊的圖是織雲包，右邊的圖是鏡像包。通過織雲包，這是一個傳輸方法，用鏡像包就是diff，從第二個版本到第三個版本，只需要傳輸4和5就好了。
如果1和2特別大，又涉及到需要傳輸的特別多，整個用戶體驗升級的過程和消耗的時間就會非常慢。我們的包管理非常輕量、非常敏捷，它的技術實際上就是圖上這樣的。
我們的版本回滾也非常快。在升級的時候，把diff內容放到了本地磁盤。如果你要回滾，從本地磁盤直接對本地磁盤傳輸，網絡消耗是零，它不需要變化。
我們整個包的版本管理和存儲一切都是增量，包括存、下載、回滾全部都是增量。
我們包操作任務一天有2萬多次，非常頻繁，每次耗時10-20秒，耗時非常少，成功率可到4個9也非常高。通過這麼多年的版本迭代解決了非常多的問題。
實例管理
實例就是讓你非常清楚的知道現網每個IP到底是哪個程序、哪個版本。我們這裡針對實例做了一些防呆設計和排序。這裡講兩個：
第一是屏蔽命令行。我做運維的時候也經常去跑命令，但是跑命令是非常高深的工作，跑錯了就非常麻煩，回滾也很麻煩。屏蔽命令行就讓研發他們非常便捷的使用這個包管理。
第二是減少運維對象。減少運維對象是做優化的永恆法則。以前我們敲每個命令，看條件和匹配，你敲命令越多，大腦消耗的就越多，通過這個來減少運維對象，提升效率。
實例管理沒有那麼簡單，每一個IP看起來都很爽，其實沒有這麼簡單。這裡我們有1.0、1.1、1.2、1.3這四個版本。這個在現網上確實存在的。這裡有幾個問題：
第一個問題，這種情況合不合理？
第二個問題，高版本會把低版本的特性夾帶出去引發事故。
第三個問題，運維擴容的時候懵逼，以哪個為準？你負責一兩萬的時候還能選出來嗎？拿一個記事本記下來嗎？根本不可能。
我們允許多版本存在。互聯網非常敏捷，需要快速得到用戶的數據和反饋，因此我們用了金絲雀發佈，當然還有灰度發佈和藍綠部署，因為有灰度的需求，所有必須至少有兩個版本，一個新，一個穩定版，要不然運作不起來。
第一個圖全是1.0，A開發在灰度中，B開發夾帶1.1版本的特性灰度後全量發佈。
經常做發佈的同學應該會遇到，這也是我們經常遇到的一個問題。它的原因比較簡單，但是引發的後果比較嚴重，經常有人跑過來問我怎麼辦，我們同學又把版本夾帶出去了。
我說別緊張，給你提需求，凡是灰度發IP的時候都給我發一個郵件，也告訴B同學，有版本在發了，你還沒有灰度完，還剩幾個IP，當到第四個IP的時候到哪裡，我說這沒有用，發到滿郵箱都是郵件也沒有用，我來出一個主意，就是約束。
一個集群下最多存在兩個版本。金絲雀發佈是需要的，我做一個約束，最多出現兩個版本，不需要出現第三個版本，其實就是兩個原配不允許第三者插足，當兩個原配單身的時候就可以了。
當你有1.0和1.1的時候，1.2想發佈都發布不出去，要麼把1.0全升級成1.1，要麼把1.1回滾到1.0。
除了版本夾帶的問題，還有一個是幫助運維非常方便的選擇擴容版本。其實擴容版本就是正式版本，灰度版本也是正式版本，幫助客戶決定哪個是正式版本。我們選擇比例大於50%的版本。為什麼選擇比例大於50%的版本呢？
這裡寫了一堆文字描述。其實就是大家的選擇。選新的時候，問題可能會放大，如果選舊的版本，新版本灰度很久了，你還放舊的版本，這時候用戶體驗不太好。
還有一個是人工定義，每次發佈的時候都讓權威人士或者領導審批，讓他定義哪個是正式版，這個也行，但是效率太低了，多中心團隊那麼多產品要發，怎麼做這個。如果你的產品就是一個傳統企業，審批流非常嚴格，半個月一審批，一個月另外一個審批，下下個月另外的審批，那就不存在這個問題。
發佈管理
在發佈管理上我們面臨版本迭代頻繁、回滾緊急、規模巨大、文件眾多的問題。前面講過我們怎麼做到非常快、非常輕量的應對這些挑戰。
誰來發布的問題，我們的發佈是全民發佈，產品、開發和測試，這裡誰發現需求誰來變更，這個效率是最高的。
我們有一系列辦法、約束條件去讓這些開發、產品和測試能夠很好的用我們這套發佈系統，這裡有收益和風險並存。
既然是全民發佈，那麼多人都在發，很可能是同一批目標機器，而且複雜業務上下游關聯性特別強，你發完覺得正常，但是上游不正常了，所以變更非常重要，因為需要快速捕捉有誰在那個時間點在做變更。
按照我的經驗，如果你的業務出問題了，一定有人變更，只是變更對象不一樣。比如說掉電了，可能在電力調整，如果你能把這些數據採集上來，那也很牛。如果光纖被挖斷了，變更對象是大地，你的業務也就受影響了，或者你的支撐部門、操作系統變更，總之一定要有變更。
我們這邊做了一個變更日誌，一旦出問題馬上來看，告警出現之後對應的時間點，選業務，把時間再一選，八九不離十，一定是他，抵賴也沒有用。
發佈管理中還面臨一個問題，金絲雀發佈的節奏和時間怎樣強制?
對於上述問題，現在處於半解決狀態。我們經常說為了安全一定要灰度，時間上，下班了不要發，半夜不要發，但是有時候他發了你也沒有辦法。現在要強制他，一種要制度加強，二是秋後算帳，沒有采取很強硬的手段。
我們採用了一個半強硬的手段，叫做“發佈計劃”，將來把要發佈的內容，比如你要發什麼包或者什麼版本到哪個環境下，通過這樣一個發佈計劃的制定，讓非常多的人提前得知你要幹什麼，不至於當你乾的時候發現已經晚了。
我們鼓勵使用這樣的方法，而且很多的人已經習慣了，這個不僅僅是幫你強制性的做這個，而且可以提高效率，不然那麼多IP，你哪裡知道上面發佈了哪些。
我從文件管理、進程管理、版本管理和發佈管理方面，詳細講了一下我們包管理的特點。總結一下，務虛一下：
第一，包是一種管理框架，整個包是以運維管理為目的，不需要侵入研發代碼，而且通過目錄功能的規劃，讓所有的包看起來都長得一樣。
第二，包是DevOps中連接各角色的橋樑，簡單而敏捷。
DevOps就是講多角色、多團隊合作，怎樣高效的合作，就是大家彙總到一個點上，我們包管理從06年就做了這樣一個東西，沉澱最深厚的系統就是簡單而敏捷。
第三，包是一個精細化的運維管理對象，改造門檻低。前面我也提到，運維管理對象的減少是非常非常重要的，但是減少以後，還可以通過包裡面具體的內容去了解裡面到底管理的是什麼，不至於真的聚成黑盒子一樣。
大部分公司選擇運維方案的時候覺得高大上，回去跟老闆和研發談判，決定不做。
2014年有一個2.8萬臺的業務，說要做包管理，我們協助他做，也做了一些小改造，大概百分之八九十的設備就接下來了，他們變成了包的發佈方式，現在效率非常高。
第四，能解決60%的問題。為什麼敢這麼說？到現在為止，我們資源一體化的那麼多功能和模塊，包的PV和UV都是非常高的，甩第二名非常遠的距離。就是因為對於一個管理或者運維訴求非常高精尖的人來說，一個包足以解決非常多的問題，對程序的管控非常有效果。
我這裡把包和Docker作一個簡單的對比。前面介紹過，包的發佈速度是非常快的。包可以做到千人一面，但是Docker不一樣。
我前面很少講基礎的東西，因為包主要是管業務邏輯，包括進程、發佈方法這都是業務邏輯相關的。包是業務邏輯，而Docker是物理的。Docker解決環境問題非常理想。
包管理的思考—-標準化。整個包的發展是從效率靈活往規則約束這邊發展，現在互聯網發展的大趨勢下必然往靈活上面靠。
我們現在尋找到一個平衡點，這個平衡點就是標準化的做法。比如說我們的目標、節奏、分工、強約束、多數原則、非包不發、全民發佈無審批，這些東西是我們所要達成的標準化的契約。
這裡尤其重要的一點是“達成一致”，作為運維負責人，要跟你研發的老闆以及一大堆人去做溝通，去說你的優化方案，說你的解決思路，一定要找到打動他們的點。
而我們找到的那個點是什麼？就是非常低的改造門檻，卻能帶來巨大的效率提升。對於這樣的一個東西，相信很多研發的人具備不了。
3. CMDB資源鏡像與流程自動化
複雜業務的另一個表現是架構複雜。上面這個圖和微服務架構一樣，就是一個一個微小的服務，只是沒有采用標準接口。
大家知道微服務的運維和管理非常複雜，這裡也面臨一樣的問題。前面都是對程序的管理，對服務的管理就涉及到非常多問題，程序以外有很多東西，比如說權限、配置文件、設備、資源管理、名字、文件分發、驗證服務、其他接口，所有這些東西都是一個服務正常跑起來所必須依賴的。
我們採用的傳統手段就是文檔，第一步先做什麼，第二步跑哪個命令，第三步找誰，第四步跑到哪裡之後發現出錯。我認為文檔用來傳達思路和架構比較合適，所以我們暫時拋棄了文檔的方法，用了CMDB鏡像的模式。
大家理解CMDB是管硬件的，但是我們的CMDB不只是能管硬件，還能管業務。
在物理結構之上構建了業務層，包括地域、包、配置、權限、測試用例等等，我們把所有的東西統稱為資源，每一個服務節點都需要這個資源，通過這樣的邏輯方法來進行管理。
我們CMDB鏡像的維護是一致性的，線上會上報一些配置信息，一致性的邏輯層會去配置庫拿對應的，發現不對就進行修復。
修復的邏輯以前是用現網覆蓋配置的，現在是反過來的，用配置覆蓋現網。CMDB鏡像具體落到頁面上如右圖所示。
有了資源鏡像，而且很可靠，在做一鍵擴容就非常容易了，這圖上面的23個步驟也很好理解的，看一下就可以。這23步的順序不能搞亂，如果搞亂就會出問題，這個順序是我們摸索出來的。
還想說一點，現網的20多萬臺機器那麼多服務，我們濃縮的流程上只有四套來管理的。
上圖是我們演示的結果，這裡放大了，想重點突出一下自動擴容。
想做到自動擴容，我們也做了一些邏輯，但是這個邏輯是針對非常嚴格、非常高標準的業務模塊來的。
我們會在高負載擴展，低負載縮容，根據它的標準去判斷到底有沒有達到我們自動擴容和縮容的要求，如果達到會通過負載組件、通過一定的權重調節上線還是下線、上線的節奏是什麼。
變更體檢，既然是全流程，一定要從頭到低全負責起來，不能只顧開始。變更完了之後，我們通過變更體檢發變更報告的方法，讓變更負責人和相關人收到異常的告警，如果正常就不發了，如果異常就發報告，所以變更完一定要發變更報告。
總結下，團隊在什麼思路下做這個管理，分享了我們的程序管理，模塊資源和自動化流程，整個自動化運維還包含更多的內容，如權限如何做的、配置、流程引擎、運維組織的劃分、事件管理、資源如何流轉更高效、API平臺、業務架構。管了單個服務，如何管理更大片的服務。
前幾年我經常聽到一些聲音，自己也有所擔心，說運維要失業了。現在雲計算很火爆，自動化運維很流行，又出來一個AI 運維。我覺得沒有必要擔心，我自己總結了三種受歡迎的運維，深度型、全局型和耐操型。
耐操型是一個人願意加班，願意做很多東西，在很長一段時間內，只要業務需要就可以。
全局型的可以掌管很多資源，包括 QQ 紅包 和 跨年活動，或者是高併發的突發事件和活動，一定需要全局型的人出來針對業務架構做運維方案的優化和問題的解決。
深度型的可能手裡沒有那麼多資源，但是卻非常理解運維。
比如說AI運維，什麼場景適合用AI，這種場景下要抓什麼特徵給算法去算、給機器學習，機器不會自己得知這些東西的，需要人。
希望成為受歡迎的運維，就必須解放自己，讓自己進步。謝謝大家。
說明：本文根據楊利東老師在 GOPS 2018 深圳站的演講整理而成。
GOPS 2018 深圳站騰訊運維體系沒看夠？ 還有GOPS 2018 上海站 騰訊運維雙雄專場哦，屆時，騰訊運維總監 聶鑫、騰訊織雲負責人梁定安將親臨現場，帶您暢聊騰訊運維體系的方方面面~
想一窺騰訊運維體系的全貌 ~ 請戳原文鏈接
閱讀更多 高效運維 的文章
