“雙十一”剛剛結束，其實最緊張的不是商鋪理貨，也不是網友緊盯大促商品準備秒殺，而是網購幕後的運維人員，他們最擔心：什麼網路中斷、應用卡頓、響應速度慢，伺服器宕機……

雙十一作為電商 IT 部門的頭等大事，大促前，運維人員就需要早早地做好多套預備方案，並時刻緊繃著神經，經歷著上百次模擬演練。他們在後端有多少不眠不休的夜晚，不得而知。

看似簡單的雙十一背後牽扯到是包括支付、架構、資料庫、網路、運維、電力、客服、物流等整個商業配套基礎設施的協同和考驗。

雙十一大促這些年，運維領域邁過了哪些坑？智慧化運維初露端倪的今天，企業又該如何佈局？帶著這些疑問，Info 採訪了袋鼠雲首席運維專家林傑，他此前支援過淘寶網，天貓，共享業務，無線事業手機淘寶，聚划算等 BU 業務運維，對運維領域有著自己獨到的見解。

雙十一大促這些年  運維邁過的坑

林傑回憶：天貓雙十一大促最早開始於 2009 年，那時候還是淘寶商城，一天的 GMV 只有幾千萬，而且還沒有零點全民瘋搶的概念。在大促前工程師們基本上會根據各自的經驗判斷，比如伺服器的當前負載、應用的當前 RT 和 QPS，判斷每臺伺服器最大能支撐多少能力等，然後幾個人討論後就決策拍板，某某核心應用各自要加多少臺伺服器，到底要加多少伺服器，實際上大家的心裡沒底，實在不放心臨時再多申請擴容。總之這個階段業務量也小，也能應付過去。

後來幾年隨著天貓品牌的提升，雙十一大促逐年爆發，原來的運維方式已經無法適用。業務發展迅速，後端的應用數量也大大增加，各個應用系統之間的呼叫鏈路錯綜複雜。大促前到底要準備擴容多少資源？不能拍腦袋熱，因為你申請資源太多會可能被拒絕，申請少了你要承擔更大的風險。這時候我們是用線上壓測的方式來解決，比如可以直接在生產環境抽取 1 臺伺服器，通過模擬回放或者直接引入多倍流量做壓測，根據壓測結果計算出單臺伺服器的最大可承載能力，然後用數字來說話，去申請擴容。還有就是即使容量規劃做到位了，但在零點峰值的時候還是可能會超出預期，系統還是會擠爆。所以又引入了限流和降級，限流就是對各個應用設定一個最大閾值，超過閾值就立刻拒絕新的請求，這樣的好處就是保護應用，避免雪崩。還有就是降級，由於應用太多，在大促的期間，可以關閉部分非核心功能，保證交易主流程的能力最大化。那個階段的壓測也不是完全精確的，主要問題是壓測的侷限性，只是對某個應用做單獨壓測，但是應用之間是有依賴有關聯的，特別是一些共享服務中心，基本上被所有應用都依賴呼叫，那怎麼辦呢？後來幾年時間又研發出新的壓測工具，全鏈路壓測。這個對於容量規劃來說，是全新的思路，直接在生產環境上通過模擬複製產生大批的流量，每個環節都會被壓測到，並有相應的監控系統配套，來找出瓶頸點在哪裡，並迅速優化。而且這個過程被自動化完成。

可見，自動化運維是大勢所趨。

零點瘋搶背後的運籌帷幄

現在的電商雙十一大促活動仍舊延續零點瘋搶模式，對於應用系統保障來說，能否順利扛過前 15 分鐘，甚至是前幾分鐘，成為最核心的保障任務。林傑給出了以下幾點建議：

a. 容量規劃。 儘可能在生產環境做壓測，只有經歷過壓測，心裡才會有底。

b. 關鍵應用要支援限流。 零點全民瘋狂的流量很可能會超出預期，只有設定好限流才能保護好自身應用，否則出現雪崩式連鎖反應。

c. 對非核心功能做降級。 每次雙十一會投入大量的資源，基本會往核心交易類應用傾斜，那麼非核心功能的降級一定程度上是可接受的。

d. 應急預案。 對可能發生的異常狀況提前準備。

雙十一大促是最典型的彈性場景

彈性是雲端計算的最大優勢，而大促是最典型的彈性場景。

隨著雲端計算特別是公有云的普及，現在的運維人員基本上無需關注機房、網路、作業系統等底層設施。在不斷地演練後，如今的電商平臺早已採用彈性可擴充套件的雲端計算平臺，配合分散式資料，高效的 CDN 分發來實現負載均衡，避免在雙十一凌晨高併發狀態下崩盤。運維人員將更多精力轉移到快速上線，快速迭代，去支援業務發展。

大促活動的流量跟日常完全不在一個量級，完全可以利用雲資源的按需使用，來達到擴容的需求，而且在成本上是巨大的節省。除了擴容以外，當然還需要準備應急預案。整理出當天可能出現的異常情況，提前預演。

