識別和評等流程的建議

適用於此 Azure Well-Architected Framework 可靠性檢查清單建議：

RE：02	識別和評分用戶和系統流程。 根據您的業務需求使用重要性調整，以排定流程的優先順序。

本指南說明識別和排定工作負載流程優先順序的建議。 識別和排定工作負載流程的優先順序牽涉到將使用者流程和系統流程對應至組織，以判斷其重要性。 此做法可確保您識別並排定最重要的工作負載功能優先順序，以降低損害失敗的風險。 無法識別工作負載流程並排定工作負載流程的優先順序，可能會導致系統分解和工作負載可靠性遭到入侵。

定義

詞彙	定義
使用者流程	使用者在應用程式或系統內採取的路徑或動作順序。
系統流程	系統內的資訊和處理程式流程。 系統會自動遵循此流程，以啟用使用者流程或工作負載功能。

主要設計策略

當您設計工作負載時，必須定義使用者流程和系統流程。 使用者流程會透過您的應用程式繪製用戶移動的圖表。 他們著重於使用者介面、互動、決策，以及完成工作所需的步驟。 使用者流程提供以使用者為中心的用戶體驗和介面設計觀點。 系統流程會繪製您工作負載的內部工作。 它們著重於工作負載元件、後端服務和外部 API 之間的數據移動、輸入處理、輸出處理和互動。 系統流程指出工作負載在內部運作方式的複雜詳細數據。

您應該在工作負載的設計階段早期識別和定義流程。 它可讓您更清楚了解影響工作負載可靠性的內容。 它會與您的架構決策緊密配合工作負載的可靠性目標。

識別所有用戶和系統流程

識別所有使用者和系統流程的輸出是工作負載中所有流程的目錄。 此識別程式會要求您從頭到尾對應系統中的每個用戶互動和程式。 此對應是識別重要流程的必要條件。 以下是識別工作負載中所有用戶和系統流程的建議：

• 面試項目關係人。 項目關係人可以提供寶貴的信息來識別流程，甚至可協助您對應和排定流程的優先順序。 您也可以面試使用者、商務分析師和技術小組，以收集工作負載內用戶互動和相依性的深入解析。

• 檢閱檔。 在設計階段中，您可能沒有檔可檢閱。 不過，如果檔存在，您應該使用它。 要求系統架構圖表、用戶手冊和程式描述。 這些文件可協助您瞭解工作負載及其個別流程的預期功能。

• 觀察工作負載。 監視作業中的工作負載，指出使用者與其互動的方式，以及不同的元件如何彼此交談。 您應該分析系統記錄、效能計量和用戶活動記錄，以識別模式、頻繁的工作和系統回應。

• 列出已識別的流程。 面試、文件和觀察應該可讓您識別工作負載中的所有流程。 編譯您識別的所有流程清單，並將其分類為使用者流程， (著重於用戶互動) 和系統流程， (著重於後端進程和數據移動) 。

• 定義流程起點和終點。 針對每個已識別的流程，清楚定義流程的開始位置及其結束位置。 針對使用者流程，記錄每個用戶互動及其預期結果。 專注於用戶體驗和介面設計。 針對系統流程，您必須識別其基礎觸發程式和預期結果。

• 細分每個流程。 將每個流程分解成個別步驟，描述每個時間點所發生的動作、決策或程式。 請注意每個步驟如何與系統的其他部分互動，包括其他流程或外部系統的相依性。 您應該能夠找出流程如何與工作負載和用戶體驗整合並影響。 這種雙重方法可讓您全面檢視整個工作負載。

• 檔唯一輸出。 識別每個流程內的任何替代路徑或例外狀況，例如錯誤處理或條件式分支。 如果流程有多個可能的結果，您應該將它新增至目錄作為不同的專案。 針對使用者流程，您應該識別互動的預期行為。 針對系統流程，您應該識別程序的預期行為。

• 使用圖表視覺化。 建立流程圖或圖表，以可視化方式表示流程及其步驟。 您可以使用 Microsoft Visio、UML 順序圖、使用案例圖表、簡單繪圖工具或文字格式的描述性清單等工具， (請參閱 範例流程目錄) 。

• 反覆更新流程對應。 流程對應是反覆程式。 流程可以變更、分割或合併，特別是在設計階段。 當工作負載流程變得更清楚定義時，您應該更新流程目錄以符合。 使用專案關係人的意見反應來驗證並精簡您的流程圖，以確保正確性和完整性。

識別每個流程的商務程式

商務程式是一系列的工作，可達成輸出，例如訂單履行、客戶服務管理或庫存控制。 識別每個流程的商務程序牽涉到將流程對應至一或多個商務程式。 此對應可協助您瞭解每個流程對企業的重要性。

您可能已有提供流程對應至商務程式的現有文件或商務方案。 有時候使用者手冊、訓練教材或系統規格可以提供工作負載及其流程預定用途的深入解析。 如果沒有，您必須將流程對應至其支援的商務程式。 以下是識別每個流程商務程序的建議：

• 使用工作負載輸出。 您可以使用工作負載輸出和流程明細，將流程與其支援的商務程式相互關聯。 首先，檢閱工作負載所產生的輸出。 輸出可以是銷售報表、數據檔或已完成的工作。

