對于移動(dòng)技術(shù)而言，2017 年是繼往開來之年。一方面是移動(dòng)技術(shù)領(lǐng)域進(jìn)入深水區(qū)，另一方面移動(dòng)技術(shù)邊界和內(nèi)涵被不斷重塑。

[[213797]]

阿里巴巴希望進(jìn)一步推動(dòng)移動(dòng)應(yīng)用研發(fā)事實(shí)標(biāo)準(zhǔn)落地，從而賦能整個(gè)行業(yè)開發(fā)者。在 2017 年杭州云棲大會上，螞蟻金服高級技術(shù)專家竹光為大家分享了螞蟻金服移動(dòng)端在高可用技術(shù)方面的具體實(shí)踐，以下內(nèi)容根據(jù)演講視頻以及 PPT 整理而成。

本次分享的內(nèi)容主要分為以下四個(gè)方面：

• 億級 APP 在可用性方面的挑戰(zhàn)
• APP 線上運(yùn)維的發(fā)展和演進(jìn)
• 移動(dòng)端高可用的定義、目標(biāo)、核心打法
• 支付寶在移動(dòng)端高可用技術(shù)實(shí)踐

億級 APP 在可用性方面的挑戰(zhàn)

可用性的概念

簡單而言，可用性就是當(dāng)用戶想要使用 APP 做一個(gè)事情，這件事情做成了就是可用，沒有做成就不可用。

為什么沒有做成？可能的原因有很多，比如有可能使用 APP 的時(shí)候閃退了，或者使用支付寶付款的時(shí)候，由于后臺某個(gè)環(huán)節(jié)出現(xiàn)錯(cuò)誤，導(dǎo)致了這筆支付失敗了等，這些都可能造成 APP 的不可用。

如果各種各樣不可用的情況都沒有出現(xiàn)，那么對于客戶而言就是可用的。雖然每個(gè)開發(fā)人員都希望自己開發(fā)的 APP 是 100% 可用的，但是實(shí)際上這一點(diǎn)是不可能的。所以開發(fā)人員真正需要做的事情就是讓 APP 發(fā)生不可用的情況越來越少。

億級 APP 的可用性挑戰(zhàn)

目前，APP 開發(fā)技術(shù)已經(jīng)比較成熟了，所以很多開發(fā)人員會認(rèn)為自己的 APP 可用性應(yīng)該問題不是很大，因?yàn)?APP 都經(jīng)歷了相關(guān)的測試流程、灰度驗(yàn)證等保障措施。

但是現(xiàn)在情況已經(jīng)發(fā)生變化了，與以前相比，APP 的用戶量大了很多，很多的 APP 都達(dá)到了億級用戶，所以一點(diǎn)點(diǎn)可用性問題都可能會影響大量的用戶。

比如 APP 的閃退率上漲了千分之一，雖然這一比例并不是很大，但是對于一億用戶而言，乘上千分之一就是 10 萬人。

大家可以想象一下，如果某一天大家在使用支付寶在超市付款的時(shí)候，其中的 10 萬人出現(xiàn)閃退的情況，這個(gè)影響是絕對不可以接受的。

現(xiàn)在開發(fā)移動(dòng)端 APP 講究動(dòng)態(tài)化，業(yè)務(wù)要求實(shí)時(shí)動(dòng)態(tài)地實(shí)現(xiàn)線上變更，可以說今天的支付寶和昨天的支付寶相比就已經(jīng)產(chǎn)生很大區(qū)別了。

每一次線上的變更其實(shí)都會增加線上可用性的風(fēng)險(xiǎn)，而且一天中可能會發(fā)生很多次變更，在這種情況下風(fēng)險(xiǎn)也會變得很大。尤其對于作為保障 APP 可用性的一線人員而言，壓力也會特別大。

正是因?yàn)槊媾R這么多的問題和挑戰(zhàn)，才需要通過移動(dòng)端的高可用技術(shù)體系解決這個(gè)問題，保證線上客戶端高可用性。

APP 線上運(yùn)維的發(fā)展和演進(jìn)

如上圖，是這幾年來支付寶客戶端在可用性運(yùn)維上的發(fā)展歷史，大致分為了三個(gè)階段。隨著支付寶的成長，可用性運(yùn)維也一直在演進(jìn)，***演進(jìn)到了移動(dòng)端高可用的狀態(tài)。

