多雲環境的架構設計與治理

44 min readJun 3, 2022

所有的CSP(Cloud Service Provider) 都會提供雲端適應框架CAF(cloud adoption framework)，協助企業實施雲端的治理和部署，同時控制雲端中的服務等級和 KPI，在多雲環境中，企業必須考慮如何對不同CSP的不同雲端組件實施管理，而且是將其全部組件作為單一環境進行管理。

我們將探討多雲治理的不同之處，並使用 CSP 的CAF以及Well-Architected來檢視企業在雲端採用的各個階段。

本文中我們將介紹以下幾個議題：

什麼是多雲環境的鷹架
使用Well-Architected Framework
理解甚麼是雲端採用
將業務的KPI轉化爲雲端的SLAs
運用CAF來對齊不同的CSP
了解雲端運算的身份驗證(identities)與角色(roles)
建立一個雲端服務的設計與治理模型

多雲環境的鷹架

企業如何在雲端中開始的？台灣很多企業在沒有計劃與研究就開始了。畢竟，一開始使用不會很難？我們訂閱雲端帳號並開始部署資源。這可能適用於非常小的環境，但我們很快就會發現它開始亂長。想一想 — — 我們是否會買辦公室並來取得裡面的網路線和機架還有服務器來開始建立資料中心？當然不是。那麼，為什麼我們會在沒有計劃的情況下在公有雲中開始構建雲端機房呢？我們這時會走向災難 — — 浪費一堆人力、資金與時間，最後又搬回地端機房。正如我們在什麼是多雲(Multi-Cloud)文章中已經看到的那樣，企業需要清楚的了解成本，知道誰在雲端中執行什麼、何時執行以及為什麼執行此操作，最重要的是，這一切都需要都要有保護資料和資產來確保安全性，就像企業在地端機房中所做的那樣。

PS:這裡有一個重點，那就是：我們正在建立一個資料中心。我們正在使用公有雲構建它，只是它不是一般co-locate的機房，機器不是企業擁有的，而我們也無法到現場去查看。

幸運的是，所有主要的 CSP 其實都一樣，發布了CAF。簡而言之，這些框架有助於企業制定計劃，而且最重要的是，有助於保持對雲端部署的控制。這些框架在某些方面確實存在差異，但它們也有很多共同點。有關於三大CSP(AWS/Azure/GCP)的差異請參閱本部落格"CAF雲端採用框架比較"系列文章。

建築物的鷹架是支持建築物在建造過程中的結構，微軟 Azure 用該術語來支援"建立和管理"部署在 Azure 中的環境。儘管在雲端中，鷹架不會是一個臨時結構(因為真實環境中，房子蓋完鷹架就拆掉了)。它是用作建立和管理雲端landing zone環境的基礎的結構。

雲端環境的鷹架由以下一系列的基礎組件構成。

使用Well-Architected Framework

各家CSP的Well-Architected Framewrok是被用來協助CSP的客戶(也就是一般使用雲端的企業)，根據最佳實踐來建立其雲端環境。多雲環境的建立與管理的挑戰在於每家CSP都有它自己的工具、工作流程、命令列、服務名稱等。不過三大CSP的Well-Architected Framewrok大概都做這個目標(來自AWS的分類):

卓越維運
資安
可靠度
效能
成本優化
ESG環境永續(雖然筆者覺得這一個面向是胡扯)

有關這六個議題可參閱本部落格"AWS的雲端架構框架"系列文章。這些議題同時也協助從雲端運算分支出來的其他學科，例如講雲端財務控制的FinOps，安全控制的SecOps與工作負載管理的BaseOps。有關雲端財務控制FinOps可參閱本部落格FinOps系列文章。

IAM(Identity and access management)

誰可以做什麼，什麼時候做，為什麼做？這是公有雲中的安全運作的最最基礎，也是最最讓很多人搞混的，因此我們將在本文後面的“了解雲端中的身份和角色”標題下用更多的詞彙來討論身份和連結。要記住的最重要的事情是，雲端中的幾乎所有東西都是一個身份(identifies)。我們在這裡談論的不僅是人類，還包括允許執行某些操作的函數、API、機器、工作負載和資料庫。所有這些資源都需要唯一身份，以便在外部環境中對其進行身份驗證。

接下來，需要為這些身份(identities)設定特定的規則，它們需要被授權才能執行作業。顯然，Identity directory system（如 Windows AD 或 OpenLDAP）作為identity providers或identity store非常重要。問題是我們是否想要在我們的公有雲環境中使用這個identity sotre，或者我們是否想要在我們的環境中使用身份驗證和授權機制，與identity store進行通訊。如之前所述，在“了解雲中的身份和角色”標題下，我們將在本文後面更詳細地討論這一點。

安全性

這可能是一個大膽的說法：AWS、Azure 和 GCP 等雲端平台可能比世界上絕大多數企業還要安全的平台。因為他們也必須如此，不然企業怎麼可能將系統託管在在這些雲端平台上。然而，資安仍然是企業自身的責任。雲端平台將提供保護企業的系統運作上在雲端環境的工具。我們是否要使用這些工具以及在多大程度上使用完全取決於企業的業務。資安始於政策。通常，企業必須遵守某些框架，這些框架帶有建議甚至是保護系統的義務。除了這些產業標準，還有跨產業的安全底線(baseline)，例如 CIS(Center for Internet Security)。 CIS baseline是廣泛的，並且在雲端中的強化雲端資源的資安方面涵蓋了很多領域。Baseline有定性與定量的項目，其中定量項顯然是最重要的。當未達到baseline時，稽核人員將在這些項目上進行標記。

一個框架值得更多關注：MITRE ATT&CK。security baseline只是最基本的，但我們如何在不了解實際攻擊方法和被駭客利用我們系統漏洞的情況下保持對安全性的控制？ MITRE ATT&CK 是一個知識庫，它根據資安攻擊和已知不合規行為的真實世界的觀察不斷進行評估。這裡的關鍵詞是真實世界。他們追踪主要公有雲（AWS、Azure 和 GCP）以及在這些平台之上註冊的平台（例如用於Container orchestration的 Kubernetes）的真實攻擊和這些攻擊的緩解措施。

成本管理

我們以前可能聽過這個：公有雲不像我在自己的資料中心運行的程式那麼便宜。那這句話就是真的。如果企業決定從傳統工作負載轉移到公有雲，無需更改任何參數(lift-and-shift的方式)，哪麼這個系統在雲端的運作就是365天全年無休的託管該工作負載，哪可能比佈署在地端機房更昂貴，如果地端機房的資產是攤提五年，哪雲端費用絕對比地端還要貴(這是就是機器本身的成本來比較)。而對此可能有兩種解釋：

