容量、可靠性與營運要求

容量、可靠性與營運要求分別確立產品必須支援的需求量、必須維持的成果，以及維持運作所需的工作。本文說明如何透過結構化討論，結合產品意圖、穩定使用案例、組織義務、營運證據與系統可靠性工程（Site Reliability Engineering，SRE）原則，形成適合產品的要求。參與者須決定哪些失效會造成重要影響、何時需要介入、可接受多少中斷，以及哪些重複工作應透過工程手段消除，並將這些判斷連同理由、適用條件與決策權限保存在知識系統中。

這些產品常設要求為架構、功能規格與技術規格提供依據，讓已核准的判斷逐步落實為實作與驗證。產品負責人（Product Owner）或產品經理（Product Manager）核准業務承諾及可接受的後果；架構師、開發負責人或具明確責任歸屬的工程團隊確立支援這些承諾的技術要求與設計。系統可靠性工程師（SRE）及其他專家提供分析與專業建議。每次討論都必須檢查所作的決策是否符合其依據的要求。

要求是否已足夠明確，取決於具備相應專業能力的參與者能否根據紀錄評估方案是否符合義務、辨認驗收所需的證據，以及理解哪些決策仍由工程團隊處理。不熟悉產品的參與者測試用來檢查知識系統能否支持這種獨立判斷。本文說明所需的準備活動、決策紀錄、各環境的觀測要求與驗證方式，讓產品判斷得以落實至工程師或 AI 程式開發代理撰寫的程式碼。

返回頁頂

1. 產品示例的背景

本文以同一個線上購物平台貫穿各節。顧客瀏覽商品、管理購物車並下單；行銷團隊則執行活動，使用由供應商銷售資料產生的每日報表分配支出。容量示例假設每小時有 10,000 位完成購買的顧客，每人下單一次，平均訂單金額為 $50。適用的組織政策要求產品部署於雲端。產品團隊必須決定要支援多少需求量、何種資料差異會使報表無法使用，以及哪些購買流程中斷可以接受。

後續示例都圍繞這個產品展開：供應商資料檢查可以自動套用已知的行銷活動條件，減少重複調查；結帳流程的韌性要求則可能促成同時使用 AWS 與 Azure 的架構方向，並進一步確立中斷時的功能行為，以及部署、路由、狀態、復原與監測埋點的技術細節。文中的數字及設計選擇用來呈現此產品的判斷；工程框架所要求的是形成後續參與者能夠運用及驗證的要求。

返回頁頂

2. 透過結構化討論形成產品要求

返回頁頂

2.1. 輸入、詮釋與決策權限

要求的形成從產品情境出發。產品意圖說明產品所服務的目的；穩定使用案例指出使用者反覆進行的活動與預期成果。適用政策提供義務，例如允許的部署環境或資料複寫限制。既有要求、架構知識、事件紀錄、工作負載預測與營運做法，則揭示已經影響產品的承諾及假設。SRE 原則引導參與者檢視可接受風險、服務目標、監控、容量與重複營運工作。

參與者透過結構化討論一併解讀這些輸入。對每項關切事項，都要確認受影響的使用案例、相關運作條件、失效後果、所需回應，以及有權作出決定的人。輸入之間的衝突必須形成明確決策：行銷活動預測可能提高容量需求，成本限制卻壓縮了備援空間；資料處理政策也可能限制架構師提出的復原位置。參與者須確立兩項條件如何同時適用於產品，並記錄經授權的取捨。

在選定設計之前，先釐清與架構品質有關的需求，才能建立評估各方案的具體條件。團隊可以透過訪談、情境分析、事件回顧或引導式工作坊完成這項工作。品質屬性工作坊（Quality Attribute Workshops，QAWs）是其中一種已有文獻記載的方法：利害關係人檢視業務與技術脈絡，提出情境、排列優先次序，再按觸發來源、觸發事件、環境、受影響的系統部分、回應及回應衡量方式，細化選定的情境。¹ 這樣便能交代在什麼條件下發生何種失效，以及系統必須提供什麼可衡量的回應。規格優先交付接納任何能為後續工作產生足夠明確、已核准判斷的需求釐清方法；QAW 是細化情境時可選用的參考。形成的產品承諾還須指出決策負責人，以及後續參與者應使用的權威紀錄。