***個(gè)階段就是簡單的閃退監(jiān)控。絕大多數(shù)的 APP 也做過這個(gè)事情，就是本地收集一些閃退信息并進(jìn)行上報(bào)，在 APP 后臺對于閃退率進(jìn)行監(jiān)控，解決閃退比較多的問題，并在 APP 的下一個(gè)版本中進(jìn)行相應(yīng)的修改，***使閃退率維持在某一個(gè)指標(biāo)以下。

但是現(xiàn)在來看，這個(gè)階段距離實(shí)現(xiàn)高可用的要求相差很遠(yuǎn)，因?yàn)橛脩羲龅讲豢捎脝栴}中閃退只占據(jù)其中一部分，所以對可用性而言，解決了閃退問題只是改進(jìn)了一點(diǎn)點(diǎn)而已，還存在著大部分的問題沒有解決。

第二個(gè)階段，在阿里巴巴內(nèi)部叫做穩(wěn)定性監(jiān)控體系，相比于***個(gè)階段而言，穩(wěn)定性監(jiān)控體系可以說前進(jìn)了非常大的一步。

首先，可以監(jiān)控的問題大大豐富了，通過對多種問題的監(jiān)控可以了解線上用戶穩(wěn)定性方面的可用情況，而不僅僅是一個(gè)用戶。

第二個(gè)方面，穩(wěn)定性監(jiān)控體系具有相當(dāng)程度的診斷能力和修復(fù)能力。當(dāng)發(fā)現(xiàn)問題的時(shí)候，可以通過診斷日志等相應(yīng)的方法分析故障原因并嘗試進(jìn)行修復(fù)。

穩(wěn)定性監(jiān)控體系在最初的時(shí)候效果比較不錯(cuò)，并且阿里巴巴內(nèi)部也使用了很長的時(shí)間，但是后來問題也逐漸暴露出來。

舉兩個(gè)例子，曾經(jīng)一個(gè)版本的 APP 在 X86 一款機(jī)器上運(yùn)行時(shí)出現(xiàn)的問題非常多，但是那個(gè)機(jī)型的用戶量很小，所以問題一直都沒有被發(fā)現(xiàn)，直到很晚的時(shí)候才通過其他方式發(fā)現(xiàn)了這個(gè)問題，也就是說因?yàn)橹槐O(jiān)控具體問題導(dǎo)致已經(jīng)不能發(fā)現(xiàn)局部人群的問題了。

第二個(gè)例子，在做像雙 11 這樣的大促值班的技術(shù)保障的時(shí)候，因?yàn)楸O(jiān)控的問題比較多，運(yùn)維人員需要通過不停地翻監(jiān)控來發(fā)現(xiàn)問題，翻來翻去***還是不敢確定 APP 的可用性到底有沒有問題，有時(shí)候確實(shí)會遺漏一些問題。

第三個(gè)方案就是在發(fā)現(xiàn)了問題之后，能否快速修復(fù)還需要碰運(yùn)氣，有可能很快就能夠修復(fù)，也有可能修復(fù)起來不太容易，需要等到下一次發(fā)版，這就使得有些問題所影響用戶數(shù)會非常多。

以上就是在 2.0 階段所遇到的問題，這說明穩(wěn)定性監(jiān)控體系也已經(jīng)不夠用了，需要繼續(xù)進(jìn)行改進(jìn)，這也是支付寶決定繼續(xù)做 3.0 階段的移動(dòng)端高可用的動(dòng)機(jī)和動(dòng)力。

移動(dòng)端高可用的定義、目標(biāo)、核心打法

高可用在移動(dòng)端的重新定義

高可用原本屬于服務(wù)端的概念，阿里巴巴的服務(wù)端都在講高可用。服務(wù)端的高可用重點(diǎn)講的是停機(jī)時(shí)間短、服務(wù)不可用時(shí)間短。

移動(dòng)端的高可用從服務(wù)端借鑒過來之后進(jìn)行了重新定義，因?yàn)榭蛻舳瞬淮嬖谕C(jī)時(shí)間概念。

