[[160040]]

主要討論人員

　　◆提問： 智錦

　　◆回答： 梁定安(大梁)

　　嘉賓介紹

　　梁定安

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

　　引言

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

　　精彩回答

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

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

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

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

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

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

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

　　我舉個簡單例子：

　　09年時，我們?yōu)榱送瓢芾硪?guī)范，就一度要求研發(fā)如果上線了非標準化的包，就必須要來運維團隊做1周的打包苦力。通過這樣的舉措，我們將一個個歷史遺留問題的山頭攻克，現(xiàn)在我們內(nèi)部的織云自動化平臺，也是整合了運維團隊一直以來的建設成果功，利用流程引擎整合而成的自動化系統(tǒng)，讓我們的運維效率得以提高。

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

　　Q2 :作為QQ這樣成熟的產(chǎn)品，“織云”未來的技術(shù)上的發(fā)展規(guī)劃是怎么樣的，還會不會有一些新的設計思路。

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

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

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

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

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

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

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

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

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

　　◆國際化的挑戰(zhàn)，微信用戶國際化程度很高，QQ用戶相對集中在國內(nèi)；

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

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

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

　　答： 監(jiān)控相關(guān)的問題，涉及的背景比較大，我盡量簡單的說：

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

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

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

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

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

如何一起愉快地發(fā)展

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

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

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