域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過

最近互聯(lián)網(wǎng)也是非常有意思，接二連三的發(fā)生故障，讓我們一起先回顧一下。

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

2015年5月27日下午，部分用戶反映其支付寶出現(xiàn)網(wǎng)絡(luò)故障，賬號(hào)無法登錄或支付。故障原因：光纖挖斷。影響時(shí)長(zhǎng)：4個(gè)小時(shí)

2015年5月28日上午11:09，攜程官網(wǎng)及APP出現(xiàn)故障無法打開，到28日23:29全面恢復(fù)，整個(gè)過程耗費(fèi)12個(gè)多小時(shí)。故障原因：誤操作。影響時(shí)長(zhǎng)：12個(gè)小時(shí)左右

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

2015年6月15日12點(diǎn)30分知乎網(wǎng)無法打開，直接提示【服務(wù)器提出了一個(gè)問題】錯(cuò)誤，在13點(diǎn)45分左右的時(shí)候，知乎頁面恢復(fù)正常。故障原因：機(jī)房故障影響時(shí)長(zhǎng)：60分鐘左右

到底是怎么了，是什么讓我們的互聯(lián)網(wǎng)業(yè)務(wù)如此脆弱?真的是運(yùn)營(yíng)商老是在后面干壞事?還是我們的系統(tǒng)架構(gòu)不給力?還是我們運(yùn)維能力真的很弱?如果廣義的去看這個(gè)，我還會(huì)把它歸結(jié)成運(yùn)維問題。不過對(duì)于以上的故障，從運(yùn)維的角度來說，我依然會(huì)說官方結(jié)論不夠?qū)I(yè)，希望內(nèi)部不是這樣的哈。

1、網(wǎng)易說骨干網(wǎng)收到網(wǎng)絡(luò)攻擊影響業(yè)務(wù)，貌似那天好像也就網(wǎng)易業(yè)務(wù)受到影響?

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

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

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

5、知乎故障，直接說是機(jī)房故障，太簡(jiǎn)單了，但我覺得最大的可能應(yīng)該是Tengine后端服務(wù)超時(shí)導(dǎo)致的，而非簡(jiǎn)單的一個(gè)機(jī)房故障引起。

在每一次故障發(fā)生的時(shí)候，其實(shí)都是傷害了我們的用戶，內(nèi)部的表述就是可用性或者質(zhì)量。因此我們必須要足夠的重視，更需要我們把它變成寶貴的經(jīng)驗(yàn)。那到底什么是可用性和可靠性?影響可用性的因素有哪些?運(yùn)維如何提高可用性?等等。

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

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

1. MTBF——全稱是Mean Time Between Failure，即平均無故障工作時(shí)間。就是從新的產(chǎn)品在規(guī)定的工作環(huán)境條件下開始工作到出現(xiàn)第一個(gè)故障的時(shí)間的平均值。MTBF越長(zhǎng)表示可靠性越高正確工作能力越強(qiáng)。

2. MTTR——全稱是Mean Time To Repair，即平均修復(fù)時(shí)間。是指可修復(fù)產(chǎn)品的平均修復(fù)時(shí)間，就是從出現(xiàn)故障到修復(fù)中間的這段時(shí)間。MTTR越短表示易恢復(fù)性越好。

3. MTTF——全稱是Mean Time To Failure，即平均失效時(shí)間。系統(tǒng)平均能夠正常運(yùn)行多長(zhǎng)時(shí)間，才發(fā)生一次故障。系統(tǒng)的可靠性越高，平均無故障時(shí)間越長(zhǎng)。

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

從這些時(shí)間指標(biāo)上可以反向去推導(dǎo)IT能力不足的地方，比如說一個(gè)故障恢復(fù)時(shí)間很長(zhǎng)，一定是自動(dòng)恢復(fù)、運(yùn)維意識(shí)、處理過程、系統(tǒng)架構(gòu)等地方不對(duì)，導(dǎo)致了這個(gè)宕機(jī)時(shí)間過長(zhǎng);平均失效時(shí)間短，一定是系統(tǒng)的可靠性出了問題，找技術(shù)設(shè)計(jì)的問題，找依賴的硬件環(huán)境問題等等

二、影響可用性的因素

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

1、人與組織

其實(shí)這個(gè)地方可以談?wù)勀愕娜撕徒M織類型了，領(lǐng)導(dǎo)是否重視IT?是否重視運(yùn)維?組織是否已經(jīng)認(rèn)識(shí)IT帶來的價(jià)值，把IT當(dāng)作自己的一個(gè)核心能力來看待?是否把面向用戶的業(yè)務(wù)能力和IT能力很好的對(duì)接?是否建立起用戶質(zhì)量的組織文化?等等。

2、流程

