本文是對解決問題的一些方法內容的改寫與補充！

首要的問題

對于發生在線上的問題， 最緊要的事項一定是“以最快最有效的方式解決問題，降低對線上業務的影響”，然后才是深挖問題，探求根本原因，防微杜漸，未雨綢繆。
而對于非線上問題，客觀上會有“相對多一點的處理時間、多一些的分析和處理方法”。

1 接觸與了解

從總體著眼，從細節入手！

確認基本相關信息是必須執行的首要環節，也是后續處理問題的基礎。
如果無法清楚地辨別或陳述問題的基本信息，那么，此時要面對的將不僅僅是問題本身！
不明確和不充分的信息資源，將極大地制約問題處理的效率和效果。

問題的基本信息概括起來，主要包括兩個方面：在怎樣的背景環境下？發生了怎樣的問題？
進一步的細分，可能涉及如下內容：

1.1 問題現象的描述

• 問題的直觀現象
• 問題的初始級別
• 問題發生的時間、地點、報告人
• 問題發生的階段和場景：新安裝階段、實驗階段、生產場景、維護場景。。。
• 問題發生前的操作

1.2 問題的邊界與歸屬

從現象和場景，來判斷是自身的問題？還是外部問題？
實質上，這是在確認自身在問題處理中的角色定位：該發揮怎樣的作用和達到怎樣的效果，由誰來處理、跟進、協助。

如果是自身的問題，那么當前的問題級別和影響是什么？
對應級別和影響的問題，應由對應級別和影響的人去解決，因為這涉及到相應的應急方案措施、資源調動和投入。

如果是外部的問題，那么誰是相關人？需要提供哪些必要的信息？需要進行哪些必要的分析？

1.3 當前狀態和進展

確認是自身的問題后，就需要進一步了解問題的詳細信息。

- 設備版本信息
- 設備使用信息：單方使用還是多方共用。。。
- 設備相關配置、流程、服務、網絡狀態- 收集設備當前日志，并開啟Debug級別日志
- 報錯信息來源與內容- 獲取設備遠程登錄信息
- 客戶及現場工程師的聯系方式- 已采取的步驟、操作、方案。。。問題狀態和現象發生了怎樣的改變；
- 當前投入的資源：參與問題處理的人員及角色定位；

1.4 問題定性

根據收集到問題信息，清楚地辨別問題性質，是探尋問題本質的第一步，也決定著后續處理的方向。

產品問題？ --- 需求問題？ --- 情緒發泄？
原生問題？ --- 由其他問題引發的衍生問題？
個別？ ---  共性？
偶發？ ---  頻繁？
。。。。。。

1.5 下一步的信息

• 在當前處理狀態下，問題的發展趨勢；
• 下一步的人力或物質資源的需求；
• 下一步的步驟、操作、方案。。。；

2- 定位與分析

從總體著眼，從細節入手！

2.1 一般性流程

precondition status  -->  configuration & data flow  -->  log&infos flow  -->  troubleshooting flow

• 每一個環節的前提條件是否成立？
• 每一個環節的配置和數據流是否正確？
• 依據每一個環節的日志或信息，能夠獲取怎樣的判斷依據？

問題定位和分析的過程，實質上是具體業務流程的“映射”，順序和步驟大致相同，遵循著業務數據的流向。
每一個業務環節和階段的日志和配置信息，都是判斷的依據。
因此，熟悉業務環節和階段是問題定位與分析的基礎要求。

2.2 常用的定位與分析方法

a. 場景區分

針對不同階段和場景，側重點不同。
例如：

• 如果問題發生在全新安裝或全新集成階段，那么問題發生的原因更可能與誤操作、誤配置、流程錯誤相關。
• 如果問題發生在產品使用階段，那么要首先確認問題發生之前的狀態、操作信息、業務使用背景、備份配置等。

b. 最小環境與分解排除

• 最小環境法：正向流程分析（業務起點至終點），從最基本因素開始排查，逐步添加其他因素進行判斷。
• 分解排除法：反向流程分析（業務終點至起點），根據業務原理流程，逐步查找有效信息，排除干擾項，縮小范圍。

c. 對比與替換

• 對比：跟正確的做比較，不同的便是可疑的。縱向，同一事物不同時間段的對比；橫向，同一時間段不同事物的對比。
• 替換：分階段分區域，逐步調換對象，分別驗證。換數據、換配置、換模塊、換設備、換環境。。。換人。

d. 重現與模擬