企業只算直接成本而沒有加間接成本，諸如電力、冷卻系統和人力（尤其人員的變動）之類的事情都都算進成本內。
企業使用公有雲的心態就像使用地端機房一樣，但沒有使用到雲端運算的靈活性，也就是大鍋炒的方式，不做程式與業務面的分析。因為並非所有工作負載都需要 24/7/365 全天候運行。雲端系統提供了真正的pay-as-you-go模式，企業只需為其消耗的實際資源付費。

成本管理至關重要。我們希望完全控制我們在雲端中消耗資源的任何業務。但這需與 IAM 齊頭並進。如果員工可以完全存取雲端平台，並且例如為資料湖等大型資料平台建立一個高用量的存儲環境，那麼企業肯定會為此付出代價。這裡可能會出現兩件事：

首先，這個員工是否被授權執行該操作？
其次，企業是否為這個環境分配了預算？

讓我們假設員工已獲得授權，並且已經有預算可以用了。然後，我們需要能夠追蹤和追溯實際資源消耗，如果需要，能夠將費用做chargeback到使用這個環境的某個部門。因此，我們需要能夠識別資源。這就是資源中的命名和標籤發揮作用的地方。我們必須確保所有資源都可以通過名稱唯一標籤。標籤用於提供有關特定資源的資訊；例如，哪個單位負責這個資源，就向這個單位收費。

監控

我們需要在我們的雲端平台上獲得可見性(Visibility)。會發生什麼事出於什麼原因？我們的環境在效能和安全性方面仍然健康嗎？ CSP都會提供自家的監控平台：Azure Monitor、AWS CloudWatch、GCP Cloud Operation Suite 。基本功能是可以apple to apple相比的：monitor agents收集資料（日誌）和指標，然後將它們存儲在日誌分析系統中，在那裡他們可以使用告警規則和儀表板虛擬化進行監控。所有這些監控套件都可以與雲端平台本身一起運行，但也具有跟 ITSM 系統的 API的整合溝通，例如 ServiceNow，後者將在 IT 環境中的不同平台上提供單一的監看視窗。

這一類 CSP的監控方案和套件有很多第三方替代品，其中一些套件有AIOps的功能。 AIOps 不僅僅執行監控：它意味著對指標和日誌進行智慧分析。

自動化

我們已經談到了成本。到目前為止，IT 中最昂貴的成本之一是員工。對於許多公司來說，這是他們在外包 IT 時開始最主要的驅動力(人力很貴又難找)。但我們已經注意到，IT再次成為這些公司的核心業務。例如，如今的銀行是一家 IT 公司。在九十年代末到兩千年伊始，他們幾乎完全外包了他們的 IT，我們現在看到他們的 IT 職能又回到了內部。然而，仍有盡可能降低成本的驅動力。借助 IaC(Infrastructure as Code)、Configuration as code、存儲代碼的repo等概念，以及使用 DevOps 完全自動化的代碼部署，這些公司試圖最大限度地實現自動化，但不是每件事都能自動化的。這樣做能讓員工的人數成長保持在最低限度，但是員工的素質與技能就要求得很高。

然而，成本並不是自動化的唯一原因，儘管必須說這是一個有點模棱兩可的論點。自動化的容錯性往往不如人工，但是AI的出現卻可能改變這一趨勢。現行的自動化只有在經過全面測試時才有效，我們仍然需要優秀的開發人員來編寫初始代碼和自動化腳本，當然夠優秀的技術人員也能驅使類似ChatGPT這一類的AI幫忙編寫初始代碼與腳本。CSP確實提供了許多優秀的自動化工具，讓企業的日常作業更容易，但我們將意識到自動化不僅僅是工具和技術。這也與企業的流程有關；諸如由 Google 發起的 SRE 之類的方法正在風靡整個IT業界。

理解甚麼是雲端採用

我們可能聽過另一個術語：Cloud landing zone。 Landing zone是最終將託管工作負載的基礎環境。這就像一個房子。我們有許多支柱的基礎。最重要的是，我們的房子有大門、走廊和幾個房間。這些房間將是空的：沒有裝潢，沒有傢俱。這一切都還沒有設計和實施，我們有一個大賣場，我們可以從中選擇各種解決方案，讓我們的房子完全符合我們的要求。最後要做的就是人搬進房子。請記住：沒有鷹架，一開始就很難蓋房子。

CAF(Cloud adoption framework)是關於如何使用雲端技術的內容。通常，這被稱為雲端旅程。無論使用哪個CSP，整個雲端運算使用都由多個階段定義。CAF通常有以下幾個階段：

Stage 1: 定義業務策略與業務案例

在運用多雲策略加速企業的業務文章中，我們廣泛探討了企業的業務策略以及如何建立業務案例。企業需要有明確的目標並知道雲端產品在哪裡進行了加值。我們還探討了rehost、replatform和rebuild等技術策略。就 TCO(total cost ownership) 而言，rebuild可能並不永遠是最便宜的解決方案。這是因為企業傾向於忘記(甚至視而不見)將應用程式重新架構和rebuild到雲原生環境需要相當多的資源、時間。企業應該考慮這些架構和構建成本。然而，雲原生環境無疑會在靈活性和敏捷性方面帶來商業效益。簡而言之，這個初始階段在整個雲端適應周期中是經常發生的。

Stage 2 :組建團隊

讓我們立即打破這一個認知：在雲端中沒有 T 型專業人才，意思是可以在雲端中做所有事情的人：從開發程式到配置基礎設施。 T 越寬，T 這隻腳越短。換句話說，如果我們有通識的專業人才，基本上了解所有雲端平台(筆者就屬於這種)，他們可能不會對某一特定的雲端技術有深入的了解與實作。而且軟體工程師也不是網路工程師，反之亦然。

當然，在 AWS 或 GCP 中接受過架構和構建雲端環境訓練的人可能知道如何部署工作負載、資料庫，並對雲端網路有基本的了解。但是防火牆規則呢？或特定路由？換句話說：防火牆專家可能不太擅長 Python 開發。如果我們的團隊中有這類人，恭喜。付高薪給他們，這樣他們就不會離開。但我們可能會有一個混合了這些技能的團隊。我們將需要在設計和配置基礎設施方面受過熟練培訓的開發人員和員工，即使是在雲端運算中也是如此。