去年天貓雙十一開場僅僅十分鐘，世界支付紀錄被再次重新整理。支付寶公佈的資料顯示，在零點 9 分 39 秒，支付寶的支付峰值達到 12 萬筆／秒，是前年的 1.4 倍，重新整理了去年創下的峰值紀錄。在支付方式的選擇上，花唄和餘額寶成為非常受網友歡迎的支付方式，筆數佔比分別高達 29% 和 18% 。

經得起鉅額交易，玩得起光速秒殺，技術系統抗得住，收益率流動性各種穩妥……只有經得起雙十一的終極考驗的才算是真正的神器！

天弘基金基於日誌資料分析的高效運維

對於天弘基金來說，如何確保餘額寶在雙十一的流動性和收益率平穩是一大挑戰。

線上系統最常規的問題定位方式，就是日誌分析了。接下來我們以餘額寶為例，重點剖析天弘基金在日誌資料分析領域是如何突破的？

此前，天弘基金一直使用開源的 ELK 日誌方案，研發和運維人員通過 ELK 對日誌資料進行處理，使用日誌檔案進行查詢檢索。隨著應用場景的不斷深入，以及內部人員需求的不斷增加，天弘基金希望通過日誌分析來解決運維和應用相關的新問題，在這方面，選擇和袋鼠雲合作。具體包括以下幾個方面：

一、資料脫敏  

天弘基金存有大量的個人使用者資訊，日誌檔案中都會保留個人和銀行卡四要素資訊，這些資料都屬於個人隱私，原有 ELK 方案無法遮蔽這些敏感資料，不能從根本上解決問題。以往開發人員需要檢視日誌的時候，旁邊都必須跟著一個運維人員，在運維人員的監督下才可以檢視日誌。僅僅在查日誌這樣一個簡單過程中，都需要多浪費一個運維人員的時間，不僅協同工作效率低，且不能解放運維人員的監督工作。

袋鼠雲日誌資料脫敏功能，可以通過簡單的設定解決這一問題。安全管理員選擇日誌檔案中需要脫敏的欄位，以表示式匹配的方式進行轉換，系統將自動過濾轉換成脫敏後的資訊，同時，結合許可權控制功能，對無權檢視日誌原文的使用者自動遮蔽敏感資料資訊。

金融客戶對日誌中的敏感資料進行脫敏是常見需求。諸如銀行卡、身份證、手機號等等，標識使用者身份的資訊脫敏。袋鼠雲日誌除了支援這些常規資料的脫敏，還支援自定義脫敏規則。通過自定義脫敏規則，可以增量新增使用者所需的任意脫敏規則。

二、採集資源管控

天弘基金所有線上業務的伺服器資源，都必須保證 24 小時不間斷對外提供服務，並且業務和應用程式都要保證高可用。任何外部程式或第三方應用都不能影響生產環境的穩定執行，所有部署在伺服器上的程式，都不能對應用系統具有侵入性。同時，部署在伺服器上的採集程式也要經過嚴格的壓力和效能測試，確保採集程式不會對業務系統產生任何影響。

袋鼠雲日誌在產品設計之初就開始考慮如何最大程度降低日誌採集客戶端對伺服器的影響。雲日誌通過對 Agent 採集程式的資源管控，從資源限制到異常終止提供安全保障。

第一層：資源限制

袋鼠雲日誌將 Agent 的執行佔用資源進行嚴格限制，例如：CPU 佔用率不能超過 5%，記憶體佔用率不能超過 100M，頻寬佔用不能超過 500KB/s，該閾值可以通過頁面自由定製。一旦資源限制開啟，Agent 將會在該閾值允許範圍內執行。如果有日誌量暴增的情況發生時，Agent 也會自動進行資源抑制。

第二層：Agent 自刎

當發生極為特殊的狀況，導致資源限制失效，Agent 佔用資源超出設定閾值，袋鼠雲日誌的 Agent 會通過自刎機制將程序終止，充分保障業務系統的安全性。在系統穩定後，重啟並恢復 Agent，可將之前遺漏的日誌進行重新採集，保證日誌資料不丟失。

三、呼叫鏈路分析

天弘基金的業務系統採用分散式架構設計，並引入螞蟻金融雲的 Sofa 框架進行開發，Sofa 框架可以通過配置來實現日誌檔案的生成，每個系統都生成大量的呼叫鏈路日誌。這些日誌原本沒有利用價值，但通過日誌分析可以發現，基於日誌的分散式呼叫跟蹤系統，其關鍵核心在於呼叫鏈，為每個請求生成全域性唯一的 ID（Traceld），通過它將不同系統的“孤立的”呼叫資訊關聯在一起，還原出更多有價值的資訊。

如何利用這些日誌來幫助使用者進行分析是雲日誌要解決的問題，經過一段時間對 Sofa 日誌檔案的研究，袋鼠雲日誌成功將其中的呼叫鏈路進行解析，以視覺化的方式為使用者呈現各中心之間的呼叫關係，以及介面的呼叫成功失敗次數、呼叫耗時等關鍵資訊。

呼叫鏈路具體的應用場景包括以下幾個方面：

 A. 定位異常統計耗時

