探索未確定的未知問題

2023年5月16日發佈者：Andrew Reedy

每天有數十億用戶使用 Meta 的產品生態系統來進行社交聯繫或業務互動。這數十億用戶也希望我們在產品上連續不斷地加速帶來新功能和改善項目。由於用戶規模龐大，我們每天需要更改成千上萬的程式碼才能滿足以上期望。

不斷發佈如此大量的產品改善項目，可能會導致應用程式狀態倒退，令用戶的體驗變差。在 Meta，我們會採用精密的分層預防工具，以防發佈有缺陷的產品變更。在發佈應用程式之前，我們會使用這類預防工具監察各種產品訊號，偵測有沒有出現狀態倒退的情況。這些訊號反映效能、可靠度（功能和系統）和效率這三方面的狀況，統稱為產品的「PRE」。為防止發佈有缺陷的產品，開發人員第一步會在編寫程式碼時蒐集各種觀測和分析追蹤資料。此外，各種觀測和監察工具會蒐集在正式發佈前的環境中內部使用產品的資料。透過結合人手措施和自動品質保證工具，雙管齊下地在正式發佈前的環境中測試產品。

雖然我們制定了以上的機制以在正式推出程式碼變動前評估有關品質，避免對用戶帶來影響，但一些會影響到用戶的變更仍可能流入正式發佈版本，繼而需要重新修改以便再次推出。而為了降低某個問題影響大量用戶的可能，我們採用多種機制來向公眾逐步發佈變更。

每當達不到用戶預期的功能要求時，我們將這種情況定義為「表現倒退」。我們會以「訊號」一詞來代表用戶反映有些地方不如他們所預期。透過數據分析資料和偵測代碼，我們會儘快有系統地蒐集有關表現倒退的訊號，然後部署修復方案來努力降低對用戶的影響。當我們從自家工具蒐集不到顯著的訊號時，便需要依賴用戶報告來蒐集有關表現倒退的訊號。這類報告從各種機制而來，例如用戶會搖晃手機來報告問題，並且表明在遇到問題時正處於應用程式的什麼位置。

為確保滿足顧客需要，並且儘快實現他們所需（有時甚至在當天內就要達成需求），Meta 大力投資引進多個可靠度計劃和系統，務求出眾地大規模回應顧客需要。

各種訊號可能源自公眾用戶（個人、公司、團體等）或內部用戶。我們會仔細審視內部用戶的訊號，以助預防不受歡迎的變更推出到正式發佈版本。要注意的是，我們的訊號是彙總所得，例如每一百萬用戶遇到的錯誤數量也是訊號之一。訊號也可能源自自動測試工具和情境、開發工具（我們會警告開發人員變更或會導致運行時問題）、系統記錄以及其他來源。我們還會使用不同工具來處理以上訊號，以便迅速找出成因和相應的修復方案。

在發現表現倒退的情況後，我們接下來會迅速找出相關的工程師，以套用並發佈修復方案。根據表現倒退的複雜程度，我們會運用多種方法來準確地找出合適的工程師，當中包括善用 Meta 在機器學習方面的觸覺。鑒於機器學習的運作原理，這是一個持續不斷的過程，我們需要隨著新功能的發佈再次訓練模型，這樣才能跟上不斷的變化。

而這一切並非漫無盡頭，我們從偵查到表現倒退的情況，到緩解有關問題，以至預防及以可持續的方式遏制情況，一步步地取得進展。在這個過程中，我們充分提高了回應能力、投資回報和效率。

在下一節中，我們會進一步探討如何確定真的出現表現倒退的問題，以及在知道此情況後如何回應。

將未知問題轉變為已知問題，然後量化處理

說到未知問題時，我們主要是指用戶或系統遇到的錯誤。我們可能會首先透過許多不同的來源得知可能出現的錯誤。

測試我們各個應用程式及當中特定產品是否正常運行的綜合測試。
正在測試以找出錯誤的內部用戶，這包括我們的專屬測試團隊，或 Meta 廣大的用戶群。
在應用程式中遇到問題後透過問題報告對話框回報問題的外部用戶。

