網易即時通信雲平臺99.99%可靠性的運維經驗談

網易即時通信雲平臺99.99%可靠性的運維經驗談

 

轉載自：http://mp.weixin.qq.com/s?__biz=MzIzNjUxMzk2NQ==&mid=2247483968&idx=1&sn=fc9dfd261da9206271a557e113870196&chksm=e8d7fd82dfa074945c2e9fdcbc846802356c4597affe147fbb842a96a1171edff840dc08cd8f#rd

原創 2016-11-14 田浩然、周梁偉 高效開發運維
本文源自11月10日『高效開發運維』微信羣的在線分享活動總結，轉載請在文章開頭註明來自『高效開發運維』公衆號。加羣學習請關注『高效開發運維』公衆號，並點擊菜單中的「加羣學習」或直接回復「加羣」。

一句話背景介紹：網易即時通信雲平臺，即網易雲信，是網易集16年IM經驗打造的即時通信雲服務（PaaS）。




運維解決方案及最終效果

一: 怎樣作到99.99%，確保穩定性

在網易雲信，運維工程師的主要職責包括但不限於軟硬件部署、網絡管理、應用代碼維護、安全漏洞修復、容量規劃、故障處理、性能優化等。

網易雲信做爲即時通信雲平臺，核心功能保證99.99%的可靠性，也就是說一年不可用時長要小於52分鐘，爲什麼作到？歸納爲兩個方面：第一，咱們的開發團隊有很高的運維意識，在開發設計時就注重應用的可用性和擴展性；第二，咱們的運維團隊很懂開發，經過專業的運維能力幫助開發規避風險；運維和開發相互合做，打造了雲信的穩定。下面我和你們一塊兒分析下網易雲信的穩定性保障策略。

運維工程師們很相信一個神聖的定律——墨菲定律（Anything that can go wrong will go wrong）。根據墨菲定律的推論，任何一個環節都不是100%靠譜的；所以容災是必不可少的，須要把容災作到方方面面。

首先，硬件資源都是冗餘的，主要包括如下幾點：

1)    服務器：雙電源，雙網卡bonding，系統盤raid10

2)    機櫃：雙電路接入，電源容量充足

3)    交換機：接入交換機堆疊而且單個交換機網卡bonding

4)    網絡：核心路由器/核心交換機冗餘

5)    IDC：到各ISP的光纖要大於等於兩條

6)    運維人員：應用運維、系統運維、DBA全部角色一主一備。

其次，整個應用架構的容災，主要包含如下幾個層次：

1）接入層：雲信使用了ospf+Nginx作爲了前端接入集羣的負載均衡，全部Nginx機器配置統一，upstream配置裏添加了到後端服務器（大於1個）的健康檢查。

2）應用層：各集羣服務器無單點，而且保證服務器分佈在不一樣機櫃，不一樣交換機。

3）中間件：HBase自己就是分佈式系統，其餘中間件雲信也作了高可用改造。

4）數據庫：作爲架構中最核心的一環，數據庫的容災設計也是最完善的。數據庫支持主從同步，主庫掛了以後，能夠1分鐘內自動切到從庫，而且可以保證數據一致性。

最後，萬一IDC機房掛了怎麼辦？

咱們業務基建穩定，多機房多活架構，而且作到業務無感知。

作爲運維人員，如何能夠作到業務運行情況瞭如指掌？這個時候，就須要一個強大、好用的監控系統了，監控是穩定性建設的基石；網易IM雲使用網易自研的哨兵監控系統，意指向哨兵同樣迅速發現並相應異常狀態。咱們使用哨兵作了如下幾個維度的監控：

1）在監控完整性方面，自上而下作了業務監控、應用監控、基礎監控，相關監控項類型以下

如某業務指標的監控趨勢圖：

2）在監控有效性方面，經過哨兵監控系統，報警有效性達到90%以上

•    監控數據採集、數據上報有效：數據採集失敗、數據不能上報監控agent的監控採集器天天以報表形式發送到運維負責人，運維負責人進行修改

•    報警發送方式（短信、郵件等）、報警接收人有效：天天統計短信、郵件及其餘渠道的報警發送量，有異常變化（突增或者爲0）以報表通知到運維負責人修改

•    報警1分鐘內到達：對自身發送器進行監控，消息堆積時及時處理解決

3）最後是哨兵的報警收斂功能。哨兵經過增長報警重試次數，集羣報警合併等手段進行報警收斂，有效的避免了服務器數量級達到必定程度後，過多的報警會讓人麻痹，進而忽略掉了真正有效的報警。

4）然而，雖然作了以上的工做來預防故障、快速發現故障，但故障的發生仍是在所不免的，一個合適的故障處理流程可以有效的縮短故障處理時長。

