雲端運算的治理框架

運用"雲端服務"加速企業的數位轉型願景

26 min readMar 27, 2023

該框架適合以下的企業內外部的各單位或組織:

雲端的執行發起人(通常是企業中的IT單位)將進行檢查與平衡，以確保出於正確的業務因素系統性的運用雲端運算，並持續的擷取結果性的指標。
企業架構師和 IT 策略單位可以將雲端運算的參考架構和技術與企業的架構和技術方向保持一致。
雲端服務的使用者(通常是企業的業務單位)將能夠定義他們的業務和技術需求，並推動雲端服務的持續改進，以確保與服務水平期望保持一致。
雲端服務提供商(公有雲業者或私有雲單位，以下簡稱CSP)將獲得對他們所提供服務的整體效能的第一手觀察，推動他們維持對雲端服務使用者具有商業意義的關鍵服務量。
雲端服務的SI(系統整合商)可以與其他服務提供商和客戶合作，以確定跨雲端運算解決方案的協同作用，從而增強SI自身的能力。

框架簡介

使用雲端運算的企業必須應對其運營模式變革相關的商機和風險，而雲端運算也是大多數企業近進入數位轉型的重要第一步。 有效的治理框架對於確保成功的數位轉型和獲得對持續運營的更好管控至關重要。

理解主要的雲端運算的挑戰和注意事項有助於解釋在朝向雲端運算的使用轉型期間應用治理的迫切需要。

雲端運算治理框架提供了一套深入到企業中所有適用的業務和 IT 領域的雲端範例相關的一致性指導方針。

概覽

今天，雲端運算正在推動企業中多個層面的變革。在最基礎的層面上，雲端運算是以更具成本效益的方式提供 IT 基礎設施。這是大多數(不過不是全部)雲端運算解決方案的普遍預期特性。利用雲端運算的這一個面向會導致技術、組織和程序上的變革，並且需要確保這些變革會帶來預期的結果和效益。

在大部分情況下，企業需要進行變革才能將走向指定的方向。在任何一種情況下，治理都可以幫助企業確保"變革"確實實現其意圖。

隨著更複雜的雲端服務的開發和提供，更多的利害關係人、期望和成功衡量標準開始發揮作用。作為使用雲端運算的理由，靈活性、敏捷性和業務競爭力與 IT 經濟學同等重要，甚至更具吸引力。隨著變革在整個企業中變得越來越明顯，潛在風險和回報的範圍也會增加，企業面臨的問題是:如何確保變革帶來預期的結果和效益。PS:有關雲端經濟學可參考本部格FinOps的系列文章。

虛擬化和雲端運算的運用改變了資料中心、伺服器環境中的標準 IT 開發和維運，並挑戰了一些非功能性需求，例如資安、合規、計量和計費模型，這些在傳統資料中心的非功能性需求跟不上雲端運算的複雜性還有快速的步伐。

傳統的非雲端運算治理框架（例如 ITIL、COBIT 5、TOGAF 9.1 標準和 SOA 治理框架）是通用的，沒有辦法支援雲端運算特性(例如彈性)的治理。他們也沒有充分考慮到這樣一個事實，即對於雲端運算，IT 服務的使用者(一般企業)和CSP(如AWS/Azure/GCP)之間的責任劃分問題變得完全不同並且非常重要。雲端運算使得在功能和IT基礎設施方面處於“What”和“How”之間的任何規模成為可能。 IT基礎設施可以由使用者根據腳本定義，由CSP執行。應用程式可以由使用者選擇或由CSP預先提供。 不同等級的控制項可以組合在一個 IT 環境中。當前的治理框架和治理術語沒有充分支持這種類型的可變性。當今存在多種治理框架來解決重疊領域，有一些治理框架更適合用在 IT領域中。

雲端運算引發的挑戰包括了:

從資本支出(CapEX)轉向運營支出(OpEx)的投資模式
需要額外的管理來解決交付模型中的預期變化
管理風險所需的新業務和 IT 角色
透明的雲端使用者-CSP的互動
覆蓋著"架構和技術決策"的差距
對多租戶和資源虛擬化這一議題而做出決策的支援不足

雲端運算治理框架從主要利害關係人(如使用者、提供商和開發人員)的角度定義了基於雲端的解決方案所有階段的總體治理流程、結構和指南。

