前言

• 在有效率的開發高品質的軟體，並以低風險方式佈署和發布後，我們要開始觀測交付到用戶手中的軟體或應用程式的使用情形。
• 了解用戶的使用偏好和軟體執行的狀況，並以蒐集到的量化數據做為回饋，確保我們可以持續開發並改進軟體，為使用者繼續服務。
• 從用戶需求開始進行軟體開發，到低風險佈署/軟體發布，接著監控營運狀況並蒐集數據，我們完成了軟體開發流程的封閉環－讓我們驗證開發的功能是否有達到預期的目標。

13.1 生產監測範圍

為了了解用戶與軟體之間的互動，企業會根據相關的數據做為研發與改善的指標。

一個軟體對用戶的服務橫跨我們管理的後台伺服器和用戶裝置上，因此這兩個裝置上的服務和運行狀態都需要監測。

13.1.1 後臺服務的監測

• 基礎監測：針對系統基礎設施，包括網路與伺服器節點的監測。內容包含網路連線狀態、流量、CPU負載、內部和外部儲存空間等使用狀況。
• 應用監測：針對應用程式的運行健康，如流程是否存在、是否有正常提供服務、是否有缺陷、是否有正常的與伺服器連線、是否出現time out、是否友直回例外或警告、是否能應付突增的服務請求量等。
• 業務監測：針對業務指標，如用戶造訪量、功能使用需求等。

13.1.2 用戶裝置上的監測

監測用戶裝置上的軟體運作狀態和設備運行狀態需要取得使用者授權，並將蒐集的數據定期發送到後台伺服器上來分析。在離線狀態下，程式得先在本地端暫存數據，待連線後再一併上傳。

監測的項目與在後台的一樣：

• 基礎監測：針對用戶設備的硬體環境，以及與伺服器的連線狀態。
• 應用監測：同後台監測的內容。
• 服務監測：本地端的服務功能使用情形。

最後，也要根據市場評價來修正軟體服務的缺失，提供更優質的體驗。

13.2 數據監控體系

對監測數據的獲取過程、處理流程全面管理，包括數據來源、數據格式、採集週期、數據處理方法等。

13.2.1 收集與處理

每個步驟的職責如下：

1. 採集上傳：在本地端蒐集事先定義的事件數據並上傳。
2. 數據整理：過濾整理上傳數據。
3. 實時分析：分析當前數據。
4. 離線分析：對大量數據進行規則提取或模型化。
5. 結果輸出：呈現實時和離線分析結果，供決策參考。
6. 問題決策：根據輸出結果，透過人為或自動方式判定情況，並儲存判定結果，以利日後參考。
7. 數據儲存：保存離線狀態的原始和分析後數據。
8. 自動修復與執行系統之間的管道。修復指令需要被傳給執行系統，並由它將指令分配到對應的節點，進行相關操作。

13.2.2 數據標準化

要得到監測的數據，我們得先規劃軟體內如何觸動「事件」，並持續追蹤。持續交付價值環中強調的「探索」和「驗證」依靠用戶回饋來執行。為了提升驗證的即時性，在開發一個功能前，除了訂定功能開發目標外，還需要：

1. 定義功能指標，以及如何處理功能指標－如何以指標量化該功能，且找出使否有與其他功能指標有關連；以及
2. 數據事件的定義－要在程式碼內合適的位置安插監聽事件，定義輸入與輸出的格式，並確認數據是否與其他事件有關係。

若在開發實沒有定義數據指標的體系，當遇到產品開發瓶頸時，就無法察覺用戶行為。指標包括：

• 偏好關注基礎事件和應用事件的數據分析，而忽略了業務方面的數據。
• 在沒有重視業務數據監測的情況下，當打算蒐集數據時，得額外花費時間取得資料。

因此，在高度不確定的功能環境開發下，業務數據蒐集的重要性遠高於功能實現的重要性。

為了利於統計分析，一開始就必須先定義數據日誌格式與蒐集規範。訂定標準可以使數據蒐集和處理更方便，減少無用的數據或錯誤的分類，進而提升分析處理的效率和準確性。

數據紀錄的紀錄內容包含基礎訊息和擴展訊息。前者描述基本的應用情況，即 Who（哪一個用戶或服務）、When（何時發生）、Where（哪裡發生）、和 What（做了什麼）。擴展訊息是為了讓數據有更好的擴展性，以應對不同監測統計需求。

13.2.3 監測數據系統和能力衡量

