據報道，近日，由于中國聯通整治違規(guī)互聯網接入及大帶寬業(yè)務，某CDN/IDC服務商業(yè)務中斷，華為云故障一整天，導致生意幫一整天當機，脈脈服務器掛了，失聯15個小時……

　　接著整個經歷就非常崩潰了：用戶不間斷的咨詢投訴，很多用戶幾百萬的生意，重要的戰(zhàn)略合作受影響，重要數據和資料的無法調用，CDN直播叫停……都因為網絡故障而停擺，影響甚大。

　　意外在所難免。用戶和客戶是無辜的。如何保障自己的技術和服務的高可用性，做到即使在出現0.0001%的故障發(fā)生率的情況下，仍然可以給用戶和客戶提供高可用性，保證災難情況下網絡服務的及時恢復，是云技術服務商、提供商必須面對，又亟待解決的重要問題。

　　什么是高可用性？

　　要了解高可用性對于服務提供商的必要性和重要性，首先我們要了解什么是高可用性。一般來講，一個靠譜的云服務一定是：

　　可用性非常高的，24*7隨時可以用。

　　可控性一定要好，非云服務你可以上個鎖，云服務沒法上鎖，如何能做到可控性很好是一個難點。

　　災難恢復，是軟件就會有問題。怎么樣積極地面對這個問題，多長時間恢復，如何恢復，是否有成熟的預案這是任何一個云廠商都要誠實面對的問題。

　　首先，我們來看一下可用性的評判標準，就是SLA，Service Level Agreement。一個東西是不是高可用，那么就問他幾個九，敢不敢拿出來說一下。

　　3個9基本上是國內云服務的基礎線。也就是說云服務至少要做到3個9才稱為基本上可用，是合格性產品。如果做不到這個，你的產品就連忽悠客戶都做不到了。回去重新開發(fā)，重新裝備，刷到至少3個9再回來。

　　從3個9邁向4個9，也就是99.99%的可用性，每年只有52.6分鐘的時間是不可用的。以前谷歌搜索可用度大概是全球5個9到6個9之間，每一個小節(jié)點都是5個9不到6個9之間。其實這個是很可怕的一個概念，也就意味著即使有不可抗力，發(fā)生了臺風，洪水，地震等重大災害性事件，也只需要5分鐘內恢復服務。

　　相較而言，大部分國內的IDC機房都是按照99%設計的，一年至少3天是不可用的。這一標準，給了廠商一定的機動時間，也提供了一定的靈活性。

　　所以說，從3個9往上，每一次提升都是一次技術的挑戰(zhàn)。SLA直接反映一個云服務的靠譜程度：

　　從99%到3個9，是基本可以靠人力和運氣解決的；

　　從3個9到4個9，考驗的是運維自動化的能力，災備的能力；

　　從4個9往上基本考驗的是服務基礎架構、業(yè)務設計的能力。

　　聲網Agora.io一直在4個9到5個9之間努力，這個目前還是很有難度的。為了保證高可用性，聲網Agora.io特意將核心機房分布在全球各地，以減少地區(qū)性的網絡故障對于通信的影響，同時，核心機房用了十幾家不同的IDC，即使某家的網絡故障了，也能最大限度上保障服務的穩(wěn)定性。

　　聲網在全球部署了覆蓋四個大洲的虛擬實時通信網，100多個數據中心，近千臺服務器，每年為用戶提供數千億分鐘的網絡通話服務，這一系列的舉動都是為了充分確保接入SDK的客戶隨時隨地獲得高質量的通話服務。

　　我們認為，要提升高可用性，需要從方方面面整體布局。

　　從架構上，聲網的所有服務都有多點備份，并且所有備份節(jié)點都能夠獨立服務，不依賴其他節(jié)點。任何機房故障，甚至幾個機房同時故障都不會影響到整體服務，除非所有節(jié)點同時發(fā)生故障。

　　聲網的SDK也能夠快速切換，一旦檢測到某個服務節(jié)點不可用，可以快速切換到其他備份節(jié)點。

　　當然，武功再高，也怕菜刀。為了防范一些萬一的故障導致服務不可用，聲網還有一系列措施應對故障。

　　首先聲網部署了實時故障檢測系統(tǒng)。在服務用戶的同時，該系統(tǒng)收集整個系統(tǒng)服務狀態(tài)，并實時分析。如果遇到服務數據異常立即報警。

　　接下來，聲網的數據分析系統(tǒng)可以對服務數據進行多個維度和層面的分析匯總。在故障發(fā)生時，可以快速判斷是哪個模塊或者機房出現問題。有了這個系統(tǒng)，聲網就可以快速定位故障。比如常見的數據庫故障，進程崩潰，遇到性能瓶頸，還有此次事件的主角——機房故障。

　　在定位了問題之后，聲網還有一套工具能夠實時調整線上系統(tǒng)，進行故障隔離。比如遇到某些數據庫瓶頸時，能夠暫時關閉某些數據庫的寫服務，不影響讀數據。能夠暫停某個機房的服務，避免用戶受到影響。或者某些后臺服務故障，暫時禁用，不讓用戶的音視頻通信受到影響。

　　在進行故障隔離后，或者遇到難以隔離的故障，就需要快速恢復了。對于常見的進程崩潰，聲網有自動化的包管理工具可以一鍵重啟，回滾到前一個穩(wěn)定版本。對于數據庫故障，有數據庫工具可以快速重建數據庫，并恢復數據。即使遇到這次事件中的機房故障，除了架構設計能夠保證服務基本不受影響外，也有機房上架工具能夠快速上架，并使用部署工具重新部署一個新的機房。一般而言，聲網上架一個新機房僅需幾十分鐘。

　　故障隔離處理后，聲網會盡快對故障的根本原因做一個徹底的調查。首先從系統(tǒng)中收集各種數據和日志，進行分析，并嘗試建立測試環(huán)境以確認故障的根本原因。

　　最后，需要進行服務改進。改進主要從幾個方面著手：第一，修復問題。直接修復bug，改進算法性能等。第二，架構改進。下一次這個模塊再出問題，怎么樣設計系統(tǒng)才能夠讓服務不受影響？如何設計多點備份？第三，工具改進。下次再出現這些問題，需要哪些工具可以幫助更快速的定位，對故障進行隔離，更快速的恢復故障？

　　面對市場上魚龍混雜的云服務提供商，開發(fā)者應該如何正確地甄別和選擇高可用度的服務呢？三個層面：

　　觀察該服務商的架構是否符合高可用度，SLA一定要達到4個9；

　　是否具備完整的、實時的災難預案。從問題發(fā)生的預警，到問題定位分析，到問題解決和服務恢復，是否能在最快的時間內完成，將用戶的損失降到最低，

　　是否把服務可用性當成生命線的信仰。