容量與可靠性都涉及業務和技術決策。以下比較說明各類決策的權限與產出。

系統可靠性工程師、安全工程師、資料專家與品質專業人員提供失效分析、可行性證據、量測設計及營運經驗，以改善決策；業務承諾仍由產品負責人或產品經理決定，既有的安全與政策核准權限也繼續適用。工程團隊可以透過共識確立技術要求，但須明確指定由誰記錄及維護結果。若可行設計會改變已接受的業務後果，就必須交回產品決策負責人重新討論。

返回頁頂

2.2. 足以支持下一層決策的明確程度

當要求的適用條件、預期成果、評估準則及偏差處理足以支持下一個依賴它的決策時，要求便已足夠明確。紀錄須把所需成果寫得足以評估候選機制，而具體機制則由適當的技術決策人員選擇。

以購物平台為例，若要求在預算決策前，暫停使用含有無法解釋之供應商資料差異的行銷報表，就已指出受影響的活動及預期行為。要完成這項要求，還須確立比較母體、介入準則、決策期限、允許的替代處理方式，以及放行權限。這些細節決定設計必須達成什麼；至於遙測後端、通知 API 或驗證程式庫的選擇，則可在架構或技術規格工作中處理。

準備活動須產生經核准的紀錄，包含適用的使用案例與條件、所需成果、量測或審查方法、偏差處理、決策負責人、理由及重審觸發條件。數值目標須附上適用母體及評估期間；仍需專業判斷的事項，則須說明所需證據及判斷權限。持續適用的義務納入產品的常設要求。

這個流程說明產品常設要求如何進入後續交付：組織義務先形成產品判斷，再轉化為架構安排、明確的功能行為、可執行的技術工作及程式碼。規格逐步加入細節，同時保留適用要求與決策來源。團隊可以一併細化相關規格；圖中的次序表達的是義務如何透過交付工作產物逐層落實。

交由 AI 程式開發代理處理的工作，其技術規格與所連結的脈絡必須讓代理找到所有適用要求。每項重大義務都能對應到實作責任及行為驗證方式，才表示要求已完整傳遞。代理可以完成獲授權的全部程式碼變更，再由負責人審查符合程度與驗收證據；要求是否落實至實作，則由可追溯的關係及驗證結果判定。

要求仍在形成時，不熟悉產品的參與者測試就可以揭示遺漏。若參與者無法判斷某項行銷活動是否足以解釋警報，就表示缺少產品脈絡或仍有判斷尚未解決。負責人補充資訊或作出決定後，須重做受影響部分的測試。測試提供知識能否使用的證據，核准權限則仍由負責的人員行使。

返回頁頂

3. 將 SRE 原則轉化為產品判斷

返回頁頂

3.1. 將減少營運瑣務納入要求

營運要求須考慮設計會產生多少人工作業。Google 的 SRE 著作以 toil 描述具備重複、手動、可自動處理、缺乏長期價值，並隨服務規模增長等特徵的生產環境工作，本文稱為營運瑣務。透過工程工作消除一項反覆出現的營運任務，能帶來持續改善。因此，重複介入本身也屬於系統設計的考量，並會影響團隊還有多少工程時間可用來改善可靠性。²

購物平台的團隊運用這項原則，檢視營運過程會反覆出現哪些任務。供應商資料管道可能需要每天核對總數、尋找行銷活動日程、排除預期內的警報，以及重新執行相同的比較；結帳服務則可能需要逐次人工確認兩個雲端的部署，或反覆準備備援環境。結構化討論須釐清哪些決策需要人員判斷、哪些檢查可以自動完成，以及缺少什麼脈絡會使同一項調查不斷重來。

形成的營運要求應直接寫出預期行為。例如，報表資料管道可以要求例行匯入自動依照已核准的比較規則驗證，自動套用已識別的行銷活動條件，並將未能解釋的差異連同判斷所需證據交給指定審查人員。這項要求會影響設計：驗證流程必須能取得持續維護的活動脈絡，也必須保留判斷證據。紀錄須指出要自動執行哪些重複檢查、保留什麼證據，讓減少瑣務的原則成為可用的設計依據。