一些採用框架確實將其稱為CCoE(Cloud center of excellence) ，該團隊匯集了具有所有必需技能的人員。組建這個 CCoE 是採用雲端技術的重要一步。不過這通常是大企業才有辦法做的事，中小企業通常更多的是委外給供應商(SI)。

Stage 3: 評估

評估階段是確保正確遷移到雲端環境的重要步驟。在我們開始在landing zone的遷移或重建應用程式之前，我們需要藍圖。

首先，我們需要評估我們的業務策略。我們想把我們的業務帶到哪裡去？如何才能到達那裡？下一個問題是：我們當前的 IT 狀態是否準備好實施該策略？我們擁有哪些應用程式以及它們服務於哪些業務功能？應用程式和底層基礎設施是最新的還是（接近）不堪使用了，甚至生命週期結束？我們有哪些外包合約，我們是否需要在雲端轉型期間延展這些外包合約，或者我們可以取消這些合約。

一個正確的評估需要一些時間，但請不要跳過它。我們的最終目標應該很明確；歸根結底，所有企業都希望成為一家使用資料驅動決策的數位公司。我們需要一個環境，我們可以在其中以安全的方式披露資料，以使環境盡可能靈活和可擴展，以便它能夠配合業務進行的速度。問題是我們的傳統 IT 環境，它已經運作了很多年。如果我們幸運的話，一切都會有很好的文件記錄，但現實是文件很少是最新的。如果我們在沒有適當評估的情況下開始改造，我們必然會在不知道那新系統到底有多穩定的情況下開始從拆舊系統。同樣，在這裡，我們也需要鷹架來拆牆。

Stage 4: 定義架構

這是我們將定義Landing zone的階段 — — 將要託管工作負載的基礎平台。在多雲環境的網路連接設計文章中，我們討論了雲端的網路，因為這一切都是從連接雲端平台開始的。通常，這些網路連接將終止於transit zone或hub，這是通過firewall、proxy和gateway和過濾inbound和outbound流量的中心位置。

大多數管理員將通過 API 或console訪問系統，但在某些情況下，可能建議使用跳板機或堡壘機，即在他們可以訪問任何其他服務器之前形成環境入口的服務器。通常，系統整合等第三方合作夥伴使用這種類型的服務器。簡而言之，這個trainsit zone或hub在架構中很重要。

下一件議題是根據我們的業務策略定義架構。這定義了我們的雲端環境是如何設置的。我們的業務有分部門或產品線嗎？讓雲端環境與業務佈局相對應可能是值得的，例如，使用不同的訂閱帳號或每個部門或產品線都有自己的 VPC。

將有一些應用程式在整個業務中被更通用的來使用。 MS-Office 應用程式通常是一個很好的例子。這些應用程式將託管在一個單獨的訂閱帳號中嗎？那麼管理員的訪問權限呢？每個部門是否都有自己的管理員來控制工作量？企業是否採用了一種敏捷的工作方式，或者是否有一個集中的 IT 部門來處理所有的基礎架構？誰負責雲端資安策略？這些策略可能因部門甚至工作負載群而異。這些資安策略也可能無法全部套用在雲端或不適用於雲原生世界。它們可能需要根據我們的雲端 SME 的反饋進行更新，甚至有可能整個改弦易轍。

我們已經可以做出的一個主要區別是記錄系統(systems of record)和參與系統(systems of engagement)之間的區別，這兩個術語都是 Microsoft 首次使用的。記錄系統通常是保存資料的後端系統。參與系統是前端系統，用於連接資料、處理資料並傳達所述資料。這一步是要反映在環境的調整上，其中tier 1是access layer，第tier 2是worker（middleware），tier 3層是DB layer。架構中的一個常見規則是資料庫應該靠近訪問資料庫的應用程式。在雲端中，這可能會有所不同，因為我們可能會將 PaaS類型的DB engine。

這些是在雲端適應框架中提出的問題類型。這些都是非常相關的問題，在我們開始之前需要回答它的所有架構。這是關於將業務對應到全面的雲端運算藍圖。

Stage 5: 開始雲端平台的使用，並確認有將財務目標放在整體的使用上

在這個階段，我們將決定我們將構建雲端平台環境以及我們將使用哪種類型的解決方案：IaaS、PaaS、SaaS、container或serverless。這些解決方案應該源自我們在第 3 階段定義的架構。我們將不得不做出一些自己開發或買現成的決定：我們可以使用CSP自己現成的解決方案，還是我們需要開發一些針對業務需求客製化的東西？

在這個階段，我們還必須定義可以自動化產生或購買分析的業務案例。例如，如果我們計劃在 IaaS 上部署 VM，我們將不得不考慮該 VM 的生命週期。對於預計壽命超過 3 年的VM，與pay-as-you-go相比，在RI(reserved instance)上託管會更具成本效益。 CSP 為RI的產品提供相當多的折扣，這是有充分理由的：RI意味著長期使用合約，因此是有保證的收入。但請注意：這是一項長約。毀約是有代價的。所以一定要讓我們的財務部門參與進來，以使其正確解決。

開發環境通常只存在較短的時間。儘管如此，CSP 確實希望企業在他們的雲端平台上盡可能多地進行開發，並為開發人員提供特別授權，讓他們真正感興趣。歸根結底，CSP 只對一件事感興趣：客戶在他們平台的消費。有很多程序提供各種指導、工具和遷移方法，以將工作負載轉移到這些平台。

Stage 6: 建立與設定 landing zone

實際開始構建 Landing zone有多種選擇。正確理解是：Landing zone是基礎平台，通常是 Transit zone或Hub，以及 VNet、VPC 或project的基本配置。我們的目標是從一開始就盡可能地實現自動化。因此，我們將根據 IaC 和 CaC (Configuration as Code)進行工作，因為我們只能在component是code-based時實現自動化。

但是，當然還有其他方法可以開始我們的構建，例如，使用相應 CSP portal。如果我們要構建一個小型、相當簡單的環境，只需少量工作負載，那麼企業的對外形象網站就是一個完美的選擇。但是假設我們正在與一家企業合作，哪這一類的網站一開始可能不是構建在雲端環境的好主意。開始試用雲端平台絕對沒問題，但隨著企業的發展和環境的發展，我們需要一種更靈活的方式來管理和自動化工作負載。正如之前說過的那樣，我們希望盡可能多地實現自動化。我們如何做到這一點？通過編碼我們的基礎架構並將其定義為我們的主代碼。該主代碼存儲在repo中。現在，如果我們需要部署基礎設施組件，我們可以從這個repo中分叉代碼。由於某些業務需求，我們很可能時不時地需要更改代碼。沒關係，只要我們將更改的、批准的代碼合併回master repo。通過這種方式，我們已經部署為infra pipeline，如下所示：

