> 作者 劉宇 發布于 2014年9月24日
SNG是騰訊體量最大、產品線最豐富的一個事業群，其覆蓋了QQ、手機QQ、騰訊開放平臺、騰訊云平臺、廣點通、移動分發平臺應用寶在內的多條業務線。可見SNG的運維體系的龐大，早在2013年QCon北京大會上，騰訊業務運維T4專家、總監趙建春就在QCon分享過[《海量SNS](http://www.infoq.com/cn/presentations/huge-amounts-sns-website-efficient-operations)[社區網站高效運維探索》](http://www.infoq.com/cn/presentations/huge-amounts-sns-website-efficient-operations)，當時引起了運維界的廣泛關注；而整個SNG的運維又是如何運作的呢？
梁定安，2009年加入騰訊運營部，先后從事系統運維、業務運維、運維規劃和運營開發的工作，目前是社交平臺業務運維組Leader，可以說是整個SNG云平臺的締造者，也是今年[QCon](http://2014.qconshanghai.com/user/703)[上海2014](http://2014.qconshanghai.com/user/703)大會自動化運維的講師，屆時將分享《騰訊SNG織云自動化運維體系》的話題。
為什么會有織云？織云重點解決什么樣的問題？面對錯綜復雜的業務，織云又是如何自尋突變的呢？梁定安會全面介紹這個平臺的特性、底層技術組成、以及給SNG所帶來的價值。
_InfoQ_：梁定安你好，織云是什么時候開始做的？
> 梁定安：2012 年底 CTOTony 將云化戰略推廣到公司內部各個 BG ，織云正是在公司云戰略的背景下，為 SNG 量身定做的內部云管理平臺，定位是為 SNG 自研業務提供虛擬化管理和自動化運維的平臺，幾乎所有 SNG 的業務（ Qzone 、 QQ 秀、 QQ 相冊、 QQ 音樂、 QQ 等等）的運維操作都基于織云平臺完成。
_InfoQ_：織云定位為內部的自動化運維平臺，那么它具備那些特征呢？
> 梁定安：織云平臺定義了 SNG 業務的標準化運營規范，在平臺中運維人員抽象出上層的管理節點，減少與統一運維對象，降低海量運維的復雜度，得益于運營環境的標準化建設，有更多通用的自動化工具被設計開發，配合流程引擎的驅動，使我們逐步邁入自動化的運維階段。平臺最大的特色是“一鍵上云”幫助 SNG 自研業務快速實現織云最初的上云目標；而“自動調度”則實現標準化服務的容量自動維護；還有我們基于內核 inotify 的一致性監控，保證了配置資源與現網資源的一致性。此外，織云的核心模塊還有：資源管理，包管理，配置管理，自動流程，中心文件源，權限中心，都是自動化運維必不可缺的重要功能模塊之一。
_InfoQ_：“一鍵上云”實現沒有那么容易吧？非標準化業務應該是很難接入，在實現這一目標時，你們又遇到那些難題？
> 梁定安：困難是必然存在的，我們第一個遇到的難題是虛擬化選型和適配改造，在 XEN 和 LXC 之間，我們選擇更輕量成本更低的 LXC 作為織云平臺的虛擬機，在運營過程中，由于虛擬機與實體機管理模式的差異，我們沒少踩坑。如同母機下子機對 CPU 、網卡流量搶占造成相互影響，子機多 crontab 集中調度，常用系統命令只顯示母機狀態， LXC 內網 NAT 管理改變原運維習慣等等問題，都被一一啃下， LXC 順利本土化成功。
> 第二個難題是運維標準化的普及，像 QQ 秀、會員這類騰訊比較早期的業務，在當時沒有標準化規范的背景下，現網的運維管理有諸多阻礙順利上云的問題點，如程序混布、 hardcodeIP 地址、依賴非標準庫等等，在接入織云前都要經過運維和開發的適配改造。為了順利推動讓業務開發配合運維做上云的改造，我們設計了織云的“自動調度”、“一致性監控”、“權限中心”等核心功能，讓開發改造的工作量有了充足的利好回報，讓舊業務標準化的改造如期完成。我們樂觀的看到織云平臺使 SNG 運維從 D/O 分離轉型為 DevOps 模式。在織云平臺中，沒有運維和開發的嚴格區分，平臺的用戶會在既定的標準管理框架中，對統一管理對象——模塊，進行錄入或變更資源配置（包、配置文件、權限、目錄、腳本），流程引擎則會按照既定的次序和調用不同的自動工具，完成用戶的一鍵上云或其他變更需求，而這一切都會在織云的標準化體系保障中自動化的實現。
> 一鍵上云的成功，得益于 SNG 自研業務的標準化運維管理的良好基礎，我們所有程序的包管理（ pkg 包系統）、配置文件 svn 管理（ CC 系統）、目錄管理（中心文件源）、權限管理（標準 api ）、名字服務（ L5 ）的高覆蓋率，都可以經過輕量的改造即可成為織云平臺的功能之一。再輔以流程引擎，將上云的步驟串成自動化的流程。用戶只需在織云平臺上管理好模塊與依賴資源的關系，織云便可以一鍵式的完成整個遷云的過程。
_InfoQ_：織云的自動調度是實現業務動態擴縮容？你們又是如何控制“雪崩”的？面對業務的大量突發，是全自動，還是人工干預？
> 梁定安：是的，我們認為當一個模塊可以靈活的實現擴容自動化時，它便具備了跨 IDC/ 城市遷移的調度能力。同理，我們對運維的業務按核心功能的不同分別抽象成不同類型的 SET/ 服務視圖（包含多個模塊），當整個 SET 的標準化程度且 SET 內的模塊都具備自動調度的基礎能力時，我們便可以對整個 SET 進行調度操，目前 Qzone 、說說、廣點通等重點業務的 SET 已經具備快速調度能力。
> 雪崩的預防是負載均衡管理中必須解決的一個問題，在 SNG 我們擁有一款十分出色的負載均衡 + 容錯組件 L5 ， L5 利用名字服務將一個集群標識成一個 L5ID ，主調方可以通過嵌入 L5api 并調用 getroute 來獲取被調 L5ID 中的每個 IP ： port ，然后當請求結束后 updateroute 來更新該 L5ID 的每個 IP:port 的成功與延時信息， L5 組件便可以通過全局數據的整合，在下個調用時間片動態的為 L5ID 下的每個 IP 分配合適的請求量，利用這個原理， L5 根據實際每個被調 IP:port 的請求量、成功率和延時的波動數據，可以計算出每個 IP ： port 最大可支持的請求量，當遇到業務請求量陡增的場景， L5 會啟動過載保護，在保證被調方飽和的請求量前提下，對新到的請求全部拒絕服務，以防止雪崩的發生。這些都是由 L5 組件全自動實現的。
> 織云的自動調度原理是對服務 / 模塊的容量指標（ CPU/ 流量）進行監控，當觸發擴容閥值時，織云后臺便自動觸發部署、測試、灰度、上線這一系列的全自動流程，保證線上服務容量的可用，除非耗盡可用設備 buff ，否則織云的自動調度功能輔以 L5 的優秀容錯能力，可保持業務容量處于高可用的水平。
_InfoQ_：一致性應該是多個方面的，包括上面有提到一致性監控，還有織云的另一大特色服務一致性管理，這里的關系與具體包含的內容都有那些？
> 梁定安：先介紹下一致性本身，這是一套 C/S 的監控程序， C 利用內核 inotify 訂閱監控的對象，并通過動態上報的架構，在一個集群內選取一個 leader 匯總數據后，傳輸到 S 進行數據落地，實測性能可達監控 1000 個文件秒級感知，是我們實現織云前臺實時監控現網環境的核心手段。
> 回到一致性管理，視乎場景的不同，具體可以分為兩大類：資源的一致性和服務的一致性。資源的一致性，比較容易理解，織云自動調度中依賴的資源，包括：包（進程、版本、運行狀態）、配置文件（ md5 ）、目錄（ md5 ）、權限、后置腳本（ md5 ）。通過一致性的管理，使織云能夠在無人職守的前提下，自動的變更運營環境。服務的一致性則與 SNG 業務的形態耦合比較重，如 Qzone 的多地容災分布，每地的服務彼此一致，主要也是利用一致性的監控管理，服務一致性管理的會比資源一致性管理緯度要粗，往往只包含多個模塊的包、通用目錄、權限這 3 類。
_InfoQ_：織云的核心模塊有：資源管理，包管理，配置管理，自動流程，一致性監控，中心文件源。對于開發團隊而言，在織云做這些操作，和不使用織云有什么區別？大體的操作流程是什么樣子的？
> 梁定安：織云提供給開發和運維團隊的是工作效率的提升，讓我逐一為大家介紹這些核心模塊的功能。
> 資源管理，我們對現網操作的最小管理對象——模塊，部署上線所依賴的所有資源，和操作這些資源的先后次序，都將錄入到織云的資源配置，并存入模塊的 CMDB 配置管理數據庫，成為該模塊必不可少的屬性之一，結合自動流程可實現多種自動化的操作。原則上模塊的資源配置只能由少數模塊負責人修改，并且當資源發生變更時，織云提供鎖表的能力，防止交叉篡改。沒有織云的資源管理，運維 / 開發只能依賴 wiki 、文檔等古老的方式記錄，并且無法自動化。包管理，是 SNG 一個最基礎的系統，運維要求每個上線運營的程序，都必須按照 SNG 包管理規范打包，包管理本身提供了一套完整的框架，包括：進程名字與端口管理，啟停方式統一管理，標準化的目錄結構，完善的進程監控體系，靈活升級回滾的 svn 管理等等。包管理是一切標準化的基礎，離開它，運營環境將一片狼藉。
> 配置管理，指的是配置文件管理，包括線上編輯、版本迭代、 diff 、前后置腳本、批量下發 / 回滾等等功能，是單文件管理的利器。沒有它的話，就只能回到腳本發布時代了。
> 自動流程，指的是織云的流程引擎，主要功能是將不同的標準化工具串聯起來，前者的輸出可作為后續工具輸入用途，支持流程分支匯總的能力，可通過串聯不同的工具，拼裝出不同的自動化流程，實現無人職守的各種操作。這就是人肉和自動化的差別。
> 一致性監控，主要就是秒級感知現網變化的能力。有了它，開發再也不會提讓運維批量查一批 IP 的配置是否一致的需求了。
> 中心文件源，主要是為目錄管理誕生的一套 svn 管理的系統，可根據策略不同，自動與現網同步或被同步，且支持大批量的分發能力。沒有它，大伙還是只能靠腳本來進行目錄類的發布管理，效率低下。
_InfoQ_：在織云上的業務部署監控、日志收集是如何實現的？而運維“織云”這個平臺運維工程師又是如何保證平臺的穩定性？
> 梁定安：托管于織云上的業務使用的是 SNG 內部統一的上報通道，將監控數據和日志上報到監控平臺的 storm 集群中，監控數據處理集群利用 mongoDB 、 rabbitMQ 和 Infobright 對大量的流數據進行處理，最終產生監控告警或報表。織云負責提升運維效率，統一監控平臺則負責提供監控告警管理。
> 織云平臺本身的可用性，也是嚴格按照 SNG 可運營規范要求設計的。值得一提的是，織云為了保證具備自動調度能力的模塊在關鍵時刻的可用性，我們特別設計了演習功能，每天都隨機抽取演習，隨時檢驗平臺核心能力的可靠。
_InfoQ_：大部人都認為運維不如研發，作為一名運維工程師，你是如何看待這兩者之間的關系的？
> 梁定安：干一行愛一行，既然選擇了運維崗位，我認為就應該熱愛運維工作并努力在這個崗位上做到卓越，否則就是對個人對工作的不負責。
> 談談運維和研發的區別，任何一款互聯網產品，當具備一定的運營規模時，必然會有開發和運維的明確分工。開發專注于產品功能的實現，運維則會從質量、監控、容災、成本、安全等緯度去支持產品的發展。
> 認為運維不如研發的看法，往往都是看到了處于初級階段的運維。我認為優秀的運維團隊，和開發團隊之間是互惠互利、缺一不可的。以 SNG 社交平臺業務運維團隊舉例，我們會根據業務的規模，提出很多優化建議，如優化 Qzone 的分布架構，制定跨地域、機房的容災策略，對核心服務抽象成 SET 化管理，建設 SET 調度的智能決策和執行系統；降低業務的運營成本，引入更廉價的運營方案，根據不同的場景，提出用 SSD 硬盤存儲替換內存存儲，用虛擬化解決長尾服務的成本壓力，或者利用 buff 設備提供離線計算能力；我們還建立了大數據分析系統，為移動業務提供運維 SDK ，利用機器學習能力建立外網用戶反饋智能分析告警的平臺；為了讓運維和研發能夠更及時的查閱業務運營狀態，我們還開發了手機側的運維工具 MSNG ，提供了關鍵服務的核心指標展示和通用的告警處理工具；為了解決告警量大的問題，我們研發了告警預處理系統，告警根源分析系統等等，這些都是運維團隊為產品和研發團隊輸送的超越運維范疇的價值。
> 也許運維這個崗位不常會在鎂光燈下，成為耀眼的明星團隊，但是目前運維團隊的價值遠未被發掘完，我們仍在積極探索未來可以觸及的新方向。
查看原文：[梁定安：解密騰訊SNG](http://www.infoq.com/cn/news/2014/09/tencent-sng-cms)[云運維平臺“織云”](http://www.infoq.com/cn/news/2014/09/tencent-sng-cms)
