運維的線上系統故障總結

語言: CN / TW / HK

線上故障是一件讓人很“緊張”的事情,之所以用緊張這個詞,是因為暫時找不到更好的詞彙描述遇到時的心態。

對於運維人員來說,出現故障,可能意味著: 失職、麻煩、質疑、加班、績效、無盡的報告等負面詞彙,但也意味著: 機會與挑戰。前者大家都好理解,後者也是很重要的,為什麼呢?

故障的機會與挑戰

一、有一部分故障是大家都沒有預料到的。

個人對故障的發生是不用擔責的,只需要善後就可以這種。

比如機房突然斷電了這種大故障,來電後各種毛病就出現了,開不了機、服務啟不起來、啟動順序又不對、配置丟了、網路不通、資料異常等等。

這種情況就非常鍛鍊人啦,只要出現過一次,一般你之後就會對此專案的全域性掌握比較清晰了,並且一般遇到這種大場面,也正是展示你臺下十年功露臉的最好時機,但可遇不可求。

小故障當然也有學習的價值,遇到得越多,對經驗的提升和以後對問題的全面分析能力都有幫助。

二、有一部分故障是個人操作失誤導致的。

我們經常說,人總是會犯錯的嘛,但這樣自言自語說多了後就會讓人產生懈怠、疏忽,經歷或個人導致故障後,成長更快。

說一個小故事,我在之前一個專案組時,幾乎每個人都有造成過線上故障,於是一旦新人來後,我都會笑著給新同事說,不要怕故障,我們都等著看你表現啦!

一般來說大家的心態都是這樣的: 剛接觸時(小心翼翼),一段時間後(肆意妄為),在觸發故障後(後續做事會不自覺地考慮影響面,對大事很謹慎),希望新入行的同學們早日迎來自己的專屬故障然後突破到第三階段吧!

三、不破不立。

老闆和業務方一般對運維的主要訴求就是穩定,平時這也不讓動、那也不讓動。

自己發現個隱患、提出想主動修復,一般得到的答覆有: 寫個方案研討吧、節後再看看、你找誰再確認一下、有空大家再開會討論、下期專案再搞吧等等等。

但如果是故障期間,你說不這樣搞就恢復不了、或者不搞就算恢復了也堅持不住一天,大家就會空前的支援你。

我很早前實習做網工的時候,辦公室接入有4條電話線,有2條不通,但交換機上和房間內的各種走線太亂根本找不出線來,經常有投訴,但真要去拆開理線時大家又不配合。

某天我實在氣不過,於是把幾條線都悄悄拔了,大家各種支援協助,於是很快就理順了那一坨網線和電話線,美滋滋~。

現在想起來當然還有更恰當的辦法,也肯定不會建議誰主動這樣幹。但如果是故障已經不可避免發生了,那能爭取一下還是爭取一下吧。

如何正確的面對故障

故障的發生是不可避免的,根據墨菲定律,有可能發生就肯定會發生。本文所說的故障,主要是指計劃外事件所觸發的故障,普通割接變更視窗時間內觸發的問題一般不算作故障。

主要是為了說一下關於故障需要注意的地方和建議做的一些事情。

本文就按一般的時間線來走,粗略分為這三個階段:

  1. 事前: 還未發生,可能存在隱患,做一些準備工作;
  2. 事中: 故障開始啦!主要是做一些排查、分析、處理工作;
  3. 事後: 故障已經解決啦!做一些善後事務。

一階段:故障發生前

熟話說有備無患嘛,做足準備是必須的,這一階段主要內容就是做準備工作。

一、常規準備事項

1. 主動巡檢

包括例行巡檢和突擊巡檢,重點是瞭解系統當前是否存在問題。

很多地方的巡檢已經變成了很隨意的形式了,要麼就是給個萬年不變的指令碼讓一線人員上機去跑一下、生成個空報告,或者乾脆就外包出去讓一些看似專業的廠商的實習生對一些通用中介軟體啥的來走個過程。

個人覺得此階段很重要,應該由核心專家團隊來進行,太忙的話一季度或半年一次總行吧。

2. 監控系統

