[[160040]]

主要討論人員

　　◆提問： 智錦

　　◆回答： 梁定安(大梁)

　　嘉賓介紹

　　梁定安

　　10年運營開發、海量運維和架構規劃經驗，任騰訊社交平臺運維團隊、綜合運維團隊leader，主要負責Qzone、相冊、音樂等社交平臺類業務的運營開發和運維規劃工作，精通海量服務的架構設計和自動化運維建設，目前專注于devops、APM、大數據的運維實踐探索。infoq高級運維講師，騰訊云布道師。

　　引言

　　「坐而論道」是高效運維社區獨創的一種技術交流形式，由技術高手之間互相提問并進行解答，每周討論一個話題，由其中一位發起提問并指定下一位進行解答，解答完的人繼續提出新的問題并指定下一位回答者，以此類推。

　　精彩回答

　　◆運維面對最困難的問題，我們統稱歷史遺留問題。如無標準化包管理、配置有硬IP、監控點覆蓋不全等。

　　◆織云解決了運維持續部署的難題，實現服務的快速自動上下線，基本上滿足了80%運維效率的訴求，目前我們主要做的還是在不斷的打磨讓系統用的更順，標準化流程的適用面更廣。

　　◆但整個織云體系的對外開放，目前的計劃是有所限制的，暫時只會對騰訊系的企業輸出。

　　◆QQ和微信，分屬騰訊的SNG和WXG，這兩款產品都算得上是國內IM的巨頭，在IM的運維場景下，有著相同的運維挑戰。

　　Q1 :QQ產品線和歷史如此悠久，歷史上的遺留問題和遺留工具一定很多，作為用運維人員，如何去解決歷史遺留問題；作為運維開發人員，如何吸納歷史上的工具系統，降低重構的代價。這方面有沒有經驗和案列可以分享。

　　答：這個問題真的說到運維的痛點上了，運維面對最困難的問題，我們統稱歷史遺留問題。我們面對的歷史遺留問題也挺多的，如無標準化包管理、配置有硬IP、監控點覆蓋不全等。

　　所幸我們從09年就開始著手進行運維的標準化統一，得益于和開發、測試團隊的良好合作關系(6年前就可以說開發、測試、運維間就已經萌芽了devops的文化)，運維推動的包管理系統、配置管理系統、cmdb、質量監控規范都被很好的貫徹落地了。

　　我舉個簡單例子：

　　09年時，我們為了推包管理規范，就一度要求研發如果上線了非標準化的包，就必須要來運維團隊做1周的打包苦力。通過這樣的舉措，我們將一個個歷史遺留問題的山頭攻克，現在我們內部的織云自動化平臺，也是整合了運維團隊一直以來的建設成果功，利用流程引擎整合而成的自動化系統，讓我們的運維效率得以提高。

　　現在游離在運維標準化體系外的業務還是有的，原因很多，有并購的公司、有組織架構調整引入的老架構等等，對這部分的管理，只要還要增長的服務，運維都會提出可運維規范要求，如打包、接入織云，如穩定期，不需要繼續增長的服務，我們就不求自動化運維效率多高，只要求有路由的自動容錯，保障服務的質量，維持現狀即可。

　　Q2 :作為QQ這樣成熟的產品，“織云”未來的技術上的發展規劃是怎么樣的，還會不會有一些新的設計思路。

　　答： 織云解決了運維持續部署的難題，實現服務的快速自動上下線，基本上滿足了80%運維效率的訴求，目前我們主要做的還是在不斷的打磨讓系統用的更順，標準化流程的適用面更廣。提到新的設計思路，根據SNG的業務場景和不同時期運維關注點的不同，我們針對服務調度、跨IDC搬遷、SET復制、成本管控的場景，都有開發相應的工具，但這一切都是基于自動上線這個核心功能的。

　　Q3 :織云和藍鯨都是騰訊系的比較成功的運維產品，而藍鯨已經從服務內部開始走向服務外部游戲客戶了，織云有沒有類似的走出去的規劃?

