Azure Well-Architected Framework 工作負載
在 Azure Well-Architected Framework 的內容中, 工作負載 一詞是指應用程式資源、資料和支援基礎結構的集合,以達成定義的商務成果。 工作負載是由元件以及開發和作業程式所組成。
架構設計人員設計工作負載,而工作負載小組會實作這些工作負載。 工作負載的設計和實作是為了達成功能性和非功能性商務需求。 工作負載可以分類為許多類型。
工作負載分類的一般準則包括:
工作負載的公用程式、特性和使用模式,例如 Web 應用程式、批次處理和即時分析。
重要影響因素,例如技術平臺或與產業的一致。
預定的目標物件。 各種物件的解決方案範例包括企業內部企業營運應用程式、購買的獨立軟體廠商 (ISV) 解決方案,或多租使用者軟體即服務 (SaaS) 解決方案以供公開使用。
相同類別中的工作負載可以共用相似之處,包括其目標物件、合規性需求和技術堆疊。 Well-Architected Framework 的五個要素、其原則、檢查清單和取捨都與所有工作負載類別有關。
Well-Architected Framework 的工作負載指引會說明與特定工作負載類別相關的常見優先順序和取捨。 在工作負載指引中,要素指引適用于代表工作負載優先順序的技術設計原則和設計領域。 請遵循建議來協助設定成功的工作負載,並將其與 Well-Architected 架構一致。
什麼是 Well-Architected Framework 工作負載?
任何工作負載的設計和作業都必須與五個架構要素競爭:可靠性、安全性、成本優化、營運卓越和效能效率。
若要建立成功的工作負載,請根據下列理想的 Well-Architected 架構原則加以開發。 |
---|
Well-Architected Framework 工作負載:
- 具有已定義並排定優先順序以達成目標的功能和非功能需求。
- 其設計目的在於您可以使用資源併入設計模式和取捨來達成這些需求。
- 建置並操作至設計和用途的規格。
- 測量其達到其用途的適當程度。
- 可以在調整或變更用途時進行調整。
- 就像需要一樣可靠。
- 就像安全一樣安全。
- 提供足夠的投資報酬率。
- 開發並負責操作。
- 在可接受的期間內完成其用途。
工作負載小組和組織中央小組之間的共同作業必須建立具有上述特性的工作負載。 下列各節說明這些小組及其功能。
工作負載小組
建立具有各種技術和商務專業領域的小組成員的工作負載小組。 所有小組成員的主要焦點應該是工作負載的成功。
工作負載小組成員的範例 | |
---|---|
應用程式安全性工程師 商務專案關係人 雲端開發人員或軟體工程師 雲端解決方案架構師 資料科學家或分析師 資料庫管理員 |
DevOps 工程師 基礎結構工程師 產品經理或擁有者 品質保證 (QA) 工程師 支援小組成員 |
集中式小組和專案關係人
集中式小組通常支援工作負載小組。 它們提供支援函式,並針對組織內的許多或所有雲端工作負載套用治理。 集中式小組著重于組織成功,這部分是由組織工作負載的成功所達成。 它們提供工作負載的服務、指引和防護措施。
集中式小組和小組成員的範例 | |
---|---|
商業智慧分析師 商務專案關係人 (CCoE) 面板的雲端中心 雲端平台小組 網路安全性分析師 資料庫管理員 企業架構設計人員 |
財務分析師 基礎結構工程師 法律與合規性人員 網路工程師 採購專家 專案管理員 |
Well-Architected Framework 工作負載小組著重于工作負載結果。 他們與集中式小組成員的特製化支援協調並受益。
共同責任模式
工作負載必須部署並使用,才能提供價值。 身為工作負載小組的一部分,您必須負責設計、實作及部署工作負載,以建立價值給組織的方式。
工作負載存在於組織的內容中。 組織通常具有受規範的控管和授權角色。 您的工作負載小組必須負責在組織基礎內設計、實作及部署工作負載。
根據 Azure 的雲端採用架構,將工作負載的雲端資源標準化。 嚴格套用標準化,以提供受控管的平臺,以協助讓工作負載小組上線。 根據組織的雲端作業模型套用此治理。
您可以使用 Azure 登陸區域來協助您執行標準化。 Azure 中提供平臺登陸區域和應用程式登陸區域。 在應用程式登陸區域中部署工作負載。
您的組織可能會有一個雲端平臺供應專案,其嚴格且完全符合 Azure 登陸區域。 或者,您的組織可能會有不同的採用策略或沒有實作。 如果沒有實作,工作負載小組幾乎是完全自發的實體。
對於組織使用的任何平臺和治理,您必須將 Well-Architected Framework 的原則套用至您的工作負載。 Well-Architected 架構通常會參考 Azure 登陸區域,但並不相依于特定的平臺實作。 Well-Architected 架構要素、原則、檢查清單和指南適用于所有雲端平臺和大部分的工作負載類型。
滿足需求
在 Well-Architected 架構中,例如核心要素和工作負載指引,建議會與工作負載義務一致。 建議通常不表示哪些小組成員或小組有助於這些義務。 您可以判斷誰應該執行每個動作。 執行工作負載層級對應,以判斷與拓撲、工作負載類型和重要性相關的小組角色和責任。
直接工作負載小組會處理大部分的工作負載需求。 某些需求會以與集中式小組共同合作來處理。 例如,實作選擇可能以集中式小組所設定的護欄為基礎。 或者,集中式小組可能會獨佔地處理實作選擇。
您的工作負載小組必須與其他小組建立工作關係,以協助撰寫工作負載目標的程式碼。 如果您外包元件或責任,則必須成功傳遞這些義務。
瞭解條件約束
集中式小組支援以小組的核心功能和核心基礎結構為基礎的各種工作負載。 為了在組織規模上提供這項支援,集中式小組可能會對提供的服務或基礎結構實作統一性和限制。 當您設計工作負載時,請務必瞭解這些條件約束,並盡可能與瞭解這些條件約束的企業架構設計人員合作。 盡可能從先前的實作中學習。
每個平臺治理實作都不同,但許多工作負載都有下列條件約束:
- 雲端資源的允許清單
- 雲端資源的設定授權
- 雲端資源和跨單位連線可用性的區域允許清單
- 非上班時間有限或無平臺支援
- 修補需求
- 特定的中樞輪輻實作,其會驅動網域名稱系統 (DNS) 和私人端點實作
- 供應鏈控制需求
明確傳達需求
如果您的工作負載需求面臨條件約束或服務等級協定 (SLA) 未明確定義核心功能或基礎結構供應專案,請將該情況視為風險。 若要解決此風險,您的工作負載小組必須清楚說明其他小組對工作負載的影響。 您可能需要變更工作負載需求、設計或實作,或變更基礎結構供應專案。
當您瞭解與組織指示詞和工作負載小組義務相關的平臺小組義務時,您可以與實際的期望和建議溝通工作負載需求。
傳達常見的工作負載需求
每個平臺合作關係都不同,但下列領域是共同責任交談中的常見主題:
- 合規性和法律需求
- 網路特性,例如靜態輸入或輸出 IP 位址的需求
- 提供有效即時網站分級的可檢視性需求
- 效能需求,例如網路輸送量、雲端資源的可用性,或區域可用性
- 從輸出和輸入的觀點來看,公用網際網路存取的預期
- 服務等級目標 (提供給工作負載使用者的 SLO) 或 SLA
- 技術支援的可用性
尋找統一的勝出
共同責任不只是取捨、條件約束和入侵。 平臺小組通常會有高度特製化的技能和專用預算,可擴增個別工作負載小組可承受的技能。 請思考一下下列範例。
安全性專家。 您的工作負載可能有安全的開發生命週期。 當集中式安全性小組在組織中大規模執行安全開發工作時,它可能會執行超過您工作的例行滲透測試。 它也有助於規劃和執行事件回應策略。
企業架構指引。 如果您符合企業架構小組的模式和做法,可以節省時間和精力,因為小組已經簡化程式。 如果在沒有交涉的情況下,無法在合作關係內執行解決方案,您也可以避免重新工作。
大型票證支出。 平臺小組通常會為個別工作負載小組裝載成本過高或過於廣泛管理的元件或服務。 平臺小組可以負擔這些元件和服務,因為它們會將成本分散到工作負載。
這些服務或集中式平臺通常會以僅顯示的形式提供,因此有助於讓工作負載成本保持優化。 當它們以退款的形式提供時,它們通常因為規模和集中化經濟而成本較低。
平臺小組通常會為工作負載小組提供各種活動的自助選項。 例如:
- 提供自我引導式教育的檔存放庫
- 透過特定資源標記上線至成本管理
- 透過正式的訂用帳戶銷售程式提供訂閱
探索可能適合您工作負載的自助式選項。
分享成功和挑戰
與其他小組共同責任也表示共用工作負載的成功和挑戰。 當您的工作負載符合其義務並取得預定的價值時,請與您的合作夥伴小組共用。 告訴他們他們如何參與工作負載的成功。 當您的工作負載不符合其義務時,請分享無法運作的內容,並共同作業並重新調整以回到追蹤。
平臺小組也有義務和成功準則。 您應該預期合作夥伴會告訴您您的工作負載是否與供應專案搭配運作良好,或是否有雜訊鄰近的風險。
致力於持續改善
所有 Well-Architected 架構要素的主題都是持續改善。 採用漸進式思維。 您可以處理現有問題的新方法、採用新技術、解決新需求,或在新的限制下操作。 隨著您的工作負載隨著時間而改善,請預期合作夥伴小組的思維相同。 不過,每個改進機會也表示變更,而且應該由適當的管理程式支援。
工作負載小組必須與平臺小組溝通有關可能對平臺小組服務產生影響之工作負載需求的建議變更。 同樣地,平臺小組必須義務將其工作負載合作夥伴納入變更控制程式中,並清楚傳達具影響力的平臺變更。 與合作夥伴建立定期溝通步調,以瞭解並分享產品演進的方式。
達成成功的結果
工作負載對使用者、監督、法規機構、員工、卓越中心,以及經驗長有許多期望。 預期可以設定方向指南針旋轉。 Well-Architected 架構提供明確的合理化,讓架構決策達到成功結果,以提供與設計和實作相關的清楚性。 開發成功的工作負載,並與組織共用該成功。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應