企業通常在沒有為複雜性做好適當準備的情況下就開始進行雲端運算的規劃。 如果治理流程不直接解決雲端運算的特性，雲端運算專案可能就會失敗。 Open Group Cloud Computing Governance Framework認知到向業務主導的 IT 戰略的轉變。它使企業能夠保持對整個深入企業中日益複雜和整合的服務提供商和解決方案的雲端生態系統的控制。

規範性的參考

ISO/IEC 17788:2014: Information Technology — Cloud Computing — Overview and Vocabulary; refer to:https://www.iso.org/standard/60544.html
ISO/IEC 17789:2014: Information Technology — Cloud Computing — Reference Architecture; refer to: www.iso.org/iso/catalogue_detail?csnumber=60545.

名詞定義

以下是我們在討繼續往下討論之前必須做一些名詞上的定義。

雲端運算治理(Cloud Computing Governance)

一種 IT 治理的觀點，著重在包含雲端運算環境中的問責制、定義決策以及平衡效益或價值、風險和資源。

治理流程(Governance Process)

組織用來實現治理意圖的過程。

受控的流程(Governed Process)

由"治理流程"來控制、監控、測量或以其他方式治理的過程。

流程對(Process Pair)

一對流程，其中一個是治理流程，另一個是被治理流程(governance process)所治理的流程(Process)。

雲端運算治理(Cloud Computing Governance)

所謂雲端運治理是指 — 在最抽象的層面上，治理旨在確保我們所管理的是在做正確的事情：

我們在做正確的事嗎?
我們做的對嗎?
我們怎麼知道?

雲端運算治理是由業務驅動(business-driven)的政策和原則所建立的，而雲端運算服務的生命週期過程會設立適當程度的投資和控制。這確保與雲端相關的所有企業支出都符合業務目標，促進整個企業的資料完整性，鼓勵創新，並降低資料遺失或不合規的風險。雲端運算治理可以認知到雲端運算增加了 IT 的普遍性，並確保C-Level 決策者能夠解決整體 IT 投資、資源需求、價值機會和風險影響 — — 無論組織或CSP是甚麼狀況。

治理模型與整體標準

治理模型和整體標準會滿足以下準則的模型和標準：

由業務治理驅動，同時解決 IT 治理問題
全球性且不特定於任何地理區域
不特定於任何一個產業領域
與現有治理模型和標準保持一致

下表呈現了根據準則對這些標準的評估。隨後在解決業務和 IT 治理的那些標準的背景脈絡中呈現了雲端運算治理。

被視為整個整體治理一部分的”標準、框架和最佳實踐”是那些同時解決”業務和 IT 面向的治理”：

TOGAF — architecture governance
COBIT
ITIL
The Open Group SOA Governance Framework

而其他標準、框架和最佳實踐則更偏向 IT領域：

ISO/IEC 38500 — overlaps with ITIL v3 and COBIT 5.
Val IT — overlaps with COBIT 5 and is based on COBIT 4.1.
Risk IT — overlaps with COBIT 5 and is based on COBIT 4.1.
Calder-Moir IT — overlaps and is based on ISO/IEC 38500.
COSO — business governance framework, addressed by COBIT.
Balanced Scorecard — addressed by COBIT.

雲端運算治理框架在整個關於整體治理中的位置

下圖說明了雲端運算治理框架的範圍和與其他產業框架的關係。它顯示了雲端運算治理框架相對於企業內其他治理形式的地位。

上圖說明了治理模型和標準的框架是怎麼相關的。它從左到右垂直劃分為實際執行到策略的各個領域，每個領域都支援下一個領域。 IT Governance和EA Governance彼此保持一致，並且是單一個技術治理領域的一部分。

雲端運算治理框架是企業整體業務治理的一個子集，其中包括 IT 和企業架構治理。它包含對雲端運算治理至關重要的所有治理類型的獨特特性。

業務治理(Business Governance)解決了由 IT 和企業架構治理所支援的企業業務的總體治理。雲端運算治理框架包括與雲端運算相關的業務決策權和問責制。

IT 治理 (COBIT) 通過優化 IT 效益、價值交付、風險和資源來解決業務價值所產生的問題。 雲端運算治理框架包括 IT 治理的特定面向，這些面向是雲端運算的價值建立、效益、風險和資源優化所獨有的。

