支付寶故障事件引發了大量的關注和讨論。事情基本過程是因為電信營運商光纖被挖斷，導緻支付寶服務故障，2小時左右後服務恢複正常。本人曾有幸做過一些關于系統可靠性方面的工作，想借此次事件抱着抛磚引玉的态度，班門弄斧地談一下系統的可靠性和對yunos可靠性的一些想法。
系統可靠性對于availability, 經典定義是：
mtbf: meantime between failures, 即平均故障間隔，就是從新的産品在規定的工作環境條件下開始工作到出現第一個故障的時間的平均值。mtbf越長表示可靠性越高正确工作能力越強 。通常mtbf關注點在硬體，但是對于整個系統的availability來說，軟體因素也是必須要考慮的。
mttr: meantime to repair，即平均恢複時間。就是從出現故障到恢複中間的這段時間。mttr越短表示易恢複性越好。
mttf: meantime to failure，即平均失效時間。系統平均能夠正常運作多長時間，才發生一次故障。系統的可靠性越高，平均無故障時間越長。(mtbf = mttf + mttr)
由于上面的經典公式比較泛化，業界除了軍事和航天外都沒有明确的計算标準，是以計算availability通常會采用下面的公式： 即服務總時間減去曆次服務中斷的時間除以服務總時間。
上面公式引入的outage的 概念，一般翻譯為服務中斷。按照産生原因可以分為3類, 通常在系統設計中隻關注第1類即産品因素導緻的outage:
由産品因素導緻 – 包括: 系統設計, 硬體, 軟體, 系統元件缺陷; 系統設計中包括的必要的計劃内的服務中斷; 由于執行例行維護導緻的
客戶因素導緻 – 主要包括：流程問題或錯誤; 服務環境因素：電源，地線，溫度，濕度，安全問題等
外部因素導緻 –包括：自然災難，如飓風，洪水，地震等; 由與客戶無關的第三方因素，如挖掘機
tl9000 标準中定義了2類outage類型：
服務完全中斷 （total outage）: 系統内的所有主要功能無法工作
服務部分中斷 （partial outage）: 系統的服務能力下降一定比例（如20%），或系統内部分元件或功能無法工作
其中：
“主要功能”的定義在不同使用者會稍有不同
服務部分中斷的比例是可以分攤和等價計算的，如10分鐘内失去50% 服務能力可以等價于5分鐘内失去100%服務能力
少量的服務能力中斷可以不算做outage, 如 <10%的系統服務能力
短時間内的服務能力中斷可以不算做outage, 如，<15秒的服務中斷可以不計算在5個9可靠性中的outage, 但如果要求高于5個9的可靠性，可不計算的中斷時間标準就需要縮短。
經常會聽到有産品介紹自己的可靠性時會說達到了幾個9，那麼具體是什麼概念呢？
平均計算一年的時間，包括閏年有365.25天，即525960分鐘 (365.25 * 24 * 60)
從表格中可以看出，5個9對應着一年中的服務downtime 要求 <= 5.26分鐘；3個9對應着一年中的服務downtime 要求 <= 525.96分鐘，大約為不到9個小時
除了幾個9的要求，還有dpm （defect per million request or task）, 即在1百萬請求或者操作當中，處理失敗的數量，一般dpm 與 幾個9的對應關系大緻為：
1 dpm 對應99.9999% availability, 即6個9
10 dpm對應99.999% availability, 即5個9
1000 dpm對應99.9% availability, 即3個9
此外，系統運作出現錯誤要求能夠及時探測，并且在規定時間内完成服務切換，如上文中提到的，5個9要求自動切換時間<15秒。這裡涉及的内容較多，同時與本人目前從事yunos工作關聯不是特别緊密，就不展開詳述了，如：
高可靠性可用性與彈性擴充 (high availability & scalability & elasticity)
容錯與災難恢複(fault tolerance & disaster recovery)
備份與恢複 (backup & restore)
負載均衡 (load balancing)
内容分發 (content distribution)
沒有特别關注這個事件的具體細節，隻是有個了解，從公開途徑得知的大緻情況是：
有小部分業務通過異地多活 （geo-redundancy and multi-active）的容災政策做到了實時業務切換
不支援多活業務的部分用了2個小時左右完成了業務切換, 這2個小時造成了部分服務的outage。
從上文的分析可以得知，這次支付寶服務中斷屬于由外部因素導緻的partial outage；好像也沒聽說之前還出過其他outage, 就假定沒有了；如果本年内不再有其他計劃外的outage，則本年内支付寶服務的availability 和 reliability可以達到99.9% - 99.99%, 介于3個9 與 4個9之間，非常接近4個9。 應該處于網際網路服務高端位置，但是還沒有達到其他有更高要求領域的标準，如電信領域的營運商客戶普遍要求5個9，99.999%的可用性。
從中可以看到由于異地多活的容災政策，讓小部分業務可以完成短時切換，完全滿足了high availability 和 reliability的要求。
但是作者也大膽推測異地多活目前可能還是試用階段，大部分受影響的其他業務很可能還不支援異地多活。如果支援的是active-standby模式，備份服務在服務中斷事件發生時是否立即啟用自動代替主服務，即備份服務的failover recovery政策是否及時生效，同時異地容錯(geo-redundancy)是否支援, 這些從公開的資訊中都沒有提及，不過從出現2個小時的partial outage的結果來看還是有不少地方可以改進的。
上面提到了異地多活，這裡還想在對geo-redundancy 和 fault tolerance & disaster recovery再多說幾句。容災政策可以分為：
無容錯 (no ft or dr)：系統不考慮error detection和 failover recovery，出了問題隻能重新開機或者幹脆無法服務
主從備份(active-standby): 正常情況下隻有主服務工作，備份服務不工作，在主服務出現故障時，備份服務可以立即啟用，通常是1+1 的方式，這種政策備份服務在很多時候可能都是備援，但又是必須，是以資源使用率不高。
雙活(active-active): 系統有2個服務叢集，這2個叢集同時提供服務，可以根據不同政策将服務轉發到其中1個叢集。當其中一個叢集中全部或者部分節點/元件服務中斷時，另一個叢集可以立刻接管。這種政策資源使用率比active-standby高，但對系統架構與設計的要求也高，如需要支援資料實時備份與同步。同時如果由于設計不當，可能會導緻在failover 後系統的服務能力下降，具體請看下面的n+k部分。
異地雙活(active-active with geo-redundancy): 和雙活類似，差別在2個服務叢集部署在不同的地理位置，中間通過高速網絡連接配接。這種政策優勢明顯：可以抵抗單一地區的突發事故，包括自然災害，但是需要有跨長距離的高速網絡連接配接，成本提高。
多活和異地多活(multi-active with geo-redundancy): 類似的，同時提供多個服務叢集即為多活，如果多個服務叢集分别部署在異地即為異地多活。這種政策比異地雙活的優勢是可以抵抗多地的同時突發事故。架構設計複雜度也很高，需要考慮多地間的備份和同步。據說隻有google和facebook實作了，還有目前處于試用階段的支付寶。
n+k: 與上面不同，n+k是指系統可用性的一種能力而不是指部署政策，即包含n個伺服器node的系統在其中k個node失效的情況下還能夠提供n個node的服務能力。比如上面提到的1+1 active-active, 如果經過适當設計調整就可以實作n=1, k=1的能力。
具體來講，比如在系統架構設計時可以分别部署n/2個 node在兩地,即1+1 active with geo-redundancy，讓每個地區的engineered capacity為系統最大能力的40%，而滿足整體業務能力要求可以通過增加系統資源實作。這樣在一個地區内所有node都完全失效的情況下，另一個地區即使完全接管失效節點所有服務，負載也隻達到了系統capacity的80%而沒有overload。此時即實作了n+k 中的1+1。
再例如：系統更新時，在支援n+k的系統中可以同時先關閉并更新最多k個node, 而對外的服務能力沒有任何降低，整個服務也沒有downtime, 不需要scheduled outage 維護視窗.
下面2張系統架構圖是本人曾經參與設計過的2個系統架構的例子,一個是傳統模式，另一個是cloud模式。貼出參考就不做過多分析了。
legacy mode： geo-diverse active-active with n+k
cloud mode： geo-diverse active-active with auto-scaling in amazon aws
yunos, 是阿裡巴巴集團旗下的一款智能裝置作業系統産品，融合了阿裡巴巴在雲資料存儲、雲計算服務以及智能裝置作業系統等多領域的技術成果，并且可搭載于智能手機、智能機頂盒（dvb/iptv/ott）、網際網路電視等多種智能終端裝置.
yunos在應用層架構上大緻可分為2部分：
雲端服務
用戶端應用
雲端服務屬于典型的網際網路服務，對這部分暫時不詳細展開了，本文上面介紹的概念和方法都可以适用。想重點讨論的是用戶端應用這部分，目的是希望從本文上面的分析中得到有助于提高用戶端可靠性的方法或者是測試政策。
目前，終端側的可靠性測試基本上是采用稱為”mtbf測試”的專有測試活動來進行的。
中國移動2015版的mtbf測試的标準是：每輪測試5台終端并行連續循環執行以下用例7x24小時，期間記錄系統級問題，包括當機、重新開機、白屏、脫 網等嚴重問題。最終計算終端的無故障運作時間
t：t = 5x7x24 /（故障數）
如果終端支援穩定性測試中對應的本地及通信類業務，則要求終端對于支援的業務滿足穩定性測試中，在 td-scdma、td-lte 網絡下平均無故障運作時長名額不低于 250 小時。零售價 2500 元以上不低 于 350 小時。
北美電信營運商at&t的mtbf名額是這樣定義的：7台手機每天24小時不間斷運作at&t規定的測試，測試内容包括2g/3g語音呼叫、短彩信、浏覽器上網、電話本操作。測試過程中出現的測試用例失敗情況都會記錄下來，然後用7台手機總的運作時間除以全部手機出現的測試失敗次數，即得到mtbf值。整個測試過程全部采用自動化方式，并且都在at&t的現網環境下進行，該測試已經成為所有與at&t合作的終端廠商都必須通過的測試，而且是所有廠商公認的最難通過的測試。
yunos的mtbf測試是由yunos系統測試團隊執行的，同時制定了更為嚴格的通過标準。
可以看出，mtbf測試标準的定義與上文介紹的system availability的概念不是完全一緻，因為移動終端畢竟與服務端從架構，實作方法，到使用者群體都不盡相同；嚴格來講mtbf測試是終端可靠性測試其中的穩定性測試部分。然而有不少地方是兩者是相通和可以借鑒的。比如：
mtbf中的故障數可以近似了解為outage，系統重新開機屬于total outage, 子產品crash屬于partial outage
提升可靠性都是需要降低故障數減小downtime
在系統和應用設計中都需考慮如何減少錯誤，或者出現錯誤如何恢複。
終端上的一些背景服務可以近似了解為服務端應用，雖然不能完全照搬上文中提到容災和恢複的場景，但是可以借鑒其中的一些思路。
終端上可以通過參考dpm的概念增加資料衡量名額，但可能不需要也不現實每個場景都執行100萬次操作，可以依據實際情況調整标準要求
可以參考failover政策中錯誤探測，隔離，恢複的操作在出現錯誤時及時發現，快速恢複重新啟動來減少對使用者造成的負面影響，恢複時間即failover recovery time就成了一個關鍵名額
這個topic太大了，不在這裡詳述了，有一點想要強調的是，任何系統的可靠性，健壯性都不是依靠測試來提高的，測試隻能起到結果驗證和資料回報的作用；相反，可靠性是系統架構和設計的關鍵組成部分。
具體講就是要在設計階段對采用的模型，樣式，架構等有清晰的需求，同時要詳細計算系統中每個元件可能失效的場景和幾率，以及由此引發的可能outage帶來的downtime，計算出産品目前距離達到可靠性标準的差距。然後通過合理的技術手段改進設計，改進的部分要作為産品的feature 寫入需求文檔，實作後最終通過測試和産品環境上的曆史資料來驗證。
例如：下面是downtime budget圖表示例，downtime budget是系統可靠性設計過程中的一個環節，通過配置設定系統各個元件可能的downtime 比例來找到最需要改進提高的地方。
從整篇文章的分析邏輯中可以看出，系統的可靠性，包括産品的整體品質都不能僅僅依靠測試環節來保證。任何希望通過測試發現問題，修複bug解決問題來提高産品品質的想法都是不切實際的，因為在産品設計之初，品質就被隐含其中了。
最後，分享一些和品質相關的觀點和理念來作為此文的結尾：
關于測試：
測試是無法窮盡和發現所有錯誤的
測試的目的不是為了證明軟體的正确性，可是要盡可能的發現錯誤
關于需求：
軟體生命周期中缺陷數量占比：需求和架構54%， 設計25%，編碼15%，其他6%
需求是一個項目的靈魂。模棱兩可的需求帶來不可避免的後果就是返工。
高品質的軟體産品要求足夠詳細的需求規格說明，然而很多組織沒有能力或者不願意制作詳細的需求規格說明
關于産品品質：
品質不能夠通過評鑒一個已完成的産品而得到，因為在設計之初品質就被隐含了
流程與成功不是等價的，沒有流程成功就不可能保證，但有了流程不意味着一定能成功
從長遠發展看，提高産品品質應該從規範軟體開發流程做起，這是一個軟體企業從小作坊到內建規範化大公司的必經之路，也是從根本上解決品質問題的一個關鍵手段
該文章來自阿裡巴巴技術協會（ata）精選集