最近互聯(lián)網(wǎng)也是非常有意思，接二連三的發(fā)生故障，讓我們一起先回顧一下。
2015年5月11號晚上21點左右開始，網(wǎng)易的網(wǎng)易新聞、云音樂、易信、有道云筆記等移動應(yīng)用均無法正常刷新，網(wǎng)易名下的游戲也全線癱瘓。故障原因：骨干網(wǎng)絡(luò)遭受攻擊。
2015年5月27日下午，部分用戶反映其支付寶出現(xiàn)網(wǎng)絡(luò)故障，賬號無法登錄或支付。故障原因：光纖挖斷。影響時長：4個小時
2015年5月28日上午11:09，攜程官網(wǎng)及APP出現(xiàn)故障無法打開，到28日23:29全面恢復(fù)，整個過程耗費12個多小時。故障原因：誤操作。影響時長：12個小時左右
2015年6月5日今日頭條網(wǎng)首頁和APP都無法訪問，直接提示500錯誤。故障原因：不明影響時長：30分鐘左右。
2015年6月15日12點30分知乎網(wǎng)無法打開，直接提示【服務(wù)器提出了一個問題】錯誤，在13點45分左右的時候，知乎頁面恢復(fù)正常。故障原因：機房故障影響時長：60分鐘左右
到底是怎么了，是什么讓我們的互聯(lián)網(wǎng)業(yè)務(wù)如此脆弱?真的是運營商老是在后面干壞事?還是我們的系統(tǒng)架構(gòu)不給力?還是我們運維能力真的很弱?如果廣義的去看這個，我還會把它歸結(jié)成運維問題。不過對于以上的故障，從運維的角度來說，我依然會說官方結(jié)論不夠?qū)I(yè)，希望內(nèi)部不是這樣的哈。
1、網(wǎng)易說骨干網(wǎng)收到網(wǎng)絡(luò)攻擊影響業(yè)務(wù)，貌似那天好像也就網(wǎng)易業(yè)務(wù)受到影響?
2、光纖挖斷影響四個小時，從這么核心的業(yè)務(wù)來說，第一原則一定是恢復(fù)業(yè)務(wù)，我想支付寶即使沒做雙活，肯定也會有一個可用的備份中心，為什么沒切過去了?一定是內(nèi)部出了亂子。不過阿里流弊的地方，負面的事情他可以變成正面，他們把"5.27"變成了技術(shù)保障日，大肆宣傳。
3、攜程事件，我之前寫過一篇文章【攜程事件：運維債務(wù)的深度分析和解決方案】，不詳談了。
4、今日頭條，500內(nèi)部錯誤，這條新聞可以讓自己上頭條，但也沒有正式的給出解釋。從500錯誤的恢復(fù)時間來說，有點長，500錯誤是十分好定位，我的懷疑是數(shù)據(jù)庫的壓力不夠，導(dǎo)致后面的擴容變更，也只有數(shù)據(jù)庫分庫分表擴容時間需要這么長了。另外頭條君的首頁上直接給個500的錯誤，技術(shù)表述，十分的不友好，建議你服務(wù)降級啊，推個大眾版的新聞，不做個性化推薦，這個可以做一個緩存就可以解決的。
5、知乎故障，直接說是機房故障，太簡單了，但我覺得最大的可能應(yīng)該是Tengine后端服務(wù)超時導(dǎo)致的，而非簡單的一個機房故障引起。
在每一次故障發(fā)生的時候，其實都是傷害了我們的用戶，內(nèi)部的表述就是可用性或者質(zhì)量。因此我們必須要足夠的重視，更需要我們把它變成寶貴的經(jīng)驗。那到底什么是可用性和可靠性?影響可用性的因素有哪些?運維如何提高可用性?等等。
一、什么是可用性和可靠性
可靠性是在給定的時間間隔和給定條件下，系統(tǒng)能正確執(zhí)行其功能的概率?？捎眯允侵赶到y(tǒng)在執(zhí)行任務(wù)的任意時刻能正常工作的概率。先來看一些指標定義：
1. MTBF——全稱是Mean Time Between Failure，即平均無故障工作時間。就是從新的產(chǎn)品在規(guī)定的工作環(huán)境條件下開始工作到出現(xiàn)第一個故障的時間的平均值。MTBF越長表示可靠性越高正確工作能力越強。
2. MTTR——全稱是Mean Time To Repair，即平均修復(fù)時間。是指可修復(fù)產(chǎn)品的平均修復(fù)時間，就是從出現(xiàn)故障到修復(fù)中間的這段時間。MTTR越短表示易恢復(fù)性越好。
3. MTTF——全稱是Mean Time To Failure，即平均失效時間。系統(tǒng)平均能夠正常運行多長時間，才發(fā)生一次故障。系統(tǒng)的可靠性越高，平均無故障時間越長。
可用性Availability = MTBF / (MTBF + MTTR)，一般我們都是用N個9來表達系統(tǒng)可用性，用宕機時長來說更好理解，如果以全年為周期(24*365=8760個小時)，3個9(99.9%)就意味著全年宕機時長是525.6分鐘，4個9(99.99%)是52.6分鐘，5個9(99.999%)是5分鐘。
從這些時間指標上可以反向去推導(dǎo)IT能力不足的地方，比如說一個故障恢復(fù)時間很長，一定是自動恢復(fù)、運維意識、處理過程、系統(tǒng)架構(gòu)等地方不對，導(dǎo)致了這個宕機時間過長;平均失效時間短，一定是系統(tǒng)的可靠性出了問題，找技術(shù)設(shè)計的問題，找依賴的硬件環(huán)境問題等等
二、影響可用性的因素
影響可用性的因素非常的多，但是可以從幾個維度去看，人與組織、流程、技術(shù)和業(yè)務(wù)管理等四個維度。
1、人與組織
其實這個地方可以談?wù)勀愕娜撕徒M織類型了，領(lǐng)導(dǎo)是否重視IT?是否重視運維?組織是否已經(jīng)認識IT帶來的價值，把IT當作自己的一個核心能力來看待?是否把面向用戶的業(yè)務(wù)能力和IT能力很好的對接?是否建立起用戶質(zhì)量的組織文化?等等。
2、流程
流程是梳理多個角色自己的關(guān)系和職責(zé)。我們第一個要去看這個流程在面對故障的是否起到了積極的作用，比如說能夠確保故障信息的準確送達，同時保證處理人的角色和職責(zé)是清晰的。其次不斷去檢查流程是否可以自動化驅(qū)動，而非人為驅(qū)動。人是不可靠之源!我們最終希望形成是一個自動化、標準化的流程，這樣的流程不容易被異化，且能保證預(yù)期執(zhí)行結(jié)果一致。
3、技術(shù)
很多時候大家看到的技術(shù)是運維技術(shù)，其實恰恰相反對于互聯(lián)網(wǎng)業(yè)務(wù)來說，對其高可用的影響，必然是業(yè)務(wù)IT技術(shù)架構(gòu)，因此在其中需要遵循很多原則，有一些原則需要有普適的參考價值。比如說服務(wù)降級、灰度發(fā)布、過載保護、服務(wù)公共化等等。這些方法論是否已經(jīng)融入到研發(fā)和運維的架構(gòu)設(shè)計哲學(xué)之中?現(xiàn)實是產(chǎn)品功能需求優(yōu)先，而非可運維性優(yōu)先，可運維性最終就是業(yè)務(wù)的質(zhì)量。
4、業(yè)務(wù)管理
把你的IT能力最終都業(yè)務(wù)能力看板化，你可以轉(zhuǎn)換成我們多個業(yè)務(wù)指標，比如說質(zhì)量、可用性、用戶體驗、用戶滿意度、成本等等，有了這些業(yè)務(wù)導(dǎo)向性指標，才能把IT能力和業(yè)務(wù)更好的對接起來。否則很容易在組織內(nèi)，形成“IT是支撐部門”認識，而非創(chuàng)造價值部門。這一點還有一個重要性，就是讓IT部門也要足夠的認識到，他們的能力直接和業(yè)務(wù)相關(guān)，需要增強業(yè)務(wù)敏感度。
三、如何提高系統(tǒng)的可用性
剛剛上面講到了影響可用性的因素，分成了四個方面，但我想提高系統(tǒng)的可用性從另外一個角度來描述，能把握一些核心準則(其實還有更多)。
1、故障發(fā)生前，建立運維質(zhì)量儀表盤
我們一定要建立運維數(shù)據(jù)看板，這個看板的數(shù)據(jù)并且要在業(yè)務(wù)、研發(fā)、測試和運維達成一致，讓大家足夠重視這份數(shù)據(jù)，這樣數(shù)據(jù)便有了推動力。建議這個地方的核心數(shù)據(jù)指標不要太多，因為涉及到多個團隊，大家不能夠一致理解，特別是傳達到管理層，太多的指標，容易失去關(guān)注的焦點。
通行的做法，就是用可用性來做運維的數(shù)據(jù)看板?？捎眯缘挠嬎惴椒ㄓ泻唵蔚姆椒ǎ灿袕?fù)雜的方法。簡單的方法就是在監(jiān)控系統(tǒng)中搞一些探針來模擬用戶監(jiān)控，最后我們能得出故障的時長和可用性的時間，這樣我們可以建立每天、每周、每月、每Q的可用性，可以做到分業(yè)務(wù)、分服務(wù)(更細粒度)等等;復(fù)雜的方法在模擬數(shù)據(jù)的基礎(chǔ)上，可以把事件系統(tǒng)記錄的時間數(shù)據(jù)拿過來作為評估的標準。另外可以把可用性上升到質(zhì)量層面，這個里面涉及到的評估維度(成本、用戶體驗、滿意度)就更多了，數(shù)據(jù)獲取的來源也變得更多，有些是來自于客服系統(tǒng)，有些是來自于輿情監(jiān)控，有些是來自于運維容量系統(tǒng)，有些是來自于事件系統(tǒng)等等，不過最終呈現(xiàn)的指標就是一個---質(zhì)量。
運維的數(shù)據(jù)看板，最好能變成產(chǎn)研側(cè)KPI的一部分，同時在運維和研發(fā)側(cè)，需要周期性的把這份數(shù)據(jù)推送到他們面前。有了KPI，同時有了持續(xù)滾動機制，一定能建立起很好的業(yè)務(wù)質(zhì)量意識。
一直覺得，數(shù)據(jù)文化，是運維能夠建立影響力的重要一步，否則你就是一個支撐的支撐部門!
2、故障發(fā)生前，設(shè)定技術(shù)準則和要求
運維需要和研發(fā)建立整體的技術(shù)標準和規(guī)范要求，這塊是騰訊做得非常好的地方，把海量服務(wù)提煉成多個關(guān)鍵詞【海量服務(wù)運營之道】，網(wǎng)上可以搜索到。當然這些關(guān)鍵詞對于很多企業(yè)來說，想理解準確，也會非常的困難。因此從運維的角度來說，我們需要設(shè)定一個路線圖，最終服務(wù)于這個技術(shù)目標。比如說之前我提到的【運維三部曲】里面講到了先做標準化(修煉運維內(nèi)功)，然后做公共服務(wù)化(修煉架構(gòu)內(nèi)功)、最終服務(wù)無狀態(tài)化(修煉業(yè)務(wù)內(nèi)功)。
運維一定要把標準化作為核心要務(wù)來推進，建立標準化的運維環(huán)境，建立標準化的技術(shù)棧(和研發(fā)確定)，建立標準化的高可用方法論，最終這個業(yè)務(wù)的可用性一定是有保證的。
3、故障發(fā)生時，恢復(fù)是第一要務(wù)
故障發(fā)生的時候，“恢復(fù)、恢復(fù)、恢復(fù)”必須是運維人腦子里面要時刻記住的。
在故障的當下，定位故障原因是大忌，這往往讓故障時長變得不可控，因為會直接影響MTTR(平均修復(fù)時間)，影響用戶的業(yè)務(wù)使用。不過有人會有疑問，不知道故障原因怎么知道如何解決?從經(jīng)驗來看，你一定有一些簡單粗暴的原則去隔離故障，比如說服務(wù)器重啟，鏈路禁用，DNS切換等等。
4、故障發(fā)生后，仔細的復(fù)盤
每一次故障發(fā)生后，運維人需要牽頭去復(fù)盤故障，剛剛說了我們恢復(fù)是第一要務(wù)，所以故障的根本原因我們可能還不知道，此時就需要運維、測試和研發(fā)一起仔細的去看整個的故障過程，看看到底哪兒有什么問題?基本上也是從剛才說的四個方面來評估。不斷的審視我們運維的能力和IT的能力，說“故障是運維最好的老師”的原因也在于此，它能夠不斷驅(qū)使我們走向更高的成熟度。
運維是復(fù)盤的首要負責(zé)人，復(fù)盤是為了找到根因(Root Cause)，根因和故障現(xiàn)象不同，舉個例子，故障現(xiàn)象是交換機故障，根因是因為技術(shù)架構(gòu)沒有對交換機故障做到容錯，根因是運維對這種故障缺乏有效的臨時應(yīng)對機制。
復(fù)盤是為了讓我們走向更好的運維階段!
5、故障發(fā)生后，復(fù)盤措施有講究
故障復(fù)盤后，我們一定會寫改進措施，對于這些改進措施，還是有些講究的，看過一些故障報告，非常的不合要求。我個人的經(jīng)驗如下：
故障的措施必須是可落實，且具體的，要落實到具體的負責(zé)人，具體的時間
故障的措施優(yōu)先是必須技術(shù)的，然后是流程，最后是人的
故障的措施可以分為長期措施和臨時措施
故障的措施一定要僅僅扣住故障的根因，避免流于形式和表面
故障的措施切忌“亡羊補牢”式的，需要全面細致的分析
故障的措施一定要保證后續(xù)的持續(xù)跟進
一葉可以障目，但也可以一葉知秋，就看我們是否真的去認真對待。你們真的重視故障了么?你們真的重視運維了么?故障不能帶來運維人的春天，從根本上去意識到運維的重要性，那才是運維人真正的春天。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
