最近互聯網也是非常有意思，接二連三的發生故障，讓我們一起先回顧一下。

2015年5月11號晚上21點左右開始，網易的網易新聞、云音樂、易信、有道云筆記等移動應用均無法正常刷新，網易名下的游戲也全線癱瘓。故障原因：骨干網絡遭受攻擊。

2015年5月27日下午，部分用戶反映其支付寶出現網絡故障，賬號無法登錄或支付。故障原因：光纖挖斷。影響時長：4個小時

2015年5月28日上午11:09，攜程官網及APP出現故障無法打開，到28日23:29全面恢復，整個過程耗費12個多小時。故障原因：誤操作。影響時長：12個小時左右

2015年6月5日 今日頭條網首頁和APP都無法訪問，直接提示500錯誤。故障原因：不明 影響時長：30分鐘左右。

2015年6月15日12點30分 知乎網無法打開，直接提示【服務器提出了一個問題】錯誤，在13點45分左右的時候，知乎頁面恢復正常。故障原因：機房故障 影響時長：60分鐘左右



到底是怎么了，是什么讓我們的互聯網業務如此脆弱？真的是運營商老是在后面干壞事？還是我們的系統架構不給力？還是我們運維能力真的很弱？如果廣義的去看這個，我還會把它歸結成運維問題。不過對于以上的故障，從運維的角度來說，我依然會說官方結論不夠專業，希望內部不是這樣的哈。

1、網易說骨干網收到網絡攻擊影響業務，貌似那天好像也就網易業務受到影響？

2、光纖挖斷影響四個小時，從這么核心的業務來說，第一原則一定是恢復業務，我想支付寶即使沒做雙活，肯定也會有一個可用的備份中心，為什么沒切過去了？一定是內部出了亂子。不過阿里流弊的地方，負面的事情他可以變成正面，他們把"5.27"變成了技術保障日，大肆宣傳。

3、攜程事件，我之前寫過一篇文章【攜程事件：運維債務的深度分析和解決方案】，不詳談了。

4、今日頭條，500內部錯誤，這條新聞可以讓自己上頭條，但也沒有正式的給出解釋。從500錯誤的恢復時間來說，有點長，500錯誤是十分好定位，我的懷疑是數據庫的壓力不夠，導致后面的擴容變更，也只有數據庫分庫分表擴容時間需要這么長了。另外頭條君的首頁上直接給個500的錯誤，技術表述，十分的不友好，建議你服務降級啊，推個大眾版的新聞，不做個性化推薦，這個可以做一個緩存就可以解決的。

5、知乎故障，直接說是機房故障，太簡單了，但我覺得最大的可能應該是Tengine后端服務超時導致的，而非簡單的一個機房故障引起。

在每一次故障發生的時候，其實都是傷害了我們的用戶，內部的表述就是可用性或者質量。因此我們必須要足夠的重視，更需要我們把它變成寶貴的經驗。那到底什么是可用性和可靠性？影響可用性的因素有哪些？運維如何提高可用性？等等。

一、什么是可用性和可靠性

可靠性是在給定的時間間隔和給定條件下，系統能正確執行其功能的概率?？捎眯允侵赶到y在執行任務的任意時刻能正常工作的概率。先來看一些指標定義：

1. MTBF——全稱是Mean Time Between Failure，即平均無故障工作時間。就是從新的產品在規定的工作環境條件下開始工作到出現第一個故障的時間的平均值。MTBF越長表示可靠性越高正確工作能力越強 。

2. MTTR——全稱是Mean Time To Repair，即平均修復時間。是指可修復產品的平均修復時間，就是從出現故障到修復中間的這段時間。MTTR越短表示易恢復性越好。

3. MTTF——全稱是Mean Time To Failure，即平均失效時間。系統平均能夠正常運行多長時間，才發生一次故障。系統的可靠性越高，平均無故障時間越長。

可用性Availability = MTBF / (MTBF + MTTR)，一般我們都是用N個9來表達系統可用性，用宕機時長來說更好理解，如果以全年為周期（24*365=8760個小時），3個9(99.9%)就意味著全年宕機時長是525.6分鐘，4個9(99.99%)是52.6分鐘，5個9（99.999%）是5分鐘。

從這些時間指標上可以反向去推導IT能力不足的地方，比如說一個故障恢復時間很長，一定是自動恢復、運維意識、處理過程、系統架構等地方不對，導致了這個宕機時間過長；平均失效時間短，一定是系統的可靠性出了問題，找技術設計的問題，找依賴的硬件環境問題等等

二、影響可用性的因素

影響可用性的因素非常的多，但是可以從幾個維度去看，人與組織、流程、技術和業務管理等四個維度。

1、人與組織

其實這個地方可以談談你的人和組織類型了，領導是否重視IT？是否重視運維？組織是否已經認識IT帶來的價值，把IT當作自己的一個核心能力來看待？是否把面向用戶的業務能力和IT能力很好的對接？是否建立起用戶質量的組織文化？等等。

2、流程

流程是梳理多個角色自己的關系和職責。我們第一個要去看這個流程在面對故障的是否起到了積極的作用，比如說能夠確保故障信息的準確送達，同時保證處理人的角色和職責是清晰的。其次不斷去檢查流程是否可以自動化驅動，而非人為驅動。人是不可靠之源！我們最終希望形成是一個自動化、標準化的流程，這樣的流程不容易被異化，且能保證預期執行結果一致。

3、技術