流程是梳理多個(gè)角色自己的關(guān)系和職責(zé)。我們第一個(gè)要去看這個(gè)流程在面對(duì)故障的是否起到了積極的作用，比如說能夠確保故障信息的準(zhǔn)確送達(dá)，同時(shí)保證處理人的角色和職責(zé)是清晰的。其次不斷去檢查流程是否可以自動(dòng)化驅(qū)動(dòng)，而非人為驅(qū)動(dòng)。人是不可靠之源!我們最終希望形成是一個(gè)自動(dòng)化、標(biāo)準(zhǔn)化的流程，這樣的流程不容易被異化，且能保證預(yù)期執(zhí)行結(jié)果一致。

3、技術(shù)

很多時(shí)候大家看到的技術(shù)是運(yùn)維技術(shù)，其實(shí)恰恰相反對(duì)于互聯(lián)網(wǎng)業(yè)務(wù)來說，對(duì)其高可用的影響，必然是業(yè)務(wù)IT技術(shù)架構(gòu)，因此在其中需要遵循很多原則，有一些原則需要有普適的參考價(jià)值。比如說服務(wù)降級(jí)、灰度發(fā)布、過載保護(hù)、服務(wù)公共化等等。這些方法論是否已經(jīng)融入到研發(fā)和運(yùn)維的架構(gòu)設(shè)計(jì)哲學(xué)之中?現(xiàn)實(shí)是產(chǎn)品功能需求優(yōu)先，而非可運(yùn)維性優(yōu)先，可運(yùn)維性最終就是業(yè)務(wù)的質(zhì)量。

4、業(yè)務(wù)管理

把你的IT能力最終都業(yè)務(wù)能力看板化，你可以轉(zhuǎn)換成我們多個(gè)業(yè)務(wù)指標(biāo)，比如說質(zhì)量、可用性、用戶體驗(yàn)、用戶滿意度、成本等等，有了這些業(yè)務(wù)導(dǎo)向性指標(biāo)，才能把IT能力和業(yè)務(wù)更好的對(duì)接起來。否則很容易在組織內(nèi)，形成“IT是支撐部門”認(rèn)識(shí)，而非創(chuàng)造價(jià)值部門。這一點(diǎn)還有一個(gè)重要性，就是讓IT部門也要足夠的認(rèn)識(shí)到，他們的能力直接和業(yè)務(wù)相關(guān)，需要增強(qiáng)業(yè)務(wù)敏感度。

三、如何提高系統(tǒng)的可用性

剛剛上面講到了影響可用性的因素，分成了四個(gè)方面，但我想提高系統(tǒng)的可用性從另外一個(gè)角度來描述，能把握一些核心準(zhǔn)則(其實(shí)還有更多)。

1、故障發(fā)生前，建立運(yùn)維質(zhì)量?jī)x表盤

我們一定要建立運(yùn)維數(shù)據(jù)看板，這個(gè)看板的數(shù)據(jù)并且要在業(yè)務(wù)、研發(fā)、測(cè)試和運(yùn)維達(dá)成一致，讓大家足夠重視這份數(shù)據(jù)，這樣數(shù)據(jù)便有了推動(dòng)力。建議這個(gè)地方的核心數(shù)據(jù)指標(biāo)不要太多，因?yàn)樯婕暗蕉鄠€(gè)團(tuán)隊(duì)，大家不能夠一致理解，特別是傳達(dá)到管理層，太多的指標(biāo)，容易失去關(guān)注的焦點(diǎn)。

通行的做法，就是用可用性來做運(yùn)維的數(shù)據(jù)看板?？捎眯缘挠?jì)算方法有簡(jiǎn)單的方法，也有復(fù)雜的方法。簡(jiǎn)單的方法就是在監(jiān)控系統(tǒng)中搞一些探針來模擬用戶監(jiān)控，最后我們能得出故障的時(shí)長(zhǎng)和可用性的時(shí)間，這樣我們可以建立每天、每周、每月、每Q的可用性，可以做到分業(yè)務(wù)、分服務(wù)(更細(xì)粒度)等等;復(fù)雜的方法在模擬數(shù)據(jù)的基礎(chǔ)上，可以把事件系統(tǒng)記錄的時(shí)間數(shù)據(jù)拿過來作為評(píng)估的標(biāo)準(zhǔn)。另外可以把可用性上升到質(zhì)量層面，這個(gè)里面涉及到的評(píng)估維度(成本、用戶體驗(yàn)、滿意度)就更多了，數(shù)據(jù)獲取的來源也變得更多，有些是來自于客服系統(tǒng)，有些是來自于輿情監(jiān)控，有些是來自于運(yùn)維容量系統(tǒng)，有些是來自于事件系統(tǒng)等等，不過最終呈現(xiàn)的指標(biāo)就是一個(gè)---質(zhì)量。