所以，移動(dòng)端高可用的定義是指通過專門的設(shè)計(jì)，結(jié)合整套技術(shù)體系，保證用戶所遇到的技術(shù)不可用總次數(shù)很低。

移動(dòng)端高可用的目標(biāo)

簡單來說，移動(dòng)端高可用的目標(biāo)就是實(shí)現(xiàn)可用率達(dá)到 99.99%，這里的可用率是支付寶自己定義的概念，指的就是用戶在使用 APP 的時(shí)候，可用次數(shù)在使用次數(shù)當(dāng)中的占比，可用率達(dá)到 99.99%。

也就意味著用戶使用 1 萬次支付寶中的 9999 次都必須是可用的，最多只有一次不可用。為了實(shí)現(xiàn)這一目標(biāo)，還會將任務(wù)拆解成為不同的子目標(biāo)分別攻克。

移動(dòng)端高可用的核心打法

目標(biāo)的實(shí)現(xiàn)還是比較困難的，因?yàn)樽尶捎寐蔬_(dá)到 99.99% 是一個(gè)很高的指標(biāo)。而為了能夠努力實(shí)現(xiàn)這個(gè)目標(biāo)，支付寶也自創(chuàng)了一套核心打法。

主要分為以下四個(gè)部分：

• 客戶端可用性監(jiān)控。用戶遇到不可用的時(shí)候，要把造成不可用的問題收集并上報(bào)上來，并且要提供足夠的診斷信息用于分析解決。
• 高靈敏監(jiān)控報(bào)警平臺。需要實(shí)現(xiàn)當(dāng)線上的問題剛剛出現(xiàn)苗頭的時(shí)候就立即能夠發(fā)現(xiàn)。
• 快速修復(fù)能力。當(dāng)發(fā)現(xiàn)問題之后不僅要保證能夠修復(fù)，還要保證修復(fù)的速度足夠快。對一些級別高的故障，支付寶要求在一個(gè)小時(shí)之內(nèi)完成快速修復(fù)。
• 故障演練。

支付寶在移動(dòng)端高可用技術(shù)實(shí)踐

如上圖所示，是支付寶實(shí)現(xiàn)的移動(dòng)端高可用技術(shù)架構(gòu)圖，大家可以看到支付寶移動(dòng)端高可用的技術(shù)架構(gòu)設(shè)計(jì)也是圍繞上述的四個(gè)核心打法展開的。

客戶端可用性監(jiān)控

問題采集

客戶端可用性監(jiān)控的***步就是問題采集，當(dāng) APP 發(fā)生不可用時(shí)必須能夠感知和采集到問題，這是基礎(chǔ)的基礎(chǔ)，如果沒有這個(gè)基礎(chǔ)后續(xù)什么都不能實(shí)現(xiàn)。

怎樣確保當(dāng)用戶出現(xiàn)了不可用情況時(shí)能夠采集到問題？這是比較困難的，因?yàn)槲覀儾荒鼙ＷC一定可以采集到所有類型的不可用問題，但是還是會通過多種方法盡量地實(shí)現(xiàn)全面覆蓋。

支付寶把不可用問題分為穩(wěn)定性不可用和業(yè)務(wù)不可用兩個(gè)方面。對于穩(wěn)定性不可用而言，通過 2.0 階段的逐漸摸索以及各種反饋渠道、問題搜集渠道的補(bǔ)充，現(xiàn)在已經(jīng)可以把各種各樣穩(wěn)定性的不可用問題搜集得比較全了。

比如傳統(tǒng)的閃退、卡死等以及不容易被監(jiān)控的黑屏、白屏以及非閃退類型的異常退出等。

目前已經(jīng)采集到了大部分的問題，當(dāng)然可能還會存在遺漏，對于這些遺漏的問題，還需要通過不停地搜集并補(bǔ)充到這個(gè)體系中。

對于業(yè)務(wù)不可用而言，在開發(fā)時(shí)會對于業(yè)務(wù)不可用問題進(jìn)行埋點(diǎn)，只需要將業(yè)務(wù)不可用埋點(diǎn)納入到系統(tǒng)里面來，就能夠基本覆蓋最重要的業(yè)務(wù)不可用問題。

統(tǒng)一管控