監控系統的三個主要作用:

  1. 一眼看過去能確認當前是否有故障,並確定故障影響範圍;
  2. 記錄故障中各元件異常的發生時間、指標的波動情況,以便事後關聯分析;
  3. 監控告警不分家,告警能有效通知到人很重要。

3. 日誌系統

一定要有集中化日誌系統,將各個主機、元件的日誌後彙集到一個地方進行檢視。

否則排查時,開十幾個視窗到處找日誌看就很低效和麻煩了,而且集中起來後一旦什麼元件因故障不吐日誌了,也很容易確定。

如果暫時沒條件,最次也要將所有的檔案日誌同步到一個地方來,比如集中的syslog服務,ELK日誌收集等都可以考慮。

4. 隱患排查

  1. 通過對架構進行分析,評估可能存在的故障點。 關鍵裝置的效能不足、裝置老化等顯性的隱患;

    配置存放在易失性快取裡面,共享資源隔離程度不夠,全流程涉及的網路節點過多等隱性隱患;

    監控系統自身的可用性,告警方式和路徑是否單一,如果監控系統掛了,或告警路徑斷了呢?

  2. 業務分析,每次特殊性業務開展前進行評估。 年終大促能不能頂住,新增介面的效能情況,資料遷移時能否在規定視窗期間完成,新增的資料空間夠不夠等。

二、預備動作(針對故障的準備工作)

1. 人員分配

按各自的職能和代表立場進行分配,搭配出一個最佳人員協作名單,一般的人員分類方式有:

  1. 一線人員: 最熟悉專案環境的實際維護人員;
  2. 二線專家: 最熟悉某元件或架構的人員,最好每元件或環節要定出首要負責人。 比如測試、開發、產品、資料庫等都需要推出一個第一聯絡人,避免推諉;
  3. 小組指揮: 團隊leader, 經驗豐富,能過濾干擾資訊、協調小組突擊、聯絡各方支援的人員;
  4. 總指揮: 最能拍板、牌面最大、誰都能協調得動的人員,一般是大小BOOS;
  5. 外部人員: 各路相關人員,如廠商專家、合作伙伴、上下游業務系統、對外客服或公關,還有其他一些能出力的人脈。

個人覺得,這中間最關鍵是擔任“路由”角色的人,一是能不能隔離外部的干擾資訊,並且把有價值資訊帶進來,二是能將切實有效的方案傳遞上去給領導去拍板很重要(有些影響大的措施,很多人只能私下說,卻不敢公開說)。

2. 故障分級

先有一個共識性的標準,確定在故障發生時各方需要投入的資源,不至於“草木皆兵”又或者是“狼來了”。

常見的分法: 一般故障、嚴重故障、重大故障,小、中、大,I級、II級、III級、IV級。

分類依據:

  1. 按影響程度來分:業務全部中斷、業務部分中斷、使用者感知較小、使用者無感知;
  2. 按未恢復時間來分:10分鐘都沒解決,30分鐘沒解決,1天沒解決;
  3. 按需要介入的時間分:需要24小時內響應,需要10分鐘內響應,需要即時響應;
  4. 按需要介入的人員級別分:至少要區分是否需要大BOOS介入吧。

級別的動態變化:

  1. 剛發生時,會根據現象及預計需要投入的資源先臨時定一個級別;
  2. 處理過程中如果有其它新增變數,如較長時間都還未解決,又或者引發多米諾骨牌了,就需要將級別進行提升;
  3. 故障處理完畢後,最終通過綜合分析,根據對整體的影響程度,再對級別進行定性。

其它注意事項:

  1. 什麼級別觸發什麼動作?
  2. 什麼情況故障需要升級?
  3. 不同級別對應不同的投入資源。

3. 應急預案

預案的要點:

  1. 針對最可能發生的事情:一線人員、開發人員、架構設計人員 這些應該是最清楚的人;
  2. 針對最不能承受的事情:機密資料丟了、洩漏了,資料庫、快取崩了,登入系統崩了這些;
  3. 臨時事件:大型活動前、大改造前、大領導來訪、大客戶試用等等;
  4. 針對未知的事件:為避免手足無措,總得有個萬金油的角色和小組來先臨時頂一會兒。

4. 工具箱

