摘要：對於移動技術而言， 2017年是繼往開來之年。 一方面是移動技術領域進入深水區， 另一方面移動技術邊界和內涵被不斷重塑。 阿裡巴巴希望進一步推動移動應用研發事實標準落地， 從而賦能整個行業開發者。 在2017年杭州雲棲大會上， 螞蟻金服高級技術專家竹光為大家分享了螞蟻金服移動端在高可用技術方面的具體實踐。
演講嘉賓簡介：竹光， 螞蟻金服高級技術專家。 2015年加入支付寶， 主要負責用戶端的穩定性和高可用， 曾多次參與雙11、雙12、春節紅包等大促的技術保障工作， 主要負責保證活動期間支付寶用戶端的穩定性以及可用性。
以下內容根據演講視頻以及PPT整理而成。
本次分享的內容主要分為以下四個方面：
億級APP在可用性方面的挑戰
APP線上運維的發展和演進
移動端高可用的定義、目標、核心打法
支付寶在移動端高可用技術實踐
一、億級APP在可用性方面的挑戰可用性的概念
首先分享一下可用性的概念。 簡單而言， 可用性就是當用戶想要使用APP做一個事情， 這件事情做成了就是可用， 沒有做成就不可用。 為什麼沒有做成？可能的原因有很多， 比如有可能使用APP的時候閃退了， 或者使用支付寶付款的時候， 由於後臺某個環節出現錯誤， 導致了這筆支付失敗了等， 這些都可能造成APP的不可用。 如果各種各樣不可用的情況都沒有出現，
億級APP的可用性挑戰
目前， APP開發技術已經比較成熟了，
如下圖所示的是這幾年來支付寶用戶端在可用性運維上的發展歷史， 大致分為了三個階段。 隨著支付寶的成長， 可用性運維也一直在演進， 最後演進到了移動端高可用的狀態。
第一個階段就是簡單的閃退監控。絕大多數的APP也做過這個事情，就是本地收集一些閃退資訊並進行上報，在APP後臺對於閃退率進行監控，解決閃退比較多的問題，並在APP的下一個版本中進行相應的修改，最後使閃退率維持在某一個指標以下。但是現在來看，這個階段距離實現高可用的要求相差很遠，因為用戶所遇到不可用問題中閃退只佔據其中一部分，所以對可用性而言，解決了閃退問題只是改進了一點點而已，還存在著大部分的問題還沒有解決。
第二個階段，在阿裡巴巴內部叫做穩定性監控體系，相比於第一個階段而言，穩定性監控體系可以說前進了非常大的一步。首先，可以監控的問題大大豐富了，通過對多種問題的監控可以瞭解線上使用者穩定性方面的可用情況，而不僅僅是一個使用者。第二個方面，穩定性監控體系具有相當程度的診斷能力和修復能力。當發現問題的時候，可以通過診斷日誌等相應的方法分析故障原因並嘗試進行修復。穩定性監控體系在最初的時候效果比較不錯，並且阿裡巴巴內部也使用了很長的時間，但是後來問題也逐漸暴露出來。舉兩個例子，曾經一個版本的APP在X86一款機器上運行時出現的問題非常多，但是那個機型的用戶量很小，所以問題一直都沒有被發現，直到很晚的時候才通過其他方式發現了這個問題，也就是說因為只監控具體問題導致已經不能發現局部人群的問題了。第二個例子，在做像雙11這樣的大促值班的技術保障的時候，因為監控的問題比較多，運維人員需要通過不停地翻監控來發現問題，翻來翻去最後還是不敢確定APP的可用性到底有沒有問題，有時候確實會遺漏一些問題。第三個方案就是在發現了問題之後，能否快速修復還需要碰運氣，有可能很快就能夠修復，也有可能修復起來不太容易，需要等到下一次發版，這就使得有些問題所影響用戶數會非常多。
以上就是在2.0階段所遇到的問題，這說明穩定性監控體系也已經不夠用了，需要繼續進行改進，這也是支付寶決定繼續做3.0階段的移動端高可用的動機和動力。
三、移動端高可用的定義、目標、核心打法高可用在移動端的重新定義
高可用原本屬於服務端的概念，阿裡巴巴的服務端都在講高可用。服務端的高可用重點講的是停機時間短、服務不可用時間短。移動端的高可用從服務端借鑒過來之後進行了重新定義，因為用戶端不存在停機時間概念。所以，移動端高可用的定義是指通過專門的設計，結合整套技術體系，保證用戶所遇到的技術不可用總次數很低。
移動端高可用的目標
簡單來說，移動端高可用的目標就是實現可用率達到99.99%，這裡的可用率是支付寶自己定義的概念，指的就是用戶在使用APP的時候，可用次數在使用次數當中的占比，可用率達到99.99%也就意味著用戶使用1萬次支付寶其中的9999次都是必須是可用的，最多只有一次不可用。為了實現這一目標，還會將任務拆解成為不同的子目標分別攻克。
移動端高可用的核心打法
其實，目標上的實現還是比較困難的，因為讓可用率達到99.99%其實是一個很高的指標。而為了能夠努力實現這個目標，支付寶也自創了一套核心打法，主要分為以下四個部分：
用戶端可用性監控。用戶遇到不可用的時候，要把造成不可用的問題收集並上報上來，並且要提供足夠的診斷資訊用於分析解決。
高靈敏監控報警平臺。需要實現當線上的問題剛剛出現苗頭的時候就立即能夠發現。
快速修復能力。當發現問題之後不僅要保證能夠修復，還要保證修復的速度足夠快。對一些級別高的故障，支付寶要求在一個小時之內完成快速修復。
故障演練。
四、支付寶在移動端高可用技術實踐下圖所示的是支付寶實現的移動端高可用技術架構圖，大家可以看到支付寶移動端高可用的技術架構設計也是圍繞上述的四個核心打法展開的。
用戶端可用性監控
問題採集：用戶端可用性監控的第一步就是問題採集，當APP發生不可用時必須能夠感知和採集到問題，這是基礎的基礎，如果沒有這個基礎後續什麼都不能實現。那麼，怎樣確保當使用者出現了不可用情況時能夠採集到問題？這其實是比較困難的，因為我們不能保證一定可以採集到所有類型的不可用問題，但是還是會通過多種方法儘量地實現全面覆蓋。支付寶把不可用問題分為穩定性不可用和業務不可用兩個方面。對於穩定性不可用而言，通過2.0階段的逐漸摸索以及各種回饋管道、問題搜集管道的補充，現在已經可以把各種各樣穩定性的不可用問題搜集得比較全了，比如傳統的閃退、卡死等以及不容易被監控的黑屏、白屏以及非閃退類型的異常退出等。目前已經採集到了大部分的問題，當然可能還會存在遺漏，對於這些遺漏的問題，還需要通過不停地搜集並補充到這個體系中。對於業務不可用而言，在開發時會對於業務不可用問題進行埋點，只需要將業務不可用埋點納入到系統裡面來，就能夠基本覆蓋最重要的業務不可用問題。
統一管控：當問題採集上來之後，需要通過統一管控形成用戶端可用率指標。通過這個指標可以全面地評估線上某一個人群中的可用情況，而不需要像以前那樣逐一檢查各個指標並在最後給一個不太準確的評估結果。通過統一管控可以設計出整體的監控和報警機制以及各種演算法模型，並且其擴展性更好。
埋點上報：這一功能是非常核心的。因為後續還要利用不可用埋點做高靈敏，所以埋點的即時性、準確性、到達率的要求特別高。並且對於不可用埋點而言，當用戶端已經發生了不可用時才需要進行上報，而在這個時候用戶端情況很可能非常惡劣，甚至此時用戶端可能已經無法啟動了，即便是這樣也要保證埋點能夠上報。為了實現這一點，我們利用了一些小技巧，比如對於Android系統而言，支付寶通過獨立的羽量級進程來單獨上報埋點，即便主進程已經掛掉了，但是埋點也能夠即時上報上來；對於ios系統而言，採取線上上hold住進程使其報完埋點再退出去的方式，並且後續還有補償機制，即使出現遺漏埋點的情況也能夠使其最終能夠上報上來。
通過問題採集、統一管控和埋點上報，基本上可以保障當用戶遇到不可用問題時可以收集問題並上報服務端，做好了第一步的基礎。
高靈敏度系統模型
在問題收集到的情況下需要用高靈敏系統模型做監控和報警。其實監控和報警在2.0時代就已經存在了，比如當大盤上監控的閃退率出現異常情況時就會進行報警。但是高靈敏系統模型要做的是線上上問題剛剛出現苗頭的時候就可以發現，而不是等到大盤出現波動才發現。所以這個模型的關鍵在於分析決策的過程中，它會基於使用者的人群特徵、問題特徵把線上採集到的不可用問題進行聚合再進行分析，通過預製的一些演算法模型和規則來判斷是否產生了異常，如果最終判斷的確有異常產生了則會輸出一個異常事件。
舉個例子，比如線上的某個業務發佈了一個新的H5離線包版本，其中某一個頁面的卡死率很高。那麼使用這個頁面的使用者就會形成一個特徵人群，這個特徵人群的頁面卡死率就有異常的波動，這個時候就會輸出異常事件。但是此時大盤並沒有太大波動，因為特徵人群的人數並不多，但是後臺可以捕獲到異常事件。當異常事件輸出之後，可以通過附帶資訊準確地匹配到相應的負責人以及開發、測試人員，告警系統會告知負責人進行處理，並且會根據問題的嚴重程度採取不同的告警方式，可能會採取郵件、釘釘或者電話等方式進行告警。在問題非常嚴重的情況下，如果幾分鐘之內沒有回應就有人打電話給負責人了。通過這樣的告警機制就可以保證無論在什麼的時間，只要線上出現異常問題就可以迅速地感知到。
高可用容災平臺
通過上述的內容，已經可以實現對於可用性問題的感知了。接下來分享如何通過高可用容災平臺修復異常問題。這裡通過整體的故障容災過程進行分享，如下圖所示，當一個故障進來了，會向相應的負責人發出告警，這時負責人需要檢查這個故障是怎樣產生的，到底是由於線上變更導致的，還是由於用戶端本身的Bug導致的。如果是因為線上變更導致的則比較好辦，因為現在的系統比較靈敏，只要故障剛一發生在短時間內負責人員就可以收到告警，之後就可以到發佈記錄中檢查這段時間內發生了哪幾次變更，可以很快地基本瞭解是哪一次變更導致的故障，並採取相應的處理策略，如果可以回滾就進行回滾操作，不能回滾就需要進行緊急發佈，如果不能緊急發佈就要依賴用戶端進行修復。
比較麻煩的是和變更沒有關係的情況，此時就需要通過異常攜帶的診斷資訊或者通過獲取一些日誌來檢查問題為什麼產生，問題的產生有時候是因為相容性問題，比如某個廠商灰度發佈了一批和支付寶相容性不太好的系統，導致出現了各種各樣的問題，這種情況下就要通過動態修復解決；也可能一些客戶本地出現了嚴重錯誤，比如說產生了一些髒資料，或者安裝時因為市場的臨時性Bug導致了大量安裝失敗，最終導致支付寶打不開，對於這種情況而言，可以通過本地容災做一些恢復工作，進而實現用戶端的自動恢復。總之，通過上述的過程，可以使故障得到解決。從下圖中可以看出，支付寶在高可用容災中致力於兩點：第一，希望每個故障都有一個對應的方法能夠實現修復；第二，希望流程儘量清晰並且順滑，希望不要在流程上浪費太多時間，並且將故障儘快地解決掉。
高可用的動態修復體系
移動端高可用和服務端高可用的重大區別就是移動端的發佈比較困難，所以需要依靠動態修復技術。動態修復並不是新的概念，像hotpatch等技術都已經非常成熟了，目前也有很多可選的動態修復方案。但是，雖然在高可用的動態修復體系中，hotpatch屬於比較重要的點，但是並不是最主要的點，因為它也存在一定的局限性，也有不適合的時候。目前，支付寶基於多種修復手段搭建了高可用的動態修復體系。
支付寶的高可用動態修復體系主要由以下三部分構成：
修復手段：修復手段有很多種，並且有輕有重。輕的手段線上上進行一些配置就可以解決線上不可用的問題，重的手段可以把整個模組完全重新部署下去。具體應該選擇哪一種修復手段應該根據故障的情況來看，選擇效率最高、風險最低的修復方式。
下發通道：這一點與埋點上報的要求有一點類似，也需要高即時性和高可靠性。當用戶已經不可用了，常規方法拉不到線上的修復方案的時候，能夠解決的辦法再多也是沒有用的，所以需要保障無論面對多麼惡劣的情況下都能夠把修復方案拉下來。下發通道的實現方式有很多種，最終實現只要能夠聯網一定可以將修復方案拉下來，如果暫時不能聯網，那麼一定要在聯網之後將修復方案拉下來。
發佈平臺：設計動態修復的發佈平臺的時候非常關注的一點就是把修復方案推送給真正需要它的使用者，也就是把修復方案推給已經出現或者可能出現這個問題的用戶，這樣做的原因是每一次的動態修復其實也是一次線上變更，本身也是存在風險的，如果對於所有用戶都進行推送則需要比較長的時間進行灰度來保證安全，但是如果能夠只對目標的小眾人群、特徵人群推送方案，這樣灰度時間會很短，修復時間也會很短。支付寶在用戶端請求修復方案的時候，會根據用戶端的人群特徵、是否發生過這個問題以及有沒有發生這個問題的可能來判斷是否把這個修復方案推送給他們，這樣可以很快地完成推送過程。這在圖中稱之為“智慧修復”，其實稱之為“定向修復”更為準確一些。
高可用實戰經驗
在這裡和大家分享支付寶在高可用實戰中的兩個案例，其中一個處理的比較成功，另外一個則不是很成功。
案例1：一個業務運營推送了一個錯誤的功能表配置，而用戶端沒有做好保護。在運營推送配置的10分鐘之內，相關的負責人都收到了報警，並且很快地查到是這個配置導致的，之後運營將馬上對於配置進行了回滾，這個過程所影響用戶數比較少，所以是一個比較成功的案例。這也是支付寶最期望的運維過程，實現了及時發現、很快修復並且影響用戶數很少。
案例2：在一次大促的時候，一個業務開啟了限流，用戶端彈出一個限流的頁面，但是這個頁面有Bug，會導致黑屏，進而導致用戶無法進行操作。但是由於當時的可用性監控不完善，所以這個問題沒有被監控到，最後是因為用戶的回饋才知道出現了問題，到問題出現的第三天，回饋量已經積累到一個明顯的程度了，才發現這個問題。之後，我們迅速地對於這個問題進行了分析和解決，最後定位到限流的問題，一個小時之內確定了問題所在，並暫時把限流先關掉，後來把這個Bug修復掉了之後再將限流打開，這樣用戶端才恢復正常。雖然最終把問題完善地解決了，但是這一過程存在非常明顯的缺陷。首先是發現的太晚了，這是因為可用性問題沒有覆蓋到；另外，因為沒有足夠的資訊使得決策的過程比較慢，花了1個小時進行分析才能夠止血，直到現在我們也不知道這三天到底影響了多少用戶，但是這一事件肯定對支付寶的可用性造成了不小的傷害。而現在，支付寶實現了移動端的高可用，以後像這樣的事情不會再發生了，當出現故障時，支付寶可以在第一天很短的時間內就可以搞定問題。
故障演練
有這樣一句話“避免故障最好的方式就是不斷演練故障”，所以我們要通過可控的成本線上上真實地類比一些故障，進行故障演練，檢驗高可用體系是否可靠，同時也讓相應的同學對系統、工具和流程更加熟悉，當真正發生問題的時候可以快速地處理。
為了更好的檢驗這套東西，支付寶採用了攻防對抗演練的方式，成立了一個虛擬小組，他們會想辦法類比線路上可能出現的故障情況，而另外一組人則利用移動端高可用技術接招，把對方研發的問題快速地處理掉。這樣做好準備以後，當真正出現故障需要進行處理的時候，我們也已經能夠熟練地應對了。
在前進中探索
最後再談一下對用戶端可用性運維未來的思考：
智能化。前面提到了高靈敏的模型，大家可以看到其實在決策的過程中往往需要依賴預設的演算法模型、規則以及數值等，這些都源于常年積攢下來的經驗。但是這也存在一些缺點：一是有可能出現誤報；二是為了防止誤報太多，這個模型不敢做的太緊，所以模型的靈敏度屬於比較靈敏，而不是極度靈敏。我們期待通過智慧化的方式，通過人工智慧、機器學習的方法實現決策過程的智慧化，可以做得更加靈敏，將問題發現的時間再提升一節，而且這目前已經不僅僅是一個想法了，在支付寶的很多場景中已經開始使用智慧報警了，我們也在調研和嘗試接入這個東西。
自動化。這部分主要指的是容災過程的自動化。我們想把前面展示的容災過程做的很順滑，但是其中很多步驟都需要人來做，這樣時間成本、決策成本會很高，所以我們希望把儘量多的步驟轉成自動化方式，至少是半自動化的方式，這樣才能讓容災過程更加順滑，使得修復時間產生本質的飛越。
產品化。我們希望當用戶端可用性更加成熟之後賦能給其他類似的APP，通過這個過程積攢更多的經驗，發現更多的問題。並且在未來合適的時間，或者3.0版本的用戶端可用性不能滿足需求的時候再去建設4.0可用性運維體系。
第一個階段就是簡單的閃退監控。絕大多數的APP也做過這個事情，就是本地收集一些閃退資訊並進行上報，在APP後臺對於閃退率進行監控，解決閃退比較多的問題，並在APP的下一個版本中進行相應的修改，最後使閃退率維持在某一個指標以下。但是現在來看，這個階段距離實現高可用的要求相差很遠，因為用戶所遇到不可用問題中閃退只佔據其中一部分，所以對可用性而言，解決了閃退問題只是改進了一點點而已，還存在著大部分的問題還沒有解決。
第二個階段，在阿裡巴巴內部叫做穩定性監控體系，相比於第一個階段而言，穩定性監控體系可以說前進了非常大的一步。首先，可以監控的問題大大豐富了，通過對多種問題的監控可以瞭解線上使用者穩定性方面的可用情況，而不僅僅是一個使用者。第二個方面，穩定性監控體系具有相當程度的診斷能力和修復能力。當發現問題的時候，可以通過診斷日誌等相應的方法分析故障原因並嘗試進行修復。穩定性監控體系在最初的時候效果比較不錯，並且阿裡巴巴內部也使用了很長的時間，但是後來問題也逐漸暴露出來。舉兩個例子，曾經一個版本的APP在X86一款機器上運行時出現的問題非常多，但是那個機型的用戶量很小，所以問題一直都沒有被發現，直到很晚的時候才通過其他方式發現了這個問題，也就是說因為只監控具體問題導致已經不能發現局部人群的問題了。第二個例子，在做像雙11這樣的大促值班的技術保障的時候，因為監控的問題比較多，運維人員需要通過不停地翻監控來發現問題，翻來翻去最後還是不敢確定APP的可用性到底有沒有問題，有時候確實會遺漏一些問題。第三個方案就是在發現了問題之後，能否快速修復還需要碰運氣，有可能很快就能夠修復，也有可能修復起來不太容易，需要等到下一次發版，這就使得有些問題所影響用戶數會非常多。
以上就是在2.0階段所遇到的問題，這說明穩定性監控體系也已經不夠用了，需要繼續進行改進，這也是支付寶決定繼續做3.0階段的移動端高可用的動機和動力。
三、移動端高可用的定義、目標、核心打法高可用在移動端的重新定義
高可用原本屬於服務端的概念，阿裡巴巴的服務端都在講高可用。服務端的高可用重點講的是停機時間短、服務不可用時間短。移動端的高可用從服務端借鑒過來之後進行了重新定義，因為用戶端不存在停機時間概念。所以，移動端高可用的定義是指通過專門的設計，結合整套技術體系，保證用戶所遇到的技術不可用總次數很低。
移動端高可用的目標
簡單來說，移動端高可用的目標就是實現可用率達到99.99%，這裡的可用率是支付寶自己定義的概念，指的就是用戶在使用APP的時候，可用次數在使用次數當中的占比，可用率達到99.99%也就意味著用戶使用1萬次支付寶其中的9999次都是必須是可用的，最多只有一次不可用。為了實現這一目標，還會將任務拆解成為不同的子目標分別攻克。
移動端高可用的核心打法
其實，目標上的實現還是比較困難的，因為讓可用率達到99.99%其實是一個很高的指標。而為了能夠努力實現這個目標，支付寶也自創了一套核心打法，主要分為以下四個部分：
用戶端可用性監控。用戶遇到不可用的時候，要把造成不可用的問題收集並上報上來，並且要提供足夠的診斷資訊用於分析解決。
高靈敏監控報警平臺。需要實現當線上的問題剛剛出現苗頭的時候就立即能夠發現。
快速修復能力。當發現問題之後不僅要保證能夠修復，還要保證修復的速度足夠快。對一些級別高的故障，支付寶要求在一個小時之內完成快速修復。
故障演練。
四、支付寶在移動端高可用技術實踐下圖所示的是支付寶實現的移動端高可用技術架構圖，大家可以看到支付寶移動端高可用的技術架構設計也是圍繞上述的四個核心打法展開的。
用戶端可用性監控
問題採集：用戶端可用性監控的第一步就是問題採集，當APP發生不可用時必須能夠感知和採集到問題，這是基礎的基礎，如果沒有這個基礎後續什麼都不能實現。那麼，怎樣確保當使用者出現了不可用情況時能夠採集到問題？這其實是比較困難的，因為我們不能保證一定可以採集到所有類型的不可用問題，但是還是會通過多種方法儘量地實現全面覆蓋。支付寶把不可用問題分為穩定性不可用和業務不可用兩個方面。對於穩定性不可用而言，通過2.0階段的逐漸摸索以及各種回饋管道、問題搜集管道的補充，現在已經可以把各種各樣穩定性的不可用問題搜集得比較全了，比如傳統的閃退、卡死等以及不容易被監控的黑屏、白屏以及非閃退類型的異常退出等。目前已經採集到了大部分的問題，當然可能還會存在遺漏，對於這些遺漏的問題，還需要通過不停地搜集並補充到這個體系中。對於業務不可用而言，在開發時會對於業務不可用問題進行埋點，只需要將業務不可用埋點納入到系統裡面來，就能夠基本覆蓋最重要的業務不可用問題。
統一管控：當問題採集上來之後，需要通過統一管控形成用戶端可用率指標。通過這個指標可以全面地評估線上某一個人群中的可用情況，而不需要像以前那樣逐一檢查各個指標並在最後給一個不太準確的評估結果。通過統一管控可以設計出整體的監控和報警機制以及各種演算法模型，並且其擴展性更好。
埋點上報：這一功能是非常核心的。因為後續還要利用不可用埋點做高靈敏，所以埋點的即時性、準確性、到達率的要求特別高。並且對於不可用埋點而言，當用戶端已經發生了不可用時才需要進行上報，而在這個時候用戶端情況很可能非常惡劣，甚至此時用戶端可能已經無法啟動了，即便是這樣也要保證埋點能夠上報。為了實現這一點，我們利用了一些小技巧，比如對於Android系統而言，支付寶通過獨立的羽量級進程來單獨上報埋點，即便主進程已經掛掉了，但是埋點也能夠即時上報上來；對於ios系統而言，採取線上上hold住進程使其報完埋點再退出去的方式，並且後續還有補償機制，即使出現遺漏埋點的情況也能夠使其最終能夠上報上來。
通過問題採集、統一管控和埋點上報，基本上可以保障當用戶遇到不可用問題時可以收集問題並上報服務端，做好了第一步的基礎。
高靈敏度系統模型
在問題收集到的情況下需要用高靈敏系統模型做監控和報警。其實監控和報警在2.0時代就已經存在了，比如當大盤上監控的閃退率出現異常情況時就會進行報警。但是高靈敏系統模型要做的是線上上問題剛剛出現苗頭的時候就可以發現，而不是等到大盤出現波動才發現。所以這個模型的關鍵在於分析決策的過程中，它會基於使用者的人群特徵、問題特徵把線上採集到的不可用問題進行聚合再進行分析，通過預製的一些演算法模型和規則來判斷是否產生了異常，如果最終判斷的確有異常產生了則會輸出一個異常事件。
舉個例子，比如線上的某個業務發佈了一個新的H5離線包版本，其中某一個頁面的卡死率很高。那麼使用這個頁面的使用者就會形成一個特徵人群，這個特徵人群的頁面卡死率就有異常的波動，這個時候就會輸出異常事件。但是此時大盤並沒有太大波動，因為特徵人群的人數並不多，但是後臺可以捕獲到異常事件。當異常事件輸出之後，可以通過附帶資訊準確地匹配到相應的負責人以及開發、測試人員，告警系統會告知負責人進行處理，並且會根據問題的嚴重程度採取不同的告警方式，可能會採取郵件、釘釘或者電話等方式進行告警。在問題非常嚴重的情況下，如果幾分鐘之內沒有回應就有人打電話給負責人了。通過這樣的告警機制就可以保證無論在什麼的時間，只要線上出現異常問題就可以迅速地感知到。
高可用容災平臺
通過上述的內容，已經可以實現對於可用性問題的感知了。接下來分享如何通過高可用容災平臺修復異常問題。這裡通過整體的故障容災過程進行分享，如下圖所示，當一個故障進來了，會向相應的負責人發出告警，這時負責人需要檢查這個故障是怎樣產生的，到底是由於線上變更導致的，還是由於用戶端本身的Bug導致的。如果是因為線上變更導致的則比較好辦，因為現在的系統比較靈敏，只要故障剛一發生在短時間內負責人員就可以收到告警，之後就可以到發佈記錄中檢查這段時間內發生了哪幾次變更，可以很快地基本瞭解是哪一次變更導致的故障，並採取相應的處理策略，如果可以回滾就進行回滾操作，不能回滾就需要進行緊急發佈，如果不能緊急發佈就要依賴用戶端進行修復。
比較麻煩的是和變更沒有關係的情況，此時就需要通過異常攜帶的診斷資訊或者通過獲取一些日誌來檢查問題為什麼產生，問題的產生有時候是因為相容性問題，比如某個廠商灰度發佈了一批和支付寶相容性不太好的系統，導致出現了各種各樣的問題，這種情況下就要通過動態修復解決；也可能一些客戶本地出現了嚴重錯誤，比如說產生了一些髒資料，或者安裝時因為市場的臨時性Bug導致了大量安裝失敗，最終導致支付寶打不開，對於這種情況而言，可以通過本地容災做一些恢復工作，進而實現用戶端的自動恢復。總之，通過上述的過程，可以使故障得到解決。從下圖中可以看出，支付寶在高可用容災中致力於兩點：第一，希望每個故障都有一個對應的方法能夠實現修復；第二，希望流程儘量清晰並且順滑，希望不要在流程上浪費太多時間，並且將故障儘快地解決掉。
高可用的動態修復體系
移動端高可用和服務端高可用的重大區別就是移動端的發佈比較困難，所以需要依靠動態修復技術。動態修復並不是新的概念，像hotpatch等技術都已經非常成熟了，目前也有很多可選的動態修復方案。但是，雖然在高可用的動態修復體系中，hotpatch屬於比較重要的點，但是並不是最主要的點，因為它也存在一定的局限性，也有不適合的時候。目前，支付寶基於多種修復手段搭建了高可用的動態修復體系。
支付寶的高可用動態修復體系主要由以下三部分構成：
修復手段：修復手段有很多種，並且有輕有重。輕的手段線上上進行一些配置就可以解決線上不可用的問題，重的手段可以把整個模組完全重新部署下去。具體應該選擇哪一種修復手段應該根據故障的情況來看，選擇效率最高、風險最低的修復方式。
下發通道：這一點與埋點上報的要求有一點類似，也需要高即時性和高可靠性。當用戶已經不可用了，常規方法拉不到線上的修復方案的時候，能夠解決的辦法再多也是沒有用的，所以需要保障無論面對多麼惡劣的情況下都能夠把修復方案拉下來。下發通道的實現方式有很多種，最終實現只要能夠聯網一定可以將修復方案拉下來，如果暫時不能聯網，那麼一定要在聯網之後將修復方案拉下來。
發佈平臺：設計動態修復的發佈平臺的時候非常關注的一點就是把修復方案推送給真正需要它的使用者，也就是把修復方案推給已經出現或者可能出現這個問題的用戶，這樣做的原因是每一次的動態修復其實也是一次線上變更，本身也是存在風險的，如果對於所有用戶都進行推送則需要比較長的時間進行灰度來保證安全，但是如果能夠只對目標的小眾人群、特徵人群推送方案，這樣灰度時間會很短，修復時間也會很短。支付寶在用戶端請求修復方案的時候，會根據用戶端的人群特徵、是否發生過這個問題以及有沒有發生這個問題的可能來判斷是否把這個修復方案推送給他們，這樣可以很快地完成推送過程。這在圖中稱之為“智慧修復”，其實稱之為“定向修復”更為準確一些。
高可用實戰經驗
在這裡和大家分享支付寶在高可用實戰中的兩個案例，其中一個處理的比較成功，另外一個則不是很成功。
案例1：一個業務運營推送了一個錯誤的功能表配置，而用戶端沒有做好保護。在運營推送配置的10分鐘之內，相關的負責人都收到了報警，並且很快地查到是這個配置導致的，之後運營將馬上對於配置進行了回滾，這個過程所影響用戶數比較少，所以是一個比較成功的案例。這也是支付寶最期望的運維過程，實現了及時發現、很快修復並且影響用戶數很少。
案例2：在一次大促的時候，一個業務開啟了限流，用戶端彈出一個限流的頁面，但是這個頁面有Bug，會導致黑屏，進而導致用戶無法進行操作。但是由於當時的可用性監控不完善，所以這個問題沒有被監控到，最後是因為用戶的回饋才知道出現了問題，到問題出現的第三天，回饋量已經積累到一個明顯的程度了，才發現這個問題。之後，我們迅速地對於這個問題進行了分析和解決，最後定位到限流的問題，一個小時之內確定了問題所在，並暫時把限流先關掉，後來把這個Bug修復掉了之後再將限流打開，這樣用戶端才恢復正常。雖然最終把問題完善地解決了，但是這一過程存在非常明顯的缺陷。首先是發現的太晚了，這是因為可用性問題沒有覆蓋到；另外，因為沒有足夠的資訊使得決策的過程比較慢，花了1個小時進行分析才能夠止血，直到現在我們也不知道這三天到底影響了多少用戶，但是這一事件肯定對支付寶的可用性造成了不小的傷害。而現在，支付寶實現了移動端的高可用，以後像這樣的事情不會再發生了，當出現故障時，支付寶可以在第一天很短的時間內就可以搞定問題。
故障演練
有這樣一句話“避免故障最好的方式就是不斷演練故障”，所以我們要通過可控的成本線上上真實地類比一些故障，進行故障演練，檢驗高可用體系是否可靠，同時也讓相應的同學對系統、工具和流程更加熟悉，當真正發生問題的時候可以快速地處理。
為了更好的檢驗這套東西，支付寶採用了攻防對抗演練的方式，成立了一個虛擬小組，他們會想辦法類比線路上可能出現的故障情況，而另外一組人則利用移動端高可用技術接招，把對方研發的問題快速地處理掉。這樣做好準備以後，當真正出現故障需要進行處理的時候，我們也已經能夠熟練地應對了。
在前進中探索
最後再談一下對用戶端可用性運維未來的思考：
智能化。前面提到了高靈敏的模型，大家可以看到其實在決策的過程中往往需要依賴預設的演算法模型、規則以及數值等，這些都源于常年積攢下來的經驗。但是這也存在一些缺點：一是有可能出現誤報；二是為了防止誤報太多，這個模型不敢做的太緊，所以模型的靈敏度屬於比較靈敏，而不是極度靈敏。我們期待通過智慧化的方式，通過人工智慧、機器學習的方法實現決策過程的智慧化，可以做得更加靈敏，將問題發現的時間再提升一節，而且這目前已經不僅僅是一個想法了，在支付寶的很多場景中已經開始使用智慧報警了，我們也在調研和嘗試接入這個東西。
自動化。這部分主要指的是容災過程的自動化。我們想把前面展示的容災過程做的很順滑，但是其中很多步驟都需要人來做，這樣時間成本、決策成本會很高，所以我們希望把儘量多的步驟轉成自動化方式，至少是半自動化的方式，這樣才能讓容災過程更加順滑，使得修復時間產生本質的飛越。
產品化。我們希望當用戶端可用性更加成熟之後賦能給其他類似的APP，通過這個過程積攢更多的經驗，發現更多的問題。並且在未來合適的時間，或者3.0版本的用戶端可用性不能滿足需求的時候再去建設4.0可用性運維體系。