《Google運維解密》之問題排查
該文章出自于ADDOPS團隊,是《Google運維解密》系列的關于問題排查的一篇分享。該文章主要是和大家聊了聊日常運維問題排查時候的一些原則與心得。推薦大家結合前面的解密系列文章一起來看,這樣就能更系統的了解Google SRE在運維方面的一些精華了。希望該文章能給大家日常問題的排查能有個更好的啟發。
PS:豐富的一線技術、多元化的表現形式,盡在“FT12短網址資訊”,點關注哦!
前言
今天我們來聊聊“問題排查”這個話題,本人到目前為止還在參與短網址服務一線運維的工作,遇到過很多“稀奇古怪”的線上故障和問題,結合SRE中給出的一些方法,來說說“問題排查”那點事。
排查問題不是玄學
排查出線上問題,并找到根本原因加以解決,是一件很有成就感的事情,曾經有人問過我,“你是怎么想到問題出現在xxx的?又是怎么確認根本原因是xxx的?”,我只能淡淡的說:“靠經驗”,然后感覺這個逼裝的自己還算滿意。
其實這個“靠經驗”說的很模糊,一直以來,大家都覺得排查問題要靠經驗,但是又說不出具體通過啥經驗排查出了問題,最后讓排查問題逐漸變成了一門玄學。
排查問題猶如破案
排查線上問題,就和偵探破案一樣,就是一個不停分析線索,推理的過程,在你準備破案之前,先要明確以下兩點。
系統異常是正常的,正常是特例
時至今日,計算機系統已經變得異常復雜,一次用戶請求可能要經過發送請求,DNS解析,運營商網絡和IP轉換,負載均衡,服務器硬件,虛擬機/容器,視業務邏輯的復雜程度,可能還要調用其它組件,存儲,數據庫,緩存等。每個環節都可能出現問題,有的組件又是分布式的,大大增加的排查問題的難度。
所以出現問題后,不要著急,保持好心態,要認為“系統異常是正常的,正常是特例”。
飛行員首要任務是保持飛機飛行
在初級飛行員的課程中撿到,在緊急情況中,飛行員的首要任務是保持飛機飛行,相比保證乘客與飛機安全著陸,故障定位和排除是次要目標。--SRE
所以,恢復線上系統是首要任務,而不是找到它發生的原因。
明確案情
先評估出這個問題的影響范圍,是全網用戶不可用,還是某些用戶,是某條業務線出現問題,還是很多業務線都出現問題,評估出案情的大小,是普通的民事案件,還是刑事案件。
真相只有一個
計算機是一門科學,而且計算機是由0|1組成的世界,在這個世界里只有“是或否”,沒有中間地帶,所以在計算機世界“凡事都有根本原因”,“沒有偶然發生,一切都是必然”。
所以,你要堅信真相只有一個。
理清線索
理清目前得到的線索和信息,比如監控上有網絡報警,有用戶反饋無法訪問,有開發人員反饋服務器有問題,不要漏掉看似無關緊要的線索,把這些線索先整理下來,后面一并分析。
擴大信息量
盡可能擴大你接受到的信息量,比如問詢一下開發人員今天有沒有做線上改動,網絡組有無重大調整。獲取到有價值的信息,對于排查問題至關重要。
查看監控,細看某個監控項的變化,追蹤日志和調試信息都是擴大信息量的手段。
分析證詞
分析用戶反饋的現象,數據是可信的,有時候人說的是不可信的,舉個例子,之前有開發反饋我們虛擬機有問題,有些虛擬機接口返回異常,有些正常,他就讓我們幫查查虛擬機的問題,但是最后是代碼調用一處動態配置造成的。
很多反饋的信息描述,是經過描述者過濾加工過的信息,他的排查和分析有可能把你“帶歪了”,先要用懷疑的態度,分析每個人的證詞。
當你聽到蹄子聲響時,應該先想到馬,而不是斑馬
排查問題不要先入為主,有時候你覺得極其簡單,看似非常不可能發生的事情,可能就是原因,不要輕易的排除掉某項原因,比如“宇宙射線導致某個電路信號出錯”。
我們之前有個mysql連接異常的問題,查了很久,做了很多調優都沒有解決,最后發現是網卡跑滿了。
從大到小,從上到下
排查步驟,先“從大到小”,先看比如運營商網絡,機房狀態等比較宏觀的地方是否有問題,逐一排除,逐步縮小問題范圍?!皬纳系较隆?,先從現象發生的頂端調用鏈逐一排查,逐步向下深入。
SRE給出的一些方法
SRE給出了一些方法可以借鑒:
問題排查的幾個步驟:定位,檢查,診斷,測試/修復,治愈。
什么,哪里和為什么,找出系統正在執行“什么”,詢問系統“為什么”執行這些操作,以及系統的資源都被用在了“哪里”可以幫助你了解系統為什么出錯。
確定“最后一個修改”發生的時間。
提供豐富的診斷和監控工具。
下次遇到問題,使用以上方法試試看,讓問題排查不再是“很玄妙的東西”。
掃描二維碼推送至手機訪問。
版權聲明:本文由短鏈接發布,如需轉載請注明出處。
本文鏈接:http://www.virginiabusinesslawupdate.com/article_366.html