　　答：走出去的案例是有的，如織云的核心模塊包管理系統，簡化版tars已經在騰訊云的應用市場對外開放，大家可以在騰訊云上搜下。在一些騰訊系的企業，如webank、富途、滴滴，都有或多或少的使用織云的一些模塊。

　　但是整個織云體系的對外開放，目前的計劃是有所限制的，暫時只會對騰訊系的企業輸出，原因有二：

　　1.在騰訊適用的海量運維平臺，對小企業未必適用，可能只需要其中的個別模塊就已經足夠；

　　2.我們團隊的職能還是要聚焦在騰訊內部支持，在釋放運維效率后，我們還有很多智能監控、運維大數據、APM等方向要繼續鉆研。

　　Q4 :QQ的運維，和微信的運維，你覺得有差異或者不同的挑戰嗎?

　　答： QQ和微信，分屬騰訊的SNG和WXG，這兩款產品都算得上是國內IM的巨頭，在IM的運維場景下，有著相同的運維挑戰。

　　不同點，我列3點我的個人理解：

　　◆國際化的挑戰，微信用戶國際化程度很高，QQ用戶相對集中在國內；

　　◆微信的增值功能相對少，QQ屬于一個大平臺，很多應用基于QQ生長，這也是運維的區別之一；

　　◆PC端的管理，微信和QQ的主要差異，QQ正在PC端繼續發力突破，如在線教育等領域，這些是微信沒有的。

　　Q5 :從QQ的運維出發，在“容量管理”和“故障的根源分析和自動處置”這個兩個運維的難點來看，分享一下你的經驗。

　　答： 監控相關的問題，涉及的背景比較大，我盡量簡單的說：

　　1.容量管理，運維基于容量管理，對成本管控、業務趨勢預測、調度決策等做了很多自動化和分析的事情。首先在成本管控方向，基于容量對不同業務的平均負載、單機QPS、容量一致性等緯度進行分析，驅動運維和開發針對性的優化，2014年給騰訊節省了3億運營成本。

　　業務趨勢預測、調度決策，其實說白了就是基于容量對單個模塊做快速上下線的運維操作，對SET服務做調度或柔性決策參考。

　　2.故障的根源分析和自動處理，先說自動處理，對于基礎告警(死機、進程/端口掛、硬盤滿/只讀)我們是有自愈策略的，主要是基于我們的標準化運維體系，包括：包管理、設備響應級別、自定義處理邏輯等基礎實現的。織云的流程系統，也支持類似“藍鯨”的自定義告警處理邏輯，以應對不同場景的需求，但是SNG內部標準化程度很高，基本上一套自愈策略就能cover絕大多數的業務。

　　3.故障根源分析，我們內容有個ROOT項目(2015年7月的AS大會上有分享過《騰訊端到端運維監控體系》)，原理是基于業務的訪問拓撲，在單位時間片內把各個監控系統的告警信息疊加在鏈路上的各個模塊中，通過算法計算出最有可能的告警點，從而從眾多的現象告警和原因告警中，篩選出原因告警，從而實現故障的根源分析。

　　還有一個《智子》的apm項目，主要是針對移動APP運維的場景，類似聽云和oneapm的方案，在app的每個方法中都注入我們的耗時計算邏輯，實現移動端的卡慢、異常分析，是代碼級的監控系統。

如何一起愉快地發展

“高效運維”公眾號（如下二維碼）值得您的關注，作為高效運維系列微信群的唯一官方公眾號，每周發表多篇誠意滿滿的原創好文：來自于系列群的討論精華、運維講壇線上精彩分享及群友原創。“高效運維”也是互聯網專欄《高效運維最佳實踐》及運維2.0官方公眾號。

提示：目前高效運維新群已經建立，歡迎加入。您可添加蕭田國個人微信號xiaotianguo8 為好友，進行申請，請備注“申請入群”。

重要提示：除非事先獲得授權，請在本公眾號發布2天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行。