常用命令集合、常用SQL、長命令,常用小工具、指令碼、密碼本、通訊錄、業務架構圖、網路拓撲圖、裝置位置表等等放在一個方便的地方。

經常發生的一些尷尬事情:

  1. 一大長串命令或SQL敲錯幾個字元;
  2. 幾個協助人員圍著操作人員看他慢慢敲鍵盤乾著急,恨不得推開他自己上;
  3. 準備的指令碼或命令一執行,發現伺服器上沒這個命令,要麼現裝、要麼還得傳上去;
  4. 某主機、資料庫、系統登不上去,密碼找不到、又不知道誰有;
  5. 軟體不知道裝在哪,或者目錄下有多個例項不確定是哪一個;
  6. 連續開啟十幾個日誌檔案都沒有用的內容;
  7. 緊急去到機房,半天不能找到裝置在哪;
  8. 準備打電話聯絡外援或通知誰,才發現沒有存手機號碼,一問周邊人都沒有,到群裡面喊半天對方也沒看到。

5. 可靠的環境

電腦不可靠,關鍵時刻開不了機、軟體打不開、鍵盤滑鼠又壞了,這些事情時間長了就肯定會遇得到。解決辦法:

  1. 公司借用同事電腦;
  2. 家庭備用一個老電腦;
  3. U盤或行動硬碟放著常用工具集;
  4. 弄清楚家附近最近的網咖路線。

網路要麼慢、要麼卡、要麼乾脆連不上。解決辦法:

  1. 可靠的公司網路,可靠的家庭寬頻(南電信北聯通);
  2. 手機雙卡(移動+電信/聯通)隨時開熱點或切運營商;
  3. 備用網路,隔壁公司、樓下小店、左鄰右舍;
  4. 與機房的同事或機房值班人員平時多熟絡一些,關鍵時候能幫你按一下電源,再熟一些可能順便就幫你處理了。

6. 協作方式

大家提前說好,優先用什麼方式配合,免得配合上出現問題,一般規則:

  1. 在公司的相關人員都抱上筆記本就近坐到一起來,最好能霸佔住一個會議室;

  2. 遠端則一定要拉一個線上會議,主要人員操作時投屏,非主要人員不說話時靜音;

  3. 外部專家電話接入時,一定要擴音擴音,避免轉述時出現歧義(個人經歷過此教訓);

  4. 在長時間排查處理時,要有一個行政協調人員,一般是專案領導或“王見 場”負責人擔任。

    負責打飯、訂飯、泡麵、協調會議室、上報進度等輔助工作。

(個人經歷,某次眾人集中排查到深夜,我突然有了一個點子,需要A配合,結果他去泡麵了,A回來後正要開工時,需要配合的B又去泡麵了,最後等人齊多耗了20分鐘)

7. 演練

比較常規一些的就是生產環境切換演練和安全演練了,再升級一步就是測試環境內專家出題進行演練,終極方式當然就是生產環境進行破壞性演練了。


二階段:故障事中

故障處理的基本流程:上報->快速恢復->排查->處置->觀察確認。

1. 上報

上報和搶修應該是不衝突的。

先報再查很有必要,經常遇到一些同事發現故障了,認為需要先觀察一下,要收集一些資訊後才知道上報時如何表述。

我是覺得沒必要,順手一個電話,或發個訊息,說一句“當前時間,發現XX現象,疑似XX故障,速支援”,並不耽誤排查。

先上報以便快速初步定一個故障級別,然後事中每隔一段時間或進行關鍵操作後,也應該上報一下。

2. 快速恢復

線上問題應先求快速恢復,再去分析原因或根治措施。

我也遇到過很多次故障,一群人慢慢排查分析,找出一個解決辦法給領導或客戶,拍板後就做,然後再看有沒有效果。

其實這種方式很不好,就如同本來就有主備環境,出現故障的時候,先討論10分鐘確認是否有必要切備機,一樣很尷尬。

備機難道不應該是隨時可切的嗎?如果不能隨時切換那就說明這不是合格的備用環境。

有人會說,我都沒有排查,不知道問題原因,拿什麼去解決呢?萬一切換後也沒效果怎麼辦呢?

所以快速恢復這一步能否進行的關鍵就靠預案了,良好的預案應該標註有:A現象對應A操作,B現象對應B操作。

