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

「不少事情，說出來不少人都在作，可是隻有真正作到極致，技術的差別性纔會體現出來」，螞蟻金服技術風險部研究員陳亮（花名：俊義）在接受 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 等。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。