企業架構治理 (TOGAF) 通過提供架構願景、標準和原則來支持企業治理，以通過業務和 IT 架構原則實現未來狀態的業務模型。企業架構治理與 IT 治理保持一致，被認為是有效 IT 治理的關鍵管理流程（COBIT — APO03 管理企業架構）。雲端運算治理框架包括雲端運算治理所需的企業架構治理的特定面向。

ITIL解決服務治理問題，包括服務策略、業務設計和運營以及 IT 服務。雲端運算治理框架包括針對業務和 IT 服務策略、設計和運營的特定雲計算治理特性。

雲端運算治理框架引用了 The Open Group的SOA Governance Framework 的現有元素，並包括特定於雲端運算治理的修改。

健全的業務、IT、企業架構、服務管理和 SOA 治理對於有效的雲端運算治理至關重要。

雲端運算的挑戰

雲端運算為 IT 維運模型和業務成長工具提供了不同的範例。它改變了傳統的 IT 角色，並已成為一種重要的解決方案，為企業提供了一種具有潛在成本效益的模型，因為可以實現業務目標但減緩其投資IT基礎設施的需求。在雲端環境中，存在委託代理關係：雲端服務使用者(一般的企業)是委託人，CSP(如AWS/Azure/GCP)是代理人。當操作控制權從委託人手中釋放並委託給代理人時，需要一種機制來最小化風險和成本。這種期望和責任的轉變帶來了治理可以緩解雲端運算所伴隨的挑戰。雲端服務使用者和CSP的利益最初可能不同，但需要圍繞著降低成本、支援多租戶、安全性和許多其他因素的核心目標進行協調。

隨著企業繼續向雲端運算靠攏，主要挑戰和考量因素分為以下幾大類，與企業的傳統地端機房相比，這些挑戰和考量在雲端運算中變得更加突出。

1.拓撲(Topology)

雲端運算導致從獨立的專用 IT場景轉變為涉及一套組件和服務之間更多協作的場景，這些組件和服務可能由多個內部和外部雲端服務提供商提供。這反過來又導致業務和 IT 拓撲結構可能並且經常分佈在有界線劃定的多個領域中，包括架構、設計、地理位置、跨組織、企業和政府。因此，雲端拓撲的治理方面也更加分散。

這種高度分佈的拓撲結構需要一種主動的方法來理解、委派和管理相關的權力、責任和問責制。這種分佈的成功程度與設立可能是全新的信任關係以支援雲端運算跨越這些邊界的無縫共存、整合和維運的能力直接相關。這些信任關係對於設立、維護和驗證支援企業的地端機房和雲端運算以及雲端技術和服務的無縫運作所需的底層共享策略和標準至關重要。

在某些情況下，企業(雲端服務的使用者)有時不知道用於存儲和處理其資料和應用程式的伺服器的物理位置，特別是SaaS服務。無論資料是動態的還是靜態的，物理位置和位置之間的傳輸都可能對滿足企業政策和要求的能力產生影響，而這反過來又可能受到其他治理領域的影響，包括政府法規和條例。由於這些政策和法規要求可能因不同國家區域而異，並且由多個政治實體設立，因此資料治理的一個關鍵問題以及雲端治理的結果是 — 如何在這個急劇擴展的環境中至少確保最低限度但足夠的一致性。

除了物理位置的問題外，涉及多租戶的雲端場景也引發了新的資料保護問題。 PII(Personally Identifiable Information)通常需要根據政策、適用法規和法律對使用和可存取性施加限制。安全地存儲資訊並只允許授權用戶存取需要適當的控制，當資料存儲在CSP的基礎架構中而不是在企業的直接控制範圍內時(通常是自家機房)，這可能更具挑戰性。

此外，雲端運算可以加速行動/社交解決方案和大數據的使用，伴隨著數量、速度、種類、新資料源和所有權的爆炸式增長，以及確保資料準確性的需求，進一步增加關於電腦運算和資料的位置和治理。

CSP所提供的組件完整性的潛在差異增加了確保解決方案的端到端(end-to-end)完整性和安全性不受薄弱環節影響的挑戰。一個強大的雲端治理框架將企業政策和標準與CSP整合並相互關聯，對於在分佈式雲端生態系統中設立、驗證和維護一個可實行等級的端到端(end-to-end)的一致性、可靠性和安全性至關重要。