在多雲環境中，最大的挑戰是有一個可以在多個雲平台上擴展的一致的repo和pipeline。儘管 AWS、Azure 和 GCP 的基本概念或多或少相同，但它們在應用技術方面確實存在差異。

如果我們尋找替代產品，我們可能會找到 Ansible、Chef、Puppet 和 SaltStack 等工具。但是，這些是Configuration tools，其工作方式與 Terraform 之類的configuration tools完全不同。還有其他選擇，例如 CloudFormation，但這只能用在 AWS上。

當我們真正想要一個完全中立的解決方案時，我們應該明確地談論Container和 Kubernetes。還記得兩大轉變之一嗎？其中之一是VM到container，這對於基礎設施組件來說當然是正確的。VM和container之間的最大區別在於它們處理OS的方式。 VM 需要有自己的OS，而container使用host的OS。這使得container不僅比 VM 輕量得多，而且更加靈活和真正跨平台。

我們可以在任何平台上使用容器。但是，我們需要一個orchestrating platform來對container進行落地與管理。這就是 Kubernetes 提供的。我們可以使用 Azure AKS、AWS EKS 或 GCP GKE 甚至試Vmware PKS 。下圖顯示了VM和container在概念上的區別：

Stage 7 : 遷移

現在我們有了 Landing zone，我們準備開始將服務和工作負載部署到我們的雲端中。這就是我們所說的雲端轉型(cloud transformation)。在這個階段，我們將實施我們在運用多雲策略加速企業的業務文章中討論過的外部技術策略，例如 rehost, replatform、rebuild、retain 和 retire。在評估之後，我們為每個應用程式或一群應用程式定義了業務重點和技術策略。在這最後階段，我們會將我們的應用程式轉移到新平台，應用新的雲端服務，或者重建雲原生應用程式。顯然，我們將這樣做是一種 DevOps 的工作方式，正如我們在第 5 階段所討論的那樣，我們從代碼中進行所有構建和配置。

DevOps 是一種作業模式。DevOps作業模式可能是實施新的雲端架構的解方，其中應用程式或一群應用程序的轉換可以是feature。憑藉我們從評估階段獲得的知識，結合技術策略，DevOps 團隊應該能夠進行良好的改進，將feature分解為可以在有限數量的 sprint 中執行和完成的作業。

轉型階段有兩個非常重要的項目：搬上雲端和退出雲端的策略。在上線之前，需要進行測試。強烈建議運行完整的測試週期：unit、integration、end user test。從流程的角度來看，任何公司都不應該在測試結果被證明可以得到解決之前允許任何東西上線。退出策略也是如此：沒有明確定義的退出策略，任何公司都不應允許任何東西上線；如何roll back或將系統移出雲端，回到原始狀態。這是考慮對環境進行(並行)重建的另一個原因，因此當事情結果無法按設計作業時，總是有原來的環境作為後備。當然，測試應該防止事情出錯，但我們也必須現實一些；東西總有一天會壞掉。

關於AWS/Azure/GCP等CAF介紹，請參閱本部落格CAF雲端採用框架比較 — Part 1、CAF雲端採用框架比較 — Part 2、CAF雲端採用框架比較 — Part 3、CAF雲端採用框架比較 — Final Part等系列文章。

將業務的KPI轉化為雲端的SLA

老實說，雲端中的基礎設施應該是企業的黑盒子。基礎設施就像打開水龍頭。由於這種運作方式，一些公司運作雲端基礎設施稱為流動的 IT。因此，對 SLA 的關注轉移到了業務本身。此外，這也是雲端適應的一部分。隨著企業在適應過程中不斷前進，許多企業也在採用不同的工作方式。如果我們可以在雲端中擁有靈活、敏捷的基礎設施，我們還可以加快環境和應用程式的開發。儘管如此，同樣在雲端中，我們必須仔細考慮service level objective和 KPI。

雲端的SLA 中必須涵蓋哪些主題？協議的A標準，從法律的角度來看，這將是一份合約。因此，SLA 通常具有屬於合約的格式和內容。將有合約期限、開始日期、簽訂協議各方的法律實體和服務時間的定義。更重要的是關於 KPI 的協議。我們對我們使用和支付的雲端服務有什麼期望？如果出現問題或我們需要某項服務的支援，我們要找誰？最後，服務的具體範圍是什麼？

在任何 IT 服務合約中，這些都是很正常的主題。但是，當我們使用公有雲時，它的作業方式就不一樣了。 SLA 的問題在於它通常按業務大小來調整。CSP根據業務需求會有一份制式化的合約。當然，許多 IT 廠商都盡可能地標準化和自動化，以便在他們的服務中獲得最大效率，但儘管如此，仍有調整的空間。在公有雲中，那個空間是絕對有限的。一家公司將有很多服務可供選擇以適應其要求，但各個服務都是一樣的。通常，CSP 為每項服務(產品)提供一個 SLA。在多雲環境中協商每個服務的 SLA 幾乎是不可能的。

這都是服務設計的一部分：企業必須決定他們需要哪些組件(component)來滿足他們的需求，並評估這些組件是否符合使用。組件 — — 服務本身 — — 無法更改。如果是 IaaS，會有一些自由度，但是當我們購買 PaaS 和 SaaS 解決方案時，這些服務是開箱即用的。企業需要確保 SaaS 解決方案確實具有所需的功能並以所需的服務等級來交付。

IT 中的常見 KPI 是availability、durability、RTO 和 RPO 等。主要公有雲中的 KPI 是如何制定的？ Availability定義為某個系統可以實際使用的時間。

可用性(Availability)應進行end to end測量。舉例來說，帶有OS的VM可以正常運行，但是如果在該VM和OS之上運行的一個Application component出現故障，則該應用程式將無法使用，因此終端用戶也無法使用。 VM 和OS已啟動（並且可用），但應用程式已關閉。這意味著整個系統是不可用的，這會產生一些嚴重的後果。這也意味著，如果我們想要獲得 99.9% 的應用程式的整體可用性，這意味著平台的可用性不能低於 99.9%。

