快準穩:值得所有運維學習的SRE故障處理經驗
在網路上關於 SRE 的討論中,故障相關的內容比比皆是,但關於故障發生時的應急處理過程的詳細討論卻寥寥無幾。然而面對故障,故障指揮官一定面臨著較大的壓力,需要快速、正確地處置故障,應對內外部的挑戰。在這篇文章中,我們將重點探討故障指揮官在故障處理過程中的具體行動思路。
值得注意的是,本文總結了作者在擔任故障指揮官時,對故障感知、故障定級、故障處理以及故障恢復等環節的經驗和心得,而並未涉及如何預防故障或進行故障覆盤的內容。
1、故障感知
眾所周知:故障一般來自兩個部分的輸入:監控系統和使用者(客戶)報障。
- 首先,監控系統在SRE工作中起著至關重要的作用。監控系統可以實時監測系統的業務指標和效能引數。當系統出現異常或達到預設的條件時,監控系統會自動觸發告警併傳送給SRE團隊。這些告警包括基礎設施監控(如伺服器負載過高、網路延遲異常、儲存空間不足等等),也包括業務層面的監控(如介面成功率、頁面白屏化/JS錯誤等)。
- 其次,客戶或使用者的報障也是故障的輸入來源。當客戶或使用者在使用系統時遇到問題或異常情況,他們透過電話、即時通訊、工單等各種渠道向技術支援團隊報障。我們可以透過程式去監控投訴關鍵字、重點客戶客情,當有客情出現時,SRE可以進行故障排查和解決。
涉及監控系統的實現細節,不在此贅述。
2、故障的定級
在處理故障時,首先需要判斷故障的影響範圍,即確定是否構成故障。這可以透過以下幾種方式進行判斷:
- 系統維度判斷:監控系統提供了實時的系統指標和效能引數,故障指揮官在收到告警後,可以透過監控資料來判斷系統是否真實出現異常。例如,關鍵介面返回碼成功率嚴重下降,關鍵介面耗時嚴重上升,由相關的介面指標資料來定義故障的級別。
- 使用者維度判斷:如果多個使用者報告了相似的問題,根據報障的使用者數量來判斷、根據監控系統所體現的使用者維度的資料,判斷該故障可能影響了多少客戶,從而定義故障的級別。
- 重點客戶的反饋判斷:重點客戶通常是對系統穩定性和效能要求較高的客戶。也是業務的重要收入來源, 他們的反饋對於判斷故障的影響範圍非常重要。如果重點客戶反饋了故障或異常情況,可以根據客戶的級別、受影響的業務規模、客情反饋情況等來定義故障的級別。
3、故障處理團隊的組織
當故障發生時,首要任務是立即召開線上故障會議。組織此類會議時,可以從以下幾個方面進行考慮和動作:
- 判斷要捲入誰:
- 模組元件相關性:根據故障的性質和影響範圍,確定與故障相關的模組或元件。然後捲入與這些模組或元件直接相關的團隊成員,以確保有專業知識和經驗來處理故障。
- 最近的可疑的變更團隊:如果故障與最近的變更點時間吻合,建議捲入該變更團隊。
- 歷史出現過相似的問題:歷史上出現過相似的問題,可以將當時處理過故障的人員捲入到會議。
- 內部面向客戶/使用者相關人員:如果故障影響了重要客戶或使用者,可以單獨拉取一個群組來同步與這些客戶或使用者相關的問題。這個群組應該包括與客戶或使用者關係密切的團隊成員,以便及時響應和解決他們的問題。
- 會議中的挑戰:在組織故障處理群組時,確保成員有效溝通和協作至關重要。然而,剛開始拉群時可能會面臨以下挑戰:
- 資訊缺乏同步:由於故障突然發生,每個被拉入群組的成員可能會詢問當前問題的情況。故障指揮官可能會需要重複當前的情況。
- 建議在拉入會議時同時建立一個工作群(如企業微信群、微信群),並在群裡釋出公告,公告裡詳細說明故障的影響範圍、受影響的業務以及故障發生的時間。以免入會人員重複詢問。
- 資訊不夠聚焦:在故障處理群組中,有些技術人員可能會陷入討論一些細節或不太關鍵鏈路的問題。
- 在這種情況下,故障指揮官的角色至關重要,需要確保抓住重點 主線:果斷打斷故障恢復主線無關的問題討論(如果是疑似問題根因但未確認,可以組織相關人員到分會場討論),優先恢復受損的業務,而將其他問題放在次要位置。如果故障受損的業務較多,可以考慮根據影響範圍、程式等因素進行排序,以便更有效地處理故障。
4、故障的處理
故障發生後,需要指揮、協調相關團隊進行及時止損及恢復:
- 討論制定恢復措施:快速恢復的方法包括流量排程、流量限制、業務降級、緊急擴容、元件重啟、版本回退、緊急補丁、資料恢復等。可以根據系統的能力、日常的演練結果等來綜合決策。
- 流量排程:業務具備多地/多SET部署能力,當某一部分模組有故障時,及時排程到其他地域/SET來恢復業務
- 故障隔離:由於IaaS/灰度模組等區域性原因造成業務故障時,可以考慮將相關裝置/模組剔除以恢復業務。
- 全侷限流:故障由於業務流量增長引起,可以考慮在接入層、服務閘道器等元件上進行限流。限流的閾值可以參考歷史峰值或者壓測驗證過的數值。
- 緊急擴容:故障由於業務流量增長引起,在資源足夠、能快速擴容的情況下,可以緊急對業務模組進行擴容。需要注意的是,如果使用者或業務呼叫方有大量的重試行為,此時需要配合限流措施。
- 元件重啟:某些元件可能出現了故障,由於某些原因造成了CPU Hang死或者記憶體駐留,導致系統運營緩慢或業務邏輯錯誤,可以採用重啟來恢復業務。
- 版本回退:當確認故障是由於業務發版引起,可以採用版本回退來恢復業務。
- 緊急補丁:故障因為觸發到業務設計上的缺陷而無法使用以上手段恢復。需採用緊急補丁修復。
- 資料恢復:由於問題涉及到資料損壞或丟失,需要進行資料恢復。
- 其他:所採取的其他恢復方案
- 進行恢復措施評估:
- 措施是否得力、有效。恢復業務為第一要務,該措施是否能夠有效恢復業務。
- 措施是否相對較優,如果評審中有異議,提出並討論最佳化方案。
- 如果恢復方法對業務有影響,捲入利益相關方評估影響是否能夠接受。
- 考慮相應的回退措施。
- 及時決策:由於故障對客戶的業務有損,所以及時決策非常重要,最小化故障時間有利於減少損失。故障指揮官需要有相應的擔當,及時決策相關處置措施的實施。如果涉及到業務流程相關,需要提前考慮緊急變更的業務流程。
- 實施恢復措施:確定恢復措施後,經過關鍵人員審批後,及時實施到業務環境。如果措施未生效,則需要決策回退。
- 觀察判斷業務是否恢復:觀察關鍵的監控指標是否恢復,客戶的反饋是否消失。
5、故障資訊的透明與同步
故障發生期間,會有不同的群體透過相關渠道來向故障指揮官瞭解進展,如:相關領導和同事來詢問並給出他們認為有效的意見,客戶技術支援團隊/運營團隊來詢問故障的原因及什麼時候恢復。
為了有效向各相關團隊同步業務進展,保持統一的口徑,需要考慮以下幾點:
- 故障由誰來同步比較好:
- 內部:建議由故障指揮官來進行同步,也可以由故障指揮官指派相關的同事來準備文字素材,故障指揮官整合確認後同步。所以對故障指揮官有一定的要求:故障指揮官應熟悉IT系統的基礎理論,並對應用系統技術架構有積累,具備嚴謹的邏輯思考能力,以確保故障形成的原因經得起推敲與挑戰。
- 有關是否需要向客戶同步進展:建議由故障指揮官(或故障指揮官指派相關人員)提供素材,同步給運營團隊或TAM(技術支援經理)來主導,相關對客團隊來準備合適的話術,以確保資訊清晰易懂。
- 故障資訊同步需要包含的內容:故障同步時,因為內部和外部的受眾和需求不同,資訊口徑有一些差異,主要的差異點是如下:
- 內部同步:主要面向組織內部的成員,包括技術團隊、管理層和其他相關人員。確保團隊成員瞭解故障的詳細情況、進展和解決方案,以便有效地參與故障處理和提供支援。通常會涉及更多的技術細節和操作細節,以滿足團隊成員對故障處理的需要。
- 外部同步主要面向外部的利益相關者,包括客戶、渠道合作伙伴、和其他相關方。資訊要足夠準確、透明,以便使用者瞭解故障的影響和恢復進展。通常需要使用更簡潔、易懂的語言,避免過多的技術細節,以讓外部使用者感知上透明、可控。
因此,為了滿足內部和外部受眾的不同需求,故障同步時對不同的內外受眾需要採用不同的口徑和資訊呈現方式。
- 故障指揮官需要在內部同步的內容如下:
- 故障開始時間:什麼時候開始的(可以根據監控系統的指標變動時間,極個別情況,監控系統未體現的話也可以根據客戶反饋的時間)
- 影響範圍:影響了哪些功能,哪些客戶,多少裝置量、業務量等
- 預計恢復時間:預計什麼時候可以恢復,一般在這裡要同步一個初步預估的時間。後續可以隨著處理的進展來重新整理。
- 當前進展情況:懷疑方向是什麼,誰在處理,當前處理的進展如何,一般可以先概括一下處理的整體方案,整體方案一共有幾步,目前進展到哪一步了。預計什麼時候可以執行完。
- 需要哪些幫助:有時候這一點尤其重要,當前執行預案的時候,碰到了什麼棘手的問題,需要什麼資源。
- 故障指揮官需要向外部同步的資訊如下:
- 故障的現象:發生了什麼問題,該故障的觸發條件是什麼。
- 問題原因:故障原因是否已經查明,如果已經查明,簡潔地描述原因。
- 問題處理的進展:對故障進行了怎麼樣的處理,如果有多個恢復止損的步驟,目前進行到第幾步了。
- 並預計恢復時間:預計什麼時候能夠恢復。
- 規避方法:如果在使用者側有辦法臨時規避,可以告知規避方式。例如業務切換、降級等。
以上描述的資訊框架可以用來做為故障資訊同步的參考框架。故障指揮官應保障內部和外部團隊對故障的知情權,同時也應當保證資訊的一致性和權威性。
故障恢復後,可以向各相關方推送相關的故障恢復資訊。可以參考包含以下資訊:
- 內部同步
- 故障現象
- 影響範圍
- 故障原因
- 恢復時間及恢復方法
- 外部同步
- 故障現象
- 故障時段
- 官方的故障原因
由於故障涉及到使用者的業務,可以同時請外部使用者予以驗證。
總 結
總的來說,本文詳細探討了SRE工作中故障指揮官處理故障的各個環節,包括故障的感知、定級和處理過程。故障指揮官在這個過程中的非常重要,既需要具備技術架構、技術細節的理解,又需要有良好的溝通和協調能力。以便在故障發生時,能夠迅速組織團隊,制定並執行恢復措施。
同時,故障指揮官還需要負責向內外部團隊同步故障進展,這需要他們有清晰的思考能力及語言文字組織能力。當然,一個優秀的SRE不僅能夠鎮定應對故障,他們還會透過最佳化業務部署、完善可觀測體系、組織完善應急預案並充分驗證等手段來預防故障或縮短故障的持續時間。
在故障恢復後,他們還需要負責組織深度的故障覆盤,識別故障的根源,並制定策略以防止同類問題的再次發生。
來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/70013542/viewspace-3003802/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 如何運用結構化思維進行故障處理
- rabbitmq 原理、叢集、基本運維操作、常見故障處理MQ運維
- 高校被盜郵箱處置的運維經驗分享-清華大學運維
- 谷歌SRE與運維工作的思考谷歌運維
- Linux的好處有哪些?Linux運維學習Linux運維
- 告警運維中心|構建高效精準的告警協同處理體系運維
- 【故障處理】ORA-600:[13013],[5001]故障處理
- 《Google SRE 運維解密》讀書筆記Go運維解密筆記
- 微服務的故障處理微服務
- linux故障處理Linux
- 故障分析 | Greenplum Segment 故障處理
- 轉行Linux運維需要學習嗎?學習Linux運維Linux運維
- 經典乾貨:Docker 常見故障排查處理Docker
- 運維7年,對Linux的經驗總結運維Linux
- 日常運維之TX鎖處理(一)運維
- 日常運維之TX鎖處理(二)運維
- GPON網路故障如何處理?GPON網路故障處理流程
- 【MySQL精品學習資源合集】含入門課程、學習筆記、運維經驗總結(建議收藏!!)MySql筆記運維
- 什麼是SRE工程師?SRE工程師和運維有什麼區別?工程師運維
- 如何更好的學習Linux系統?值得每一位運維人員深讀!Linux運維
- Linux 運維工程師入門和學習必經之路!Linux運維工程師
- 「譯文」Google SRE 二十年的經驗教訓Go
- 回顧走上Linux運維路上的那點經驗Linux運維
- 學習Linux運維有哪些學習方法?Linux運維
- MySQL show processlist故障處理MySql
- Oracle更新Opatch故障處理Oracle
- teams登入故障處理
- 做運維的感悟(做運維需要考慮事,運維組織結構,運維學習地圖....)運維地圖
- 學習Linux運維技術對找工作有好處嗎?Linux運維
- 初體驗!老男孩linux運維班學習心得分享Linux運維
- 學習Linux運維後的薪水如何?Linux運維
- 自學linux運維改怎麼學習Linux運維技術?Linux運維
- 運維學習有什麼好的學習方法嗎?運維
- 初學者如何學習Linux運維?影響運維的有哪些因素?Linux運維
- SpringBoot運維學習筆記Spring Boot運維筆記
- 虎牙直播運維負責人張觀石 | 解密SRE的六種能力及虎牙運維實踐運維解密
- Linux運維工程師簡歷專案經驗Linux運維工程師
- 運維每天都做什麼工作呢?Linux運維學習運維Linux