監測用數據的可靠度可以用三個面向來衡量：

1. 正確性：即收集到的數據與事實的一致性；
2. 全面性：即收集到的數據是否足以用來下達決策；
3. 及時性：即從數據產生到下達決策所需處理時間夠短。

團隊運作初期較常遇到數據結果與實際情況不符的情況，需要花比較多的時間。可以以下列兩種方式來驗確證數據品質：

1. 可在運作初期尋找專家經驗來建立數據系統。
2. 可使用來自系統外部（不同團隊）或內部（不同面相）的數據相互印證。

及時性是「敏捷」的重點。在更新某些功能後，都希望能儘早知道它對業務相關數據的影響。除了以上三個基本行量為度以外，監測系統還應具備抽象能力，即根據實際數據量的需要，工程師可以即時配置每種數據採樣的密度。

13.3 問題處理體系

判別問題的方式有兩種：人工判別或是機器自動判別。面對大量的數據，不可能全依靠人工處理。通常先由電腦根據各種規則判斷，盡可能找出疑似的問題。無法自動處理時，就發布警告給指定的工程師。

13.3.1 海量的警告與智能化管理

面對大量的警告訊息，會希望減少警告，但另一方面又擔心出了是沒有警告，只好再加入更多的警報。事實上，大部分的警告訊息會被忽略，主要是因為：

1. 自己不是該警告的負責人，
2. 這只是一個預警，不用馬上處理。

警告當然有它們的正確性和真實性，但同時也要提高這些訊息的另外兩個面向：即時性和可操作性。針對後者，處理者應該可以對警告做出有用的操作，否則該訊息應被當成垃圾訊息屏蔽，避免降低工作效率；一但真正的警告被海量的垃圾訊息淹沒，就很容易釀成災難。這個問題可以靠四個方面來減緩：

1. 讓監控點離問題發生地更近。
2. 透過動態閥值設定合理的警告。
3. 定期回顧警告配置，並清理多餘的警告。
4. 用AI動態解除警告。

這些方法可以將警告數量控制在一定的範圍內，但無法完全消除。常見的警告可能已有對應的方法；真正要花時間的是那些以往沒有出現過的異常警告，因為它們很可能是「生產問題」。

13.3.2 問題處理是一個學習過程

問題處理是一個複雜的團隊活動。可提高效率的做法：

• 儘可能將人工步驟自動化
• 建立工單系統
• 回顧處理流程

13.4 生產環境測試

• 生產環境是獨一無二，我們永遠無法1保證發現生產環境中可能出現的所有問題。
• 隨著軟體快速發佈訴求的提升，非生產環境的測試場景越來越顯得不充分。
• 如何在不影響生產的前提下，在生產環境中進行測試？

13.4.1 測試活動扁平化趨勢

• 傳統的混布式軟體開發方法中，測試執行和決策活動通常集中在軟體研發周期的中部。
• 隨著現代軟體交付頻率的不斷加快，這種情況出現了變化。很多團隊的測試活動開始向左右兩側移動，如圖13-7所示。
• 測試左移(測試前移)，是指測試人員更早且積極地參與到軟體專案前期各階段活動中，在開發功能之前就定義相關的測試案例。
• 測試執行任務也在向左移動，表現為 : 在越來越多的軟體團隊中，測試角色開始擁抱「增量測試」，即在軟體整合測試之前，就開始針對單個已開發完成的功能集進行品質驗證，提前發現品質風險。儘管這種「增量測試」無法發現全部品質問題，但可以減少整合測試階段的時間壓力，如圖13-8所示

測試左右移動

• 「測試右移」是指將一部份品質驗證工作放在軟體發布之後，也就是讓子彈飛一回兒。
• 主要因為網際網路軟體產品的測試，與原先企業內部應用的軟體測試有顯著不同，即無法窮舉性。
• 企業內部軟體的使用者有限，環境相對可控, 但網際網路產品的情況有所不同，每個人的電腦或手機上都安裝著不同的軟體，硬體與作業系統也有很多種組合，因此無法以窮舉方式進行所有相關場景測試。因此大家也越來越依賴於生產環境上的品質驗證
• 測試右移現象多見於軟體產品中的示範性功能(software for show)，即軟體功能更多地傾向於內容展示，例如搜尋軟體、拍照軟體、商品展示。即便這類功能出現一些問題，但只要即時發現即時修復，就不會對用戶造成本質性損失或嚴重影嚮。
• 對事務性軟體(software for transaction)以及問題修復成本較高的軟體(firmware)來說，一但生產環境出現問題，會帶來比較大的損失。因此軟體團隊不會冒險將功能驗證的活動右移，而是有強列的動機將測試活動盡可能左移，同時加強右測的監測能力。