工程團隊記錄預期的人工工作量、其成因，以及工作量如何隨負載改變。涉及人員配置、回應涵蓋範圍、成本或產品承諾的取捨，由產品負責人或產品經理核准。當工作確實需要專業判斷，而且相關成本已獲接受時，保留人工例外處理仍可能合適；可預測、反覆執行的檢查則可列為工程改善對象。把兩種情況都記錄下來，團隊便能在需求量增長時重新檢視原先同意承擔的營運工作量。

返回頁頂

3.2. 服務目標、風險與回應

可靠性目標反映產品取捨。對購物平台而言，討論從購買中斷、商品瀏覽不可用、訂單確認延遲或庫存資料過時所造成的影響開始；不同活動可能需要不同要求。SRE 對風險的討論，將可靠性水準的選擇與使用者期望、業務後果、工程成本及開發新功能的機會連接起來，並讓產品負責人參與目標決策。³

服務水準指標（service-level indicator，SLI）衡量服務行為的某個面向；服務水準目標（service-level objective，SLO）則為該指標設定目標值。衡量方式與評估期間共同賦予可用性陳述具體意義。SRE 指引強調選擇能反映使用者實際服務體驗的指標。⁴ 例如，結帳成功率目標須定義適用的請求母體、成功條件、相依服務失效的處理，以及量測位置，才能判斷顧客是否完成購買，並涵蓋決定該成果的相依服務。

錯誤預算（error budget）表示 SLO 允許的失效額度。要讓它支持營運決策，團隊須同意當預算持續消耗或耗盡時應採取什麼行動。SLO 實施指引將目標與利害關係人的共識、技術可行性、責任歸屬及持續審查連接起來，並說明如何以錯誤預算政策引導決策。⁵

對購物平台而言，一項候選政策可以規定：結帳服務的錯誤預算耗盡後，暫停可延後的結帳服務部署，允許復原所需的變更，並在恢復一般部署前，由產品與工程負責人共同審查。討論須確立誰有權認定例外，以及哪些證據足以恢復部署。核准後，這些判斷納入產品常設要求，技術規格再定義執行政策所需的量測與發佈控制。

返回頁頂

3.3. 支持行動的觀測與告警

觀測須支持明確的營運決策。產品團隊先確立什麼使用者後果值得中斷人員當前的工作、誰能採取行動，以及行動所需的證據；監控再提供從外部觀察的服務行為與內部診斷量測。Google 的監控指引闡述了這項關係，並強調警報須容易理解、能引導行動，而且雜訊低。⁶ 結帳警報應讓回應人員注意到購買成果正受到什麼威脅，並提供足夠脈絡供其調查或復原。

告警設計也涉及可衡量的取捨。《The Site Reliability Workbook》從精確率、召回率、偵測時間及警報重設時間評估 SLO 告警，並發展以錯誤預算消耗速率為依據的方法。⁷ 這些方法適用於已定義成功與失敗事件的 SLO。若要從資料量的日對日變化推導出 SLO 消耗速率告警，必須先說明該變化與已定義的資料品質失效有何關係。後文的資料品質示例從資料是否適合支持業務決策出發，再推導介入規則。

返回頁頂

3.4. 開發與生產環境的遙測及日誌輸出

遙測輸出是應用程式或基礎設施元件產生指標、追蹤紀錄（trace）及事件等訊號的行為；日誌輸出則記錄個別事件，提供足以還原事件經過的脈絡。這些訊號讓要求中的行為可以被觀察。儀表板與警報所能使用的證據，取決於系統實際輸出了什麼，以及觀測途徑保留了什麼，因此要求必須交代開發與生產環境預期的訊號涵蓋範圍及詳細程度。

技術決策負責人在 SRE 及工程專家的支持下，確立哪些活動須輸出訊號、輸出頻率或事件涵蓋範圍、必要欄位、取樣規則，以及允許的診斷細節。他們也須定義訊號必須在多長時間內可供使用、保留多久、誰能存取，以及收集失敗時如何處理。影響業務介入或已同意承擔的營運工作量的要求，由產品負責人確認；輸出內容則受適用的安全與隱私政策約束。各項量化限制須能支持產品的偵測、調查與容量需求。

以下以購物平台為例，呈現按環境區分的已核准輸出約定。兩個環境沿用相同的事件語義與關聯欄位，允許的診斷細節及收集設定則有所不同。