在傳統的資料中心，我們需要實施特定的解決方案來保證可用性。我們必須確保網路、計算層和存儲系統能夠提供所需的可用性。 AWS、Azure 和 GCP 主要負責這一部分。但並不是說我們在這些平台上獲得了整體可用性保證，而是這些超大規模服務器（AWS、Azure 和 GCP）確實在其產品中的每個組件上提供了SLA。例如，GCP 中的單實例 VM 具有 99.5% 的保證連接性。請注意這裡的措辭：保證與 VM 的連接。此外，我們必須為連接到 VM 的所有disk使用regional disk，如果是multi zone可提高到99.99%。你可以通過在 GCP中拉高可用性．zones和regions可以來提高系統的可用性。zone是 GCP region中的獨立資料中心。總而言之，我們可以確保系統在 GCP中的全球某處的資料中始終是活著的，但這樣做需要付出很大的代價來實施諸如在 GCP 上使用負載平衡和流量管理器的解決方案。這會產生以下的一些問題：

業務需求(系統有重要到需要高可用度嗎？)
衍生的技術設計
業務案例，高可用度意味著運作該系統將會付出更多的費用

比較CSP之間的SLA並非易事。和很多服務一樣，基本概念都差不多，但還是有區別的。看看 Azure 和 AWS 在compute上詳細說明他們的SLA的方式。在 Azure 中，有 VM。在 AWS 中，該服務稱為 EC2。如果不滿足每月保證的instance正常運行時間，並且需要明確的是，系統基礎架構（機器本身！）不可用，則兩個CSP 都使用service credit。如果正常運行時間在一個月內下降到 99.99% 以下。客戶就會在下個月的計費周期內獲得打9折的費用。而GCP的可用性低於 99.5%才會計算折數。但無論如何每家CSP都不會賠償客戶該期間的營業損失．

在GCP中，所有的服務都是被定義成SLO(Service Level objective). 哪是因為 GCP採行的是 SRE文化．要把 SLA套用到GCP中，我們會遇到不同的名詞，像是SLI(service level indicators)與 error budgets. 關於這部分我們會在以後介紹到．

同樣，對SLA的要求應該來自企業的業務要求。對於每一個業務功能和對應的系統，需求應該是一清二楚。這最終推動了架構和系統設計。雲端平台提供了各種各樣的服務來組成該設計，從而滿足要求。用更強有力的術語來說，超大規模提供了擁有最終具有彈性的系統的可能性。在傳統資料中心中，災難恢復(DR)和業務連續(BCP)意味著公司必須至少有第二個資料中心，而雲端平台也將這種需求當作服務來提供。 Azure、AWS 和 GCP 是全球性的雲端平台，這意味著我們實際上可以在全球範圍內擁有可用的系統，而無需進行大量投資。CSP在全世界都有資料中心，隨時可以使用。 CSP 有本地解決方案來執行備份並將這些備份存儲在不同region的儲存庫中，或者他們提供來自他們網站內的第三方解決方案(稱為marketplace)，以便我們仍然可以使用我們想要用的產品。

但是，應該再次強調，業務應該定義他們的關鍵服務和系統是什麼，定義 RTO 和 RPO 的藥球。業務需求應定義 DR 指標，更重要的是，定義需要執行 DR 計劃時的流程。接下來，由 IT 來使用技術解決方案來滿足這些要求。我們是否會使用從主要region的生產系統完全對映的hot site？我們是否在使用第二個region，那麼應該使用哪個tegion？在這裡，合規性和國家法律（例如 GDPR）或世界其他地區的資料保護框架也發揮著重要作用。

一種可能的選擇是在另一個region部署備用系統，並在 DR 故障轉移的情況下將這些備用系統轉為生產系統。這意味著備用系統確實類似於生產系統。而我們必須多久備份一次系統？每週一次完整備份？我們會使用增量備份嗎？如果是，多久使用一次？備份資料的保留時間應該是多少？歸檔呢？這一切在雲端平台都相對容易執行，但在實施每個可用的解決方案時要格外小心，這是一個原因。這與傳統資料中心的前期投資無關（CapEX），但我們將每月為這些服務收費(OpEX)。

簡而言之，雲端需要一個計劃。這就是我們將在接下來的部分中討論的內容，最終創建一個服務設計。

用CAF在CSP之間對齊

多雲環境中的一個詞彙是“單一的控制面板“。這是什麼意思？想像一下，我們有一個多雲環境，其中包括運行 vmware 的私有雲、公有雲AWS，並且我們還有像 Saleforce 這樣的 SaaS 解決方案。我們如何追踪所有這些組件中發生的一切？ CSP 可能會處理很多事情，所以我們不必擔心，例如系統補丁和服務升級。在 SaaS 解決方案中，提供商真正負責整個平台系統，從實體機器一直到操作系統和軟體本身。然而，作為使用者(也就是使用的企業)，我們總會對某些事情負責。考慮諸如 IAM 和資安策略之類的問題。像是誰有權訪問什麼以及何時？

這是複雜性的全新現實：由各種解決方案和平台組成的多雲環境。我們該如何管理呢？管理員必須登入到所有這些不同的環境。他們可能會有不同的監控解決方案和工具來管理組件。這需要花很多工，而且首先需要很多不同的技能。這肯定不是很有效。我們想要一個單一的控制面板：一個項圈來管理它們。

上面這樣定義的問題在於它純粹是從技術角度來看的：只有一個系統可以看出我們 IT 環境中所有不同的技術組件。然而，單一的控制面板遠遠超出了單一的監控系統。它還涉及流程的統一甚至自動化的統一。為什麼後者如此重要？如果我們沒有一種明確的自動化方式，我們仍將面臨大量工作來自動化部署和管理該 IT 環境中不同組件上的資源組。因此，單一的控制面板更像是一種可以在下面圖形中可視化的方法：

是否存在用這一種方法的系統？是的，有完整的 ITSM，例如 ManagementEngine的ServiceDesk Plus和 ServiceNow 的Now platform。根據 Gartner 的 ITSM 系統魔術象限，當然還有更多的選擇，但這些被認為是市場領導者。

ITSM，這就是談論的內容。工具跟技術是一回事，但流程同樣重要。 ITSM至少包括以下流程：

Incident management: 追蹤與解決雲端平台或運行在平台上的資源的各類事件．
Problem Management:追蹤與解決不斷重複的事件
Change Management: 追蹤踪和控制對雲端平台或平台上託管資源的變更的實施
Configuration Management: 追蹤雲端平台以及上面運行的各項資源的狀態

