本文是對解決問題的一些方法內(nèi)容的改寫與補(bǔ)充！

首要的問題

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

1 接觸與了解

從總體著眼，從細(xì)節(jié)入手！

確認(rèn)基本相關(guān)信息是必須執(zhí)行的首要環(huán)節(jié)，也是后續(xù)處理問題的基礎(chǔ)。
如果無法清楚地辨別或陳述問題的基本信息，那么，此時要面對的將不僅僅是問題本身！
不明確和不充分的信息資源，將極大地制約問題處理的效率和效果。

問題的基本信息概括起來，主要包括兩個方面：在怎樣的背景環(huán)境下？發(fā)生了怎樣的問題？
進(jìn)一步的細(xì)分，可能涉及如下內(nèi)容：

1.1 問題現(xiàn)象的描述

• 問題的直觀現(xiàn)象
• 問題的初始級別
• 問題發(fā)生的時間、地點(diǎn)、報告人
• 問題發(fā)生的階段和場景：新安裝階段、實(shí)驗階段、生產(chǎn)場景、維護(hù)場景。。。
• 問題發(fā)生前的操作

1.2 問題的邊界與歸屬

從現(xiàn)象和場景，來判斷是自身的問題？還是外部問題？
實(shí)質(zhì)上，這是在確認(rèn)自身在問題處理中的角色定位：該發(fā)揮怎樣的作用和達(dá)到怎樣的效果，由誰來處理、跟進(jìn)、協(xié)助。

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

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

1.3 當(dāng)前狀態(tài)和進(jìn)展

確認(rèn)是自身的問題后，就需要進(jìn)一步了解問題的詳細(xì)信息。

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

1.4 問題定性

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

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

1.5 下一步的信息

• 在當(dāng)前處理狀態(tài)下，問題的發(fā)展趨勢；
• 下一步的人力或物質(zhì)資源的需求；
• 下一步的步驟、操作、方案。。。；

2- 定位與分析

從總體著眼，從細(xì)節(jié)入手！

2.1 一般性流程

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

• 每一個環(huán)節(jié)的前提條件是否成立？
• 每一個環(huán)節(jié)的配置和數(shù)據(jù)流是否正確？
• 依據(jù)每一個環(huán)節(jié)的日志或信息，能夠獲取怎樣的判斷依據(jù)？

問題定位和分析的過程，實(shí)質(zhì)上是具體業(yè)務(wù)流程的“映射”，順序和步驟大致相同，遵循著業(yè)務(wù)數(shù)據(jù)的流向。
每一個業(yè)務(wù)環(huán)節(jié)和階段的日志和配置信息，都是判斷的依據(jù)。
因此，熟悉業(yè)務(wù)環(huán)節(jié)和階段是問題定位與分析的基礎(chǔ)要求。

2.2 常用的定位與分析方法

a. 場景區(qū)分

針對不同階段和場景，側(cè)重點(diǎn)不同。
例如：

• 如果問題發(fā)生在全新安裝或全新集成階段，那么問題發(fā)生的原因更可能與誤操作、誤配置、流程錯誤相關(guān)。
• 如果問題發(fā)生在產(chǎn)品使用階段，那么要首先確認(rèn)問題發(fā)生之前的狀態(tài)、操作信息、業(yè)務(wù)使用背景、備份配置等。

b. 最小環(huán)境與分解排除

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

c. 對比與替換

• 對比：跟正確的做比較，不同的便是可疑的?？v向，同一事物不同時間段的對比；橫向，同一時間段不同事物的對比。
• 替換：分階段分區(qū)域，逐步調(diào)換對象，分別驗證。換數(shù)據(jù)、換配置、換模塊、換設(shè)備、換環(huán)境。。。換人。

d. 重現(xiàn)與模擬

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

e. 相似案例

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

f. 試錯

條件允許的情況下，有依據(jù)地多次嘗試，可能會發(fā)現(xiàn)新的可用信息或處理方式；

g. 信息搜索

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

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

h. 獲得幫助

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

• 信息獲取途徑匯總

3 - 處理與跟進(jìn)

從總體著眼，從細(xì)節(jié)入手！

3.1 一些注意事項

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

3.2 無奈的“三板斧”

• 重啟: 根據(jù)問題的實(shí)際情況，進(jìn)行業(yè)務(wù)切換或重啟（進(jìn)程、服務(wù)、模塊、系統(tǒng)、節(jié)點(diǎn)、集群、硬件平臺等）；
• 重置：回退到上一版本的配置、回退到默認(rèn)配置等;
• 重裝: 軟硬件系統(tǒng)已經(jīng)徹底崩潰或損毀，重裝是無奈的選擇，業(yè)務(wù)短時間無法恢復(fù)；

實(shí)際上，以上操作都是“災(zāi)備方案”的步驟和內(nèi)容。一個合理的災(zāi)備方案，必須備份了數(shù)據(jù)和配置信息。
在“重啟、重置、重裝”過程中，通過導(dǎo)入備份數(shù)據(jù)和配置，有利于業(yè)務(wù)的快速恢復(fù)。

3.3 全局關(guān)注（whole picture）

你只是問題處理流程上的一個環(huán)節(jié)或者節(jié)點(diǎn)，從整個流程上去審視本身的作用，做好該做的事，會更好促進(jìn)問題解決！

• 從整個事件流程去觀察一個階段和環(huán)節(jié)；
• 從一個時間范圍去觀察共發(fā)事件的相互影響；
• 從一個周期去觀察時間范圍。

4 - 溝通與協(xié)作

4.1 換位思考

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

4.2 情緒控制

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

一個可行的方法：根據(jù)當(dāng)時的實(shí)際情況，來確定意愿層級 ： 盡心、盡力、盡責(zé)。

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

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

4.3 客戶認(rèn)知

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

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

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

5 - 技術(shù)問題閉環(huán)

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

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

假設(shè)如下幾種場景：

代碼問題

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

配置問題

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

硬件問題

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

測試性問題

• 為什么本應(yīng)該在測試階段就應(yīng)該暴露的問題，結(jié)果卻沒有發(fā)現(xiàn)？
• 是測試流程有缺失、測試用例和方法不合理、測試環(huán)境有缺陷？

特別注意

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

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

6 - 另一種方式

如果你認(rèn)為下面的問題處理方式是對的：

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

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

轉(zhuǎn)載于:https://www.cnblogs.com/anliven/p/9123980.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。