一線或應急團隊的人員只要熟悉預案,很快就能確定下一步該做什麼。

有人可能又會問了,那要是把可能發生的每種現象都列出一個操作來,幾百上千條誰能記得住?翻目錄都得2分鐘吧。

但實際情況下,應急操作最多也就三五十條,一是因為很多現象都可以用同一個方法去解,二是內容再多就需要分工了。

比如我之前所在的專案,如果不是業務量的問題,那最通用的也就三板斧,先回退、切備環境、再切資料中心。

關於切換:

  1. 切換還有助於隔離故障“王見 場”,事後分析也方便;
  2. 要是切換也不能解決問題,那至少也排除了很多問題是吧;
  3. 如果一開始就可以確定原因,修復起來比切換代價小,那當然還是推薦快速修復。

3. 排查

排查流程主要也就兩個點:收集資訊->分析

故障排查注意事項

  1. 優先進行最方便最快捷的檢查方式。

    那種需要去執行復雜命令、等一會兒才能出結果的慢動作可以放後面去操作,或者由其他同事並行去做。

  2. 收集到的資訊更多地用於考慮排除問題。

    收集到的資訊既要考慮問題可能在哪,又要用於排除問題應該不在哪。

    比如出現未知故障,先開啟網站首頁,能開啟則入口一側沒問題,打不開多是入口節點或鏈路的問題,從而縮小了排查範圍

  3. 注意人的侷限性

    首先是要確保參與排查的人員對這一塊內容熟悉,然後是小心他太熟悉了。為什麼這麼說呢?

    因為人總是會傾向去做和相信自己熟悉的事情,比如突然資料庫連不上了:

    開發人員傾向於去分析程式碼,看看是不是如邏輯問題導致的執行緒或鎖不釋放等,DBA傾向去排查資料庫自身,主機運維第一時間會去看系統日誌和效能監控資料,網路運維第一時間想到的是登交換機看埠狀態、流量、抓包啥的。

    但團隊裡不是所有人都同時線上的,如果此時就一個人在值班,恰好他排查時又發現了一點和自己專長相關的可疑點,可能就會帶偏大家。

    我以前就常遇到這種事情,故障排查時某人說我發現原因了,約1分鐘能解決,我們舒了一口氣,開始配合,1分鐘後現象還在,一會另一人又發現原因了,改為配合他,這樣反覆幾次才真的找到故障原因。

    所以在排查時要綜合考慮意見,多個方向和措施並行突破。

  4. 排查前要先提問

    一問:哪個節點?

    有問題的是什麼東西,某個例項或某一類例項、某一類業務?

    二問:什麼範圍?

    定位到某個例項、某個主機、某個叢集、某個中心

    三問:什麼程度?

    量級變化,如CPU增了多少,網路慢了多少,業務量增或減了多少。一般來說,如果業務量沒有超過歷史最大峰值,則大概率不是自身效能問題導致。

    四問:什麼時間?

    是否是業務高峰期,是否是關鍵定時任務執行的時間,是否是在常見的變更日(前公司集中在星期二和星期四進行變更)。

    五問:是否有什麼人工例行計劃忘記去做了?

    如:域名續費、https證書到期更換、密碼過期、手工遷移資料、雲實例或寬頻到期續費、忘充電費(真有,我在第一家公司時自建的小機房用的是民電,行政忘了去充電費直接就停電了)。

    加密證書或授權過期,現在很多證書都是有有效時間的,比如https證書一般一年一簽,如果沒有自動更換機制很容易忘。

    給上下游的或上下游給的自簽證書,一般都是設定5年10年,雖然很長,但也是會到期的。

    六問:前後都有什麼動作?

    1. 自己系統的業務和環境變更;

    2. 上下游及周邊業務系統的變更;

    3. 底層設施變更,如網路裝置和策略、儲存裝置、雲或容器平臺等;

    4. 故障發生後其他人都進行了哪些操作。

      用於排除了無效修復措施,記錄一下或許一會兒還要進行回滾。

    七問:現象有什麼規律?

    比如每5分鐘應用卡頓一下,CPU使用率波動起伏有無規律,每天幾點固定出現,做某某操作必然觸發等規律。

    八問:能否重現?

    考慮一下測試環境是否也能重現。

    九問:最近有什麼外部事件?

    • 活動事件: 上游有無活動,或者上游為了應對上上游的活動調整了什麼;
    • 突發事件: 突然爆發的病毒、漏洞,微博上的一個梗,XX門,負面輿論,挖斷光纖、惡劣天氣、地震等;
    • 行政事件: 例如因為行政原因要求限期整改但通知沒有送到有效負責人。
  5. 先靠經驗排查,再靠資料排查

    經驗排查:最瞭解這個系統的人,“王見 場”人員、開發人員、產品使用人員,他們可能看一眼就知道問題在哪了;

    資料排查:就是先把已經提供的資料都看一遍,然後通過執行一些動作獲取一些資料,通過資料進行分析。

  6. 通過資料排查時

    需要的資料

    1. 各種監控指標資料
    2. 各種日誌
    3. 業務資料,比如資料庫的交易筆數變化
    4. 相關人員操作日誌
    5. 需要主動執行一些動作才能獲取的響應資料

    基礎的資料分析方法

    1. 將正常和異常進行對比,例如把之前正常的監控圖表和當前故障點的圖表,重合起來看看看差異是什麼。

    2. 關聯分析,分析多個故障之間存在的關聯分析;

      比如主備機房連線資料庫都報網路錯誤,那就說明跨機房網路應該沒問題;

      又或者故障投訴已經找上門,但卻沒有收到告警,就可能是網路問題導致告警發不出來了。

    3. 排除法:某某指標正常,就證明不可能是某幾類原因。

  7. 無法定位問題的故障該如何處理?

    其實只要不能很快就定位問題,一般也都是這樣幾板斧先臨時解決著。

    1. 服務降級,不提供有異常的服務
    2. 緊急擴容,利用擴容解決資源使用率高的問題
    3. 回退版本,不能迅速確定是否和新版本有關係,就先做版本回退
    4. 切換備節點、備叢集、備中心