當(dāng)問題采集上來之后，需要通過統(tǒng)一管控形成客戶端可用率指標(biāo)。通過這個(gè)指標(biāo)可以全面地評估線上某一個(gè)人群中的可用情況，而不需要像以前那樣逐一檢查各個(gè)指標(biāo)并在***給一個(gè)不太準(zhǔn)確的評估結(jié)果。通過統(tǒng)一管控可以設(shè)計(jì)出整體的監(jiān)控和報(bào)警機(jī)制以及各種算法模型，并且其擴(kuò)展性更好。

埋點(diǎn)上報(bào)

埋點(diǎn)上報(bào)這一功能是非常核心的，因?yàn)楹罄m(xù)還要利用不可用埋點(diǎn)做高靈敏，所以埋點(diǎn)的實(shí)時(shí)性、準(zhǔn)確性、到達(dá)率的要求特別高。

并且對于不可用埋點(diǎn)而言，當(dāng)客戶端已經(jīng)發(fā)生了不可用時(shí)才需要進(jìn)行上報(bào)，而在這個(gè)時(shí)候客戶端情況很可能非常惡劣，甚至此時(shí)客戶端可能已經(jīng)無法啟動(dòng)了，即便是這樣也要保證埋點(diǎn)能夠上報(bào)。

為了實(shí)現(xiàn)這一點(diǎn)，我們利用了一些小技巧，比如對于 Android 系統(tǒng)而言，支付寶通過獨(dú)立的輕量級進(jìn)程來單獨(dú)上報(bào)埋點(diǎn)，即便主進(jìn)程已經(jīng)掛掉了，但是埋點(diǎn)也能夠?qū)崟r(shí)上報(bào)上來。

對于 iOS 系統(tǒng)而言，采取在線上 hold 住進(jìn)程使其報(bào)完埋點(diǎn)再退出去的方式，并且后續(xù)還有補(bǔ)償機(jī)制，即使出現(xiàn)遺漏埋點(diǎn)的情況也能夠使其最終能夠上報(bào)上來。

通過問題采集、統(tǒng)一管控和埋點(diǎn)上報(bào)，基本上可以保障當(dāng)用戶遇到不可用問題時(shí)可以收集問題并上報(bào)服務(wù)端，做好了***步的基礎(chǔ)。

高靈敏度系統(tǒng)模型

在問題收集到的情況下需要用高靈敏系統(tǒng)模型做監(jiān)控和報(bào)警。監(jiān)控和報(bào)警在 2.0 時(shí)代就已經(jīng)存在了，比如當(dāng)大盤上監(jiān)控的閃退率出現(xiàn)異常情況時(shí)就會進(jìn)行報(bào)警。

但是高靈敏系統(tǒng)模型要做的是在線上問題剛剛出現(xiàn)苗頭的時(shí)候就可以發(fā)現(xiàn)，而不是等到大盤出現(xiàn)波動(dòng)才發(fā)現(xiàn)。

所以這個(gè)模型的關(guān)鍵在于分析決策的過程中，它會基于用戶的人群特征、問題特征把線上采集到的不可用問題進(jìn)行聚合再進(jìn)行分析，通過預(yù)制的一些算法模型和規(guī)則來判斷是否產(chǎn)生了異常，如果最終判斷的確有異常產(chǎn)生了則會輸出一個(gè)異常事件。

舉個(gè)例子，比如線上的某個(gè)業(yè)務(wù)發(fā)布了一個(gè)新的 H5 離線包版本，其中某一個(gè)頁面的卡死率很高。那么使用這個(gè)頁面的用戶就會形成一個(gè)特征人群，這個(gè)特征人群的頁面卡死率就有異常的波動(dòng)，這個(gè)時(shí)候就會輸出異常事件。

但是此時(shí)大盤并沒有太大波動(dòng)，因?yàn)樘卣魅巳旱娜藬?shù)并不多，但是后臺可以捕獲到異常事件。

當(dāng)異常事件輸出之后，可以通過附帶信息準(zhǔn)確地匹配到相應(yīng)的負(fù)責(zé)人以及開發(fā)、測試人員，告警系統(tǒng)會告知負(fù)責(zé)人進(jìn)行處理，并且會根據(jù)問題的嚴(yán)重程度采取不同的告警方式，可能會采取郵件、釘釘或者電話等方式進(jìn)行告警。