運(yùn)維的數(shù)據(jù)看板，最好能變成產(chǎn)研側(cè)KPI的一部分，同時(shí)在運(yùn)維和研發(fā)側(cè)，需要周期性的把這份數(shù)據(jù)推送到他們面前。有了KPI，同時(shí)有了持續(xù)滾動(dòng)機(jī)制，一定能建立起很好的業(yè)務(wù)質(zhì)量意識(shí)。

一直覺得，數(shù)據(jù)文化，是運(yùn)維能夠建立影響力的重要一步，否則你就是一個(gè)支撐的支撐部門!

2、故障發(fā)生前，設(shè)定技術(shù)準(zhǔn)則和要求

運(yùn)維需要和研發(fā)建立整體的技術(shù)標(biāo)準(zhǔn)和規(guī)范要求，這塊是騰訊做得非常好的地方，把海量服務(wù)提煉成多個(gè)關(guān)鍵詞【海量服務(wù)運(yùn)營(yíng)之道】，網(wǎng)上可以搜索到。當(dāng)然這些關(guān)鍵詞對(duì)于很多企業(yè)來說，想理解準(zhǔn)確，也會(huì)非常的困難。因此從運(yùn)維的角度來說，我們需要設(shè)定一個(gè)路線圖，最終服務(wù)于這個(gè)技術(shù)目標(biāo)。比如說之前我提到的【運(yùn)維三部曲】里面講到了先做標(biāo)準(zhǔn)化(修煉運(yùn)維內(nèi)功)，然后做公共服務(wù)化(修煉架構(gòu)內(nèi)功)、最終服務(wù)無狀態(tài)化(修煉業(yè)務(wù)內(nèi)功)。

運(yùn)維一定要把標(biāo)準(zhǔn)化作為核心要?jiǎng)?wù)來推進(jìn)，建立標(biāo)準(zhǔn)化的運(yùn)維環(huán)境，建立標(biāo)準(zhǔn)化的技術(shù)棧(和研發(fā)確定)，建立標(biāo)準(zhǔn)化的高可用方法論，最終這個(gè)業(yè)務(wù)的可用性一定是有保證的。

3、故障發(fā)生時(shí)，恢復(fù)是第一要?jiǎng)?wù)

故障發(fā)生的時(shí)候，“恢復(fù)、恢復(fù)、恢復(fù)”必須是運(yùn)維人腦子里面要時(shí)刻記住的。

在故障的當(dāng)下，定位故障原因是大忌，這往往讓故障時(shí)長(zhǎng)變得不可控，因?yàn)闀?huì)直接影響MTTR(平均修復(fù)時(shí)間)，影響用戶的業(yè)務(wù)使用。不過有人會(huì)有疑問，不知道故障原因怎么知道如何解決?從經(jīng)驗(yàn)來看，你一定有一些簡(jiǎn)單粗暴的原則去隔離故障，比如說服務(wù)器重啟，鏈路禁用，DNS切換等等。

4、故障發(fā)生后，仔細(xì)的復(fù)盤

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

運(yùn)維是復(fù)盤的首要負(fù)責(zé)人，復(fù)盤是為了找到根因(Root Cause)，根因和故障現(xiàn)象不同，舉個(gè)例子，故障現(xiàn)象是交換機(jī)故障，根因是因?yàn)榧夹g(shù)架構(gòu)沒有對(duì)交換機(jī)故障做到容錯(cuò)，根因是運(yùn)維對(duì)這種故障缺乏有效的臨時(shí)應(yīng)對(duì)機(jī)制。

復(fù)盤是為了讓我們走向更好的運(yùn)維階段!

5、故障發(fā)生后，復(fù)盤措施有講究

故障復(fù)盤后，我們一定會(huì)寫改進(jìn)措施，對(duì)于這些改進(jìn)措施，還是有些講究的，看過一些故障報(bào)告，非常的不合要求。我個(gè)人的經(jīng)驗(yàn)如下：

故障的措施必須是可落實(shí)，且具體的，要落實(shí)到具體的負(fù)責(zé)人，具體的時(shí)間

故障的措施優(yōu)先是必須技術(shù)的，然后是流程，最后是人的

故障的措施可以分為長(zhǎng)期措施和臨時(shí)措施

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

故障的措施切忌“亡羊補(bǔ)牢”式的，需要全面細(xì)致的分析

故障的措施一定要保證后續(xù)的持續(xù)跟進(jìn)

一葉可以障目，但也可以一葉知秋，就看我們是否真的去認(rèn)真對(duì)待。你們真的重視故障了么?你們真的重視運(yùn)維了么?故障不能帶來運(yùn)維人的春天，從根本上去意識(shí)到運(yùn)維的重要性，那才是運(yùn)維人真正的春天。

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！