網易雲信的故障處理流程：

爲了不在遇到故障時，故障處理人員手忙腳亂、相關人員配合不到位等緣由形成的故障時長加長現象，咱們會按期進行故障演練；驗證業務容災能力，監控報警是否可達，人員應急處理能力。

二：運維標準化，提高效率

下面談一下咱們產品的運維標準化之路。一個產品隨着業務的日益複雜，應用系統會變的錯綜複雜。有人會問，1我的運維10臺服務器和運維1000臺服務器，哪一個更難一些？若是監控方式、部署方式無任何規律，1我的要支撐10臺服務器就已經疲於應付；相反，若是全部的服務，都是一樣的監控方式、部署方式，那麼1我的運維1000臺服務器，也是輕鬆愉快的。因此當IM雲的服務器數量達到必定規模時，爲了提升運維效率，解決運維管理混亂的難題，咱們制定了線上運維規範，包括但不限於如下幾個方面：

1) 應用部署規範：一臺機器只部署一個應用；規範文件與目錄結構，咱們全部應用代碼都在不一樣服務器的同一目錄下，下降因爲文件數量衆多帶來的運維風險，保證生產服務環境的整潔。

2）日誌運維規範：對日誌輸出目錄、命名、格式、分割和歸檔進行了規範性約束。應用相關的日誌統一存放在當前應用目錄結構下面的logs目錄。可以方便而有效地進行應用服務的多維度監控、應用日誌分析，以及提高故障發現率。

3）代碼發佈規範：爲減小代碼上線引起的事故，提升代碼上線效率。代碼有固定的發佈窗口，發佈前必須進行發佈審覈，而且有完善且可執行的回滾方案。

4）監控和報警規範：雲信全部應用包含基礎監控和應用監控；以及雲信自身的業務指標監控。報警內容清晰明確，報警接收人有效且保證在兩人以上。

5）帳號和權限規範：系統管理員使用root權限；代碼發佈使用公共帳號權限；普通開發人員使用我的帳號權限，我的帳號權限不能在服務器上執行除家目錄以外的寫操做。

普適的運維方案和推薦工具

普通研發團隊有什麼方案和工具能幫助開發者達到大廠80%的效果？
爲了減小運維管理的成本，必定要作應用部署的隔離，有運維團隊的公司會選擇傳統的虛擬化技術（KVM，LXC）對物理機進行初始化，如今業界比較流行的是物理機上運行Docker容器對服務進行隔離；也能夠選擇直接使用雲計算公司提供的服務器資源。

服務器的帳號權限配置，軟件環境配置等配置管理可使用Puppet來管理；

代碼部署方面可使用GitLab+pipeline替代方案；

監控系統業界比較經常使用的是開源的Zabbix；

持續集成一般使用Jenkins；

自動化運維工具比較流行的是使用Ansible；

提升應用的故障容錯能力可以使用Netflix Hystrix。

以上部分工具，網易目前也一樣在使用，並且很好用；關於工具的使用方式，Google有比較成熟的文檔，你們能夠按需調研學習。

系統設計及實現須顧及後期運維

以上是雲信部分運維工做的介紹，但須要特別提一句，一個可運維、方便運維的產品，開發同窗的投入功不可沒。

1. 良好的系統架構是順利開展運維工做的前提

在作系統架構設計時須要充分考慮功能模塊的耦合性，儘可能作到業務功能的獨立解耦，下降互相之間的依賴；最差的狀況就是全部的服務功能集中在一個進程中，一個掛，所有掛，一個升級所有受影響，這種系統設計對運維工做來講就是災難；作好功能模塊的劃分和隔離，能夠下降故障的影響範圍，在升級等平常運維工做中也能夠作更好的規劃；

 2. 架構設計時將HA做爲必須知足的非功能性指標

任何一個系統都會存在故障的可能，程序猿寫的代碼即時再好也有出bug的時候，即時程序不出bug，也仍是逃不過機器宕機後者斷電斷網等各類意外狀況的發生；因此設計者須要善於找到系統中存在的單點，並解決這些單點；高可用的特性並非說要求程序必定不能掛，而是說從架構上容許故障的發生，任何一個節點的故障只能影響系統的總體處理性能，可是不會形成業務不可用；具體來講，若是是Web類的應用，可使用Nginx等反向代理工具來搭建多個後端的業務集羣，並在出口上作Keepalived等高可用的方案，對於通常的應用，設計時須要保證多實例可同時服務，多實例功能相互對等，任何一個實例的停服，其業務請求能夠被其餘實例來分擔；作好了HA架構，咱們在運維工做時才能更加從容，由於當運維報警發生時，咱們知道當前業務處理能力雖然降低了，可是整個業務並非不可用的狀態，對用戶來講不會產生直接的影響，運維人員能夠從容得恢復故障節點便可；同時良好的HA架構也有助於業務擴張時的加強系統擴展性；

