支付寶技術風險負責人陳亮：把事情做到極致，技術的差異性才會體現出來

“很多事情，說出來很多人都在做，但是隻有真正做到極致，技術的差異性才會體現出來”， 螞蟻金服 技術風險部研究員陳亮（花名：俊義）在接受 InfoQ 採訪時如上說道。在最近支付寶技術嘉年華期間，InfoQ 對支付寶數次技術架構升級的見證者及主導架構師陳亮進行了獨家採訪，首次系統瞭解穩定支撐“雙十一”等多次實戰背後的支付寶技術風險體系。

支付寶技術風險體系

2007 年，陳亮加入 支付寶 ，負責支付寶搜尋及通訊中介軟體架構。在之後的十年時間裡，陳亮先後負責過支付寶交易拆分整體架構，這成為支付寶資料庫拆分架構標準；支付寶三代架構單元化及容災整體架構，實現異地多活，這成為支付寶單元化架構標準。如果簡單總結在支付寶工作的前十年，陳亮表示：

前十年，我一直在做可擴充套件性相關的工作。

在這期間，問題和需求驅動佔據上風。陳亮回憶道：“最初的支付寶是單體架構，一個小型機加兩個 Java 寫的 APP，那年 DBA 就找過來說如果不進行資料庫拆分，很難扛住業務發展”。

經過系列改造，這一工作終於完成。當時，陳亮以為這個架構起碼可以支撐支付寶未來五到十年的發展。然而，雙十一很快就來了，超大規模瞬時流量的衝擊對架構提出了全新挑戰，整個團隊又開始馬不停蹄地進行異地多活相關專案研發。

彼時，支付寶有兩個主要應對技術風險的團隊，一個叫技術質量團隊，另一個則是運維團隊。技術質量主要是各種功能測試，並解決程式 Bug、故障等問題；運維團隊主要是生產偏基礎設施以及應用、DB 運維管理保障，同時也會自發性地做一些技術風險相關的事情，但並未形成體系化的技術風險組織陣型及打法。

2013 年，支付寶技術團隊提出質量 2.0 戰略，其目的是希望在技術風險領域有一些延展，體系化沉澱 Bug 檢測等方面的能力。自此，支付寶的技術風險體系建設逐漸步入正軌。

組織架構演進

2014 年，質量技術部成立希望從全域視角解決技術風險問題。但是，質量技術部並沒有運維團隊，主要就是通用質量檢測和高可用保障相關的技術解決方案，並驅動各業務部門的技術團隊落地。當時，質量技術部人員並不多，是一個小而精悍的中臺部門。

經過一年多的發展，質量技術部發現僅僅依靠質量技術並不能解決生產上的各種故障風險。雖然，質量技術部會關注生產研發過程，但主要精力在於對各業務技術團隊輸出技術風險，比如高可用及通用質量檢測的解決方案，高可用及資金保障方面尚未出現成型的平臺體系。雖然當時的全鏈路壓測和持續整合平臺已有所成型，但關於高可用等並沒有成型的平臺。

當時，技術團隊判斷，不能只從質量角度看風險，而需要從更高的維度和更全面的視角看待風險。2015 年，質量技術部升級為技術風險部，專注研發及架構技術風險問題，做相應的解決方案和落地平臺。

2016 年，陳亮一手打造了支付寶的 SRE（Site Risk Engineer，參考谷歌的 Site Reliability Engineer ）體系。技術風險部增加 PE 和 DBA 團隊，PE 團隊直接對生產環節中的運營、操作等做技術風險防控，整個大團隊的職能屬於 SRE。據瞭解，這也是國內第一個 SRE 團隊。

陳亮發現，傳統的運維思路和文化已經無法徹底解決支付寶的穩定性問題，因此需要成立 SRE 團隊。事實上，傳統的運維方式側重於靠人肉解決風險，不管是調參還是更改配置，都無法從本質上解決支付寶的穩定性問題，相反會讓運維人員的工作成就感很低。說到底，運維領域的問題終究還是軟體問題，需要建立軟體平臺更好地管理風險。