ITSM 的核心是知識：我們必須對我們的平台是什麼樣子有無可爭議的洞察力。它是如何配置的，我們平台上存在哪些類型的數位資產，以及平台上部署了哪些資產和資源。資產和資源通常被稱為configuration items，它們都在 CMDB 或 MDR(Master Data Records) 中收集和追踪。在這裡，雲端中的挑戰才真正開始。憑藉可擴展、靈活的資源，甚至可能僅在我們的資產中存在很短時間的資產/資源，例如 container或serverless，我們面臨著 CMDB/MDR 永遠不會像我們希望的那樣準確的風險是，儘管大廠的 ITSM 系統在不同的雲端中為監控工具提供了原生 API，這些工具真正回應並幾乎即時收集資產資料。

雲端的敏捷性使變更管理可能成為多雲環境中最重要的流程。把基礎設施和配置變成代碼方式的pioeline。如果我們對代碼在主分支中的分叉、測試、驗證和合併有一個清晰的過程，那麼變更是完全可檢驗的。如果開發人員在此過程中跳過一個步驟，我們將走向失敗甚至更糟，因為不知道出了什麼問題。

所有雲端適用框架都強調雲端提供比技術還重要的治理和流程。所有框架都從企業業務風險概況進行治理。這是有道理的：如果我們在 IT 方面的工作方式不一致，最終，企業的業務就會面臨風險。基本上，服務管理的最終目標是減少因缺乏 IT 治理而產生的業務風險。 IT 治理和 ITSM 是技術提供商的通用語言，這個是有充分理由的。

回到我們的一個項圈管理所有平台的概念。我們有統一的流程，在定義 ITSM 中。 ITSM 有不同的框架（例如，ITIL 或 Cobit），但它們都具有相同的原則。現在我們可以在 ITSM(有一個單一的控制面板)，控制我們所有數位資產和資源的生命週期嗎？我們已經提到 ManagementEngine ServiceDesk Plus和 ServiceNow 作為技術工具。但是我們也可以通過這些平台實現自動化嗎？換句話說，我們能否擁有完全跨平台的自動化？這就是 Gartner 所說ＨHyperautomation。

今天，自動化通常是按雲端組件執行，或者在最好的情況下，按每個雲端平台執行。通過這樣做，我們並沒有達到自動化的最終目標，即減少一遍又一遍地執行的手動作業。就此而言我們並沒有減少人力，我們並沒有減少人為錯誤的風險。相反，我們通過在不同平台上將自動化劃分為不同的工具集來引入更多的作業和失敗的風險，所有這些工具集都具有單獨的工作流程、計劃和腳本。Hyperautomation可以解決這個問題。它使所有業務流程自動化，並將它們整合到一個自動化的生命週期中，並通過一個自動化平台進行管理。

Gartner 將此平台稱為 HDIM(Hybrid Digital Infrastructure Management)。機器學習式的RPA 和後續的 AIOps 是 HDIM 中的關鍵技術。Gartner 預計 AI 支援的自動化和 HDIM 將足夠先進，可以在 2023 年廣泛、大規模地採用。

總之，來自 AWS、Azure 和 GCP 的雲端適應框架都支持相同的原則。這是因為它們有共同且通用的 IT 服務管理語言。這有助於我們跨平台調整流程。我們面臨的一個挑戰是使用單一控制面板來控制各種雲端平台，並擁有跨雲平台的一個自動化來源 — — Hyperautomation。隨著雲端創新的速度，這變得越來越複雜，但我們將在未來幾年看到更多的工具和自動化引擎進入市場，包括 AIOps 的興起和採用。

理解雲端中的身份(Identities)與角色(roles)

雲端中的所有東西都有一個identity。我們需要對identity做兩件事：authenticate和authorize。對於authenticate，我們需要一個identity sotre。大多數企業都使用微軟的AD，其中 AD 成為存儲人類帳號和電腦帳號的地方。這裡不會講述AD的技術細節，但是在使用 AD 時我們應該了解一些事情。首先，AD 要有domain。我們可以在雲端平台中部署資源 — — VM 或其他服務，但如果該雲端平台不是我們公司 domain的一部分，它就沒什麼用。所以，關鍵之一是在我們的雲端平台的domain中獲取資源。為此，我們必須在我們的雲端平台中使用domain controller部署domain service或允許雲端資源訪問現有的domain service。這樣做我們才能將業務擴展到雲端平台。

以上這些用說的比做的容易。 AWS、Azure 和 GCP 是公有雲。亞馬遜、微軟和谷歌基本上都在向第三方(也就是他們的客戶)提供大型的雲端平台：在特定區塊上託管工作負載。但這些CSP還是對他們的平台服務擁有最後的控制權。這些雲端平台的primary doamin將是 aws.amazon.com 或 onmicrosoft.com：這是因為這些服務最終是面向Internet,而這樣做是有道理的．

如果我們想在這些平台上擁有自己的域名，我們需要通過已經註冊的域名附加到平台。例如，我們有一家名為 jasonkao.com 的公司。在 Azure 上，我們可以使用 jasonkao.onmicrosoft.com 指定的domain。現在我們在 Azure 上擁有了自己的domain。這也適用於 AWS 和 GCP。如果雲端平台上的domain連接到公司的domain，則部署在雲端domain中的資源現在可以加入domain。這個connection由domain controller來控制。下圖顯示了 AD Federation的high-level concept：

在 MS AD 中，我們的domain存在著有權限的所有資源和人員。通過確認完成的身份驗證：dientity在doamin中被識別或被拒絕。這個AD 使用 Kerbos 來驗證身份。重要的是所有 CSP 都支援 AD、 LDAP 標準和 Kerbos。

如果無法在Directory中識別資源或人員，則很容易無法access domain內的資源，除非我們明確授予他們訪問權限。當一個人在我們的 domain中沒有帳號，但需要訪問我們平台上的資源時，就會出現這種情況。我們可以使用企業對消費者的連接授予此人訪問權限。在 Azure 中，稱為 B2C，在 AWS 中稱為 Cognito，在 GCP 中稱為 Cloud Identity。

我們已經使用directory識別了一個人或一個資源，但現在我們必須確保這個資源只能做我們想要或允許它做的事情 — — 僅此而已。這就是我們所說的授權(autoorization)：當滿足某些條件時，我們指定資源可以做什麼。首先，我們真的想確保資源就是它聲稱的那個人。對於登入的人，建議使用多因素身份驗證。對於運算資源，我們將不得不使用另一種機制，並且通常基於用key的方式：識別資源的複雜、唯一的hash value。

我們已經在我們的環境中定義了identity，無論是人類身份還是系統身份。我們如何定義環境中允許的身份？為此，我們需要 RBAC(Role base access control)。 Azure中的RBAC、AWS與GCP的IAM 的RBAC 讓我們能夠管理對環境的訪問以及身份可以在環境中執行的操作。我們還可以對應用特定 RBAC 政策的身份進行分群。

