運維問題排查思路

運維問題排查思路

一、常見的方法：

1）肯定故障現象並初判問題影響
在處理故障前，運維人員首先要知道故障現象，故障現象直接決定故障應急方案的制定，這依賴於運維人員須要對應用系統的總體功能有必定的熟悉程度。確認了故障現象後，才能指導運維人員初判斷故障影響。

2）應急恢復
運維最基本的指標就是系統可用性，應急恢復的時效性是系統可用性的關鍵指標。
有了上述故障現象與影響的判斷後，就能夠制定故障應急操做，故障應急有不少，好比：

服務總體性能降低或異常，能夠考慮重啓服務；
應用作過變動，能夠考慮是否須要回切變動；
資源不足，能夠考慮應急擴容；
應用性能問題，能夠考慮調整應用參數、日誌參數；
數據庫繁忙，能夠考慮經過數據庫快照分析，優化SQL；
應用功能設計有誤，能夠考慮緊急關閉功能菜單；
還有不少……

另外，須要補充的是，在故障應急前，在有條件的狀況須要保存當前系統場景，好比在結算進程前，能夠先抓個CORE文件或數據庫快照文件。

3）快速定位故障緣由
是否爲偶發性、是否可重現
故障現象是否能夠重現，對於快速解決問題很重要，能重現說明總會有辦法或工具幫助咱們定位到問題緣由，並且能重現的故障每每多是服務異常、變動等工做致使的問題。若是故障是偶發性的，是有極小几率出現的，則比較難排查，這依賴於系統是否有足夠的故障期間的現場信息來決定是否能夠定位到老是緣由。

是否進行過相關變動
大部份故障是因爲變動致使，肯定故障現象後，若是有應的變動，有助於從變動角度出現分析是不是變動引發，進而快速定位故障並準備好回切等應急方案。

是否可縮小範圍
一方面應用系統提倡解耦，一支交易會流經不一樣的應用系統及模塊；另外一方面，故障可能因爲應用、系統軟件、硬件、網絡等環節的問題。在排查故障緣由時應該避免全面性的排查，建議先把問題範圍縮小到必定程序後再開始協調關聯團隊排查。

關聯方配合分析問題
與第（3）點避免同時各關聯團隊同時無頭緒的排查的同時，對於牽頭方在縮小範圍後須要開放的態度去請求關聯方配合定位，而對於關聯方則須要有積極配合的工做態度。

是否有足夠的日誌
定位故障緣由，最經常使用的方法就是分析應用日誌，對運維人員不只須要知道業務功能對應哪一個服務進程，還要知道這個服務進程對應的哪些應用日誌，並具有一些簡單的應用日誌異常錯誤的判斷能力。

是否有core或dump等文件
故障期間的系統現場很重要，這個在故障應急前建議在有條件的狀況下留下系統現場的文件，好比CORE\DUMP，或TRACE採集信息等，備份好一些可能被覆蓋的日誌等。

上述是通常性的故障常見的方法，在重大故障或多方處理的故障出現時，每每小範圍的排查不利於快速解決，須要啓動緊急處理的流程，建議能夠考慮如下溝通：

召集相關人員
描述故障現狀
說明正常應用邏輯流程
陳述變動
排查進展，展現信息
領導決策

2. 完善監控

1）從監控可視化上完善
完善的監控策略須要有統一的可視化操做界面，在制定完善的監控策略後，故障處理人員須要可以快速的看到相應的運行數據，好比：可以看到一段時間的趨勢、故障期間的數據表現、性能分析的狀況等等數據，且這些數據能夠提早制定好策略直接推出分析結果給故障處理人員，這樣就大大提升了故障的處理效率。

2）從監控面上完善
監控最基本的工做就是實現對負載均衡設備、網絡設備、服務器、存儲設備、安全設備、數據庫、中間件及應用軟件等IT資源的全面監控管理。在應用軟件類的監控工做中，不只須要有服務進程、端口等監控，還須要有業務、應用層的監控。全面性的應用監控可讓故障提早預警，並保存了影響應用運行環境的數據，以縮短故障處理時間。

3）從監控告警上完善
完善的監控策略須要有清晰的監控告警提示，值班人員要以根據監控告警便可做出簡單的問題定位與應急處理方案。

4)從監控分析上完善
完善的監控策略不只須要有實時的數據告警，也要有彙總數據的分析告警,實時數據分析的告警的重要性不用多說，對於彙總分析的數據則能發現潛在風險，同時也爲分析疑難雜症提供幫忙。