13.4.2 生產環境中的測試

• QA部份應將生產環境中的測試列入日常工作中，稱為「生產巡檢」。
• 對生產環境中的後台服務進行定期功能驗證，以確保該後台服務備舊對外正常提供服務，且處理的結果是正確的。
• 通常的做法是：建立一個覆蓋應用程式主要功能的日常健康檢查清單，對生產環境進行例行測試和檢查軟體服務的品質。這種測試方法與監測不同，它們是由軟體團隊自行安排的品質驗證工作，並且定期執行，因為這是一些例行驗證，所以應該被自動化執行．。這類測試中最典型的就是介面測試。
• 很多團隊開始將一些自動化介面測試的案例放在生產環境鞏，周期性執行，以代替手動檢查。
• 這類生產環境上的品質保障工作應遵循以下原則
  1. 建立自用的測試資料，確保不污染真實用戶的資料
  2. 使用的測試資料盡可能真實
  3. 不要隨便修改真實用戶的資料
  4. 建立測試專用的用戶存取憑證，登錄生產環境

13.4.3 混沌工程

• 混沌工程(chaos engineering)是指在生產環境中注入「問題」，進而發現生產環境系統性弱點，並進行系統性改進的方法或手段。
• 其目標是不斷提升生產環境面對任可變更的可靠性。這與疫苗注射類似，向系統注入一些小劑量的「病毒」使身體康立對它的抵抗力，進而使身體獲得免疫性。
• 此部份最有名的例子為Netfilx的Simon Army 
• Netflix在AWS上，開發了一系列生產環境測試工具，稱為Simon Army，用於模擬AWS如區(zone)或大區(region)出現問題，以及模擬人為製造呼叫延遲，用來模擬服務降級，看依賴這些服務的模組是否能正確做出反應。
• 這種問題注入(Failing Injection)式的主動檢測，可使軟體工程師在架構設計上就需考慮一些常見的失敗問題。

13.5 向東，還是向西

• 快速驗證環中，我們將精練後的試驗方案變為可執行的軟體，部署到生產環境，並且收集了執行結果和用戶回饋。現在是要決定下一步「向東，還是向西」以完成第一個業務閉迴圈
• 透過分析總結，可幫助我們從收集到的數據中來判定前進目標
• 若收集的結果不合預期，只要與團隊共同分析，看是針對現行方案進行微調，還是從備案中選擇新的試驗方案，繼續驅動這個快速驗證環

13.6 小結

生產環境的監測範圍包含三個層次 :

1. 基礎監測
2. 應用監測
3. 業務監測

每個層次的特點，監測資料的採集方式有所不同，但其處理流程基本一致，包括: 資料收集、上報、整理、分析、展現與決策這幾個環節

而對監測系統能力的衡量有3個維度 :

1. 資料的準確性
2. 全面性
3. 即時性

• 告警處理是研發人員和維運人員的常規工作，但告警過多反而會造成工作中的困擾，降底工作產出。因此我們應該不斷對告警點的設置及臨異值計算方式進行最佳化，進而盡可能提升有效告警率。一但告警成立，就需要啟動問題處理流程。這個流程的最後兩個環節 「根因分析」和「根源解決」是學習型組織的重要特徵
• 隨著發佈頻率的提高，測試場景的複雜性提高，越來越多團隊開始找尋方法在生產環境上進行軟體測試，這被稱為測試活動右移。這種只適用於軟體出錯後的成本和影嚮相對較少。而那些較交易性軟體或回收成本較高的軟體來說，測試左移的趨勢也較明顯。

測試右移主要有兩種類型 :

1. 將測試案例在生產環境上自動執行
2. 混沌工程(Chaos engineering)

• Netfilx開發了一系列破壞性測試工具(Simian Army)可以促使工程師在軟體設計與開發之時，就提前考慮各種失敗的可能性，這被稱為「為失敗而設計」進而提高生產環境的軟體服務穩定性，為用戶提供更好的服務體驗。
• 當收集到真實的資料回饋，就可印證在價值探索環中所提出的假設或目標，並透過主動關聯分析，最終確定是繼續進行更多的試驗，還是重新再選擇一條新的路