很多時候大家看到的技術是運維技術，其實恰恰相反對于互聯網業務來說，對其高可用的影響，必然是業務IT技術架構，因此在其中需要遵循很多原則，有一些原則需要有普適的參考價值。比如說服務降級、灰度發布、過載保護、服務公共化等等。這些方法論是否已經融入到研發和運維的架構設計哲學之中？現實是產品功能需求優先，而非可運維性優先，可運維性最終就是業務的質量。

4、業務管理

把你的IT能力最終都業務能力看板化，你可以轉換成我們多個業務指標，比如說質量、可用性、用戶體驗、用戶滿意度、成本等等，有了這些業務導向性指標，才能把IT能力和業務更好的對接起來。否則很容易在組織內，形成“IT是支撐部門”認識，而非創造價值部門。這一點還有一個重要性，就是讓IT部門也要足夠的認識到，他們的能力直接和業務相關，需要增強業務敏感度。

三、如何提高系統的可用性

剛剛上面講到了影響可用性的因素，分成了四個方面，但我想提高系統的可用性從另外一個角度來描述，能把握一些核心準則（其實還有更多）。

1、故障發生前，建立運維質量儀表盤

我們一定要建立運維數據看板，這個看板的數據并且要在業務、研發、測試和運維達成一致，讓大家足夠重視這份數據，這樣數據便有了推動力。建議這個地方的核心數據指標不要太多，因為涉及到多個團隊，大家不能夠一致理解，特別是傳達到管理層，太多的指標，容易失去關注的焦點。

通行的做法，就是用可用性來做運維的數據看板?？捎眯缘挠嬎惴椒ㄓ泻唵蔚姆椒?，也有復雜的方法。簡單的方法就是在監控系統中搞一些探針來模擬用戶監控，最后我們能得出故障的時長和可用性的時間，這樣我們可以建立每天、每周、每月、每Q的可用性，可以做到分業務、分服務（更細粒度）等等；復雜的方法在模擬數據的基礎上，可以把事件系統記錄的時間數據拿過來作為評估的標準。另外可以把可用性上升到質量層面，這個里面涉及到的評估維度（成本、用戶體驗、滿意度）就更多了，數據獲取的來源也變得更多，有些是來自于客服系統，有些是來自于輿情監控，有些是來自于運維容量系統，有些是來自于事件系統等等，不過最終呈現的指標就是一個---質量。

運維的數據看板，最好能變成產研側KPI的一部分，同時在運維和研發側，需要周期性的把這份數據推送到他們面前。有了KPI，同時有了持續滾動機制，一定能建立起很好的業務質量意識。

一直覺得，數據文化，是運維能夠建立影響力的重要一步，否則你就是一個支撐的支撐部門！

2、故障發生前，設定技術準則和要求

運維需要和研發建立整體的技術標準和規范要求，這塊是騰訊做得非常好的地方，把海量服務提煉成多個關鍵詞【海量服務運營之道】，網上可以搜索到。當然這些關鍵詞對于很多企業來說，想理解準確，也會非常的困難。因此從運維的角度來說，我們需要設定一個路線圖，最終服務于這個技術目標。比如說之前我提到的【運維三部曲】里面講到了先做標準化（修煉運維內功），然后做公共服務化（修煉架構內功）、最終服務無狀態化（修煉業務內功）。

運維一定要把標準化作為核心要務來推進，建立標準化的運維環境，建立標準化的技術棧（和研發確定），建立標準化的高可用方法論，最終這個業務的可用性一定是有保證的。

3、故障發生時，恢復是第一要務

故障發生的時候，“恢復、恢復、恢復”必須是運維人腦子里面要時刻記住的。

在故障的當下，定位故障原因是大忌，這往往讓故障時長變得不可控，因為會直接影響MTTR（平均修復時間），影響用戶的業務使用。不過有人會有疑問，不知道故障原因怎么知道如何解決？從經驗來看，你一定有一些簡單粗暴的原則去隔離故障，比如說服務器重啟，鏈路禁用，DNS切換等等。

4、故障發生后，仔細的復盤

每一次故障發生后，運維人需要牽頭去復盤故障，剛剛說了我們恢復是第一要務，所以故障的根本原因我們可能還不知道，此時就需要運維、測試和研發一起仔細的去看整個的故障過程，看看到底哪兒有什么問題？基本上也是從剛才說的四個方面來評估。不斷的審視我們運維的能力和IT的能力，說“故障是運維最好的老師”的原因也在于此，它能夠不斷驅使我們走向更高的成熟度。

運維是復盤的首要負責人，復盤是為了找到根因（Root Cause），根因和故障現象不同，舉個例子，故障現象是交換機故障，根因是因為技術架構沒有對交換機故障做到容錯，根因是運維對這種故障缺乏有效的臨時應對機制。

復盤是為了讓我們走向更好的運維階段！

5、故障發生后，復盤措施有講究

故障復盤后，我們一定會寫改進措施，對于這些改進措施，還是有些講究的，看過一些故障報告，非常的不合要求。我個人的經驗如下：

故障的措施必須是可落實，且具體的，要落實到具體的負責人，具體的時間

故障的措施優先是必須技術的，然后是流程，最后是人的

故障的措施可以分為長期措施和臨時措施

故障的措施一定要僅僅扣住故障的根因，避免流于形式和表面

故障的措施切忌“亡羊補牢”式的，需要全面細致的分析

故障的措施一定要保證后續的持續跟進

一葉可以障目，但也可以一葉知秋，就看我們是否真的去認真對待。你們真的重視故障了么？你們真的重視運維了么？故障不能帶來運維人的春天，從根本上去意識到運維的重要性，那才是運維人真正的春天。