從以上的敘述我們已經有了結論，所有主要CSP 都支援 AD 及其底層協議。因此，我們可以將我們的 AD 與這些不同雲端中的domain綁在一起來。在 Azure 中，最簡單的做法是將 AD 連接到 Azure AD。儘管這看起來像是類似的解決方案，但它們是完全不同的東西。 AD 是一個 real directory，而 Azure AD 只是一個在 Azure 中驗證身份的工具。它沒有 AD 這種具有的身份驗證機制，例如 Kerberos。 Azure AD 將使用 AD 進行身份驗證。這與其他平台與 AD 綁在一起的方式非常相似。在 AWS 和 GCP 中，我們都需要可以針對 AD 進行整合的identity。換句話說，我們的 AD 將始終是身份管理的唯一真實來源，唯一的identity store。

建立服務設計與治理模型

最後要做的是將前面的所有討論的部分組合成一個多雲環境的服務設計模型。那麼，服務設計的內容應該是什麼？看一下我們到目前為止討論的所有內容。我們需要一個涵蓋所有主題的設計：requirement、identity和access management、governance、cost和security。

需求(requirement)

這包括將有著許多雲端組件的服務目標(service target)。假設我們在公有雲中部署環境，我們應該將公有雲平台作為服務目標包括在內。 AWS， Azure與GCP分別分針他們的各項組件有著不同的SLA. 它們大部分沒有滿足企業在這些雲原生服務之上構建的平台服務。舉個例子，如果一個企業構建了一個包含前端、後端和資料庫的分層應用程式，並將其定義為一組對外的客戶平台，則需要將此企業的服務平台單獨視為一個服務目標，也就是SLA。

接下來，我們將列出服務目標必須解決的相關要求：

業務的連續性要求：這肯定與企業的關鍵業務服務相關。通常，這些在描述 RTO/RPO、備份策略、BCP(Business Continuity plan) 和 DR 措施的各部分可以解決。
合規要求：我們將需要公司受約束的合規框架。這些可以是與隱私權相關的框架，例如 GDPR，也可以是安全標準，例如 ISO 27001。需要記住，Microfost、AWS 和 Google 都是美國公司。在美國以外的某些行業部門（這通常適用於歐盟國家），只有在嚴格控制下才允許與美國供應商合作。這同樣適用於與中國供應商的協議，例如阿里雲。在我們公司開始在公有雲中部署服務或購買雲端服務之前，請務必諮詢法律顧問。
架構和接口(interface)要求：企業可能會有一個企業架構，描述公司如何生產商品或交付服務。當然，業務架構對於雲端部署來說是非常重要的input。它還將包含企業擁有的各種interface的清單，例如，與組件或第三方服務供應商的interface。這將包括公司整個生產或交付鏈中的接口 — — 供應商、HR、物流和財務報告。
維運要求：這裡必須涵蓋生命週期策略和維護時間。企業業務的一個重要要求是所謂的停電期，在此期間，對 IT 環境的所有變更都將停止。例如，在年終結束時或在生產週期預期達到峰值的情況下可能就是這種情況。生命週期包括與升級、更新、補丁相關的所有策略，並修復環境中的組件。
與連續性要求一樣，這都強烈依賴於底層的雲端平台：CSP 提供了多種工具、設置和策略，可應用於基礎架構以防止組件停機。負載均衡、核心服務和規劃不同機櫃、資料中心和甚至是region的組件都是防止環境因任何原因掛掉的可能對策。無論是計劃的非計劃的。當然，所有這些服務都需要花錢，因此企業必須定義哪些環境對業務至關重要，以便設置正確的組件保護等級和相關的維運要求。
安全和訪問要求：如前所述，雲平台都提供高度複雜的安全工具來保護部署在其平台上的資源，但安全策略和相關要求應該由使用雲環境的企業真正定義。這一切都始於誰可以訪問什麼、何時以及為什麼。必須為管理員帳戶實施合適的 RBAC 模型。

RAID(Risk, Assumptions, Issues與 Dependencies)

服務設計和治理模型應包含 RAID 紀錄。這個紀錄是要被維護的，使其永遠代表準確的狀態，為調整和適應其原則、策略以及應用的業務和技術架構提供input。

服務分解(Service decomposition)

下一部分是服務分解，也就是服務的產品分解。我們將在雲端環境中使用什麼？

資料組件：使用哪種雲端技術存儲哪些資料、存儲在何處以及以何種格式存儲？ SQL 和 NOSQL 資料庫、資料湖、檔案、queue，還有各自的雲端存儲解決方案，比如以object storage來說， Azure Blob, AWS S3, GCP Cloud Storage。
應用程式組件：雲端環境中支援哪些應用程式，這些應用程式是如何構建和配置的？這定義了我們需要加入哪些服務，並確保至少在關鍵業務系統和非關鍵系統之間有一個明確的定義。一個好的方法是將系統分類，例如，分為L1、L2和L3，L1表示關鍵業務系統，L2表示其他重要的生產和測試系統，L3表示開發系統。
但是，在對系統進行分類時要小心。就財務面而言，開發系統可能至關重要。試想一下，有幾十名工程師在交付和開發系統的時間壓力下開發特定系統。如果開發環境不能使用這肯定會導致交付延遲，幾十名工程師發呆在位置上，人力資源就有浪費的嫌疑。我們怎麼強調商業案例的重要性都不為過。
基礎建設組件：VM, load balancer, network appliances, firewall, database等這一些．這一些都需要被記錄在我們的CMDB或是MDR.
雲原生組件： PaaS服務，containerc還有serverless. 列出雲端組建的管理方式：用 Web GUI, CLI 或是 code interface，如Terraform.
安全組件：安全性應該在所有層面上都是應有的。需要保護 data in trainst 與 data at rest，需要保護應用程式免受未經授權的訪問，應該加強基礎設施，並且應該對所有資源啟用監控和告警。

通常，備份和回復也是安全組件的一部分。備份和回復是與保護 IT 資產相關的元素，但最終通過防止資料丟失和系統毀損來保護企業的業務。隨後，對於關鍵業務功能、應用程式和系統，應確定 BCDR 計劃。從 BCDR 計劃中，RPO/RTO 和備份保留時間方面的要求被導出為這些關鍵系統的架構和設計的input。

正如我們所說，我們一直遵循 TOGAF的 ADM(Architecture Development Method) 週期：業務需求、資料、應用程式和最新技術。安全性是所有層次的一部分。