• 重現：在真實環境觀察或模擬問題的發生，得到更多的信息，驗證想法和操作等。
• 模擬：如果沒有真實環境，可以建立虛擬環境（模擬器simulator）來驗證基本流程、配置、數據等。

e. 相似案例

相似的問題現象大都有著相似的原因。
從前期的相似案例中，可以獲取可參考的處理方法，推動當前問題的解決。

f. 試錯

條件允許的情況下，有依據地多次嘗試，可能會發現新的可用信息或處理方式；

g. 信息搜索

信息不僅來自公司組織內部，也廣泛的存在外部空間。

• 常用搜索引擎命令
• Get technical information from the Internet

h. 獲得幫助

每個人都是某一方面的菜鳥，某一細節的白癡。
我們的目標是解決問題，在必要情況下，應該及時從他人請求幫助，這沒什么可恥的。
可恥的是：有方法有途徑來解決問題，但卻不去嘗試。

• 信息獲取途徑匯總

3 - 處理與跟進

從總體著眼，從細節入手！

3.1 一些注意事項

• 關注根本問題：問題處理的過程中，很有可能又引入或出現新的問題，此時面對多個問題，應持續關注根本問題，合理排序，逐個解決，如無必要，不建議同時處理多個問題；
• 信息記錄：盡可能保留相關信息（log 、 screenshot、等等），作為后續處理和問題回溯的資料，例如：在相關登陸程序中啟用log保留功能；
• 獲取權限：重大影響及關鍵操作一定要獲得雙授權（customer and local）
• 狀態同步：及時更新狀態并知會相關人。更新信息應包括：當前狀態、Next action、可能的預計結果、時間點、你的困境和需求等；
• 自我審視：低頭解決問題， 抬頭看問題狀態（自己的角色與作用、進展、性質、customer和high level的反饋。。。）
• 。。。。。。

3.2 無奈的“三板斧”

• 重啟: 根據問題的實際情況，進行業務切換或重啟（進程、服務、模塊、系統、節點、集群、硬件平臺等）；
• 重置：回退到上一版本的配置、回退到默認配置等;
• 重裝: 軟硬件系統已經徹底崩潰或損毀，重裝是無奈的選擇，業務短時間無法恢復；

實際上，以上操作都是“災備方案”的步驟和內容。一個合理的災備方案，必須備份了數據和配置信息。
在“重啟、重置、重裝”過程中，通過導入備份數據和配置，有利于業務的快速恢復。

3.3 全局關注（whole picture）

你只是問題處理流程上的一個環節或者節點，從整個流程上去審視本身的作用，做好該做的事，會更好促進問題解決！

• 從整個事件流程去觀察一個階段和環節；
• 從一個時間范圍去觀察共發事件的相互影響；
• 從一個周期去觀察時間范圍。

4 - 溝通與協作

4.1 換位思考

假定此時你是客戶，從客戶的角度來理解利害點和需求。
受限于信息不對等，理解會存在偏差，不存在“感同身受”，只是盡可能地“設身處地”去了解。
別把自己的感知強加給他人！
你的理解可能只是你的主觀感受，不是客觀的實際狀態。

4.2 情緒控制

人與人的區別，比人與動物的區別都要大。
個體的巨大差別（知識背景、技能狀態、秉性喜好、利害沖突等等），必然會出現難以理解的情況。
對于過程中出現難以理解的事物，只能說。。。盡量避免情緒上的對立。
普通人一旦有了對立情緒這個內因，必然會導致態度上的消極，事物上的拖延，于己于人于事無益！

一個可行的方法：根據當時的實際情況，來確定意愿層級 ： 盡心、盡力、盡責。

• 盡心 --- 愿意投入工作時間之外的精力和資源。
• 盡力 --- 工作時間之內，力所能及地做些額外的事情。
• 盡責 --- 基于事情本身，完成職責之內的事情。

如果心中有“猛虎”，就把這理解為只是一份工作中的一個task而已，如果task的安排具有合理性（時間、技能、目標、資源。。。），那就遵從這個合理性的安排。
就事論事，簡單直接的基于事情本身來開展，基于本職盡責。這是共同協作完成事情的基本要求，同時這也是溝通與協作基礎。

4.3 客戶認知

無論是外部客戶還是內部客戶，一般情況下，可預先假定他們是“高貴、繁忙，迫切而又茫然”的。

• 高貴 --- 以客戶滿意度為最高要求，及時同步問題狀態，保持適當update頻率。否則，客戶有了情緒，分分鐘就能“Management Escalation”到high level發起challenge。
  