實作依賴輸出約定之前，須先確定會影響可行性的設定。例如，量測間隔過長，可能掩蓋對已核准可用性目標具有重要影響的中斷。成功操作的診斷追蹤紀錄可以取樣，以控制資料量，同時保留完整的 SLI 量測；但若結帳結果的唯一證據來源也被取樣，就無法充分支持該目標。日誌等級交代診斷詳細程度，要求紀錄則指出哪些事件的證據必須保留。

架構討論須確立在已核准失效情境下，必要訊號如何維持可用。功能規格描述可觀察的事件，例如報表暫停放行或復原狀態轉換；技術規格則定義監測埋點、欄位結構、訊號匯出元件、嚴重程度對應、取樣設定、保留方式及輸出約定的測試。測試也須涵蓋匯出元件失效、敏感內容遮蔽及負載下的額外資源消耗。收集元件失效時的處理，須符合已核准的產品行為，包括保留放行紀錄等義務，而且失效造成的影響必須可被觀察。

返回頁頂

4. 供應商資料品質與產品介入

返回頁頂

4.1. 從既有門檻形成已核准規則

假設購物平台的供應商資料管道已設有一條警報規則：今天載入的銷售紀錄總數與昨天相差 10% 時觸發警報。這是開發人員在產品團隊確立報表要求之前選定的規則。行銷活動可能造成大幅變化，而幅度較小但無法解釋的差異也可能影響支出決策。因此，結構化討論須在資料用於每日報表之前，確立哪些條件需要介入。

資料品質取決於資料的用途。Wang 與 Strong 的研究從資料使用者蒐集品質屬性，建立涵蓋內在品質、表達方式、可存取程度及使用脈絡的框架，其中與使用脈絡有關的品質面向，將品質與資料所支持的任務連接起來。⁸ 對這條資料管道而言，討論須先確立資料使用者要作什麼決策及其期限，再選擇門檻。

產品負責人或產品經理在相關業務及資料專家的支持下，須解決下列問題：

1. 哪項業務決策會使用這些資料？採用錯誤或不完整總數會造成什麼後果？

2. 什麼母體、時區、業務日期及完整性條件，讓兩個總數可以比較？

3. 哪些行銷活動或供應商條件能解釋預期變化？誰負責維護這些脈絡？

4. 哪些無法解釋的偏差需要審查、延後發佈、附有使用限制說明的報表，或其他已核准回應？

5. 誰能授權使用資料？若到決策期限仍未解決問題，應如何處理？

接著，平台的產品負責人核准以下報表約定示例。門檻、時間及回應共同呈現此產品所需的明確程度。

經核准的 10% 規則現在具備目的、比較條件、回應及負責人。若平台的支出決策對 1% 差異已經敏感，就須由產品負責人核准這項準則，再由工程團隊評估其影響。兩個數值都是產品示例，並非規格優先交付的條件。若季節性變化使昨天的數量不適合作為基準，也可以考慮以預測範圍判斷。自動化資料品質驗證研究展示了如何將驗證條件與歷史品質指標及異常偵測結合，包括隨時間改變的預期。⁹ 適用方法的選擇及例外的解讀，仍由產品與技術決策處理。

返回頁頂

4.2. 架構影響與營運工作量

及早確立介入條件，工程團隊便能評估所需觀測及回應。若平台需要調查持續出現的細微變化，報表資料管道可能需要歷史遙測、資料分群及視覺化；若已核准回應只是在批次完成後，於違反已確立規則時發送通知，自動驗證作業與通知 API 可能已經足夠。除了門檻，回應時限、資料可用程度、預期變化及診斷需求也共同決定實現方式。

工程團隊依所需回應、評估頻率及診斷證據，選擇觀測與介入方法。即使門檻為 1%，可預測的比較與回應仍可自動處理；需要解讀的情況則保留人工調查。Grafana 或以 OpenTelemetry 為基礎的管道可以實現部分觀測設計，產品要求所確立的則是使用案例所需的證據與介入。

討論也須揭示誤報成本。若每次行銷活動都需要工程師重新尋找已獲核准的解釋，就表示營運流程缺少可重用的脈絡。記錄活動適用條件並在驗證時套用，是其中一種工程回應。產品團隊還須決定誰維護這些脈絡，以及資訊過期或缺少時如何處理。因此，減少營運瑣務會同時影響要求、架構與維護責任。

返回頁頂

5. 線上購物平台的容量與可靠性

返回頁頂

5.1. 從業務需求量推導技術容量