在組建 SRE 團隊的過程中，陳亮認為最難的反而不是技術層面的推進，而是讓團隊工程師，包括整個公司認同 SRE 的價值，這需要讓所有人理解 SRE 可以解決哪些新的問題以及傳統的思維方式為何不可取。

據瞭解，支付寶的 SRE 團隊主要由研發、運維和測試人員組成，八成運維人員都需要寫穩定性相關的程式碼。團隊組建完成即全面開展故障自動定位、自適應容災、防抖、精細化高可用等工作。其中，防抖要保證任何網路或基礎設施抖動，使用者都無感知；精細化高可用，又叫單筆高可用，其顆粒度可以精準到使用者的每一筆交易，遠遠優於行業內的機房級高可用。

2016 年，SRE 團隊建設了很多平臺和能力。同時，技術團隊發現了兩個極為重要的現象，一是生產故障不是必然的，通常都是偶然性的；二是生產故障是低頻的。這帶來的問題就是故障樣本很少，沒有辦法證明在真實故障到來時平臺是否具備能力應對。也就是說，SRE 團隊建設的防禦系統的可靠性，無法充分驗證。

2017 年，SRE 團隊成立了專門的、獨立職能的技術藍軍，其主要的工作就是發掘防禦系統的弱點併發起真實的攻擊。技術藍軍並不對各業務方負責，只對這套防禦系統的穩定性和可靠性負責。

在技術藍軍看來，發生故障是必然的，只是時間早晚而已，技術藍軍會想盡辦法觸發這些故障，以保障在故障真實發生時，團隊有足夠的應付能力。目前，全棧級的技術攻防演練每週都在進行，而故障防禦系統及不斷優化的高可用架構則是由 SRE 團隊的紅軍與各業務深度合作，沉澱、構建出來的。

發展至今，陳亮表示，支付寶技術風險團隊的主要工作其實就兩件事情：一是保障支付寶生產環境的穩定性；二是保障網際網路金融系統的資金零差錯。目標非常明確，但如何解決問題併為之規劃可行途徑是不簡單的。

技術演進

四年前，我們最初只敢做故障定位，現在真的是在做演練。

回顧整個過程技術實力的變化，陳亮表示支付寶的攻防演練是技術演進的縮影。至今，攻防演練已經進行了四屆，時間也從一天拉長至四天。

起初，陳亮介紹，攻防演練主要針對容災方向，雖然也會做一些線上的斷網演練，但當時的體系還不具備直接線上上進行穩定性演練的條件，主要是範圍很窄的故障定位。第二年，團隊構建了新的基礎設施——灰度環境，該環境與生產環境完全隔離，但可以引入環境流量進行生產驗證。同時，該環境具備 24 小時壓測流量，團隊可以在各個環境下進行穩定性攻防，並要求在十分鐘內恢復穩態，此時已經從只敢做定位變成真正做演練。

如今，攻防演練的時間已經拉長至四天，支付寶技術風險團隊會在虛擬環境演練整體的故障恢復能力。通過 AIOps 和 TRaaS，整個團隊的目標已經變成五分鐘內自愈，最新的攻防資料顯示已有近八成業務通過自愈恢復。更為複雜的容災演練也從一年 12 次演變為百餘次，容災成功率從 50% 提升至 90%。在這個過程中，支付寶沉澱了很多與技術風險相關的能力，以下將簡單介紹 AIOps 和 TRaaS 兩個維度。

支付寶技術風控平臺 TRaaS

過去，我們對新技術的接受和採納程度一直很高，但可能缺少分享。如今，我們將整套攻防演練沉澱下來的風控體系對外開放。

去年，在杭州的螞蟻金服 ATEC 科技大會上，支付寶正式推出技術風險防控平臺 TRaaS （Technological Risk-defense as a Service）。經歷過無數考驗的 TRaaS 是把支付寶整個分散式架構和技術風險能力組合在一起的免疫系統，將高可用和資金安全能力結合 AIOps，使系統實現故障自愈，具有免疫能力。