• 繁忙 --- 客戶的時間是寶貴的，總是沒時間的，極有可能沒法及時回復和協作。保持謙遜，連環E-mail，連環Call；引入“high level”，繼續搞。或者，從第三封郵件開始，明確申明這是第幾次請求回復，并設置默認選項和時間點，促成客觀選擇。
• 迫切 --- 無論問題怎樣，客戶總是希望以最快速度解決。慎重承諾deadline。
• 茫然 --- 通常不具備相關知識背景，或者只了解基礎的一部分。因此，最初接觸到的問題信息和表述，很可能不準確、不完整，未必反映問題的本質。必要時，信息需要親自重新獲取、確認和對比。需要客戶配合某些操作時，提供詳細的步驟。

如果“恰好”遇到一個“耐心好，時間充裕，懂產品”或者"肯鉆研"的客戶，那么“However,everything has two sides......”，你懂的。

5 - 技術問題閉環

問題得到徹底解決的標志，不是問題現象的消失，而是同樣的問題不再出現。
也就是說，要想使問題真正閉環，需要探求問題的本質，明確產生問題和觸發的根本原因，制定有效的預防措施，并進一步改善處理流程。
這個過程，通常稱為RCA/EDA（Root Cause analysis / Escape Defect Analysis)，簡而言之，這是一個“問題復盤”和“制定預防措施”的過程。

如果僅僅止步于問題現象的消失，甚至滿足于問題處理完成，忽略了對問題的復盤和根本原因的探求，那么這個“根本原因”將會一直潛伏和等待，直到下一個“時機”制造出“更大的驚喜”。
深挖問題，探求根因，防微杜漸，未雨綢繆，這才是業務運行的長久之計。

假設如下幾種場景：

代碼問題

• 是否考慮加強“Code review”環節？
• 通過多人專家review、舉行review會議、采用自動代碼檢視工具和框架等方法是否可以有效避免代碼的異常？

配置問題

• “配置改動”的授權、審核和操作環節是否足夠安全，
• 能否通過“Double Authorization”、“Double Check”、操作前備份配置文件和數據等方法來充分保障？

硬件問題

• 為什么在日常巡檢中沒有發現？
• 原因是什么（評估指標不合理、檢視頻率過低、人為疏忽等等）？
• 可以采取哪種對應的改進措施（更新評估指標、提高檢視頻率、使用自動腳本或工具等等）？
• 備件儲備和更換流程是否健全？

測試性問題

• 為什么本應該在測試階段就應該暴露的問題，結果卻沒有發現？
• 是測試流程有缺失、測試用例和方法不合理、測試環境有缺陷？

特別注意

在進行“問題閉環”的過程中，有一個最容易誤入歧途的關鍵點，也就是“最終的問題歸因”。
根本原因可以是流程欠缺，可以是工具有問題，也可以是信息不準確，甚至是偶發的不可預知因素，但絕不能輕易牽扯到具體某一個人，某一個行為。
簡單來說，就是絕不能輕易將“能力不足”、“工作習慣”、“性格特征”等因素來作為根本原因。

如果認定某位員工有著“能力不足”、 “工作習慣有問題”、“性格不適合”等一個甚至幾個問題，卻又從事重要崗位執行重要操作，那這說明這不僅僅是技術故障，也是管理問題。
換而言之，就是管理層有責任，那么這就超出了“技術問題閉環”的范圍。
應該讓技術的歸技術，讓管理的歸管理，技術性的問題要對應具體的技術細節和流程，而不是具體某一個人以及行為。

6 - 另一種方式

如果你認為下面的問題處理方式是對的：

1. 疑似我的問題，請拿出充分的證據，否則就不是我的問題。。。拒不處理！
2. 第三方的問題，不做必要分析，直接透傳。
3. 存在技術性問題向“非技術性問題”轉換的可能性，于是“其實這不是問題，這是需求，這是體驗差的抱怨。”。
4. 過多引入不必要人員和事項，人多事情雜，流程長又慢，問題仍在處理中。
5. 多次、長時間的索取不必要的信息，企圖以時間來淡化微小問題的影響，迫使客戶逐漸失去關注度。
6. 問題個別罕見，沒有足夠的信息支持分析和定位，請在問題重現時，及時提供更多信息。
7. 久拖不決，不了了之。

面對問題時，如果個體基礎能力不足，卻企圖以抖機靈式的技巧來規避，最終都會將自身推入一個更深的大坑，“昨天總會在明天等你！”。

轉載于:https://www.cnblogs.com/anliven/p/9123980.html

總結

以上是生活随笔為你收集整理的TS - 处理故障的一些通用方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。