共用方式為


工作負載架構設計規格

工作負載架構設計規格是 描述設計選擇的詳細規格,並隨附圖表。 設計選擇必須符合功能和非功能需求,並包含例行、臨機操作和緊急作業的布建。

如需圖表的相關信息,請參閱 架構設計圖表

工作負載架構設計通常廣泛,從應用程式設計和進行雲端服務選擇開始。 這些階段會相互通知。 結合的應用程式和基礎結構設計必須滿足所有需求。

達成符合所有需求的解決方案,是 專案關係人、開發人員、測試人員、營運小組和產品擁有者之間的共同作業。 設計程式應涉及清楚和交涉的精簡需求。 此程式是反覆的,而且通常需要多次檢閱。

我們建議您將設計與 Azure 架構良好的架構基本指導方針一致,其中包含設計原則和建議指南,並認可取捨。

最後,工作負載架構設計規格是由工作負載開發小組實作,因此必須清楚且明確。 規格應該可供使用,並隨工作負載的檔一起儲存。

功能規格

工作負載的功能規格會詳細說明 開發中系統或功能的原因原因 ,而不是實作。 本文件必須說明目前存在的問題,以及此功能或系統如何改善該體驗。 本檔會擷取大部分的商務需求。

架構設計人員可協助塑造這份檔,但主要是產品擁有權的功能。 架構設計人員應該協助設計在此規格中擷取的數據。 此參與可確保功能規格可推動有效且有效率的技術設計。

以下是本規格中應涵蓋的幾個範例主題。

  • 除了詳細說明此設計的範圍之外,也明確說明範圍不足的連續考慮。 設定清除範圍可藉由定義功能周圍的界限來減少範圍爬行。

  • 包含如何測量此變更的詳細數據很有説明。 需要收集哪些度量,以及哪些商務目標支持這些度量。

  • 應該清楚描述使用者流程。 低費德利類比也可以有説明。 如果這些流程的錯誤處理情況很重要,請確定所述的預期行為。

  • 一律包含輔助功能、合規性、效能、隱私權或安全性的任何特定需求。

  • 包含任何計劃推出策略。 例如,「這項功能將在決定完整版本之前,為 Beta 使用者提供兩個月。

請避免此規格中的特定技術實作詳細數據。 這些功能規格將驅動架構設計人員所建立的技術規格。

技術規格

技術規格描述如何根據功能規格中所述的範圍和目標。 此規格是專為工程小組在實作期間用來作為記錄計劃而設計。

在此規格中,包括下列專案:

  • 技術決策,包括:購買、建置、重複使用、擴充或解除委任。
  • API 和數據合約 (架構),包括回溯相容性實作策略
  • 推出和復原實作詳細數據
  • 獨特的開發生命週期 (SDL) 和隱私權實作
  • 測試計劃
  • 重要監視和警示訊號來源
  • 考慮的替代設計

技術規格將推動工程工作。 工程工作專案主要是從此規格的內容建立。 實作小組會參考工作專案、技術規格和功能規格,以確保最終結果符合功能和非功能需求。

災害復原計劃

為了符合工作負載的可靠性需求,架構設計人員必須設計可在目標復原時間目標 (RTO) 和恢復點目標 (RPO) 目標內復原的系統。 架構設計規格必須包含復原計劃。 此方案必須涵蓋相關的架構元件、故障轉移機制,以及對使用者和數據流的影響,以及操作建議。 它應該描述設計符合哪些復原目標,以及其方式。

雖然初始計劃預期會根據鑽研和事件後檢閱的深入解析而演進,但架構設計人員有責任為所有新架構提供初始計劃。

安全性與合規性檔

架構設計人員負責設計符合相關安全性和合規性條件約束的解決方案。 設計成品必須強調設計中納入的能供性以支持這些需求,並識別無法直接滿足需求時的任何必要補償控件。

一致性

使用範本來記錄工作負載的各種規格。 在讀取規格時,一致性可協助項目關係人、責任方和實作小組。

確定規格具有重要的元數據欄位,例如:

  • 狀態:狀態為 草稿檢閱核准
  • 工作項目連結:小組待辦專案中主要工作項目的連結。
  • 主要交叉連結:相關規格的連結或其他支援規格的檔。
  • 關鍵人員:列出相關關鍵決策者名稱的位置。 此清單可能包含下列角色:商務分析師、商務夥伴、技術潛在客戶,以及簽署規格的產品擁有者或潛在客戶。

下一步