4. 處置(正式開始解決)

  1. 備份和保留原“王見 場”

    將系統當前狀態資訊或環境變數記錄一份,需要修改的配置檔案和資料也拷貝一份,以方便驗證無效時進行回退,以及事後寫報告時做為材料。

    但是很多人其實都沒有這樣的習慣,要麼是確實忘了,要麼是趕時間覺得沒必要,要麼是覺得信心滿滿覺得一把能成,這樣肯定是不太好的。

    但比如服務啟動異常,要來回改很多次配置檔案,每次操作前都手工備份一下很耽誤效率的,那有什麼好的辦法嗎?

    解決辦法當然有:

    1. 有定時備份任務,定期自動對配置檔案做備份;

    2. 全域性配置檔案,比如放置git上,每次都從git上改,就不用單獨去備份了;

    3. putty、XSHELL或CRT都是可以記錄螢幕內容至文字檔案的,把自動記錄日誌功能開啟。

      以後任何時候改線上配置時先 cat 一下檔案,只要內容在螢幕上出現過就行,要恢復時從日誌檔案裡面去找,並且事後看看自己的操作記錄也可以很好地梳理清楚處置過程;

      當然 windows也可以使用自帶的 psr 或者其它錄屏工具錄著,有備無患。

  2. 驗證

    理想故障處理一般都是“收集資訊->假設分析->驗證->實施”,條件具備就應該先驗證再實施,沒有條件的話多個人一起討論一下也行。

    應該避免“突然想到啥,就立馬實施”,如果故障感知不明顯且時間允許時,最好是能先在測試環境驗證一下再上生產操作。

    我舉以前遇到一個例子:

    某次線上故障,分析了一會兒得到了正確的解決思路,但操作起來要幾十步,次數多、命令長、中間還需要間隔等待什麼的。

    於是我同事就決定寫個指令碼,主要步驟單獨列出來執行,重複步驟做成迴圈執行,這樣的想法是很好的。

    為了趕時間就直接在生產伺服器上寫了一個幾十行的shell指令碼,但真執行下去,就出大事了。

    先是shell指令碼的部分行語法不對,導致部分內容執行了,部分沒執行,然後發現部分檔案路徑不存在(因變數原因),再發現這幾臺伺服器環境其實是有差異的。 完了,於是更大的麻煩出現了。

    所以勸大家有條件還是每步進行一下驗證為好。

  3. 處置時的重點

    • 快,能批量執行就批量執行,能使用一鍵指令碼就使用一鍵指令碼;
    • 關注每一步的執行結果是否符合預期;
    • 最好操作時旁邊有個人看著一下,一是可以避免誤操作,二是可以協助公開進度。