2.合規性

合規性是指企業有責任按照既定的法律、法規(例如個人資料保護法)、標準和規範進行運營。企業面臨的最常見合規性問題之一是資料所在位置對確保合規性能力的影響。企業自行建立資料中心來符合相關的法規通常不會太難，因為資料與運算環境都在企業的直接控制範圍內。相比之下，許多雲端運算服務的一個特點是資料可能會冗餘存儲(也就是多個資料複製)，並且可能存在於多個物理位置。有關企業的資料位置的詳細資訊可能不確定，可能會隨時間變化，或者甚至可能根本不會向企業披露。這種情況使得難以確定是否有足夠的保護措施以及是否滿足法律和法遵性要求，並且在某些情況下甚至難以確定潛在的多個重疊監管要求中的哪一個優先。 外部稽核和安全認證可以在一定程度上緩解這個問題，但並不是萬能的。違反合規性通常會導致政府處以高額罰款和處罰。因此，對於雲端運算治理而言，建立適當的監控流程和程序來審核和驗證合規性非常重要。

3.合約管理

雲端服務同時具有功能性和非功能性特性。企業和CSP之間的SLA必須全面解決這兩個問題。雲端運算治理必須確保程序存在並始終如一地用於有著正確定義的合約和 SLA，以驗證CSP能夠在訂閱其雲端服務之前滿足 SLA 的條款，確保隨著時間的推移持續合規，並進行補救，以及時和可驗證的方式糾正不合規的情況。

安全和隱私通常是基於雲端的解決方案的首要非功能性要求，這在很大程度上是由於雲端拓撲在分散的去中心化運算環境中分發資料和功能。因此，必須在雲端合約和 SLA 中充分解決隱私問題。 如果無法以高度的信心和確定性實現這一點，企業應考慮實現其目標的其他方式，包括尋求不同的CSP，或修改解決方案的架構以避免將敏感資料放入外部環境(不直接由企業管理的雲端運算環境)。

企業中負責控制安全性和存取 PII 的人員(通常是資安人員)需要在其組織內提高對雲端運算驅動變化的認識。他們的職責現在擴展到包括確保CSP遵守預期的安全和隱私政策。雲端運算治理有持續的義務確保CSP保持遵守 SLA 中的政策。這包括存在和使用涵蓋 SLA 所有方面的稽核程序，包括安全和隱私政策，以及存在和使用程序和方法來執行和驗證是否採取了糾正措施以保持對這些 SLA 的遵守。

3.組織變革(也是最重要的)

雲端運算可以在多個領域推動組織變革。在朝向雲端轉型的過程中可能會出現新的職位和技能要求，與雲端運算相關的自動化可能會引發關於某些現有職缺和資源是否仍然必要的問題。企業是否具備必要的技能？這些技能在人力市場上容易找到嗎？擔任現有職缺的人是否能夠承擔新的職缺和技能？我們是否仍需要現有技能來持續維持雲端中的解決方案？現有的組織架構能否有效推動整個企業向雲端的方向持續演進？這些問題突顯了評估和解決組織變革的影響作為雲端運算轉型中的關鍵成功因素的重要性。

治理可以通過確保在適當的框架內做出企業決策同時充分考慮核心原則以及及時、有效地溝通這些變革來減緩這種衝擊。

雲端運算治理原則

雲端運算治理應基於下列原則。它們適用於整個雲端運算生命週期。

原則1:遵守政策與標準

原則2:業務目標是驅動雲端策略

原則3:雲端生態系統參與者之間的合作契約

原則4:遵守變更管理流程

原則5:執行流程以達成持續改善

雲端運算治理角色

以下這些說明是基於 ISO/IEC 17789:2014 第 8 節

整體治理

治理團隊對應到雲端稽核員角色，但適用於雲端服務使用者、CSP和雲端服務合作夥伴角色。

雲端服務使用者(通常是一般企業)

雲端服務使用者與雲端服務提供商有著業務關係。雲端服務使用者也可能出於各種目的與雲端服務合作夥伴(大多是SI公司)建立業務關係。主要活動包含選擇和實施雲端服務以及監控、安全、報告和管理服務的問題回報。雲端服務使用者的主要目標是確保業務/IT 一致性和服務提供商的無縫互操作性。更多詳細的雲端運算的各類角色可以參考 ISO/IEC 17789。