在問題非常嚴(yán)重的情況下，如果幾分鐘之內(nèi)沒有響應(yīng)就有人打電話給負(fù)責(zé)人了。通過這樣的告警機(jī)制就可以保證無論什么時(shí)間，只要線上出現(xiàn)異常問題就可以迅速地感知到。

高可用容災(zāi)平臺

通過上述的內(nèi)容，我們已經(jīng)可以實(shí)現(xiàn)對于可用性問題的感知了。接下來分享如何通過高可用容災(zāi)平臺修復(fù)異常問題。

這里通過整體的故障容災(zāi)過程進(jìn)行分享，如下圖所示，當(dāng)一個(gè)故障進(jìn)來了，會向相應(yīng)的負(fù)責(zé)人發(fā)出告警，這時(shí)負(fù)責(zé)人需要檢查這個(gè)故障是怎樣產(chǎn)生的，到底是由于線上變更導(dǎo)致的，還是由于客戶端本身的 Bug 導(dǎo)致的。

如果是因?yàn)榫€上變更導(dǎo)致的則比較好辦，因?yàn)楝F(xiàn)在的系統(tǒng)比較靈敏，只要故障剛一發(fā)生，在短時(shí)間內(nèi)負(fù)責(zé)人員就可以收到告警。

之后就可以到發(fā)布記錄中檢查這段時(shí)間內(nèi)發(fā)生了哪幾次變更，可以很快地基本了解是哪一次變更導(dǎo)致的故障，并采取相應(yīng)的處理策略。

如果可以回滾就進(jìn)行回滾操作，不能回滾就需要進(jìn)行緊急發(fā)布，如果不能緊急發(fā)布就要依賴客戶端進(jìn)行修復(fù)。

比較麻煩的是和變更沒有關(guān)系的情況，此時(shí)就需要通過異常攜帶的診斷信息或者通過獲取一些日志來檢查問題為什么產(chǎn)生，問題的產(chǎn)生有時(shí)候是因?yàn)榧嫒菪詥栴}。

比如某個(gè)廠商灰度發(fā)布了一批和支付寶兼容性不太好的系統(tǒng)，導(dǎo)致出現(xiàn)了各種各樣的問題，這種情況下就要通過動(dòng)態(tài)修復(fù)解決。

也可能一些客戶本地出現(xiàn)了嚴(yán)重錯(cuò)誤，比如說產(chǎn)生了一些臟數(shù)據(jù)，或者安裝時(shí)因?yàn)槭袌龅呐R時(shí)性 Bug 導(dǎo)致了大量安裝失敗，最終導(dǎo)致支付寶打不開。

對于這種情況而言，可以通過本地容災(zāi)做一些恢復(fù)工作，進(jìn)而實(shí)現(xiàn)客戶端的自動(dòng)恢復(fù)。

總之，通過上述的過程，可以使故障得到解決。從下圖中可以看出，支付寶在高可用容災(zāi)中致力于兩點(diǎn)：

• 希望每個(gè)故障都有一個(gè)對應(yīng)的方法能夠?qū)崿F(xiàn)修復(fù)。
• 希望流程盡量清晰并且順滑，希望不要在流程上浪費(fèi)太多時(shí)間，并且將故障盡快地解決掉。

高可用的動(dòng)態(tài)修復(fù)體系

移動(dòng)端高可用和服務(wù)端高可用的重大區(qū)別就是移動(dòng)端的發(fā)布比較困難，所以需要依靠動(dòng)態(tài)修復(fù)技術(shù)。

動(dòng)態(tài)修復(fù)并不是新的概念，像 hotpatch 等技術(shù)都已經(jīng)非常成熟了，目前也有很多可選的動(dòng)態(tài)修復(fù)方案。

但是，雖然在高可用的動(dòng)態(tài)修復(fù)體系中，hotpatch 屬于比較重要的點(diǎn)，但是并不是最主要的點(diǎn)，因?yàn)樗泊嬖谝欢ǖ木窒扌裕灿胁贿m合的時(shí)候。目前，支付寶基于多種修復(fù)手段搭建了高可用的動(dòng)態(tài)修復(fù)體系。

