網易即時通訊雲平台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等多平台。
還提供了高級通訊功能，包括實時音視頻、互動直播、教學白板、專線電話、短信、專屬雲在內的獨家功能以及更多其他服務。網易雲信滿足包括游戲、協同辦公、在線醫療、在線客服、在線教育、娛樂、咨詢、生活服務、物流、旅游、金融等各行業各種產品的即時通訊服務需求。