CSP(通常是我們所知道公有雲廠商，如AWS/Azure/GCP等)

雲端服務提供商向雲端服務使用者提供雲端服務。此角色（及其所有往下細分的角色。請參考 ISO/IEC 17789）著重於提供雲端服務所需的雲端運算作業和確保將其交付給雲端服務使用者以及雲端服務維護所需的雲端運算作業。

雲端服務合作夥伴(通常是SI公司)

雲端服務合作夥伴支援或參與雲端服務提供商和(或)雲端服務使用者的作業。雲端服務合作夥伴的作業包括設計、建立、加強和維護服務組件。這還包括確保遵守安全和稽核控制。

雲端運算治理流程

在最抽象的層面上，治理主要在確保我們所治理活動的是在做正確的事情。要做到這一點，對治理流程和被治理流程進行明確定義至關重要。與其他治理領域一樣，雲端運算治理涉及對其他流程進行 — "治理流程的系統性執行"。

雲端運算生命週期

雖然企業的雲端運算規劃確實往往有自己的生命週期，但治理需要始終在持續的基礎上涵蓋所有規劃。因此，雲端運算治理本身沒有生命週期(開始和結束)。相反，雲端運算治理是在所有雲端運算規劃的整個生命週期中實施的。

下圖顯示了典型的雲端運算生命週期及其治理面向。

雲端運算治理流程的特徵

雲端運算治理流程為治理雲端的生命週期提供了總體框架。治理流程的定義特徵包括：

溝通 — — 確保每個人都知道他們應該做什麼以及做這件事的正確方法。
合規性 — — 確認每個人都遵循已確立為最佳實踐的原則、政策、標準和指南。
例外和豁免 — — 允許極端的要求快速得到考量和可能的特殊處理。
持續改進 — — 確保事情不會隨著時間的推移變得陳舊或無法改進；實際上，重新定義什麼是正確的事情和正確的方法，以避免變得過時。

流程對(Process Pairs)

必須了解治理流程與受治理流程不同。受治理的流程在雲端運算治理流程的總體框架下執行雲端服務的策略、建立、維運、使用和退役。

流程對是一對流程，其中一個是治理進程，另一個是被治理流程的過程。下表中呈現了雲端治理流程對。

流程交互

治理流程和受治理流程之間的交互產生於且具有以下幾個關鍵因素：

治理旨在確保我們“做正確的事”的概念
幫助我們回答“我們怎麼知道？”
治理涉及幾個核心流程（溝通、合規和豁免）
交互的一般模式可以專門化以適應不同角色和需求的每個受管流程
類似於雲端運算的認知可以提供彈性和適應性，有效的治理也可以從一定程度的彈性和適應性中受益，因為很難不提前考量所有可能的未來情況和要求

治理交互
每個流程對的一個共同特徵是在治理和被治理流程之間發生的一組交互。這些交互可以根據它們相關的基礎治理流程(溝通、合規和豁免)進行分組。

每一次交互都是治理 — 也就是確保我們“做正確的事”這一概念。已經在高層次上描述了交互，因此就像雲端運算提供了彈性和適應性一樣，這些交互也可以通過針對特定情況進行更詳細的調整來實現。

與溝通相關的交互使受治理的流程能夠知道它們應該如何執行。治理應確保指導受治理流程的方法以及流程為正確執行而應使用的標準和其他資訊被記錄在案並在已知的企業的文件庫中找到。良好的溝通應該回答“我們如何做這件事？”、“誰應該做這件事？”、“我們還需要知道什麼才能正確做這件事？”以及“在哪裡可以找到該資訊的正確位置？”等問題。 ”。

與合規性相關的交互可確保符合政策、流程、標準和指南等內容，這些內容已由具有權力和決策權的各方預先確定，適用於受管流程。指導受治理流程的方法或流程定義應確定合規流程的交叉點。 “合規性檢查點”會在繼續下一步之前尋找受控流程按設計工作的證據，並在發現“正確的事情”沒有做時預計會“說不”。 如果一個受治理的流程有效地利用了與溝通相關的交互，那麼它應該能夠合規。