之所以決定開放整套由攻防演練沉澱下來的風險平臺，陳亮表示，這在一定程度上受到支付寶開放戰略的驅動。過去，支付寶曾將中介軟體、PaaS 平臺等開放給客戶。其次，對金融領域的使用者而言，穩定性需求真實存在，且一直沒有特別好的解決方案，支付寶願意將數年積累的技術能力產品化並對外提供。

簡單來說，TRaaS 具備三大特性：高達 99.999% 的高可用性；千億級資金秒級實時核對；5 分鐘發現，5 分鐘自愈的免疫能力。

首先，依靠支付寶的三地五中心異地多活容災架構及全鏈路壓測的考驗，TRaaS 最終實現了高達 99.999% 的高可用性，即極高可用性，也就是說系統年度停機時間將不超過 5 分鐘。

其次，作為 TRaaS 平臺負責人，陳亮回憶道，在整個資金防控體系的演進過程中，支付寶最初與眾多銀行一樣，靠人力進行對賬。之後通過自動化的方式將全量資料庫表匯出後做計算來進行核對。後來，業務量更大，就引入了 T+H，核對時間也從天變到小時級，並在此過程中增加了異常管理。最後演進到實時業務核對，增加了熔斷決策、資金免疫以及智慧監控等方面的功能，從而形成了 TRaaS 強大的千億級資金秒級核對能力。

最後，TRaaS 整合了支付寶在 AIOps 層面的探索。

AIOps

如前文所言，自愈是支付寶 AIOps 方向的重要探索。目前，自愈的恢復能力控制在 5 分鐘左右。隨著 AI 演算法的不斷優化，陳亮認為，這一時間未來有望繼續縮短。陳亮表示，在系統建設的過程中，AI 演算法肯定發揮了較好作用，但通過 AI 實現自愈可能會侷限於某些場景，這就需要藉助 SRE 的能力用軟體工程的方法建模。支付寶也會通過 AI 的方式實現根因定位、告警處理等功能。

採訪中，陳亮提及，AI 在 DevOps 領域最大的價值可以概括為提升效率和擴充套件邊界。一方面，通過歷史監控資料對模型進行訓練，AI 可以輔助工程師進行業務監控，進而提高監控效率；另一方面，AI 有效提高了監控點的配置數量，覆蓋的業務範圍更廣，這是依靠現有人力很難實現的。

支付寶的生產環境非常複雜，要想實現 AIOps，最大的技術挑戰源於超高規模的資料併發，技術風險團隊想要實現業務高可用就需要找到造成某種故障的全部可能原因，比如造成付款下跌的全部原因，該過程在內部被稱為“找分母”，AI 在這一階段發揮了重要作用。

以資金安全為例，對於同一筆業務， SOA 架構的上下游會出現兩張表，而表單中同一筆訂單的金額必須保持一致。當表單資料足夠多，就意味著可供訓練的樣本數量足夠龐大，此時可以通過 AI 的方式找出每筆金額不一致交易的故障原因，進而不斷完善該故障的“分母”。

對於 TRaaS 平臺的未來規劃，陳亮表示，在條件成熟且允許的情況下，TRaaS 平臺會整合支付寶技術風險團隊在攻防領域的全部能力，包括灰度架構、演練平臺、自愈平臺、報警處理平臺及變更平臺等。

未來規劃

未來，技術風險防控體系將具備更多智慧特性，儘量減少人工干預，最好的情況是實現無人值守。陳亮透露，這將是整個團隊未來至少兩年內的主打方向——讓所有變更無人值守。當然，無人值守很簡單，關鍵是風險控制能力要上去。

在支付寶技術風險能力的構建過程中，陳亮坦言，未來希望將技術風險和 AI 的能力雲原生化，並將其與 Service Mesh 相結合，讓業務專注研發業務程式碼，其他的全部交給雲。

採訪嘉賓

陳亮（花名：俊義），螞蟻金服技術風險部研究員，支付寶數次技術架構升級的見證者及主導架構師。加入支付寶之前，曾做過漢語程式設計，並創業做搜尋網站；現帶領支付寶技術風險團隊，進行螞蟻新一代高可用及資金安全保障相關架構體系及產品研發，如 AIOPS，TRAAS 等。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69904796/viewspace-2647363/，如需轉載，請註明出處，否則將追究法律責任。