角色與義務

服務設計中的這一部分定義了誰在不同的服務組件中可以做什麼、定義角色以及什麼身份在具有特定角色時可以執行的任務。以下介紹兩種模型。

治理模型(Governance model)

這個模型定義了參與定義服務需求、設計服務、交付服務和控制服務的實體。它還包括回報層級和事件升級。通常，模型中的第一層是設置需求的業務，下一層是構成網絡企業架構，負責連接業務和 IT，第三層是 IT 交付組織。所有這些層面都通過稽核作為風險和變更控制的輸入來控制：

這是一個非常簡單、直接的治理模型展示。它可以有很多變化。一方面，IT 交付通常在敏捷團隊中完成，根據 DevOps 原則工作。主要原則保持不變，即使對於敏捷團隊也是如此。即使是敏捷團隊也需要受到控制並在變更管理的定義下工作。這裡只有一個重點：不要使模型過於複雜，盡可能簡單。

支援模型(Support model)

支援模型描述了誰在各個組件上提供支援，也就是各組件的專家。這只是一個內部 IT 維運部門，還是我們需要來自第三方廠商的支援(因為雲端的組件太多)？就此而言，企業很可能需要第三方廠商與CSP的支援。支援模型還定義了需要提供何種程度的支援。在某些情況下，可以選擇與CSP的主題專家進行討論，但是當公司將其雲端維運外包時，必須提供全面的支援。

支援模型中需要涵蓋的一個重要主題是企業在雲端平台上進行業務所需的專業知識水平。正如我們在運用多雲策略加速企業的業務文章中已經注意到的那樣，由於人們對 IT 的看法發生了巨大變化，因此再次將 IT 維運由企業自行運作的趨勢非常強烈。對於幾乎每家公司來說，IT 已經成為一項核心活動，而不僅僅是一個業務促進者(或是成本中心)。由於越來越多的企業在雲端中部署服務，他們也在建立自己的雲端卓越中心(CoE)，但需要CSP的主題專業知識和支援。

如果我們按照完整週期追踪所有階段，那麼我們最終將得到一個服務目錄(service catalogue)，準確描述範圍內的服務、交付方式以及支持這些服務的人員(不論內部或外部)。

流程

這裡定義了哪些流程已到位以及如何管理這些流程。應列出並描述所有涉及的過程：

Incident management(事件管理)
Problem Management(問題管理)
Change management(變更管理)
Asses management(資產管理)與 CMDB(或MDR)
Configuration Management(組態管理)
Reporting(報告)
Knowledge base(知識庫)

這些是 ITSM 中使用的標準流程。對於雲端環境，強烈建議將自動化過程作為一個單獨的主題。在我們日常維運的 DevOps 世界中，我們應該將所有代碼和腳本存儲在一個central repo中。知識庫可以存儲在這個repo的維基業面中。受到控制的代碼庫和知識庫的 DevOps pipeline必須整合到 ITSM 流程和 ITSM 工具中。請記住：我們希望對整個環境有一個單一的控制面板。

我們還沒有觸及一個重要的流程，那就是request和request fulfilment。 Request從業務需求開始。該流程的下一步是分析需求並執行業務風險評估，確定業務功能的關鍵性並將其對應到所需資料。接下來，將request對應到業務策略和資安baseline。這個設置了如何開發和部署 IT 組件的參數，同時考慮到 RBAC 的實施和資源根據服務分解中描述的服務部署的事實。該過程可以定義為request fulfilment。

如果特定資源需要不同的服務，那就是對服務目錄的更改。

成本

這裡介紹成本類型，以及如何監控和評估這些成本。它包含的模型清楚地描述了成本在企業業務中的分配方式，即所謂的chargeback。Chargeback通常基於公有雲中的訂閱模型、RBAC 設計以及已部署到資源的命名和標籤標準。應定期評估成本，隨後企業應在成本方面有明確的控制權。需要設置預算並實施成本告警並在需要時設定 IT 支出限制。我們將以美國運通為案例，公司信用卡可以被簡單的拿取，到最後，沒有人知道誰在雲端中消費了什麼 — — 或者出於什麼原因。我們可能不會是第一家在不知情的情況下運行 Hadoop cluster的公司。

就VM或網路的費用而言，公有雲中的成本不僅僅是每個部署資源的成本。資料的ingress和egress也在各個層面收費：網路連接、firewall throughput和資料庫。其實很多東西都是收費的。這完全取決於我們部署的解決方案的類型，正如俗話所說，條條大路通羅馬。想怎麼做都行，但錢花多花少的問題。

真正必須包括的一件事是軟體授權費。很明顯，很多軟體都是商業版本的。但是公有雲為軟體授權帶來了一個額外的維度：可擴展性(scability)。軟體也可以是用租的或帶自己的。公有雲提供了各種軟體授權模式，例如企業協議、高級協議或通過經銷商的協議，但所有這些都有不同的條件。

安全性

我們提到幾次：安全是內含的。意思是，安全是多雲環境中每一層的一部分，從業務到企業架構，再到平台的實際部署和管理，並嵌入到每一個服務和服務組件中。

這裡介紹包含使用不同雲端解決方案的業務風險評估以及如何降低這些風險。這是通過企業必須遵守的業務安全框架與CSP已整合到他們的雲端產品標準中的安全框架之間的gap analysis來完成的。好消息是主要的雲端平台支援大多數產業安全框架，但企業有責任在稽核時證明這一點。因此，這裡還描述了如何稽核環境（內部/外部），以何種頻率、流程來減輕稽核結果的過程。這些緩解措施必須遵循變更流程，以便記錄變更本身、適用的解決方案以及可能對服務目錄的變更。

總結

在本文中，我們探討了雲端適應框架的主要基石，並且我們了解到不同的框架有相當多的重疊。我們已經確定了雲端適應的七個階段，直到我們可以真正開始將應用程式遷移和轉換到我們的雲端平台。在多雲環境中，控制和管理具有挑戰性。它需要一個單一控制面板，但是，正如我們也了解到的那樣，只有少數工具 — — 一個統治所有它們的項圈 — — 可以滿足這單一控制面板的需求。要了解的最重要的事情之一是，我們首先必須查看我們環境中的identity：如果我們談論我們平台上的其他資源，誰或什麼被允許做什麼、何時以及為什麼？這是制定治理模式的關鍵。治理模型是服務設計的基礎。在本文的最後一段中，我們討論了此類服務設計中的不同部分。當然，這一切都從架構開始，我們將在其他文章討論：架構的創建和管理。