• 進行面試。 與與工作負載互動的小組成員和項目關係人交談。 您應該詢問其每日工作的特定問題、如何使用工作負載，以及他們達成的目標。 技術小組通常對工作負載結構有更深入的瞭解，並可深入解析其支援的商務程式。

• 監視工作負載使用量。 針對現有的工作負載，監視工作負載並尋找使用模式，以指出基礎商務程式，例如數據輸入、訂單處理或客戶互動。

• 將輸出連接到商務程式。 將流程輸出中的點連接到其支援的整體商務程式。 例如，如果流程步驟涉及處理客戶訂單，則它直接支持訂單履行的商務程式。 訂單履行有助於維護客戶滿意度和產生收益的業務目標。 最後，使用流程明細來協助判斷哪一個流程建立了銷售報表。

識別每個流程的程式擁有者和項目關係人

流程的進程擁有者是負責成功執行指定進程的個人。 他們負責該程序和支援它的流程。 您應該識別每個工作負載流程的進程擁有者。 您也應該識別每個流程的利害關係人。 項目關係人可以參與工作負載、擁有流程的相依性，或管理流程所擁有的相依性。

您可能會有責任指派矩陣 (RAM) 或 RACI 矩陣，這些矩陣已識別進程擁有者和項目關係人。 一般而言，程式擁有者負責或負責程式，而您諮詢或通知項目關係人。

識別每個流程的呈報路徑

擴大路徑的識別是關於判斷通道以呈報與流程相關的問題。 需要呈報的問題可能是緊急更新、安全性考慮、降低或技術事件。 識別呈報路徑的目標是確保問題及時且有效解決。

您對應的呈報路徑應該從最可能解決特定問題的個人或群組開始。 如果此人員或群組無法解決問題，呈報路徑應該會識別下一個連絡點。 下一個連絡點具有更廣泛的責任，而且能夠協調組織更多部分的風險降低策略。 呈報路徑上的人員數目會因流程和組織而異。 呈報路徑上太多人可能會讓解決工作變慢。

識別每個流程的業務影響

識別每個流程的業務影響對於瞭解每個流程如何參與重要商務目標而言非常重要。 業務影響可能包括營收產生、客戶滿意度或營運效率。 藉由瞭解每個流程的正面和負面影響，您可以優先處理工作，以確保對企業而言最重要之流程的可靠性。 請務必考慮流程失敗的直接影響，以及其對其他互連進程的影響。 以下是識別每個流程業務影響的步驟：

• 識別正面影響。 判斷流程如預期般執行時的預期優點。 預期的好處可能包括改善的效率、增加收益、提升客戶滿意度，或對企業的任何其他正面影響。

• 識別負面影響。 如果進程失敗或未如預期般運作，請評估潛在的負面影響。 請考慮量化特定損失，例如營收下降。 包括信譽損害、客戶信任的負面影響，或對其他相關商務程式造成負面影響等主旨效果。

• 定義容量和可用性假設。 建立每個程序的預期容量和可用性的假設。 請考慮因素，例如每個時間單位的輸送量、預期的上班時間，以及目標百分比運行時間。 如果復原時間目標 (RTO) 或恢復點目標 (RPO) 有預期，您應該包含這些期望。 這些假設有助於瞭解每個流程的可靠性需求。

透過有系統地評估這些層面，您可以全面檢視每個流程如何影響業務，並制定可靠性優化的策略性決策。

將重要性評等指派給每個流程

相對於整體業務影響的詳細流程重要性評估，可讓您將重要性評等指派給每個流程。 您可以使用量化或定性重要性評等。 目的是要依優先順序排序流程，並指派標籤，讓您識別重要流程。 此程式是識別、對應及配合商務程式和影響的邏輯接續。 使用下列重要性描述來指派您的重大評等：

• 高重要性：高重要性流程對核心商務功能而言是不可或缺的。 它們會直接影響企業的重要層面，例如客戶體驗、財務交易、安全性通訊協議、人類健康和安全性。 這些流程失敗或中斷可能會導致重大的立即或長期負面影響。 負面效果的範例包括營收損失、信任外洩和法律問題。 優先處理這些流程可確保工作負載最重要的層面是強固且具復原性的。

• 中度重要性：中度重要性流程對於系統的完整功能很重要，但不會直接與客戶或重要商務營運介面。 例如，如果問題中斷內部數據處理流程，您可以重試數據處理，而不會立即造成外部影響。 這些流程對於順暢作業而言很重要，但針對立即客戶或財務效果提供緩衝區，允許管理對問題的回應。

• 低重要性：低重要性流程對於核心商務功能或客戶體驗沒有直接或顯著的影響。 範例包括像是夜間記錄傳輸之類的輔助程式，或選擇性的使用者功能，例如意見反應問卷。 雖然這些流程會對整體系統造成影響，但其中斷不太可能造成重大的立即業務或操作問題。

藉由遵循這個結構化方法來指派重要性，您可以有效地排定資源的優先順序，並專注於維護及增強最重要流程的可靠性與效率。

取捨：可靠性的較高期望有時會與操作員的設定成本、營運成本和管理負擔較高。 確保項目關係人瞭解改善重要流程可靠性的潛在成本增加。

組織一致性

雲端採用架構 提供需要業務重要性分類之工作負載的指引。

如需詳細資訊，請參閱 雲端管理中的業務關鍵性。