5)從監控主動性上完善
監控不只僅是報警，它還能夠作得更多，只要咱們想辦法賦予它主動解決事件的規則，它便有爲管理員處理故障的能力。

三、應急方案

提早制定好故障應急方案是頗有必要的，但在平常工做過程當中咱們的應急方案遇到一些問題：

1）應急方案缺少持續維護，缺少演練，信息不及時、不許確；

2）應急方案過於追求大而全，致使不利於閱讀與使用；

3）應急方案形式大於實際使用效果，方案針對性不強；

4）只關注應急方案的內容，但沒有關注運維人員對方案的理解；

針對上述常見問題，應急方案須要作到如下幾點：
1）內容精簡
不少人可能會認爲故障出現的形式各類各樣，因此應急方案須要涉及到方方面面。但實際的故障處理過程當中，咱們能夠發現其實咱們的應急措施每每重複使用幾個經常使用的步驟，因此應急方案要有重點，若是一個應急方案能夠應對平時故障處理80%的場景，那這個應急手冊應該是合格的。過於追求影響應用系統方方面面的內容，會致使這個方案可讀性變差，最終變動一個應付檢查的文檔。如下是應用系統應急方案應該有的內容：

（1）系統級：
能知道當前應用系統在整個交易中的角色，當前系統出現問題或上下游出現問題時，能夠知道如何配合上下游分析問題，好比：上下游系統如何通信，通信是否有惟一的關鍵字等。另外，系統級裏還涉及一些基本應急操做，好比擴容、系統及網絡參數調整等。

（2）服務級：
能知道這個服務影響什麼業務，服務涉及的日誌、程序、配置文件在哪裏，如何檢查服務是否正常，如何重啓服務，如何調整應用級參數等。

（3）應用級：
能知道如何查到某應用出現了問題，是大面積、局部，仍是偶發性問題，能用數聽說明應用影響的狀況，能定位到應用報錯的信息。這裏最經常使用的方法就是數據庫查詢或工具的使用。知道最重要的交易如何檢查是否正常，重要的定時任務的應急處理方案，業務的時間要求及應急措施。

（4）輔助工具的使用：
有時候，須要藉助一些工具或自動化工具輔助分析並應急，這時須要有輔助工具如何使用的方法。

（5）溝通方案：
溝通方案涉及通信錄，包括上下游系統、第三方單位、業務部門等渠道。

（6）其它：
上述5點內容如何都完備，相信這個應急手冊己能夠解決80%的故障恢復工做。

2）應急方案是一項持續的工做
有了應急方案，如何讓運維人員持續去更新是難點。要解決這個難點，須要先讓運維人員常用這個手冊。若是一個手冊沒有場景能夠用，那就須要管理者爲運維人員創造機會去使用這個手冊，好比應急演練。應急方案最終能夠歸檔到知識庫。

3）關注運維人員對應用關鍵信息的認識
前兩點關注了手冊，最後一點有必要關注使用這個手冊的人。有些運維人員認爲應用運維人員沒有能力去把應用系統自己的內容瞭解得很透徹，因此應用運維人員在故障處理過程當中的地位很尷尬，運維人員掌握操做權，但殊不知道應該操做什麼。

對此，應用運維人員不須要掌握應用系統的業務功能，但就對應用系統自己來說應用運維人員須要具有如下最基本的能力：

（1）知道應用系統這個是幹什麼的，基本的業務是什麼；
（2）知道應用架構部署、上下游系統邏輯關係；
（3）知道應用下的服務的做用、端口、服務級的應急處理，日誌等數據信息如何找到並簡單定位。
（4）知道應用系統重要的時間點及任務，好比定時任務的時間點以及如何判斷這些任務是否正確
（5）知道最重要的業務流程；
（6）知道常見數據庫表結構，並能使用。

參考：

https://iangilham.com/2016/12/08/core-dump-from-centos-7.html

---

今天先到這兒，但願對技術領導力， 企業管理，系統架構設計與評估，團隊管理, 項目管理, 產品管理,團隊建設 有參考做用 , 您可能感興趣的文章:
精益IT組織與分享式領導
領導人怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
互聯網高效研發團隊管理演進之一
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟件工程的迷思
企業項目化管理介紹
軟件項目成功之要素
人際溝通風格介紹一
學習型組織與企業
企業創新文化與等級觀念
組織目標與我的目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網數據庫架構設計思路
IT基礎架構規劃方案一(網絡系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變

若有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關注個人微信訂閱號：

做者：Petter Liu
出處：http://www.cnblogs.com/wintersun/ 本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。 該文章也同時發佈在個人獨立博客中-Petter Liu Blog。