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