在有人實際提出這類錯誤，表示有用戶遇到有關事件之前，這些錯誤都是未知問題。當這類錯誤報告的數量達到一定門檻時，我們便確定此為實際問題，反映真的出現了表現倒退的問題，也就是程式碼變更帶來了新的錯誤，而我們必須迅速舒緩有關影響。報告主要分為兩大類型：

「已確定的未知問題」：即偵測代碼探測到表現倒退問題並加以報告；我們有眾多工具可以幫助產生此訊號
「未確定的未知問題」：即內部人員找不到表現倒退問題，而我們需要依靠用戶報告表現倒退的情況

此外，表現倒退還涉及多種類別，例如表現倒退的範疇到底是程式碼錯誤、比較類似垃圾訊息的情況，還是其他違反內容政策的狀態。我們的重點在於第一個範疇，希望解決當中與程式碼相關的用戶體驗問題。面對用戶成千上萬的問題報告，又可以如何做到這一點？

產生訊號和分析資料

為管理大量報告，我們會產生特定訊號來助自己標記問題。第一種訊號在配合經過適當調整的門檻之下，可以告知我們確實發生了事件或表現倒退問題。要注意的是，視乎表現倒退的類型，發生的事件可能多於一件。舉例來說，表現倒退的問題可能由於基底程式碼共通，而影響到多種產品。我們需要找出這種共通之處，並將涉及的不同事件都視作同一事件來解決，以便按最佳的方式調整資源。下圖正是一個例子，展示我們可以如何視覺化地看出偏離趨勢線的情況，反映出表現倒退的問題。

然後，我們需要蒐集更多訊號，其中某些訊號將點出我們可能遇到的表現倒退類型。這些訊號由專為特定 Meta 產品而調整的機器學習演算法所產生，有助我們洞察與表現倒退情況相關的徵兆。有關演算法會分析各項用戶報告，以確定造成表現倒退的成因，進而判斷哪隊工程團隊可以部署程式碼修復方案或其他措施，最有效地解決問題。

此外，我們還會根據蒐集的記錄資料產生其他訊號。這些診斷記錄可以是用戶端或伺服器端的記錄，當中蒐集的內容均是經過用戶同意，而且是出於幫助找出問題成因之目的來蒐集。應用程式當中會加入適當的徵求用戶同意流程，以判斷能否根據用戶的授權蒐集此類資料。我們還會顧及有關資料的保留時間，以符合適用的法規要求。

透過綜合不同的訊號，我們得以整理表現倒退的問題，並將其分配給適合的產品團隊處理，以便迅速緩解問題影響，使用戶體驗回到預期水平。

而彙總的結果當中也能歸納出分析資料。我們會審視資料，務求找出共同的根本原因，並且判斷是否需要作出變更，以防止再次發生表現倒退的問題。這樣是找出穩健的方法來解決用戶體驗問題的關鍵所在，有助在日後儘可能縮小表現倒退問題的影響面。

我們的流動應用程式不僅加入了支援用戶報告問題的導覽路徑，還提供功能來讓用戶透過搖晃裝置表示出現問題。這樣一來，我們便可以蒐集具體情境的遙測數據。而應用程式發出的黑盒訊號還可進一步令遙測數據更為充實。這個黑盒與飛行記錄器相似，會自動捕捉某些記錄來反映報告錯誤當下應用程式出現什麼情況，以便我們更妥善地診斷問題；而有關記錄蒐集也會經過用戶同意。

此類遙測數據會融入一組時間軸檢視畫面當中，以幫助工程團隊判斷問題成因。考慮到我們各應用程式的發佈節奏之快，再加上伺服器端應用程式元件不斷變更，如果沒有這項功能，我們便很難找出問題所在。隨著時間的推移，這類遙測數據有助我們偵測表現倒退的模式，防止未來發生有關問題。

擴大範圍至較小的產品影響面

在改進提高訊號精準度的功能後，我們得以進一步應對表現倒退的影響面，其中部分影響面是我們以前所無法偵測。影響面是指產品中的特定項目，例如動態消息或 Reels。這是一個挑戰，畢竟產品不僅包含許多精細的功能，還會定期引進新功能。因此，表現倒退的影響面不只是大，還會隨時間逐漸擴大。我們必須不斷視情況調整防禦和進攻策略。