在年初舉行的螞蟻金服ATEC城市峰會上，螞蟻金服高級技術專家王亞宏做了主題為《技術風險防控平臺：打造金融交易系統的故障免疫能力》的精彩分享。
演講中，王亞宏介紹了螞蟻金服的技術風險保障體系，同時分享了螞蟻金服如何將自己在過去多年積累的的實踐經驗通過TRaasS平臺分享給整個金融生態圈的合作伙伴，助力金融機構建立穩定可靠的金融業務。
王亞宏 螞蟻金服高級技術專家
金融級分佈式架構面臨的挑戰和機遇
軟件產品向分佈式架構和微服務轉型已經成為行業的共識。在架構的轉型過程中，作為守門員的企業運維保障部門面臨著巨大的挑戰。這些挑戰包括但不限於：1:產品需求變更頻繁、軟件開發速度也越來越快，但運維保障部門由於缺乏完善的保障措施只能通過控制發佈次數來降低風險，使得業務更新速度下降。2: 從大型機器轉移到PC服務器使得系統單機故障率更高，現有的容災與FO機制能否支撐系統準確地運行仍存在疑問。3:從單體架構遷移到微服務架構要求系統進行全面的迴歸測試，這帶來了巨大的測試工作量。4:，分佈式系統中的一條調用鏈路可能橫跨多個系統，問題排查變得非常困難。5:，對金融行業而言，解決分佈式系統中的數據一致性問題也非常關鍵。
從另外一個角度看，企業運維保障部門也應看到分佈式架構帶來的機遇。在過去，單體系統發佈新版本通常要求產品通過層層測試來保證新版本上線後不出問題。但分佈式系統允許使用真實用戶和流量實現線上驗證以確保產品上線後出現問題帶來的影響最小。分佈式架構使灰度驗證和快速發佈成為可能。此外，從前只能在線下進行的模擬演練，現在可以隨時在生產環境中進行。全鏈路壓測還讓獲取真實流量成為可能，讓我們能在每次大促時做到高枕無憂。
在過去十年中，螞蟻金服的運維保障體系也經歷了深刻的變革。通過抓住架構升級帶來的機遇，通過技術和平臺提升解決系統問題，運維保障部門做到了在架構升級的過程中平滑過渡，系統保持非常高的可用性的同時充分享受架構升級帶來的收益。
螞蟻金服技術風險保障體系
下圖是螞蟻金服的技術風險保障體系的總體設計圖。
在目標層，螞蟻金服的運維保障部門力求做到99.99%的系統高可用、系統全年無重大資金安全故障，同時實現系統運維零成本。這些也是螞蟻金服給客戶的SLA承諾。治理層：與螞蟻金服的團隊、文化和制度相關。為了應對技術風險領域的挑戰，螞蟻金服組建了技術風險保障部門，聚焦於使用技術升級運維和質量保障手段以解決系統面臨的技術風險難題。同時，螞蟻金服建立了一系列制度保證系統內的任何變更都符合可監控、可灰度、可回滾的“三板斧”要求。在運營層：設置了四道防線。前兩條防線即需求和研發包含了風險評審、自動化測試等常規內容。第三道防線通過灰度發佈和藍綠髮布實現產品變更的驗證和管理。第四道防線即系統監控，保證了系統在線上運行過程中具有最小的運行風險。最後一層是平臺層：技術風險保障體系的目標、治理和運營層需要依賴平臺層來實現，平臺層包括業務監控、演練中心、預案中心和變更管控等各種技術平臺。
TRaaS技術風險防控平臺
螞蟻金服將其構建技術風險保障體系的實踐和經驗沉澱下來，形成了TRaaS技術風險防控平臺，開放給金融生態圈的所有合作伙伴。下圖右側的能力閉環展示了技術風險防控平臺的核心方法論，分為三個部分。風險基線衡量了系統的風險保障能力，使風險保障人員瞭解系統的風險防控水平。監控/巡檢、預案自愈以及演練屬於第二個部分，確保系統在發生問題是能快速發現，定位和自動修復。此外，變更是系統風險的最大來源，螞蟻金服對系統變更進行了嚴格的管控，確保所有變更都符合三板斧制度。
下面我們分別看一下這三個關鍵環節中，平臺具體所做的事情。
風險基線
風險基線這部分核心要解決的問題是如何評估我們當前的風險保障能力，以及發現哪些地方存在風險隱患。 所有做風險管理的同學都會面對一個問題：“風險分母到底有多大？”，這是一個理論上就無解的問題。
那怎麼辦呢，螞蟻金服的實踐經驗是接受風險本身的未知性，但在平臺中將已知的風險場景沉澱下來，確保未來不再犯類似的錯誤。通過對這些沉澱下來的風險場景的風險保障能力的自動檢查，來對我們的風險保障能力做個打分，並且發現存在問題的地方。
具體到平臺中的做法是：第一步，先獲取到所有和風險相關的實體的元信息，包括應用，服務，網絡，容器，物理機 等各個層次的風險實體，並將他們通過業務鏈路或部署拓撲關聯起來。 第二部：將風險知識沉澱為風險模型，一個風險模型的內容可以用一句話來概括當XXX類型的風險實體具備XXX屬性時，必須有XXX，XXX。。。。 的風險保障措施。這裡的保障措施包括 監控，巡檢，核對，預案，演練等一系列能力。 有了第一步，第二步獲取到的信息，我們可以獲取到一個相乘的笛卡爾集。在這個集合中可以清晰的看到，基於我們已有的風險知識沉澱，我們當前的技術風險保障水位如何，哪些地方是存在隱患的。針對每個風險點，風險揭示關注系統是否有完整的風險保障措施，以及對保障措施不完整的風險點應當如何處理等問題。風險揭示為一 線風險防控人員包括業務負責人和架構師等都提供了監控視角，以評估系統的風險防控能力，應對當前系統的風險防控問題。總的來說，將風險防控經驗沉澱為風險模型，輔以完善的系統元信息和保障機制，風險揭示平臺提高了系統發現風險的能力。
風險處理
風險處理平臺對接各種監控系統獲取監控報警信息，再將收集到的監控信息聚合為風險事件。
對於業務報警信息或單機報警信息，在聚合為風險事件後，處理平臺提供標準的分析引擎（同時支持自定義引擎）幫助提供異常鏈路，相關變更，主成分等各種輔助定位信息。在有了對應的信息後，給用戶推送自動的應急自愈預案，或手工的業務應急預案。 最後，在問題解決後對整個故障進行復盤，將一些新產生的風險知識沉澱到風險基線中去，最終實現閉環。
變更管控
螞蟻金服的內部統計數據顯示，80%的系統生產故障都來自於代碼變更，因此變更管控對技術風險防控而言至關重要。大規模系統內往往包含著幾十乃至上百個變更來源，一旦線上發生問題，很難第一時間找到對應的變更，變更本身的質量也很難有效控制住。
變更管控平臺利用變更接入API整合所有系統變更，使變更可見。同時，變更管控平臺還提供了變更編排，變更灰度檢查，變更預檢，變更結果監控等能力。確保所有生產變更都符合可灰度，可監控，可回滾的三板斧原則。 同時，通過提供變更關聯，以及變更回滾來加快線上問題處理速度。
其他SaaS服務
上面所講的整體體系，大家可能會感覺特別重，整個體系實施起來的組織成本，技術成本都還是比較高的。 這點上確實如此，要想系統性的對技術風險進行託底保障，確實需要一套相對比較重的體系和機制來。
對於一些小型企業，或者說想解決一些特定領域的問題的客戶，技術風險防控平臺還提供了一些輕量級的SaaS服務，包括全鏈路壓測、資金安全監控、流量仿真測試、高可用巡檢以及智能監控等。這些服務都可以在螞蟻金融科技的公有云或專有云平臺上輕鬆獲取，快速提升某一方面的能力。
螞蟻金服技術風險防控能力實踐
下圖是我這邊摘抄出來的一些內部運行數據，可以讓大家更有體感的去感受螞蟻金服技術風險保障體系是怎麼運作的。
第一張圖是1218紅藍大攻防的數據，在螞蟻內部，有一支專門負責搞破壞的技術藍軍，他們每天所做的事情就是不停的對系統進行攻擊，注入，製造高可用和資金安全故障。以此來檢驗我們的發現機制，應急機制是持續有效，不斷保鮮的。螞蟻金服在執行紅藍攻防演練時做到了每5分鐘產生超過500個故障場景，同時保持每週超過200次故障場景演練。
第二張圖是今年雙11大促前，我們所做的技術保障工作。為了應對雙十一大促的流量高峰，螞蟻金服進行了長達三個月甚至更長時間的全鏈路壓測、預案驗證以及線上巡檢炎症。高頻率的故障場景演習以及高時長的大促技術備戰使得螞蟻金服具有極強的防禦能力。
第三張圖摘自技術風險保障週報，這裡能看到的是螞蟻金服技術風險防控團隊在日常工作中也不在斷優化系統的風險防控能力。螞蟻金服通過將容災仿真演練、高可用常態演練、資金安全常態演練以及自愈檢查等納入每週，每天都要做的事情，以此保證螞蟻金服系統能夠持續穩定安全地運行。
技術風險防控平臺如何助力合作伙伴
我們認為傳統的風險保障體系具有以下三個特點：
第一，風險保障設計聚焦於風險出現後的問題處理，系統本身風險防控能力處於未知狀態，只能被動地等待出現“黑天鵝”事件。
第二，風險保障部門通過嚴格控制發佈週期、儘量不發佈和不變更來避免系統出現風險事件。
第三，每次新版本發佈都伴隨著大量測試資源的投入和層層評審來降低新版本中出現風險的概率。
下一代技術風險防控體系具有以下四個特徵：
第一，風險保障通過建設反脆弱的系統來降低意外事件帶來的影響，聚焦於系統健壯性的提升。
第二，強調風險保障能力可見，並且能夠通過持續演練持續保鮮。
第三，重視灰度變更，強化變更過程的監控能力和回滾能力以降低系統變更風險。同時，通過技術手段和制度規約限制每次變更的影響範圍，使變更可控。
第四，依賴於自動化測試、線上壓測和線上仿真測試等技術手段來降低系統風險。
螞蟻金服技術技術風險防控平臺希望能在這個技術升級的變革過程中。
將我們積累的保障能力沉澱為平臺能力，將平臺能力開放給我們的合作伙伴。
將我們積累的風險知識沉澱為沉澱為模型，規則。將風險知識來分享給生態圈中的合作伙伴們。
系統需要通過持續演進得以不斷完善，而螞蟻金服的願景在於將自身在技術風險防控中的平臺積累及實踐經驗分享給整個金融生態圈的合作伙伴，讓生態圈中的夥伴們能通力合作、共享風險保障技術，更重要的是共享風險防禦知識，一起打造穩定可靠的在線業務。
閱讀更多 ATech 的文章
