1.背景
由于受新型冠狀病毒感染的肺炎疫情影響，釘釘流量從春節後開始出現了飛躍性增長。此次疫情流量主要來源于釘釘遠端辦公和線上教育功能，從字面來看，好像隻是釘釘的兩個業務功能，但在釘釘内部依賴子產品不下20個，主要有消息、視訊會議、直播、家校、健康打卡等業務場景。如何保障超過20個業務在如此爆發式增長下的性能和穩定性，是對釘釘背景系統、資料庫系統的一個很大挑戰。
本文将從資料庫DBA的視角來介紹我們是如何打赢這場“戰役”的，在這個過程中我們究竟遇到了哪些挑戰，我們是如何組織我們的團隊，如何思考，如何真正利用技術克服這些挑戰，最後通過這場戰役，我們又沉澱了哪些經驗及技術。
2.對資料庫系統的挑戰
資料庫是釘釘業務系統運作的強依賴，在這種類似雙11的場景下，如何規劃部署資料庫成了穩定性中最重要的一環。但是這次的戰役來得突然，并沒有很多時間準備，是以面臨了非常多的困難與挑戰，總結下來有以下3點：
（1）系統所需要的容量是多少，無法預估
以消息子產品為例，在春節前，釘釘消息日常流量峰值不到千萬，第一次容量評估，大家給2月3号定的目标是日常峰值的3倍。随着2月10号開課高峰的到來，又将2月10号的目标調整為10倍。之後又因為2月17号開學季的到來，再次将目标調整為40倍。是以總容量相比日常峰值翻了40倍！
（2）時間緊，擴容需求衆多，資源不足
疫情流量的猛增，給系統帶來的沖擊不亞于每年的雙11。電商會花半年時間準備雙11，但這次留給我們的時間隻能以小時來計。另一方面，釘釘出于成本的考慮，資源池中基本沒有空餘的機器，現有的資源部署密度也比較高，如何騰挪資源在較短的時間内為釘釘接近20個核心叢集進行擴容是一個很大的問題。
（3）極限場景下如何保障系統穩定性與使用者體驗
在各種因素制約導緻叢集無法擴容且系統達已經達到瓶頸時我們能怎麼辦？有哪些應急手段能用？是否存在一個平衡點，将對使用者的影響降到最低？
3.應對措施
3.1人員合理化安排
（1）資料庫團隊成立疫情期間釘釘業務保障小組
小組成員包含了資料庫團隊DBA/資料庫核心/CORONA/TDDL/DTS/精衛/NOSQL各産品線同學。根據釘釘業務線進行分工，每個DBA跟進一個業務線，參與高峰期的保障，及時播報線上系統狀況與水位，讓重保決策人員及時了解系統的狀況。對線上出現的問題緊急處理，保證問題在短時間内得到修複。對不合理的業務場景進行優化，保證已知問題隻出現一次。參與系統的壓測，發現潛在風險點及時修正，對系統容量不夠的系統進行及時擴容，在資源滿足的情況下讓資料庫在高峰來臨之前已經具備足夠的容量。
（2）資料庫團隊與釘釘穩定性團隊緊密合作
由于前期資源有限，需要擴容的系統衆多，此時釘釘穩定性團隊主動站出來幫DBA分擔了大量的的壓力。他們将資料庫的擴容需求根據業務的重要性進行優先級劃分，統一擴容需求，DBA根據優先級順序，結合業務的目标容量進行判斷，在有限的資源下有條不紊地進行擴容，保證資源優先用在刀刃上，大大提升了擴容效率。
3.2資源緊急協調
疫情突然爆發，所有人都預期流量會增長，但漲多少很難預估，必須要早作準備。為了保證資源不會成為系統擴容的阻力，DBA和雲資源團隊進行合理規劃，短期内通過借用集團上雲的機器，同時縮容其他BU資料庫叢集，湊出400台左右的機器，保證高優先級系統的擴容需求。同時協調雲資源進行搬遷，在短短幾天内搬遷了300多台機器到釘釘資源池，保證了釘釘所有資料庫的擴容需求。
資源到位後就是檢驗資料庫彈性的時候了，依托于PolarDB-X三節點分布式的部署架構，我們可以較為友善地對原有叢集進行線上更新和擴容，對使用者影響很低，并且保證資料的一緻性。有些場景使用者需要從原有叢集将資料遷移到分庫分表更多的新叢集，我們利用DTS搭配成熟的管控平台也能較為流暢地完成。最終可以做到隻要有資源，資料庫也能具有極緻的彈性，滿足業務需求。
3.3應急與優化
在系統高峰來臨之前，資料庫團隊内部已經準備好緊急預案：
- 參數降級，調整資料庫參數充分發揮資料庫能力，提高吞吐
- 資源降級，調整資源限制，CPU隔離放開及資料庫BP大小緊急上調
- 針對異常SQL，确認影響後緊急限流，或者通過SQL Execute Plan Profile進行緊急幹預
- 全叢集流量備庫分流，依據壓力情況最大可100%讀流量切換到備庫
- 準備資料庫弱一緻腳本，在必要時進一步提高資料庫吞吐
同時結合業務的限流/降級預案保證了很多資料庫系統在未知高峰流量到來時的穩定運作。
但業務限流降低了很多使用者的體驗，之前業務限流值設定為30QPM/群，表示為每個群在一分鐘之内隻能發送30條消息，很多時候在1分種的前20s甚至更短時間就已經發出30條消息，在剩下40s以上的時間内使用者的體驗就是無法使用釘釘。針對這種情況DBA建議減小限流視窗，将限流值30QPM改成30/20S，限流降低了97%，大大改善了使用者的體驗。
3.4 DB容量預估及性能分析
業務上往往通過叢集的CPU情況即可大概分析出系統的水位，但是對DB而言不僅是CPU，IO、網絡、SQL、鎖等等，任何一個元件的瓶頸往往都會成為最終容量的瓶頸。不同的業務模型，往往瓶頸不一樣，即使都是查詢量較大的業務，有些可能是CPU的瓶頸，有些可能是記憶體命中率不夠導緻的瓶頸，有些則是索引設計不合理導緻的瓶頸。更複雜的部分在于，有些瓶頸往往不是線性的，可能壓力提升2倍還沒什麼問題，硬體能力都還有富餘，但是提升到3倍就直接崩潰。在這種場景下我們如何比較準确地評估DB的容量呢？
以往我們都是通過經驗并和業務方一起進行全鍊路壓測進行DB容量（叢集能支撐多少讀寫）的預估，這種方式有以下幾個問題：（1）壓測資料集和資料庫總量相比往往比較小，DB命中率基本100%，這對于分析有IO的業務模型存在較大誤差；（2）成本較大，需要打通上下遊整個鍊路，需較多的人員參與，即使進行全鍊路壓測，真正壓到DB端的往往也隻是核心的幾個接口，無法100%覆寫線上所有的接口，而很多慢SQL往往都來自這些易忽略的接口。
解決這個痛點問題的方法很容易想到——隻要把線上的業務流量全部采集下來回放一遍即可，但實作起來是非常複雜的。我們真正需要的其實是針對DB的一種通用的單鍊路壓測能力，并不依賴上遊業務，DB層可以自己進行流量的生成、放大或縮小，甚至具備将事務比例更改後再次壓測的能力。從2019年開始，在DBA和達摩院資料庫實驗室科學家們共同的努力下，我們開發了ClouDBench實作了上述的需求，并在此次的戰役中幫助DBA進行容量的評估。效果如下圖所示：
圖1：ClouDBench容量評估效果展示
藍色是真實業務在某個時刻的性能曲線，綠色是我們采集DB端流量回放出來的性能曲線，可以看出兩條曲線在時序上高度拟合，特别是InnoDB内部的名額都非常接近，包括流量的波動。
當我們能夠比較真實地回放出業務的workload，我們即可以對壓力進行放大，以此來分析DB的容量，并分析出極限場景下的性能瓶頸，進而進行DB的優化及驗證優化效果。ClouDBench目前已經在公共雲資料庫自治服務Database Autonomy Service（DAS）中灰階上線。
4.成果及思考
短短兩周内各資料庫系統具備了數倍到40倍以上的能力，其中不乏超大型資料庫叢集，存儲空間超過1PB，所有這些都充分證明了阿裡雲資料庫的彈性能力。此次疫情帶來的爆發式流量對我們來說是毫無防備的，經曆過此役，經驗總結下來有以下幾點：
4.1人員組織
首先在人員組織上，業務和開發要對突發流量具備敏銳的嗅覺，及時發現提早準備，由業務方穩定性負責人成立應急小組，梳理依賴業務以及對應背景系統，将各業務線owner和背景資料庫産品owner納入應急小組。由應急小組統一容量規劃、人力配備以及資源協調，實作業務方、背景産品團隊、資源團隊關聯。
4.2技術架構
在技術架構上，一方面是要使用具有足夠彈性的資料庫産品，保證使用的資料庫産品有自由擴容和縮容的能力，既要保證流量增大後能擴容，也要保證日常流量時可以縮容。管控等各個運維元件需要在實作自動化運維的同時，對于很多關鍵操作留有應急開關，確定在一些極端場景下，可以較友善地從自動駕駛切換成手動模式，確定任務平穩高效地運作下去。
4.3應急手段
在面對系統瓶勁時，在業務上和資料庫産品上都要提前做好預案。在業務上要有降級和限流功能，在系統無法承受壓力時，可以降級一部分非核心功能，限制一些次核心功能來保核心業務的正常運作。在資料庫産品上需要具有在不擴容的情況下，通過一些優化手段瞬間提升資料庫吞吐的能力，更重要的是這些能力需要有較好的相容性，在不同的部署環境、不同的DB架構下都具有相應的工具和預案。
另一方面，我們需要有評估和檢測預案效果的手段，我們現在可以利用ClouDBench對DB進行容量的分析和預測，但是目前的使用成本還是過高，後續ClouDBench需要更加自動化，降低使用成本，将能力透傳給業務的owner，在大促之前，自動進行大量的DB單鍊路壓測，評估系統水位，發現性能瓶頸，優化DB參數，驗證預案效果。
作者：章左中
阿裡雲智能資料庫産品團隊運維專家
阿裡巴巴運維專家，從事資料庫領域十年以上，先後在甲骨文（中國）、網易等公司任職，在傳統行業和網際網路行業都有着豐富的經驗。目前在阿裡雲資料庫事業部從事專家服務相關工作，擅長資料庫優化、架構設計及異構資料庫之間的遷移等。
作者：陳榮耀
曾就職于烽火通信任職Oracle DBA，2015年加入阿裡，現任阿裡雲資料庫運維專家，有豐富的Oracle、MySQL運維開發經驗，擅長資料庫故障診斷、性能調優、穩定性建設。目前主要負責資料庫性能壓測、流量回放（ClouuDBench ）等。
我們是阿裡雲智能全球技術服務-SRE團隊，我們緻力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基于雲建構更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運作更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿裡雲SRE技術學院釘釘圈子，和更多雲上人交流關于雲平台的那些事。