支付寶的高可用動(dòng)態(tài)修復(fù)體系主要由以下三部分構(gòu)成：

修復(fù)手段

修復(fù)手段有很多種，并且有輕有重。輕的手段在線上進(jìn)行一些配置就可以解決線上不可用的問題，重的手段可以把整個(gè)模塊完全重新部署下去。具體應(yīng)該選擇哪一種修復(fù)手段應(yīng)該根據(jù)故障的情況來看，選擇效率***、風(fēng)險(xiǎn)***的修復(fù)方式。

下發(fā)通道

這一點(diǎn)與埋點(diǎn)上報(bào)的要求有一點(diǎn)類似，也需要高實(shí)時(shí)性和高可靠性。當(dāng)用戶已經(jīng)不可用了，常規(guī)方法拉不到線上的修復(fù)方案的時(shí)候，能夠解決的辦法再多也是沒有用的，所以需要保障無論面對多么惡劣的情況下都能夠把修復(fù)方案拉下來。

下發(fā)通道的實(shí)現(xiàn)方式有很多種，最終實(shí)現(xiàn)只要能夠聯(lián)網(wǎng)一定可以將修復(fù)方案拉下來，如果暫時(shí)不能聯(lián)網(wǎng)，那么一定要在聯(lián)網(wǎng)之后將修復(fù)方案拉下來。

發(fā)布平臺

設(shè)計(jì)動(dòng)態(tài)修復(fù)的發(fā)布平臺的時(shí)候非常關(guān)注的一點(diǎn)就是把修復(fù)方案推送給真正需要它的用戶，也就是把修復(fù)方案推給已經(jīng)出現(xiàn)或者可能出現(xiàn)這個(gè)問題的用戶。

這樣做的原因是每一次的動(dòng)態(tài)修復(fù)其實(shí)也是一次線上變更，本身也是存在風(fēng)險(xiǎn)的，如果對于所有用戶都進(jìn)行推送則需要比較長的時(shí)間進(jìn)行灰度來保證安全，但是如果能夠只對目標(biāo)的小眾人群、特征人群推送方案，這樣灰度時(shí)間會很短，修復(fù)時(shí)間也會很短。

支付寶在客戶端請求修復(fù)方案的時(shí)候，會根據(jù)客戶端的人群特征、是否發(fā)生過這個(gè)問題以及有沒有發(fā)生這個(gè)問題的可能來判斷是否把這個(gè)修復(fù)方案推送給他們，這樣可以很快地完成推送過程。這在圖中稱之為“智能修復(fù)”，其實(shí)稱之為“定向修復(fù)”更為準(zhǔn)確一些。

高可用實(shí)戰(zhàn)經(jīng)驗(yàn)

在這里和大家分享支付寶在高可用實(shí)戰(zhàn)中的兩個(gè)案例，其中一個(gè)處理的比較成功，另外一個(gè)則不是很成功。

案例 1：一個(gè)業(yè)務(wù)運(yùn)營推送了一個(gè)錯(cuò)誤的菜單配置，而客戶端沒有做好保護(hù)。在運(yùn)營推送配置的 10 分鐘之內(nèi)，相關(guān)的負(fù)責(zé)人都收到了報(bào)警，并且很快地查到是這個(gè)配置導(dǎo)致的。

之后運(yùn)營將馬上對于配置進(jìn)行了回滾，這個(gè)過程所影響用戶數(shù)比較少，所以是一個(gè)比較成功的案例。

這也是支付寶最期望的運(yùn)維過程，實(shí)現(xiàn)了及時(shí)發(fā)現(xiàn)、很快修復(fù)并且影響用戶數(shù)很少。

案例 2：在一次大促的時(shí)候，一個(gè)業(yè)務(wù)開啟了限流，客戶端彈出一個(gè)限流的頁面，這個(gè)頁面有 Bug，會導(dǎo)致黑屏，進(jìn)而導(dǎo)致用戶無法進(jìn)行操作。

但是由于當(dāng)時(shí)的可用性監(jiān)控不完善，所以這個(gè)問題沒有被監(jiān)控到，***是因?yàn)橛脩舻姆答伈胖莱霈F(xiàn)了問題，到問題出現(xiàn)的第三天，反饋量已經(jīng)積累到一個(gè)明顯的程度了，才發(fā)現(xiàn)這個(gè)問題。