業務容量說明平台在一般及行銷活動負載下，必須支援哪些瀏覽、搜尋、購物車管理與購買活動。產品負責人或產品經理核准工作負載承諾、規劃期間及允許的限制；預測提供承諾的依據，同時保留其不確定程度。Google 的 SRE 容量規劃論述結合需求預測、資源配置需求，以及用來建立基礎設施容量與服務容量關係的負載測試。¹⁰

技術團隊將已核准的工作負載轉化為資源需求。電子商務工作負載研究曾以顧客工作階段及活動間的轉換，建立使用者如何使用網站的模型。¹¹ 每小時有 10,000 位顧客完成購買，仍未交代瀏覽、搜尋、放棄購物車及瞬間湧入的流量；這些活動也會消耗資源。因此，工程團隊須取得或明列推導請求率、並行量、儲存及相依服務需求所需的假設。

例如，資料庫增長可以從每日訂單數、每筆訂單的儲存位元組數、保留期間、索引、複寫及相關事件估算。每個因素都須有來源或暫定假設，並指定負責人。若韌性要求是一個雲端不可用時，另一個仍須承擔已承諾的工作負載，容量估算就必須涵蓋這種情境；只按平時流量分配配置容量的設計，無法充分支持該失效要求。

返回頁頂

5.2. 可能受影響的業務量與技術目標

依前述示例的工作負載，購買中斷一小時會使 $500,000 的銷售總額受到影響：10,000 位完成購買的顧客，各有一筆 $50 訂單。這個數字估算的是受影響活動，並非實際損失的預測；顧客可能延後購買、放棄購買，或改用其他通路完成。若原始數字代表訪客量，還須加入轉換率假設。

這項估算為中斷容忍程度的討論提供依據。產品決策負責人考慮哪些時段的中斷影響最大、何種降級服務仍有用，以及顧客需要什麼復原或核對處理。工程團隊據此提出可衡量目標、容量餘裕、復原行為及營運工作量。若成本可承擔的技術方案與業務承諾不相容，就須交回適當的產品或政策決策負責人處理。

99.9999% 可用性的候選目標，需要特別精確的解讀。若以時間為基礎，評估期間為 30 天，這項目標只允許 2.592 秒不可用；若以請求為基礎，限制的則是符合條件但失敗的請求，不能直接換算成停機時間。團隊須同意量測解析度、涵蓋的使用者流程、相依服務的處理方式，以及評估可行性所需的證據。單一數值本身無法提供失效模型或可行的復原設計。

返回頁頂

6. 將判斷記錄於適當的脈絡

產品團隊須保留已核准義務與各項實現決策之間的關係，並持續維護相關紀錄。產品常設要求說明哪些要求跨交付作業持續適用；架構規格在持續維護的架構知識中，記錄為履行義務所選定的系統安排；功能規格定義可觀察的行為，包括失效及介入；技術規格將經審查的決策轉化為實作工作與驗證；營運程序則讓形成的行為能在服務運作中執行。

以下紀錄為購物平台示例分配各項責任。這些相互關聯的知識，可以保存在既有的程式碼儲存庫、架構系統，或按既定程序管理的文件平台。

每項工作產物都須連結其所依據的權威決策。後續規格可以直接引用已核准的可用性定義，避免另建評估期間不同的版本。若技術調查發現目標需要不同的失效模型或營運承諾，就須提出議題，交由相應的要求或架構討論處理。實作細節的更新不能在未經明確核准下，降低產品義務。

返回頁頂

7. 跨雲要求、架構與技術規格

返回頁頂

7.1. 辨認不相容的架構

假設購物平台的要求討論已確立雲端部署、結帳流程在兩個雲端供應商任一個中斷時仍須具備韌性，以及已核准的 99.9999% 可用性目標。產品決策負責人已核准業務承諾，技術決策負責人則定義支持該承諾的目標及量測方式。要求紀錄指出涵蓋哪些中斷，以及復原期間如何處理訂單與顧客可見的影響。這些決策確立所需成果，是否符合要求則須透過約定的證據證明。

接著，一項架構方案將全部結帳狀態放在同一個 Azure Storage account。架構的結構化討論須載入適用的可靠性要求，沿著結帳流程檢視相依關係。若 Azure 中斷會令唯一可用的狀態無法存取，這項方案就無法符合雲端供應商中斷時的行為要求；衝突須在授權實作之前，於架構討論中處理。

