電商平臺年度最大的購物促銷活動雙11即將開打，去年的雙11活動京東單日創下人民幣111億元的營業額，能夠撐起龐大的交易流量而保持服務穩定不中斷，並非偶然，而是需要靠平時分散維運的工作，不僅如此，京東還定期演練服務中斷的應變工作。
京東一年度會有兩次大型的促銷活動，年中的618和雙11活動開跑時，用戶會非常集中在單日產生爆量的流量，平臺的I/O流量會暴增，若是支付服務停擺1分鐘，就會造成業務非常大的損失，且業務繁忙時，每個工程師都會非常緊張，當下才要找問題試圖去解決，會需要花費很多時間。
「穩中求進是我們維運的原則，」京東內部多達3萬個伺服器，超過2,000個資料庫，光是為運團隊就超過180人，京東金融MySQL維運資深資料庫管理員潘娟表示，由於交易平臺涉及支付且提供24小時不中斷的服務，京東對資料庫穩定性和一致性的要求特別高，京東相信預防勝於治療，因此，將維運的基本功分散到日常的工作，將交易平臺服務出狀況的風險降到最低。
為了能夠打造出高達99.99%的高可用率的系統穩定性，將許多維運的工作，像是業務的評測、監控與預警、壓力測試與服務中斷預演，以及相關的業務演練等都分散在平時日常的工作來進行，潘娟認為，等到出現問題後，才開始找原因和試圖解決問題，需要花費的力氣遠超過平時維運工作所付出的代價。
新服務上線流程標準化，自動部署不出錯
公司內部的研發或是業務團隊，若有新的服務或是應用要上線，則需要申請伺服器和資料庫，京東的規矩是，業務申請人必須填寫一張應用服務的記錄表格，包含應用需要的資料庫容量、業務增長量、I/O流量等資訊，資料庫管理人員根據記錄表的資訊，會對該服務的規模有初步的了解，接著再與線上正在執行的應用比對，評估新服務所需的伺服器規格和資料庫架構。
潘娟舉例，若新上線的應用規模較小，停機半天也都不會對公司營運有太大影響的應用，像是後臺的管理系統，則資料庫管理員會選擇最簡單的架構HDB，可以實現單機多應用，若是非常重要的業務，I/O流量也有一定的要求，就會選擇MHA（Master HA）的架構，來確保高可用性，MHA如果監控到Master節點異常，將會把Slave轉換成Master，而若是業務量非常大的應用，京東則是另外開發一套CDS的架構。
選定好伺服器和部署應用的架構後，資料庫管理人員就要負責設置監控和預警的機制，需要保證應用服務24小時都能夠正常運行，包括檢測應用的存活率、資料庫的主從一致性，以及硬碟容量和延遲等訊息。
最後，在服務正式上線前，免不了還需要做壓力測試，潘娟表示，京東通常會用該服務平時2~5倍的業務流量來測試，查看伺服器和應用會不會出問題，也能檢視選擇的架構是否滿足業務需求，此外，「若該服務與其他服務共存，則要特別小心！」她提醒，測試的過程中也要留意該服務的運行是否會影響到其他原有的服務。
這些檢測的工作，都是需要在服務上線前確實落實，她認為，在服務上線前的檢測工作，不但可以先找到潛在問題，還能讓業務人員和資料庫管理人員，對該服務的現況有所了解，即使服務上線後出差錯，對資料庫管理人員來說，也能夠較快地找到問題並解決，而不用從頭開始找問題。
服務上線後也不能鬆懈，災難演練確保服務中斷能迅速恢復
服務上線前，京東不放過每一個細節的檢測工作，為的就是確保服務上線後不會有任何問題，但是服務正式上線後，因應業務，資料庫會有不少變更，需要擴充容量或是升級等，「通常90%以上的服務，只要變更過，一定會存在許多潛在問題！」潘娟表示，資料庫每一次的變更，都是風險，潛在的問題就像定時炸彈一樣，早晚都會爆發。
為了不讓這些潛在的問題突然爆發，而且突然出現問題時，維運人員也往往會措手不及，於是，京東在服務運行的日常中，就安排了服務的離峰時段，大約是凌晨3～5點的時間，在不影響服務的原則下，將主服務停掉，切換到異地防災備援的伺服器上運行，確保主服務停機時，服務可以順暢且快速地恢復，確認沒有問題，才又將主服務切換回來。
「剛開始這樣做時，業務人員很不能理解，」她表示，業務人員質疑為何服務明明能夠正常運行，卻要三更半夜做服務中斷的演練，也會影響到原本的服務，但是，京東的維運部門堅持，只要變更過的資料庫，沒有辦法百分之百確認資料庫沒有異常，如果服務真的中斷了，需要恢復卻發現無法恢復時，代價就更大了。
因此，京東堅持在線的服務，都必須定期安排災難演練，模擬服務不可用的情況下，能不能及時恢復服務，以及恢復服務需要花多久的時間，京東是由系統分析師、資料庫管理員，以及研發服務相關的工程師組成一個團隊，來負責災難演練的工作。
況且，潘娟表示，若服務平時沒有經過演練，業務人員和維運部門團隊人員的流動，也很容易造成服務中斷時，沒有一套標準的流程可以依循，「我們希望將一切未知變得可知。」她說。
如何打造一套維運標準化流程？以災難演練為例
過去京東的維運工作沒有標準化的流程，導致難以管理，出現問題也不容易快速找到問題的根源，潘娟表示，京東從2016年7月到今年5月這段期間，開始重整維運架構，建立出一套維運的標準化流程，盡可能在問題發生前先預防。
京東的災難演練分為兩類，一個是同機房的演練，也就是假設在北京的機房有主和從資料庫，主資料庫當機了，要馬上切換到同機房的從資料庫，另一種則是異地機房的演練，如果北京機房的資料庫都不可用了，維運部門能不能迅速地切換到上海，或是其他地方的機房，來提供相關的服務。
為了做防災演練，資料庫管理員必須先做許多事先的準備工作，包括整理資料庫的分類、每個應用和服務的相對應關係，也要確認好每次測試的應用演練範圍，以及將所有的應用都建立異地備援的機制，最後因為京東的服務和應用非常多，不可能用手動的方式完成部署，資料庫管理員還需要撰寫自動化的程式來執行相關任務。
將基礎的工作準備好之後，維運團隊要一起討論並制定出災難演練的計畫，將所有的流程標準化，如此一來，新進的維運團隊人員也可以依循著既定的工作流程執行任務，最後還需要跟業務部門的人員協調，在服務流量最低的時間點來執行演練，演練過程需要確認的內容包括，確認資料庫、系統配置訊息、主從資料庫一致性、防火牆的權限，潘娟表示，所有的服務的相關訊息都會檢查一遍，經過災難演練後就會發現一些隱藏的問題，像是服務的一些功能模組沒有升級、權限設置有問題，或是程式碼有問題等。
她也提醒，應用在一開始就需要考慮用自動化來維護服務正常運行，有些企業習慣到服務業務量增加到一定的量才來考慮，但是，業務量高速發展時，工程師需要花較多的心力在應用服務當前的問題，沒有足夠的時間來處理自動化維運的工作，因此，她建議，成長型的業務需要更早是先做好自動化維運的工作，況且，自動化的程式需要真正應用在服務上，經過反覆的修改才能完成，並不是短時間一次就能完成的工作。
打造DBA自動化維運和萬用流程平臺，維運資訊透明化更快找到問題
除了上述的維運基礎工和災難演練之外，潘娟認為，「所有的維運資訊都必須透明化！」京東維運團隊打造了DBA自動化維運平臺Mega，將資源管控、慢查詢、效能優化，伺服器負載情形、效能熱力圖等功能都包含在內，並且每個伺服器也會顯示維運的負責人、業務類型等相關資訊，方便維運和業務人員有狀況時，即時聯繫到負責人。
除此之外，平臺還能顯示服務30天內上線的情形，像是資料庫的負載，若想查詢某個伺服器負責哪些應用、負責人等資訊，也只需要輸入伺服器的編號，就能查詢相關的訊息，例如，網域名、主從架構，以及在伺服器存放在哪個機房，她認為，將所有的資訊透明化並且方便查詢資訊的功能，讓維運團隊在應用出問題時，可以更方便地查詢問題的原因。
有了維運所需的資料之外，京東還發現一個問題，也就是業務研發人員上線新服務時，往往需要找維運部門負責不同工作的工程師協調，不過，研發人員不了解維運的工作，也常常漏掉某些環節，導致應用上線時出現問題。
因此，「京東將維運部門所有業務都統整到單一平臺，」潘娟表示，京東為了不讓業務人員在協調時造成混亂，建立了萬用流程系統MagicFlow，目標就是讓維運團隊對外是一個單位，研發部和業務部需要協助時，不需要了解維運內部如何協調，只需要按照MagicFlow系統的流程申請，對維運人員來說，也不需要擔心自己的任務從誰的手上承接，完成後又要移交給誰負責。
設計MagicFlow系統的過程即是將維運和業務團隊的組別負責人找來一同討論，先收集大家的需求，再將一些大家都會需要使用的功能整理出來，一同協調出共同的標準和流程，並建立模組，如此一來，所有人都能遵循一定的標準化流程申請服務。
最後，經過過去近一年的努力，京東發現應用、資料庫和域名等問題並且已完成修復，也開發跨機房切換資料庫的程式，總共新建置了206個內部系統災難備援機制，共完成 284套分批23次的資料庫切換演練，「盡可能將維運的基礎工作在平時做好，」潘娟強調。
京東資料庫防災演練9大事前準備工作
1 確認主備機房的資料庫分級標準
2 梳理資料庫分類、主從關係，確認可演練範圍
3 建置異地機房備援
4 梳理應用與資料庫對應關係和權限驗證
5 開發域名切換操作介面
6 編寫演練執行程式
7 確定演練方案
8 制定切換演練標準
9 制定演練計畫表
資料來源：iThome整理，2017年11月
from iThome 新聞 http://ift.tt/2m3hHmH
沒有留言:
張貼留言