通過呼叫鏈路在業務異常日誌的錯誤資訊中找到 TraceID，在系統中可以看到呼叫鏈中具體的情況，在呼叫鏈上更加直觀地定位到問題，層層排查後確定問題的所在。

 B. 呼叫鏈下鑽報表

對於分散式呼叫跟蹤系統而言，不僅僅提供呼叫鏈功能，同時可以監控所有中介軟體的具體情況。因此，在形成呼叫鏈的過程中也會形成一份詳細的呼叫監控報表，與其他監控的不同之處在於：該監控報表是帶有上下鑽取功能。因為呼叫鏈可以形成各種維度的報表，不僅可以看到服務的情況，還可以檢視其呼叫服務的情況，掌握清晰的呼叫鏈資訊。

 C. 全鏈路分析

全鏈路與呼叫鏈的區別是：全鏈路是一個應用全域性的概念，而呼叫鏈是單體呼叫的過程。分析全鏈路的價值主要體現在以下幾點：

鏈路拓撲形態分析： 通過應用之間的呼叫拓撲關係，分析呼叫過程的來源和去向，識別不合理呼叫來源；

依賴梳理和容量估算： 識別易故障點 / 效能瓶頸、接口出錯率等問題；根據鏈路呼叫比例、峰值 QPS 評估容量；

研發和管理人員可以快速通過以上檢視定位故障或問題節點，並通過節點檢視詳細的介面呼叫分析與統計資料，使用者可以很方便的找出問題所在。

全鏈路分析跟蹤的最大優勢在於，所有分散式應用之間的關係都是透明的，每個交易或訂單請求在日誌分析的基礎上，都可以進行追本溯源，無需人工進行協查，有效降低運維和研發人員的排障時間成本。

智慧運維要藉助資料和演算法才能實現

運維的發展階段經歷了從標準化、工具化、自動化、到現在初露端倪的智慧化，每個階段的發展都代表了生產力和效率的大幅提升，整個趨勢是不可避免的。智慧時代的運維不是要讓運維人員失業，而是對運維效率的提高有著極大的訴求，比如如何在錯綜複雜的環境中快速定位問題、root cause、甚至是故障預測，避免發生故障，保障應用穩定性。

林傑認為：智慧運維要藉助資料 (運維資料) 和演算法才能實現。首先運維能力的發展不是直接跳到智慧運維階段的，必然經過標準化、工具化、到自動化的發展過程，只有高度完善的自動化才具備基礎能力。其次就是資料積累，需要大量的運維資料，可以是日誌資料、網路抓包資料、資料庫資料等等。還有日常運維產生標註的資料，比如出一次故障後，運維人員會記錄下過程，這個過程會反饋到系統，反過來提升運維水平。最後就是演算法，到底採用哪類演算法模型做持續優化。

天弘基金在運維部門希望通過伺服器效能日誌採集分析，實時監控應用系統基礎資源的使用情況，通過採集客戶端 Agent 收集伺服器和叢集元件的 CPU、記憶體使用率，以視覺化形式展示資源執行狀況。

而袋鼠雲智慧運維解決方案基於自研的資料庫管控、日誌分析和大資料平臺，可為天弘基金 (餘額寶) 提供整體的運維解決方案。目前一期已接入數十個核心應用，伺服器規模數百臺，日誌資料日增量達到 T 級規模，幫助其實現了日誌集中管理、日誌分析、業務全鏈路、故障定位、資料脫敏等應用場景。故障發現、定位及恢復效率大大提高，提升系統穩定性。

據悉，天弘基金雲日誌平臺專案已開始進行內部推廣，在系統正式執行期間得到了使用者認可，對使用者的具體價值體現在以下幾個方面：

• 運維人員：資料脫敏功能幫助運維人員解放人力；採集資源管控功能可以防止 Agent 程式對伺服器和應用產生影響，有效避免災難性故障發生。
• 研發人員：日誌查詢功能可方便快捷的查詢日誌檔案；呼叫鏈分析幫助研發人員快速定位故障原因和問題點，協助研發團隊優化系統程式碼並進行架構治理。
• 業務人員：監控告警功能可及時發現業務故障，最大程度上降低故障響應時間，提升使用者服務體驗。
• 管理人員：智慧運維可實時掌握服務資源執行情況，並能夠預測叢集水位，提供基礎資源擴容建議。

寫在最後：

截至 11 月 12 日零點，2017 年天貓“ 雙十一 ”交易額定格在 1682.69 億元人民幣。不斷創新高的銷售額、交易峰值、支付峰值，這些驚人數字的背後倚仗的是怎樣的技術體系？智慧化正逐漸走入 IT 行業乃至社會生活的各個方面。未來，利用大資料關聯分析與機器學習技術為運維繫統賦予人工智慧，提供從故障預防到故障定位、再到故障閉環的智慧保障能力。或許到那個時候，運維工程師也可以輕鬆玩轉雙十一，妥妥的購物買買買啦！

作者：謝然

原文來自微信公眾號：高效開發運維