觀察確認

確認是否真的恢復了,如果沒有恢復,那就再回到“排查-修復”階段。

故障中期的其它要點:

  1. 有預案的先拿出預案來,快速確定是否可以靠預案進行;

  2. 避免獨自排查,排查和處置時及時將有用訊息通知出去,積極請求外部的技術和行政支援;

  3. 需要判斷當前現象是否為最嚴重程度,有可能你發現的只是苗頭,更壞的情況即將出現。

    例如: 備份伺服器故障,導致主庫的資料未能及時遷移走,2分鐘後主庫就要滿啦~


三階段:故障後期

當然不是就這樣簡單的結束啦~,痛苦才剛剛正式開始啦~

要點:

  1. 確認真的恢復了,不要再被打臉啦;
  2. 覆盤,至少要說服自己吧,原因、過程、時間線需要理清楚;
  3. 善後工作: 可能要持續很長時間。 比如資料的導來導去,臨時頂上的裝置和元件、改了的配置都要持續地進行觀察,隨時準備重啟服務啥的;
  4. 影響面、影響程度、損失等資料確認;
  5. 整改計劃,要確認可行、目標不要太高,最好還能舉一反三。 趁這個機會把其它一些不合理的地方也提出改進一下,畢竟不出故障時有些事情是不容易推動;
  6. 彙報,提前想好各種刁鑽問題的應答措辭。

其它注意事項:

  1. 嚴肅的事後形式

    比如誤操作,雖然不一定要進行什麼實質性的處罰,但開個小會內部檢討一下還是有必要的,不然不僅當事人自己不重視,其他同事以後也會不重視。

    (PS: 我們這雖然不做檢討,但預設故障之後的“故障報告+幾十次修改+十餘次的故障報告會”都需要當事人主導,也相當於脫了層皮。)

  2. 有產出

    既是個人的經驗積累,也是公司的知識積累,對新人培訓及熟悉環境很有幫助; 積累到一定數量和時間後,針對top3的故障進行根治; 對完善日後的各項應急預案、監控體系做為輸出材料依據很有幫助。

好了,基本上常規的故障處理流程就結束了,說一些其它相關內容吧。


常見故障整理

個人在這幾年常遇見的以及一些罕見的故障型別梳理:

1. 硬體和網路:

硬體宕機、需要停機進行的配件更換(一般是磁碟、記憶體)、UPS壞了、機房空調壞了、機房進水、機房缺水。

網路一般就是交換機埠壞了,網線介面鬆動,錯誤配置導致網路形成了環路,網路裝置內部系統有BUG,ARP表不夠,網路黑白名單、ACL白名單等等。

(PS: 這個機房進水和缺水還能真能遇得上,去年鄭州暴雨,機房進水不就發生了嗎,機房缺水(缺少乾淨的空呼叫水)也發生了。)

2. 資料庫:

  1. 誤操作刪除或修改了資料;

  2. 高峰期進行 dump/Load 或跑大SQL影響了效能;

  3. 線上DDL操作影響了效能;

  4. 程式bug導致事務長時間未提交,執行緒越來越多;

  5. 各種奇怪的鎖;

  6. 網路儲存的效能問題。

    網路儲存只要不是獨佔就很可能出現被別的系統爭用資源導致的效能問題。

    尤其注意NFS。

3. linux系統:

一般現在作業系統都比較穩定,硬體不出問題的話開機10年都沒有啥問題。

我之前維護的裝置,5、6年沒有重啟過的非常多,只要正確配置好剛上線時不出問題,那就很難出問題。

能出現的主機系統故障,多數是人為導致的。常見情況:

1. 改了關鍵配置

舉個我以前的例子,甲方給的安全加固手冊要求把passwd檔案通過 chattr 加只讀許可權,又要求密碼3月自動到期,並且不允許root使用者遠端登入。

