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