從攜程到知乎,運維人該如何覺醒?

責任編輯:editor04

2015-06-16 21:54:58

摘自:互聯(lián)網(wǎng)運維雜談

最近互聯(lián)網(wǎng)也是非常有意思,接二連三的發(fā)生故障,讓我們一起先回顧一下。運維一定要把標準化作為核心要務(wù)來推進,建立標準化的運維環(huán)境,建立標準化的技術(shù)棧(和研發(fā)確定),建立標準化的高可用方法論,最終這個業(yè)務(wù)的可用性一定是有保證的。

最近互聯(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分鐘左右

QQ截圖20150616105215

到底是怎么了,是什么讓我們的互聯(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í)行其功能的概率。可用性是指系統(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)系和職責。我們第一個要去看這個流程在面對故障的是否起到了積極的作用,比如說能夠確保故障信息的準確送達,同時保證處理人的角色和職責是清晰的。其次不斷去檢查流程是否可以自動化驅(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ù)盤的首要負責人,復(fù)盤是為了找到根因(Root Cause),根因和故障現(xiàn)象不同,舉個例子,故障現(xiàn)象是交換機故障,根因是因為技術(shù)架構(gòu)沒有對交換機故障做到容錯,根因是運維對這種故障缺乏有效的臨時應(yīng)對機制。

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

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

故障復(fù)盤后,我們一定會寫改進措施,對于這些改進措施,還是有些講究的,看過一些故障報告,非常的不合要求。我個人的經(jīng)驗如下:

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

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

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

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

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

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

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

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號