3. 業務系統給運維繫統提供更加友好的接口

運維平臺的一個重要工做是從業務系統中提取到準確的指標，並針對這些指標來作線上的監控和預警；更加了解業務系統的仍是開發人員，而非運維人員，因此開發人員須要在設計功能時同時兼顧到運維的需求，充分設計哪些指標須要被暴露出來，常見的好比當前系統的TPS(每秒的處理能力)，MRT(平均響應時間），系統的能力上限等，再結合如JVM內存使用狀況，GC狀況等基礎數據，運維平臺就能作出更加合理的監控支持，有了這些監控數據以後再製定更加科學的預警，能夠在故障實際發生以前就作出預警（好比TPS達到系統容量的80%了），讓運維人員提早作出擴容等應對，而不是等到功能不可用了才報警；從技術實現上來講，業務系統向外暴露接口的方式就很是多了，好比Java程序能夠經過JMX來實現，通用的進程可使用隱藏的Http接口等方式來實現；若是運維平臺使用的是Ganglia等開源平臺，也可使用對應的客戶端Agent來向運維平臺暴露數據；

4. 規範的日誌輸出

不少開發者在實現業務系統的時候每每會忽略日誌的做用，或者只把日誌當作偶爾查查問問的工具，日誌的輸出內容每每是隻有人來讀取的非格式化內容；其實除了定位問題以外，日誌還能夠幫助咱們作更多的事情，咱們能夠設計一個程序友好的日誌格式，好比輸出JSON格式的日誌來記錄每一個業務請求的執行狀況，如請求參數，處理時間和響應碼，失敗信息等；有了規範的日誌以後，能夠經過腳本的方式將日誌中的信息提取成指標輸入到運維平臺中，能夠對業務系統當前處理的成功率，響應時間等作更加細粒度監控和報警；

5. 善於利用功能測試框架

不少公司對開發人員的代碼質量要求都很高，會要求在QA測試以前作到單元測試等工做，有些QA部門也會利用一些標準化的工具對線上流程作迴歸測試，好比Junit或者TestNG等；其實咱們也能夠充分利用這些資源來作線上的運維監控；咱們退一萬步來講，若是一個系統沒有任何運維預警，那麼若是線上發現問題的會是誰？這必定是用戶，那麼能不能有一個機器人用戶來幫咱們提早發現問題呢？這裏咱們就能夠利用功能測試的成果了，將用做線上迴歸的TestNG代碼用程序自動化的方式按期執行起來，並解析執行的結果，若是迴歸測試失敗就馬上發報警出來，這種看起來很土的方法在實際操做中。

羣友&嘉賓的問答實錄



Q：很是感謝兩位專家的分享。請問單元測試網易雲信是作到什麼程度，所有采用仍是部分採用呢？        

A：單元測試對於保證線上服務的質量是很是重要的，咱們對開發人員的要求是總體單元測試的代碼覆蓋率要達到80%以上，核心模塊的覆蓋率要100%，在每一個版本的迭代中，都須要使用單元測試對老功能作迴歸。

Q：雲信運維人員是否還會負責其餘產品？好比同時負責雲筆記、雲信等B2C產品，又負責雲筆記、雲信大數據平臺建設？

A：雲信運維人員同時也會負責其餘運維產品，好比我在負責網易雲信的同時也會負責網易七魚，個人同事在負責網易雲音樂的同時會負責網易新聞客戶端；雖然是不一樣產品，但架構大致是相同的，這個時候就體現出了運維標準化建設的重要性，不然運維成本將會很高

Q：代碼發佈頻率達到一天一次？幾天一次？仍是一天屢次？

A：網易雲信的發佈頻率是一月一次，bug修復除外；發佈次數主要看業務類型吧，好比金融類業務以穩定爲主，發佈頻率較低；電商類業務會配合較多的運營活動，發佈頻率比較高；我認爲無論什麼業務，合理發佈窗口和完善的發佈回滾流程均可以有效的下降故障的發生

Q：請問兩位老師 1.「通用的進程可使用隱藏的Http接口等方式來實現」這個怎麼理解？ 2.能簡單說說發佈過程及回滾方案是怎麼樣嗎？ 謝謝。        

A： 1. 好比你的應用是一個web類的應用，前端確定會有nginx之類的接口來控制可訪問的接口範圍，你能夠把暴露監控指標的請求路徑在nginx上作控制，對外不可見，僅對內網環境開放；這類接口對外部用戶來講就是「隱藏」的；若是不是web類的應用，能夠在進程中內置jetty等小型的web容器，來暴露一些控制和採集指標的接口； 2. 發佈的過程須要制定詳細的發佈計劃，控制涉及到的模塊範圍，作好回滾方案，這些也須要QA部門全程參與，由於QA須要針對升級的內容制定線上迴歸的用例；在升級操做時，須要作好線上業務的流量切換，對web類應用也能夠在nginx等前端代理上有意識地切斷心跳檢查，使線上流量從即將升級的目標服務器上切走，再對這個目標節點升級，這種方式能夠作到線上升級不停服的效果；

Q：raid10 /raid 5 如何進行選擇？

A：網易目前通常用raid10，選擇raid的類型主要從恢復成本、性能、經濟成本幾方面來考慮；從產品運維的角度來看，我以爲應用自己作好容災，重要數據按期備份比糾結raid的選型更重要

Q：報警指標，頻次，對象的選擇，如何把握正確的度

A：我認爲報警的完整性、有效性、及時性缺一不可，報警的頻率取決於被添加應用的重要程度，好比雲信的發消息最重要，那我認爲1分鐘發一次報警，而且爲了防止漏接，使用電話報警是頗有必要的；而對於一些後臺應用，我認爲頻率三分鐘1次，甚至更低也ok

Q：網易雲信是使用了Docker嗎？若是是的話，何時開始的，效率提高了多少？        

A：網易雲旗下的IaaS產品叫蜂巢，就是Docker類雲服務。這個服務在網易內部產品中已經獲得了很普遍的應用，雲信業務中也使用了蜂巢來承載一些業務功能；帶來的好處就是經過節點複製等方式能快速實現業務擴容，提高運維的便捷性；另外一個明顯的好處就是極大提升了硬件資源的利用率，這也是雲計算帶來的最大的好處，我想你們對此都有至關的認識了，不用細說了；至於你說的效率提高了多少，不少是表如今人力的解放上面；好比原來咱們運維人員須要花5個小時作的部署工做，如今也許半個小時就能夠搞定了；

Q：對於錯誤解決方面，可否實現簡單的自動解決模塊，儘量的減小人爲動做了？

A：網易雲信目前採用的方式是和監控系統聯動來解決，當監控採集器觸發報警表達式的時候，會調自動化工具來進行自動化處理，若是自動化處理失敗，纔會發報警出來，如刪除日誌等，具體看自動化工具是否強大

Q：貴公司在運維開發方面，是怎樣實踐的？ 好比哨兵監控系統，運維人員參與了多少？

A：我瞭解到的業界互聯網公司的監控系統最初所有都是運維人員開發的，最起碼也是運維人員參與設計的。由於監控系統最主要的使用者是運維人員，要想用的爽，仍是要本身動手的。

Q：對於傳統的系統，有cs架構和IIS 的web監控有什麼建議嗎？

A：對於cs的架構的系統，s端的監控是重點，監控的方法其實和bs的server端相似，而對於c端的監控，通常能夠經過心跳的方式來實現，在s端檢查c端心跳超時，再上報預警系統；IIS的web和其餘的web也相似，基礎的指標，如內存佔用，cpu使用率等能夠從操做系統層面來作採集和監控，而業務層的指標也可使用對外暴露接口或者暴露日誌來採集監控數據；

關於兩位嘉賓

田浩然，網易雲信運維負責人

2015年加入網易，參與網易杭研院核心產品監控方案的設計，監控有效性以及監控完整性的提升；參與網易雲容災架構設計；現做爲雲信運維負責人負責穩定性保障、成本控制、運維效率提高工做。2011年時就任阿里巴巴，負責阿里巴巴國際業務的運維工做，參與雙十一活動的運維保障；參與國際業務異地多活架構設計。


周梁偉 網易雲信首席架構師

2011年加入網易，涉獵範圍包括：通用服務器後端開發，大數據統計分析，IM系統設計開發等方面。前後參與雲存儲系統開發；通用日誌採集平臺Datastream的設計和研發；通用網站數據分析平臺；易信產品的服務器研發，易信WEB版長鏈接服務器；HBase集羣搭建和運維；目前做爲雲信系統首席架構師負責平臺的架構設計和服務器研發團隊。

網易雲信

雲信是網易公司集16年IM經驗打造的即時通信雲服務（PaaS），開發者經過集成客戶端SDK和雲端OPEN API，便可快速實現強大的IM功能，做爲PaaS服務模式的網易雲信全面支持Android、iOS、Web、PC等多平臺。

還提供了高級通信功能，包括實時音視頻、互動直播、教學白板、專線電話、短信、專屬雲在內的獨家功能以及更多其餘服務。網易雲信知足包括遊戲、協同辦公、在線醫療、在線客服、在線教育、娛樂、諮詢、生活服務、物流、旅遊、金融等各行業各類產品的即時通信服務需求。