審查的重點是：在要求涵蓋的供應商中斷情境下，結帳狀態是否仍然可用。跨 Azure 可用性區域或地理區域的複寫，可以處理相應層級的失效；要在 Azure 供應商中斷時繼續運作，則須在仍可運作的另一個雲端具備獨立可用的處理路徑。若 Storage account 用於非關鍵功能，或其用途可以獨立復原，仍可能符合要求。判斷取決於該依賴對要求涵蓋的顧客活動有何影響。

討論須記錄被否決的假設、受影響要求，以及仍需作出的設計決策。若既有系統已存在這項依賴，架構現況就須如實呈現，並記錄尚未符合的要求。目標與目前運作能力各有不同的證據狀態。

返回頁頂

7.2. 核准架構方向

架構師、開發負責人或具明確責任歸屬的團隊，可能選擇讓容器化應用程式工作負載同時在 AWS 與 Azure 執行。在此示例中，應用程式僅以容器部署的規則，因支持所選定的可攜性及運作模式，成為已核准的架構限制。規則的範圍須清楚：應用程式容器仍依賴網路、身分、儲存及其他平台服務。

在兩個雲端部署同一個容器映像，展示了部署可攜性的一種形式。架構還須說明仍可運作的部署如何取得可用狀態、接受流量、驗證請求身分、完成或核對訂單，以及支援所需負載。共用身分服務、路由控制、發佈缺陷或不可用的狀態儲存，都可能同時影響兩邊部署；架構審查須沿著這些依賴，判斷已核准失效情境下，結帳流程是否仍可使用。

架構決策須確立流量模型、狀態與一致性策略、供應商中斷時的容量、允許的相依服務，以及復原責任，也須交代維持兩個環境的成本與瑣務。要符合營運要求，可能需要自動檢查設定及自動復原；把相同的例行人工作業在兩個雲端各做一次，則可能削弱這項要求。

已獲充分支持、可以進入實作的決策，連同理由、採用範圍及尚待履行的驗證義務，納入已核准的架構方向；仍在調查可行性的選項則保留為提案。實作及證據決定何時可更新架構現況。是否符合可用性目標，仍須以約定的失效測試，以及已核准評估期間內的服務量測判定。

返回頁頂

7.3. 訂明功能行為

功能規格將已核准的韌性要求套用至購買行為，定義顧客在中斷期間會看到什麼、如何識別處理中的訂單、平台何時確認接受訂單、重試如何與該訂單連接，以及復原時如何核對結果不確定的訂單。產品決策負責人依照要求確認這些規則，工程團隊則檢查規則與所選定的狀態及流量模型是否相容。遙測與日誌須識別相應成果，讓驗證及營運工作能判斷系統是否遵循規則。

返回頁頂

7.4. 訂明部署與驗證

已核准方向的技術規格，須在實作層次定義變更，並解決那些一旦失效，就會使架構無法符合要求的細節。對這項跨雲交付作業而言，包括：

1. 部署行為。 指出應用程式工作產物、各雲端的設定、機密資訊與身分服務依賴、逐步部署次序、相容性檢查及回退條件。

2. 流量與健康狀態決策。 訂明外部進入路徑、負載平衡或故障切換機制、能代表結帳實際可用的健康訊號、偵測行為、路由收斂，以及進行中請求的處理。

3. 連線與狀態。 定義網路路徑、路由及存取規則、複寫或核對行為、一致性預期，以及連線或供應商中斷時的運作。

4. 監測埋點與輸出。 訂明開發及生產環境的指標、追蹤與日誌欄位、輸出位置、嚴重程度、取樣、匯出及保留設定，並包括從仍可運作雲端進行觀測的安排。

5. 驗收證據。 建立測試，涵蓋供應商隔離、相依服務失效、複寫中斷、仍可運作雲端的容量、重複或不完整訂單、恢復、所需人工介入，以及各項成果的輸出證據。

對此平台而言，連線部分可以訂明 AWS 與 Azure 之間具備備援的站對站 VPN 路徑、路由與存取規則，以及通道失效時所需的行為。Azure Virtual Network peering 可連接 Azure 內部的相關網路；跨雲流量則需要另行建立互連。工程團隊依照已核准架構，評估所選路徑的吞吐量、收斂及失效行為，並在技術規格中記錄設定與測試。