這樣做的效果是什麼呢,安全加固做完了,當時沒啥問題。

3個月後某天密碼到期了,普通使用者登入時就提示要修改密碼,輸入新密碼又提示沒有許可權,想改許可權呢又登入不上主機,死迴圈了。

當時我是怎麼解決的呢?我悄悄潛入機房(正式流程太長,緊急流程又聯絡不上關鍵人,機房在同一棟樓),推個顯示器逐臺修改。

2. 應用程式影響

CPU使用率高、負載高、記憶體使用高、磁碟使用高,基本上和主機作業系統沒啥關係,優先排查應用。

例子: 某次發現一個介面呼叫特別卡,於是ping主機發現延遲特別大(上千ms延遲),於是找網路的人員排查,許久沒結果。 又找主機的人排查,發現CPU負載特別高,排查許久發現負載高的原因居然是記憶體使用率高,記憶體高是因為slab裡面的dentry項太多。 繞了一大圈最後回來發現是還是因為業務程式有bug,有個功能會高頻建立開啟隨機檔名導致。

3. 確實存在的一些系統BUG或機制導致(概率很低);

比如以前使用el5時iptable的ip_conntrack鏈路跟蹤表總是打滿然後拒絕連線,改了配置後一重啟iptable就恢復原值,遇到幾次才發現。

又比如記憶體的使用機制問題,明明還有剩餘記憶體就使用swap了。

4. 軟體:

一般多是執行緒洩漏、記憶體洩漏、連線數太多、日誌吐太多、程式BUG。

5. 安全類:

前幾年有個通過java中介軟體weblogic的反序列化漏洞進行挖礦的事件,原理就是利用漏洞先攻進來,殺死全部JAVA程式,並下載遠端的一個程式進行挖礦。

我們當時的客戶是個國企,出網訪問都需要網路側開目標白名單的,所以沒有真的挖上礦。

但這個java程式總死我們卻找不到原因,一開始沒往攻擊這方面去想,總以為是不是自己程式哪有啥bug,什麼回退版本、改程式碼、抓包分析啥都做了也沒效果。

直到幾天後我把一段特殊的痕跡放到百度上一搜,幾乎驚掉了我下巴,居然還能真遇上攻擊,臨時做了個URL黑名單然後再升級補丁。

所以遇到靈異事件時,最好也先想一想是不是攻擊導致的,還有注意DDOS攻擊也是常有的。另外羊毛黨也要防一下的。

其它要點

故障的責任算誰的?

  1. 你提前發現隱患並提出來了,後面即便出現了你也不會是主責;
  2. 人員誤操作那就別多解釋,認了;
  3. 非人員誤操作,那就集體擔著,如果有可能就推給廠商(拿錢當然得背鍋);
  4. 管理也是口鍋,什麼都可以放,啥故障對內都可以說後續加強管理改進,先有態度和讓步。

一份有效的故障報告要素:

  1. 故障簡述:三五句話說明這次故障事件;

  2. 故障過程:什麼時間發生了什麼,做了什麼;

  3. 故障影響:對業務造成的影響,量化指標。

  4. 比如影響了XX時間至XX時間的多少筆交易,影響xx使用者數,影響了N個上下游業務系統;

  5. 故障原因:詳細列舉故障的根本原因;

  6. 改進措施:短期臨時措施,根本解決措施;

  7. 其它資訊(選填):比如責任方、責任人員、故障定性、損失金額、人員處置措施、人員管理改進措施等等。

故障是如何發現的呢?

  1. 監控系統發出告警:當然覆蓋面、採集時間要合理;

  2. 主動巡檢分析發現:沒事時多看看監控系統指標資料,看看日誌檔案總會有啥新發現的。

    比如某指標異常波動,但還沒觸發告警閾值,日誌檔案吐了點新內容,但沒有被以往關鍵字匹配上。

  3. 外部人員發現通知:使用者投訴、上下游和周邊系統告知等。

個人覺得就 “通知數量和重要程度”來說 監控系統發現佔比80%,主動巡檢發現佔比10%,外部通知佔比10%。

距離寫個人第一篇部落格,居然已經過去8年了,希望自己能重拾初心,繼續熱愛這個專業。