與豁免相關的交互，儘管盡了最大努力來定義什麼是“正確的事情”，但總有可能出現意想不到的要求、新情況或隨著時間的推移而發生的變化，這些都可能證明正常現行規則的例外情況是合理的。知道事情會隨著時間的推移而變化，並且可能會出現一些新的或未預料到的情況或要求，治理處置過程提供了一些彈性和適應性，以便可以重新考量來自合規性的“否”答案以查看是否可以允許異常。 例外/豁免狀況可能是推動標準和政策隨時間演變的力量之一。

高層次交互

雲端運算治理"流程對(process pairs)"通常在治理和被治理流程之間有十個高層次交互。在"流程對"圖中使用術語來標識這些交互。每個交互將在此處進行較高等級的描述，並且可能會在後面的部分中為各個"流程對"提供其他資訊，以解釋它們是如何專門化的。

溝通：方法、文件庫、標準、特定過程的輸入/輸出
合規性：檢視合規性、批准(或拒絕)合規性
豁免：例外的考量，例外的授予，例外的拒絕

溝通:方法

治理溝通過程向受治理過程提供有關方法的資訊，以確保那些參與受治理流程的人知道應該如何執行該流程。這包括有關在哪裡可以找到有關的原則、政策、流程、標準和指南的重要和官方訊息的資訊，受治理流程在執行時需要應用這資訊。

溝通:文件庫

治理溝通流程識別受治理流程的官方訊息來源。對於那些參與治理流程的人來說，了解在何處以及如何找到他們需要的資訊，並確信這些資訊是正確的和最新的，這一點至關重要。溝通過程確保參與治理過程的每個人都知道當前和官方訊息在哪裡是可用的。文件庫代表已知的良好資訊存儲位置的廣義概念。這些文件庫中的訊息應該通過持續的管理來維護，以確保它隨著時間的推移保持最新和具權威性 — — 否則，資訊的可信度將受到質疑，文件庫將不再有效。

知識庫可以以多種形式保存多種類型的資訊，包括參考架構以及內容致中呈現的方法與標準。

溝通:標準

治理溝通過程確認了對治理過程至關重要的原則、政策、標準和指南。標準闡明了受治理流程可以做出決策和採取行動的界限。

溝通:特定過程的輸入/輸出

受管控的流程會有特定的輸入並產生特定的輸出。治理溝通過程確定了應該用於溝通、存儲和檢索這些輸入和輸出的適當的溝通機制、工具和程序。

合規性:檢視合規性

“受治理流程”向”治理合規流程”提出請求，以執行特定的合規檢查點審查。受治理的流程應該明確定義需要使用合規流程要點。一種常見的模式是在流程中存在因合規性相關”重工”而浪費時間和資源的風險點進行合規性檢視。受治理的流程可能會擔心合規流程會干擾其進度；但應將合規視為避免日後可能出現的重大成本和延誤的一種方式。

合規性:批准

“治理合規流程”將其發現傳達給”受治理流程”，以批准合規性。合規性檢查點審查的結果會傳達給受治理的流程(和其他利害關係人)。 批准應反映出完全符合預期的政策、標準和指南 — — 描述流程在該檢查點之前應該實現的“正確事情”的資訊。

合規性:拒絕

治理合規流程將其發現作為不符合現行政策而拒絕的結果傳達給受治理流程。 合規拒絕應包括關於不合規內容的明確聲明以及實現合規的指導。在某些情況下，受控流程繼續往下進行並同時進行修正以實現合規性可能是可以接受的。在其他情況下，不合規的性質可能會產生太大的風險，並且可能需要在允許受治理的流程繼續進行之前進行修正。

豁免:例外的考量

“受治理流程”向”治理豁免流程”提出請求，以考量允許對策略進行例外處理。受治理的流程可能認為合規流程的“拒絕”決定並未反映當前政策未充分考慮的新的或獨特的需求。 實際上，合規流程是甚麼都做不了的 — — 它應該適用法律條文，並且無權做出例外情況。受治理的流程應該能夠使用定義的請求程序來觸發豁免流程，以便為例外情況提供理由。當發現當前政策因最初制定政策時未預期到的要求而與核心原則和目標背道而馳時，豁免流程有權酌情授予例外情況。