驗收計畫須在失效及復原期間，量測要求涵蓋的顧客成果，並納入資料正確程度與營運工作量。故障測試可以揭示共用依賴或過慢的切換，並確立受測條件下的行為；長期可用性目標的證據，還須依賴約定的營運量測及審查流程。成功部署至兩個雲端，只提供其中一部分證據。

返回頁頂

8. 透過不熟悉產品的參與者測試驗證知識

不熟悉產品的參與者測試，用來評估所記錄的知識能否支持獨立專業判斷。知識系統就緒度說明更廣泛的準備責任。對可靠性工作，應選擇具備相應專業能力、但未參與原始決策的人員，提供一般知識入口、待評估變更，以及實際參與者應有的存取權限。AI 參與者也須透過它實際使用的檢索途徑接受評估；人員能存取某項資料，並不表示代理也能找到同一份內容。

購物平台的測試可以提供以下架構：應用程式容器部署於兩個雲端，但關鍵功能仍依賴同一個 Azure Storage account。請參與者根據持續維護的來源評估方案。預期結果是提出有依據的判斷：部署可攜性仍未解決雲端供應商中斷要求，並指出適用義務及負責架構決策的技術決策人員。

測試須檢查參與者能否：

1. 找到適用的業務承諾、技術可靠性要求及已核准工作負載條件；

2. 區分架構現況、已核准的架構方向與未解決提案；

3. 指出哪項依賴與失效行為要求衝突，並解釋其對顧客的後果；

4. 指出解決衝突所需的功能行為、技術規格工作及證據；

5. 判斷開發與生產環境必須輸出哪些遙測與日誌，以及提出的觀測途徑能否在涵蓋的失效情境下維持運作；以及

6. 將未解決的產品、架構或政策決策交給相應負責人，並保留尚未核准的決策狀態。

同一平台的報表營運可提供第二項評估：向參與者提出一個發生於已記錄行銷活動期間的門檻超標，詢問每日支出報表能否放行。知識應讓參與者根據比較規則、活動適用條件、完整性檢查及放行權限作答。若仍須詢問原始會議參與者「門檻當時指什麼」，就表示缺少脈絡，或脈絡無法透過正常途徑取得。

每項發現須記錄為檢索缺口、模糊判斷、衝突決策或缺少證據，並指定負責人及受影響的後續工作。負責人更新權威來源或解決決策後，參與者須重做相關評估。通過測試表示參與者能提出有依據的結論，也能正確指出未決事項應由誰決定；這證明知識可以使用，系統是否符合要求仍須以約定的技術與營運證據判定。

重大缺口會阻止依賴該資訊的決策繼續。例如，供應商中斷要求尚未解決時，就不能核准聲稱符合該要求的架構。產品承諾仍待確認期間，工程團隊可以繼續進行已獲明確授權的可行性調查。發現缺口的人可以說明後果並提出解法，決策權限則仍由負責的決策人員行使。

返回頁頂

9. 維護要求及其後續影響

產品團隊將已核准要求、理由、相關架構決策、實作證據與營運回饋，作為相互關聯的知識一併維護。當變更影響這些判斷時，就觸發審查，例如新的行銷活動模式、供應商交付方式改變、需求量修訂、重複人工介入、相依服務行為改變，或失效測試推翻設計假設。

例如，無法解釋的資料管道警報增加時，負責人須檢視比較規則、行銷活動脈絡及人工審查負擔。提高門檻會改變業務介入決策，須取得該決策負責人的核准。跨雲復原測試失敗，則先形成架構或實作問題；若原目標經證實不切實際，業務承諾才交回產品討論。變更的來源決定應重新討論哪一項判斷。

當韌性設計增加資料副本、網路路徑、身分或診斷紀錄時，安全與隱私要求仍然適用。參與者須協調這些限制與復原設計，並透過適當程序記錄已授權例外。任何營運例外提案，都須保留適用的政策核准及理由。

持續維護的紀錄，應讓下一位參與者從產品關切事項，沿著產品常設要求、架構規格、功能規格、技術規格及程式碼，追查至行為證據。結構化討論建立及修訂這些判斷；不熟悉產品的參與者測試檢查其他參與者能否使用這些知識；營運證據則將實際失效、工作負載變化與反覆出現的瑣務，帶回同一個決策過程。