想像一下:您和您的團隊日以繼夜地工作,以完成軟體產品的下一個主要版本。您正以不錯的速度建立新功能。一旦 QA 報告了錯誤,團隊就會對其進行偵錯。單元測試都是綠色的。在應用程式透過更全面的測試套件獲得批准後,即是發佈它的時候了。然後——發展壯大! 一旦它進入生產環境,應用程式就會崩潰。什麼地方出問題了呢?

事實證明,測試環境並沒有您想像的那麼接近生產環境。在沒有任何記錄的情況下對環境進行了基礎設施變更。結果便是,環境慢慢開始偏離。

作為技術產業的專業人士,我們有相當一部分時間花排除缺陷在上。是的,我們還要花時間對其進行修正——但是當您不知道問題出在哪時,您便無法進行修正。任何曾在偵錯工具面前花費過數小時的軟體開發人員都會告訴您,通常情況下,真正的難點在於找到錯誤。一旦您知道了問題所在,對其進行修正甚至可能毫不費力。

因此,學習更快地進行疑難排解是您作為軟體開發人員或 IT 工作者可以做出的最佳投資之一。

讓我們談談如何快速發現問題並更快地修正它們。

根本原因分析:它是什麼以及為什麼您應該關注?

根本原因分析 (RCA) 是一種可用於疑難排解問題的特定技術。使用此技術,您可以使用一組特定的步驟來分析手頭的問題,進而確定問題的主要原因。RCA 基於這樣一個原則,即只關注問題的症狀而忽略其根源毫無用處。

透過運用 RCA,您將能夠了解發生了什麼。通常,您無法僅透過觀察症狀來獲得完整的圖片。但確定發生了什麼只是第一步 — 接著您需要繼續深入並揭示發生的原因。有了這些知識,現在是時候付諸實踐了,即制定計劃或策略以降低問題再次發生的可能性。

涵蓋了「什麼」和「為什麼」,這裡有四個技巧可以幫助使用 RCA 減少問題。

使用橡皮鴨法
是的,我是認真的,就是橡皮鴨方法。這不是我編的。該方法也稱為橡皮鴨偵錯法,當然還有一些其他名字。它包括向橡皮鴨解釋您的問題。沒有橡皮鴨? 別擔心! 您可以使用手邊的任何無生命物體。或者,您甚至可以和一個人交談!

那麼,到底什麼是橡皮鴨方法? 這種方法基於觀察到的效果,即透過向某人解釋某事,您會強迫自己整理腦海中的想法。我們的思維過程通常是雜亂無章的。當我們不得不向他人解釋這些問題時,除了命令他們,我們別無選擇。熱門問答網站 Stack Overflow 的聯合創始人 Jeff Atwood 談到,有好多次團體開發人員告訴他,要向網站寫一個新問題,在此過程中,需要自己找出答案,但從未真正提交過問題!

橡皮鴨方法是否足以解決任何問題? 當然不能。可能是這樣,但通常這只是更廣泛策略的第一步。

您是否擔心人們會認為您與無生命的物體交談有點奇怪? 好吧,問題是,整個橡皮鴨的想法聽起來就蠻好笑的。這是一個愚蠢而令人難忘的形象,不用太過較真。重要的是,您要強迫自己有條不紊地表達腦海中的想法,盡可能清楚地解釋手頭的問題。

您可以使用以下方法:
1.寫一個 Stack Overflow 問題。或者,您可以假裝您正在編寫 Stack Overflow 問題,但將其寫在記事本中。
2.提交詳細的偵錯報告。無論如何,總有人得去做這件事,那麼為什麼不一石二鳥呢?
3.前往您同事的隔間/辦公室,與他們交談幾分鐘。當然,前提是他們對此並不介意。不要不必要地打擾你的同事。


收集大量日誌資料 (並高效進行搜尋)

如果您已成功地以明顯的方式解釋了問題,但仍然無法解決根本問題,那麼您必須繼續下去。現在需要的是收集有關問題的資料並從中擷取洞察。

此時,日誌記錄和監控便可派上用場——損毀日誌、應用程式和伺服器日誌等等。您必須收集問題發生的證據,但如果可能,還要找出問題發生的時間和頻率。

不過,您不能就此止步。收集大量資料很重要,但如果您不能足夠快地找到所需的特定位,那麼所有這些資料就可能沒有多大用處。陷入「大海撈針」的境地既不有趣也無成效。

這就是為什麼您必須使用能讓您即時搜尋和分析您收集的所有日誌資料並將其轉化為可用於更快診斷和解決問題的寶貴洞察的工具。


運用五個為什麼技術
收集資訊後,就該是識別因果因素,進而予以使用了。這裡的「因果因素」是指目前問題的直接原因。您不得再確定一個因果因素後就立馬停止。你必須繼續探究。其中最著名的技術就是「五個為什麼」技術。

該技術包括反覆提問「為什麼?」,直到找到問題的根源。讓我們看一個簡單的範例:

問題:網站顯示 error 500。
1.為什麼? 因為 Web 架構的路由元件出現故障。
2.為什麼? 因為它需要另一個元件,該元件本身出現故障。
3.為什麼? 因為 Web 架構的這個元件需要 intl 擴展,但這不起作用。
4.為什麼? 因為它在伺服器軟體更新後被意外停用。

如您所見,數字 5 只是舉例說明而已。可以用更少的步驟解決根本問題。或者您可能會需要更多的問題。

五個為什麼技術遠非完美。它受到了應有的批評,當然也有其局限性。但它有助於鼓勵工程師繼續搜尋問題的根本原因,而不是在接近解決方案的第一個跡象時就停止。


獲得第二雙眼睛
在我的軟體開發人員職業生涯中,我最開始欣賞的一種做法是程式碼檢閱。讓另一個無任何偏見的人檢閱您的程式碼的可以揭示許多您以前無法發現的問題,這一簡單事實簡直令人驚訝。隨著時間的推移,純粹只是讓其他人檢閱您的程式碼這一期望,會讓您更加意識到這一點。您開始投入更多的注意力。

那麼,就這點而言,我是否推薦程式碼檢閱? 嗯,是的,但這不是您獲得第二雙眼睛的唯一方法。我建議您對工程師所做的幾乎每項任務都採用類似檢閱的流程。或者更好的方法是,配對。進行結對程式語言設計、配對伺服器組態、對等偵錯和對等面向客戶的支援。簡而言之:對問題進行疑難排解。

科學還是藝術?

缺陷疑難排解處於藝術而非科學的階段。但這不應該阻止您運用技術和工具來提高效率

因此,請使用這些技術進行 RCA:
1.使用橡皮鴨法
2.收集大量日誌資料並使用適當的工具對其進行搜尋和分析
3.運用五個為什麼技術
4.獲得第二雙眼睛

是時候抓住您的橡皮鴨並開始分析問題的根本原因了。

進一步了解 Amazon OpenSearch Service 定價

瀏覽定價頁面
準備好開始建置?
Amazon OpenSearch Service 入門
還有其他問題嗎?
聯絡我們