之后，我們迅速地對于這個(gè)問題進(jìn)行了分析和解決，***定位到限流的問題，一個(gè)小時(shí)之內(nèi)確定了問題所在，并暫時(shí)把限流先關(guān)掉，后來把這個(gè) Bug 修復(fù)掉了之后再將限流打開，這樣客戶端才恢復(fù)正常。

雖然最終把問題完善地解決了，但是這一過程存在非常明顯的缺陷。首先是發(fā)現(xiàn)的太晚了，這是因?yàn)榭捎眯詥栴}沒有覆蓋到。

另外，因?yàn)闆]有足夠的信息使得決策的過程比較慢，花了 1 個(gè)小時(shí)進(jìn)行分析才能夠止血，直到現(xiàn)在我們也不知道這三天到底影響了多少用戶，但是這一事件肯定對支付寶的可用性造成了不小的傷害。

而現(xiàn)在，支付寶實(shí)現(xiàn)了移動(dòng)端的高可用，以后像這樣的事情不會再發(fā)生了，當(dāng)出現(xiàn)故障時(shí)，支付寶可以在***天很短的時(shí)間內(nèi)就可以搞定問題。

故障演練

有這樣一句話“避免故障***的方式就是不斷演練故障”，所以我們要通過可控的成本在線上真實(shí)地模擬一些故障，進(jìn)行故障演練，檢驗(yàn)高可用體系是否可靠，同時(shí)也讓相應(yīng)的同學(xué)對系統(tǒng)、工具和流程更加熟悉，當(dāng)真正發(fā)生問題的時(shí)候可以快速地處理。

為了更好的檢驗(yàn)這套東西，支付寶采用了攻防對抗演練的方式，成立了一個(gè)虛擬小組，他們會想辦法模擬線上可能出現(xiàn)的故障情況，而另外一組人則利用移動(dòng)端高可用技術(shù)接招，把對方研發(fā)的問題快速地處理掉。

這樣做好準(zhǔn)備以后，當(dāng)真正出現(xiàn)故障需要進(jìn)行處理的時(shí)候，我們也已經(jīng)能夠熟練地應(yīng)對了。

在前進(jìn)中探索

***再談一下對客戶端可用性運(yùn)維未來的思考：

智能化

前面提到了高靈敏的模型，大家可以看到在決策的過程中往往需要依賴預(yù)設(shè)的算法模型、規(guī)則以及數(shù)值等，這些都源于常年積攢下來的經(jīng)驗(yàn)。

但是這也存在一些缺點(diǎn)：一是有可能出現(xiàn)誤報(bào)；二是為了防止誤報(bào)太多，這個(gè)模型不敢做的太緊，所以模型的靈敏度屬于比較靈敏，而不是極度靈敏。

我們期待通過智能化的方式，通過人工智能、機(jī)器學(xué)習(xí)的方法實(shí)現(xiàn)決策過程的智能化，可以做得更加靈敏，將問題發(fā)現(xiàn)的時(shí)間再提升一節(jié)，而且這目前已經(jīng)不僅僅是一個(gè)想法了，在支付寶的很多場景中已經(jīng)開始使用智能報(bào)警了，我們也在調(diào)研和嘗試接入這個(gè)東西。

自動(dòng)化

這部分主要指的是容災(zāi)過程的自動(dòng)化。我們想把前面展示的容災(zāi)過程做的很順滑，但是其中很多步驟都需要人來做，這樣時(shí)間成本、決策成本會很高。

所以我們希望把盡量多的步驟轉(zhuǎn)成自動(dòng)化方式，至少是半自動(dòng)化的方式，這樣才能讓容災(zāi)過程更加順滑，使得修復(fù)時(shí)間產(chǎn)生本質(zhì)的飛越。

產(chǎn)品化

我們希望當(dāng)客戶端可用性更加成熟之后賦能給其他類似的 APP，通過這個(gè)過程積攢更多的經(jīng)驗(yàn)，發(fā)現(xiàn)更多的問題。并且在未來合適的時(shí)間，或者 3.0 版本的客戶端可用性不能滿足需求的時(shí)候再去建設(shè) 4.0 可用性運(yùn)維體系。