轉載/資料來源：https://jason-kao-blog.medium.com/%E4%BC%81%E6%A5%AD%E7%9A%84%E9%9B%B2%E7%AB%AF%E6%9C%8D%E5%8B%99%E6%8E%A1%E8%B3%BC-5ef051cda5b0
企業購買和使用雲端服務跟傳統的IT軟硬體一樣都應該有一個生命週期流程，在這個生命週期流程中企業選擇雲端服務並檢視它們的使用，也跟傳統的IT軟硬體一樣以此作為更新或更換它們的基礎。本文將討論，企業如何評估、選擇、使用後再評估的整個雲端服務的週期流程。
雲端服務生命週期(取自Open Group)
生命週期的起點是企業的系統功能需求 + 企業正在開發的解決方案的一組模型。
確定匹配(Determine Fit)階段，企業評估正在考量中的雲端服務與功能需求和解決方案模型的匹配程度。 這為企業提供了對這些服務的第一次篩選。 它還為企業提供了一些額外的解決方案需求。
建立需求(Establish Requirements)階段，企業會有初始需求，並建立企業的候選服務應滿足的完整需求。
選擇(Select)階段，企業選擇雲端服務並就合約達成一致。 選擇的服務取決於哪些服務最能滿足要求、它們的成本以及它們的合約內容。
監控(Monitor)階段，企業會觀察正在運行的服務效能，以了解它與承諾或假設的效能相比是怎麼樣的。 開始使用的模型和之前設立的需求構成了這個比較的基礎。
當企業續訂服務或選擇備選方案時，此階段的結果和更新的模型構成了採購生命週期循環的下一次迭代起點。
企業在設立雲端願景時，應該已經了解了自身的業務環境，並對雲端適用性進行了評估。 此時企業應該清楚雲端服務是否將成為解決方案的一部分以及要考慮哪種雲端服務。 下一階段是查看這些服務是否符合企業的功能需求和解決方案模型。
對於 IaaS 或 PaaS，功能需求只是基礎設施或平台； 除非企業需要特殊功能 — — 在這種情況下企業可能不應該考慮雲端解決方案 。 對於 SaaS，企業必須確定存在滿足企業的應用程式處理需求的雲端服務。 對於各種雲端服務，企業需評估是否適合解決方案模型。
為解決方案開發模型需要時間和作業，它無法一蹴可及。 企業架構師和 IT 團隊應該合作開發模型。 企業架構師可能會在這方面發揮帶頭作用。 在企業的高層對模型感到滿意之前，需要使用不同版本的模型進行多次迭代。
選擇和監控雲端服務的重要模型是
財務模型
工作負載模型
風險模型
工作負載模型和財務成本模型與雲端服務採購的生命週期密切相關。我們會介紹工作負載模型和財務成本模型，以及如何使用它們和其他模型來確定是否合適。
工作負載模型至關重要。 它使企業能夠估算雲端服務成本。 它還使企業能夠確定吞吐量(throughput)和配置速度要求。
該模型以業務術語描述了雲端服務必須處理的流量，以及它如何隨著用戶數量和時間的推移而變化。 它還用技術術語描述了用於執行此處理的資源，並顯示了所用資源與處理負載的關係。
沒有標準的工作負載模型。 對於每個企業以及企業使用的每項服務，它都是不同的。
企業可以根據工作負載模型中的資源使用情況估算服務成本。 不幸的是，每個雲端服務供應商(以下簡稱CSP)的計算都不同，因為每個CSP以不同的方式打包他們的資源。 對於運算資源尤其如此； 每個CSP提供（和收費）的運算單元可能不同，並且很難將這些單元相互關聯起來。 但是，如果企業想比較不同的產品，則必須這樣做。 這意味著企業需要每個CSP的成本模型。
最好注意模型對不同因素變化的敏感程度。 例如，存儲成本可能比 I/O 成本更容易預測。 而這些資訊將幫助企業評估風險。
在為工作負載建模時，企業應該考慮可變性和可預測性，以及平均或“穩定狀態”值。
例如，平均水準可能是每秒 200 筆交易和每天 500,0000 筆交易，根據一天中的不同時間，每秒可能有零到 20 筆交易。
計劃和排程是可預測性的，我們應該注意它的周期性。 這是需求的周期，包括平均時間、高峰時間和非作業時間。 週期可以基於日曆（包括每小時、每天、每週、每月、每季度和每年），也可以基於事件。
我們還應該考慮具有可預測容量的事件，這些事件不會在每個月或每年的同一時間發生。 例如自然災害、火災等災難。
回想一下典型穩定狀態使用的成長或收縮，包括以下內容：
每個穩定狀態的年度合約開始時產能的增加或減少
一次性變更
收購、資產分離、監管變化和新市場
按類型考慮企業中使用者的平均和峰值數量。 使用者類型包括業務使用者、“高階長官”和流程管理員。
不同類型的工作負載存在不同的擴展方式。 在為工作負載建模時必須考慮到這一點。
具有大量共享記憶體、許多inter-dependent threads,和tightly-coupled interconnections的應用程式不能輕易地在運算單元之間進行分區，只能垂直擴展。 具有不共享記憶體且具有loosely-coupled interconnections的independent threads的應用程式可以進行分區和水平擴展。 其他應用程式在某種程度上可以雙向擴展。
取自Open Group官網
下圖呈現了不同類型的一些範例
取自Open Group官網
工作負載分配應遵循以下原則：
集中關鍵服務以最大程度地集中可用的總容量
部署基於標準模組化建構區塊的解決方案，以實現最大的靈活性和重複使用的潛力
自動配置標準image以獲得最大的敏捷性
在適當的情況下，使用虛擬化從基礎架構中提取工作負載
確定可以從將短期突發負載轉移到雲端服務中的工作負載
短期突發使用的雲端成本通常較低，但對於穩定或變化不大的工作負載，放在自家機房可能比長期使用雲端服務更便宜。
有一些定價選項可以使雲端在某些長期使用中具有吸引力。Reserve instances — — 簽訂長期合約的雲端資源，通常價格低於On-Demand的雲端資源 — — 降低了長期使用的成本。 突發服務使高峰運營需求能夠轉移到雲端容量。
企業應根據實際工作負載配置文件與容量使用情況來評估其需求使用模型。 許多運營工作負載不是 24x7x52 的，可以通過 reserve instances和 spot instance或“cloudburst”的組合來滿足。 下圖說明了這一點。 （注意，假設混合雲的 OpEx 為 30%，地端機房為 25%。在地端機房解決方案中，OpEx 可能佔年度成本的 25%，其中 75% 是利息和折舊 — — 這是CapEx的特色。 混合雲解決方案的 CapEx 比例較低，OpEx 比例較高，因為它具有公有雲元素。這些數字說明了可能遇到的情況。）
變動的工作負載成本(取自Open Group官網)
固定的工作負載成本(取自Open Group官網)
使用 IaaS 和 PaaS，企業可以擁有一個混合系統，一些處理在地端機房，一些在雲端。 (但這無法用在 SaaS)挑戰在於定義可變工作負載並能夠打開和關閉雲端容量以及在地端機房之間做切換。 需要評估與此相關的成本才能把“雲端服務隨選即用”。
如果企業使用的是 SaaS(如M365，Saleforce)，並且費用與業務單位(如帳號數量)而不是運算資源(如CPU/Memory)有關，則無需將資源構建到企業的模型中。 通過將業務單位對映到CSP的收費單位，企業可以為每個CSP建立一個成本模型。 這個模型使企業能夠確定特定工作負載的可能成本。
對於 PaaS 和 IaaS，或者對於 SaaS，如果CSP是按運算資源而不是帳號數量收費，企業應該對運算能力、記憶體、存儲和 I/O 的使用進行建模。 這些是大多數CSP計價方式。
思考以下事項:
峰值的資源 — — 企業要求CSP能夠提供的資源能力。對於公有雲的資源，幾乎可以符合所有台灣中小企的需求。
每個時間區段的使用量 — — 這是企業需要支付的費用
資源變化率 — — 它決定了企業對於啟用/關閉雲端資源速度的要求
嘗試用標準術語表達以上這些事項，企業可以對映到可能會使用的CSP的資源使用單位。 可能有可用的基準資料。 這是一個困難的領域，需要專業的技術專長，FinOps專門處理這一類的問題。
將企業的資源使用單位對映到CSP的資源使用單位將為企業提供所需的成本模型。
在依靠模型做出重大決策之前驗證模型是必要的。 企業可以開發自己的基準測試程序，並使用企業正在考量的每項雲端服務使用測試資料測試它。 雲端運算的優勢之一是on-demand self-service可以很容易的做到這一點(假設企業內部已有雲端專家)。
A公司開發了一個簡單的工作負載模型。 負載由產品數量、客戶數量和訂單數量來衡量。 所需的運算能力、記憶體、存儲和 I/O 是根據這些因素通過簡單的代數公式計算得出的。絕大多數的台灣公司都沒有這一類的歷史資料，也沒有過這一類的經驗。對公司的IT單位來說，一開始可能很困難。
該公司根據經驗對一年中每個月的一般、最大和最小負載進行了估算。 將這些輸入模型可以估算所需的運算資源，包括任何時候的最大值和一年的預期總量。
負載變化很大，但可以至少提前一天以合理的準確性預測所需資源。 雲端架構師計劃每天會有兩次最大容量需求，並設定能夠在一小時內供應新資源。 他們相信這將滿足需求，並且認為沒有必要對變化率進行建模，因為使用公有雲的AutoScaling的功能。
建模者基於現有的內部系統以“伺服器資源”為單位呈現運算資源。 他們基於他們的模型開發了一個簡單的基準程序，並在內部系統上對其進行了校準。 然後他們在一些可能選擇的CSP中的 IaaS 測試它們，以驗證模型並確定服務的資源單元如何與他們的相關。 這為他們提供了針對每個 IaaS CSP的經過驗證的成本模型。
最終結果是他們可以計算出每個CSP的預期年度資源成本，從而提供公司做出CSP選擇所需的重要資訊。
B公司IT單位制定了一個不同的模型。 根據存在的微服務的數量和它們處於活動狀態的比例來衡量負載。 同樣，所需的運算能力、記憶體、存儲和 I/O 是根據這些因素簡單計算的。 據估計，每個微服務始終需要 10M的硬碟存儲空間，並且需要 0.1 個CPU、100 M的記憶體，並且在其處於活動狀態時平均每秒傳輸 25 個 2 byte的資料。
IT單位不知道公司將使用多少個微服務，或者它們的活躍時間比例。 出於選擇CSP的目的，IT單位決定假設 100,000 個微服務在平均 5% 的時間和 20% 的峰值時間處於活動狀態，給出最多 2,000 個和平均 500 個CPU，以及記憶體、存儲和 I/O 的相應數字。
可預測性是有計劃內的，也有計劃外的。 IT單位預計工作負載會在白天動態變化，出現突然的、意想不到的高峰。 系統將根據實際和預期需求自動提供資源。 IT單位設定了一個要求，即能夠在兩分鐘內配置或取消配置新的運算單元和記憶體，並且系統將配置處理器和記憶體，使其超出所需容量的 10%，以應對意外激增。
IT單位在一個簡單的電子表格中製作出模型(如下)。
該模型以一個特定的CSP使用的單位呈現運算資源。 IT單位在該CSP的資源上部署了Beta版本軟體以驗證模型，並在其他CSP的資源上進行比較。IT單位將用來比較CSP的模型得出的衡量標準是每月每個微服務的成本。
為所考量的每項雲端服務建立成本模型後，企業可以確定在解決方案中使用它的預期成本，並將此成本放入到到整體財務模型中。 企業還應該使用風險模型來評估解決方案的風險狀況，我們將有專篇文章來說明雲端運算的風險。
這些財務和風險評估可能會導致不使用某些雲端服務。 實際上，企業可能會不使用所有雲端服務，並得出結論認為雲端運算不是企業要解決當前問題的答案。
但是，如果企業對雲端的適用性進行了全面評估，那麼在此階段企業可能會有一些考慮中的雲端服務。 企業其實已確定合適性，並著手確定企業的需求。
需求是解決方案必須或應該滿足的條件。 它們可以分為強制性(必須要有的)和選用(應該要有的)。 當企業選擇一項雲端服務時，企業也同時拒絕那些不符合強制性要求的雲端服務，並優先考量那些滿足選用性需求的服務。 當企業監控正在使用的雲端服務時，企業會檢查它是否真的滿足強制性需求，以及它在多大程度上滿足選用的需求。工作負載模型和成本模型可用於確定性需求，並可幫助企業表達需求，但它們本身並不是需求。
企業可能有與一般IT服務的使用和管理相關的要求，而不是專門針對雲端服務的要求。 這方面的標準實踐描述可從許多來源獲得，例如ITIL。 在建立完整的要求清單時，企業可能希望參考這些要求清單之一。
企業需要描述功能、IT供應商選擇、效能、可管理性、安全性和法遵性的要求。 下表中總結了本節中描述的這些領域的要求。根據企業考量的是 IaaS、PaaS 還是 SaaS，不同的需求領域可能具有更大或更小的重要性。
這些是系統應該做什麼的要求。 在確定雲端解決方案的適用性時，它們被視為整體解決方案需求，如確定匹配階段中所述，然後它們直接轉化為對雲端服務的需求，雲端服務將成為該解決方案的基礎。
IaaS 讓使用者(一般企業)能夠配置運算、存儲、網路和其他基礎運算資源。 企業應該考慮需要哪些資源。 尤其是，應該考慮企業將使用什麼作業系統，以及CSP是否有提供這些作業系統。
A公司需要 UNIX(或 Linux)來運行他們的應用程式，並希望將其作為雲端服務的一部分，而不是BYOL(bring your own license)。 他們注意到這是一項要求。
PaaS 讓使用者能夠部署使用CSP支援的開發語言和工具建立的應用程式。 企業應該指定應用程式將在其中運行的環境，以及它們將在其中建立的環境。
一種可能是大部分開發都是在地端機房上完成的，代碼只是上傳到雲端服務進行整成、最終測試和部署。 這節省了成本，並且可以顯著加快開發和單元測試的速度。 企業應該考量這一點，並在適當的情況下為它指定需求。
B公司正在用 Java 開發他們的微服務。 它們需要 Java 開發環境和 Java 運行時環境。 他們計劃使用 Eclipse [ECLIPSE] 開源軟體開發環境在地端機房上進行大部分開發，並將此功能作為一項要求。
定期備份可以在系統出現故障時恢復資料。 當企業希望糾正他們所犯的錯誤時，它們也很有用，例如誤刪除資料。
CSP可能會負責備份資料。 事實上，地端機房的參與是不可避免的，例如，當使用磁帶備份時。 企業大都會指定recoverability objectives(之後會提到)而不是特定的備份模式。企業應該指定該服務必須具備的功能，才能進行這些備份並從中恢復資料。應注意備份和恢復不會中斷正常作業。
A公司計劃進行每日備份，以使其內部系統與當前做法相匹配。 它指定了他們的CSP執行此操作並將備份副本保存在安全存儲中的要求。
每秒 10 MB在當今的互聯網上是一個最最基本的傳輸速率。 但是現代企業要移動的資料可能都比10M多得多，尤其現今處於大數據時代。 所幸，現今的公有雲CSP絕大部分都沒有頻寬問題。
企業可能需要在正常業務過程中傳輸大量資料。 作為轉換CSP政策的一部分，如果企業轉向另一家CSP，企業還應該考慮轉移所有資料的必要性。
一些CSP提供大量資料傳輸設施； 例如，AWS的Snowmobile服務。企業應該考慮可能的大量資料傳輸需求，並指定使它們可行的設施。
需求會讓企業在必要時轉向其他類似的供應商，這將使企業擁有可行的退出策略。 這一點的重要性在會在選擇(Select)階段進行了討論。 它會大大增強企業在與CSP談判中的實力(前提是你的企業要夠大)。
在 TCP/IP 之上，雲端運算使用已建立的標準 Web 和 Web service 資料格式和協定。 雲端 PaaS 產品所基於的API介面標準同樣已經確立。
在配置和管理方面情況有所不同，CSP之間的配置和管理可能存在很大差異，即使對於 IaaS 也是如此。 標準不太可能使企業對其所有CSP擁有單一的管理制度(雖然有第三方供應商努力解決這個問題)，但它們至少應該使從一個CSP轉移到另一個CSP變得更容易。 然而，目前這是學術性的。 統一的雲端服務配置和管理標準目前還不存在。 有幾個產業機構致力於它們，包括Distributed Management Task Force[DMTF]、Open Grid Forum [OGF] 和Storage Networking Industry Association [SNIA]。
可用性或正常運行時間是系統可用時間的比例。 它通常用 9 的數量來描述。 一個“五個 9”的系統在 99.999% 的時間裡都是正常運行的 — — 每年停機時間略多於五分鐘。 但如果是計畫性的維護則排除在外。
可用性很重要。 99.9% 的正常運行時間意味著每月有 42 分鐘的停機時間，在此期間企業無法為客戶提供服務，但企業可以事先轉移到其他的運算資源。
Uptime Institute [UPTIME] 為資料中心定義了一組廣泛使用的標準可用性等級，範圍從第 4 層的 99.999% 到第 1 層的 97.6% 可用性（每年將近 9 天的停機時間）。 這些等級可以作為雲端服務可用性的衡量標準。 現今，絕大部分的CSP都可以提供三個9等級以上的可用性水準，如果企業的雲端架構師設計得當5個久的可用性也是可能的。
在電子元件產業，可修復元件的可靠性呈現為兩個參數的組合：MTBF(Mean Time Between Failures)和MTTR(Mean Time To Repair)。 對於不可修復的組件，則是MTTF( Mean Time To Fail)。 以此類推，MTBF 和 MTTR 是被用作衡量雲端服務可靠性的指標。
平均可用性、MTBF 和 MTTR 之間存在簡單的代數關係 [平均可用性 = MTBF/(MTBF + MTTR)]。 企業可能不會指定可靠性和可用性。 如果兩個可靠性因素中的一個對企業來說比另一個更重要，企業可以指定可靠性而不是可用性。
MTBF 和 MTTR 是平均數。 它們可用作預期服務品質的指標，但在 SLA 的整體脈絡中則是沒有用的。 假設某項服務的 MTTR 為 30 分鐘，而企業實際上是一個小時的中斷時間。 CSP是否違反了協議，或者企業是否不幸遭受了特別長時間的停電，而其他時間的平均停電時間較短？ 在 SLA 中，企業應該尋找在一段時間內保證的最大中斷次數和最大中斷長度，並且類似地尋找任何月份或年份的保證正常運行時間。 這些數字當然不會像服務的平均值那麼好。
A公司認為，其客戶會接受故障，將其視為正常互聯網體驗的一部分，但如果系統長時間停機，客戶會很不爽，並可能跳槽到別家。 因此，它賦予 MTTR 高於 MTBF 的優先等級，並指定了最大中斷時間。
大部分的CSP 會在其中一個雲端資源出現故障時將客戶重新分配到另一個資源，但大都是在同一個Region機房。 它的優先等級是 MTBF 而不是 MTTR，它指定了每年的最大故障次數。
可恢復性是從故障中恢復的能力。 它是根據RTO(Recovery Time Objective)和RPO(Recovery Point Objective)來衡量的。 RTO 確定系統需要多快才能完全上線； RPO 決定了可以容忍多少資料遺失。
RTO 和 RPO 通常用於災難性故障的情況，在這種情況下可能會丟失大量資料（例如，整個資料庫的內容），而不是暫時性故障（例如，作業系統崩潰） 只有少數記錄可能會遺失。 這些情況應該加以區分； 他們需要不同種類的恢復策略。
RTO 被指定為一個時間區段，包括從備份副本恢復資料所花費的時間。
RPO 可以根據可以丟失的資料小時數來指定。 在某些應用程式中，例如金融交易，這通常為零 — — 但滿足這樣的需求可能代價高昂。
回應時間是系統回應輸入所花費的時間。 它可以指定為允許變化的平均值； 例如，“平均 200 毫秒，不超過 1% 的回應超過 800 毫秒”。 或者，可以給出最大數字； 例如，“不到一秒”。
在考量整個系統時，不同的回應時間可能適用於不同類型的交互。 例如：
3秒內顯示的產品網頁
1 秒內完成線上交易購買
回應終端用戶的時間是最重要的回應時間數字。 不幸的是，企業永遠無法將這個標準給CSP，因為它總是包含CSP無法控制的因素。 在所有情況下，雲端機房和終端用戶之間都存在網路延遲，CSP只能提供CDN這種web加速服務。 對於 IaaS 和 PaaS，會導致延遲的因素也有可能是企業開發的程式效能不好。
企業可以要求的最多是雲端機房本身內的運算和網路延遲。 這些數字通常都很低； 一些CSP使用 1 毫秒數量級的數字。 相比之下，對於終端用戶和雲端服務之間通過互聯網交換資訊（這是大多數終端使用者關心的），企業可以利用第三方解決方案來觀察與解決此類的問題。
部分往返延遲可能是由於CSP回應緩慢所致，這通常是CSP本身的服務出了問題。 雲端服務回應應該與非雲端服務中的回應具有廣泛的相比性。 然而，更高的系統利用率通常意味著更慢的回應，因此企業應該預料到一個高使用率的雲端服務的回應會比企業的地端機房的一個未充分利用的系統慢。
此外，由於虛擬化，有時還會有額外的延遲。 例如，某些資源池排程的特殊後果可能是雲端系統上的一個問題 — — 稱為“cold start”。 當某個虛擬機在一段時間內未被使用時，它會從其真實處理器中移除，以便為其他處理器騰出空間。 下次需要時，必須重新加載。 因此，不經常運行的應用程式可能必須每次都重新加載，以致終端用戶感到的回應確實很差。 這對所有應用程序的平均回應時間（這可能是CSP將引用的數字）影響不大，但對一個特定應用程序（可能是對企業很重要的應用程序）有很大影響。
我們的經驗是，在指定回應時間的要求時，最好了解CSP的架構以及企業自己的軟體的運作方式。
A公司沒有不尋常的響應時間要求，並相信其應用軟體將在雲端服務中運行，其回應時間與在地端機房運行時的回應時間相似。 它沒有為其將使用的雲端服務指定特定的回應時間要求。 [其高階管理團隊大吃一驚 — — 我們將在衡量和追踪雲端運算的投資回報率討論。]
吞吐量是電腦在特定區段時間內可以完成的工作量。 對於交易處理系統，它通常以每秒交易數來衡量。 對於處理大量資料的系統，例如影音伺服器，它以資料速率（例如每秒MB）來衡量。 Web 伺服器吞吐量通常呈現為支援的終端使用者數量 — — 儘管這顯然取決於使用者活動的水準，而這很難一致地衡量。
每筆交易的規模可能很重要。 一個每秒可以處理 100 筆交易的系統，每個交易使用 1 MB的記憶體，如果每個交易使用 1 MB，則可能無法每秒處理 100筆交易。 其他因素也可能很重要。TPC(The Transaction Processing Performance Council) 定義了幾種不同類型的交易，具有不同的特徵，用於基準測試。峰值和平均吞吐量的要求應源自工作負載模型，如之前提及的建模資源和成本中所述。
On-demand self-service是雲端運算的一個基本特徵。 使用者無需與CSP的員工溝通即可提供功能。 但是為此提供的功能因CSP而異。 企業應該考慮需要哪些功能，並將它們指定為是需求。 這些可能包括：
使用軟體而不是手動完成配置和啟用資源的能力
配置和取消配置資源的速度
指定特定資源組合的能力
能夠對使用的資源量設置限制
多租戶分區和隔離的可見性和可控性
例如，B公司需要在軟體控制下快速啟用和取消雲端資源，而A公司可以接受較慢的啟用/取消雲端資源，並且可以手動完成。
有關雲端系統使用情況和效能的報告必須為企業的目的提供足夠的資訊。 計費資源使用情況的報告是正常的，並構成計費的基礎。 但是，企業可能需要顯示其他資訊。 例如，企業可能想知道已部署的虛擬機的 CPU 和memory利用率。 例如，B公司就是這種情況，其系統使用這些資訊來調整微服務到CPU的分配。 企業可能對這些報告的時效性也有要求。 A公司希望在第二天早上 9:00 之前提供每天的使用情況報告。 最後，企業可能希望報告採用特定格式，或者採用適合機器處理的格式。 A公司希望它們清晰易讀。 B公司希望它們以機器可讀的 XML 形式存在，以便進行資料分析。
診斷和糾正雲端服務中的錯誤將是CSP的責任。 企業應該需要足夠的程序來報告故障並檢查在修復故障方面取得的進展。 企業需要有CSP的call center來支援這件事。
如果只用雲端服務替換傳統 IT 架構的組件的情況下，如 A公司的情況，終端使用者存取控制要求與傳統架構的要求類似。 但是，在利用雲端運算提供分佈式協作環境的地方，一大堆新問題開始產生。
如果 A公司開始超越其最初的概念，並考慮與其CSP之間的協作，它將面臨其中的一些問題。 供應鍊需要什麼等級的協作？ 哪些資訊和服務必須協作和共享？
一旦做出決定，就必須解決如何識別會使用該系統的人員，以及如何確保這些人員可以存取資料，並且只能存取他們應該能夠存取的資料的問題。 傳統的方法是為每個人分配一個 ID 和password，但這種方法的局限性已經慛在了很長時間，而federated identity and access control的新範例則已是雲端服務的標準。
為雲端服務選擇合適的身份和存取控制機制仍然是一個挑戰。 能夠適應它的企業將要求支援適當的協定。 對於 SaaS，這意味著要求服務支援協定。 對於 PaaS，這意味著要求平台使企業能夠構建和部署支持協議的應用程式。 對於 IaaS，這意味著找到一個標準平台來執行此操作並將在 IaaS 基礎架構上運行。
B公司已經面臨這些問題。 它的微服務代表其所有者存取第三方應用程式。 B公司打算使用 OAuth 協定進行授權，並將對 OAuth 的支援作為其正在尋找的 PaaS 服務的要求。
系統管理員和其他具有特殊權限的員工存取特殊資訊的能力，即使他們沒業務上理由這樣做，但長期以來這一直是一個問題。而雲端運算賦予它一個新的維度。 內部系統管理員是一名員工，受公司檢查和紀律約束。 公有雲系統管理員則為CSP的員工，並且在企業無法看到這些管理員在做什麼。
這是CSP認識到的一個問題，其中一些CSP已經制定了機制來控制其員工對客戶資訊的存取權限。
如果企業的資料安全對企業很重要，企業應該將CSP存取控制作為一項要求，並堅持將其作為合約的條件。
公有雲上的資源池的一個含義是，企業的應用程式和資料可能正在與其他CSP客戶編寫和部署的程序共享資源。 該應用程式可能與企業的程序在相同的物理 CPU 上運行，並共享相同的記憶體。
當然，CSP確實有確保程序安全分區的機制，例如企業可以指定專用的機器(但這樣費用就會提高許多)。 但是企業可能仍然希望將通過共享資源進行存取的安全性作為一項需求和合約條件。
企業可能還想了解和控制哪些其他應用程式正在與企業共享資源，通常這是非常有困難的，除非自行建立私有雲。 企業可能將此作為一項要求，但堅持這樣做可能會無法使用公有雲服務。
使用者活動日誌在發生資安問題時非常有價值，對於正常活動也很重要。 它提供了一個稽核追踪，幫助系統管理員確定已經造成了什麼損害，重新保護系統，並採取措施防止將來發生同類型的破壞。 安全日誌長期以來一直是常見的做法。 他們可能需要遵守法律，但企業可能希望在任何情況下都能夠滿足追蹤使用者存取的業務需求。 企業應該將此指定為必要的需求。
威脅管理包括 ITIL 定義的事故(incident)、事件(events)和問題(problem)管理的學科。 為了方便討論，在這裡我們統稱這些為“威脅管理”。
企業應該查看CSP有哪些程序來評估和回應已識別的安全威脅。 如果確實發生了安全漏洞，則大部分補救和糾正工作必須由CSP完成。 企業應該要求CSP具有滿足需求的程序。
許多法律法規禁止按雲端的原始設計概念來使用雲端服務。 例如，歐盟GDPR對個人資料的保存位置施加了限制。 除法律規定外，合約或道德義務可能要求企業注意對資訊保密，或保證資訊不會遺失或毀壞。 當資料在雲端時，企業能履行這些義務嗎？企業應該確定影響企業使用雲端服務能力的義務。
對於影響企業使用的雲端服務的每項義務，請指定對這些服務的要求以確保企業遵守所在業務地區的法規法令。
目前公有雲產業已經有足夠的認證方案來確保向客戶提供雲端服務的合規性和 QoS 交付。 此外，前幾大的公有雲CSP已經有了外部審計。 這使客戶在選擇CSP具有很大的方便性，尤其是面對外部監管機構時，企業可以提供由CSP的稽核認證。
一旦確定了使用服務的成本並確定需要求，企業就可以查看合約和交付條款，協商以嘗試降低價格或提高效能(這些需要企業本身的用量夠大)，然後選擇企業需要的服務。 但是，在做這些事情之前，請考慮退出策略(就是要跳槽別家CSP)的問題。
自有IT供應商以來，Vendor lock-in一直是企業面臨的一個問題。 發展開放的、供應商中立的 IT 標準和認證以實現互操作性和防止Vendor lock-in是 The Open Group 的主要職責。
多年來，情況發生了變化。 起初，企業的IT關心的是作業系統和應用程式的可移植性(portability)，然後是網路和互操作性(interoperability)。 既然我們擁有了合理程度的可移植性，並且互聯網已經解決了網路互操作性問題，The Open Group 要做的是改善企業內部和企業之間對整合式資訊的存取：也就是無邊界資訊流的願景(關於甚麼是無邊界資訊流)。
雲端運算開闢了一條新的戰線。 使用雲端服務的協定、資料格式和API介面標準大多已經到位。 這也是市場能夠如此快速增長的原因。 但雲端服務的配置和管理標準尚不存在。 實踐、方法和概念框架的關鍵脈絡標準仍在不斷發展。
在管理和整體脈絡標準得到充分發展和穩定之前，雲端運算將無法發揮其全部潛力。 在制定這些標準的同時，企業會發現使用雲端比它想像中的更難。 特別是，他們會發現更難更換CSP。 要求快速的解決方案很誘人，但歷史表明，有效的標準只能根據經驗判定。
今天，更換手機電信商很容易，但更換CSP的便利性在很大程度上仍未嘗試過。 隨著市場競爭越來越激烈，我們預計CSP之間的轉換會變得更加容易，尤其現今是多雲的時代。
在與新的CSP談判或與現有CSP重新談判時(前提企業本身用量夠大)，或者如果企業希望內包某項特定服務，企業應該確保有退出策略 。
堅持CSP選擇和大量資料傳輸的要求將幫助企業實現這一目標。 企業還應該考慮合約條款和進行變更的成本。 企業將需要為任何大量資料傳輸付費 — — 不同的CSP收取不同的費用。 可能還需要將資料轉換為不同的格式、重新編寫軟體、重新測試解決方案並重新培訓使用者。
對於 IaaS 和 PaaS，問題相對簡單，因為處理邏輯由企業處理，資料很可能以標準形式存儲。 不過，明智的做法是檢查企業使用的特定標準格式是否可以得到其他CSP的支持，或者是否存在轉換機制。 例如，如果您使用 MS-SQL，是否可以輕鬆遷移到另一家CSP也有MS-SQL？
對於 SaaS，這個問題通常更難解決(這與企業更換ERP一樣很困難)，因為處理邏輯由CSP提供，並且資料格式可能是專有的。 另一個CSP不太可能具有相同的處理邏輯，因此更換CSP可能意味著業務流程的變化。 資料轉換可能需要自行開發程式。
合約涵蓋廣泛的方面，而且可能很複雜。 但除非企業使用量非常非常大，不然使用時用的都是CSP的公版合約，沒得修改的。
但以下是企業在檢視雲端服務合約時應該提出的一些與雲端運算具體相關的關鍵問題：
誰擁有資料(根據CSP的共同責任模型通常是企業)，對於 IaaS 和 PaaS，誰擁有應用程序？ CSP對企業有什麼權利？
合約持續多長時間，企業有什麼提前終止的可能性？ 這對企業的退出策略很重要。
CSP有哪些提前終止的可能性？ 這會影響企業承擔的風險。尤其越小的CSP月有這一類的風險。
合約是否導入了依賴關係，例如，如果企業也訂閱了不同的雲端服務，企業只能使用該服務？ 這對退出策略也很重要。
什麼是 SLA？ 這定義了CSP合約支援的服務水準，特別是效能。 通常，它不會涵蓋企業的所有效能要求。
如果供應商不符合合約規定的SLA會怎樣？ 與CSP的合約中通常會為停機時間留出一定的餘地，但除了CSP會退一定時間比例的租費，CSP不負責客戶的業務損失。 如果CSP持續未能履約，企業可能希望能夠終止合約。
資料將位於何處？ 企業能確保它位於特定位置嗎？ 可能需要這樣做以遵守對企業有影響的法規。
CSP實施了哪些安全機制？ 可能需要特定的機制來遵守法規。
適用什麼管轄權？ 如果您必須將CSP告上法庭，是否必須在國外進行？
CSP可以轉包嗎？ 如果是這樣，責任 — — 例如，滿足SLA — — 是留在CSP身上，還是轉移給下包商？
CSP的公版合約通常不容修改，因為大多的企業使用量不夠大到與CSP談判(因為我們不是美國政府)。
CSP的選擇是通過權衡成本、風險、滿足需求的能力、退出策略和合約條款等因素做出的。
如本文前面所述，成本由CSP成本模型確定，雲端運算的風險請參閱本部落格雲端運算的風險一文。
企業應該確定需求的優先等級，確定必須滿足的需求以及願意放棄的需求以降低成本或風險。 例如，企業可能決定必須滿足峰值可用性和吞吐量要求，但回應時間要求可能會降低。 企業也可能不得不在退出策略或合約條款上做出類似的妥協。
A公司有很多 IaaS 供應商可供選擇，包括三大公有雲(AWS/Azure/GCP)和一些小型本地供應商。 它可以與較小的供應商協商更好的條款，但評估這些供應商的風險更高。 退出策略沒有嚴重問題； 應用程式運行在標準平台上，資料不需要轉換，量體也不大。 合約條件沒有重大困難。 它決定與提供優惠條件的本地供應商合作，與三大公有雲相比則願意承擔更高的風險。
B公司處於非常不同的情況。 它找不到滿足其所有專業和嚴格要求的單一 PaaS 供應商。 B公司老闆決定考慮將 IaaS 作為替代方案。 他發現 IaaS 服務具有標準平台，比大多數 PaaS 供應商更能滿足要求。
B公司老闆為兩家 PaaS 提供商和一家 IaaS 提供商開發了成本模型。 這些顯示了相似的數字，每種情況下每個微服務每月的成本都合理。 （範例資料取自真實CSP的公開網站，但省略了名稱）
取自Open Group
第一個 PaaS 提供商最能滿足要求，而且成本也最高。 B公司老闆擔心沒有好的退出策略，但他對此無能為力。 他選擇了第一個 PaaS 供應商，並製定了退出策略的應急計劃，其中B公司將使用 IaaS 供應商的基礎設施和盡可能類似於其 PaaS 供應商平台的標準平台。 然而，這仍然意味著大量的軟體重新開發成本。
在雲端服務運行期間，企業應該監控它與工作負載和成本模型的吻合程度，以及它與需求的符合程度。 結果將幫助企業評估是續簽服務合約、與CSP重新談判不同的合約，還是更換為不同的CSP。
通過監控工作負載和已使用的雲端容量，企業可以了解模型的運行情況，並控制成本。
A公司追蹤已使用和已配置的運算資源。 這表明，按照計劃，在一年中的大部分時間裡，預先配置的運算能力遠低於在地端機房內使用的能力。
然而，它仍然高於必要的水準。 購買的雲端容量的利用率僅為 33% 左右。 下圖顯示了 12 月高峰日的每小時利用率，解釋了原因。
每天兩次的資源供應週期沒有足夠的細緻度。 它只是在高峰期和非高峰期提供了足夠的容量，但這仍然遠遠超過了日常週期最低時的需求。 通過微調雲端資源，似乎還有進一步提高回報的空間。 然而，鑑於A公司的“垂直縮放(vertical scaled)”架構，這將是困難的。 更改系統配置相當麻煩，甚至每天兩次的循環也被證明是對IT單位來說是一種壓力，但透過自動化部署工具也許可以進一步解決。 或者使更現代的軟體架構(代碼重購)，基於可以單獨配置資源的鬆散耦合(loosely-coupled)服務，企業可以更好地充分利用雲端服務特性。
它監控運營第一年的實際和預計成本。
這表明實際成本與預計成本接近吻合。 12 月份的差異主要是由於在快速變化的時期無法足夠快地加載容量。 儘管存在這種差異，但與模型的擬合度足夠接近。 公司高階管理層認為新系統幾乎達到了他們的成本目標，他們在這一點上對他們的CSP感到滿意。
在許多情況下，是否符合需求是“Yes”或“No”。 該雲端服務執行或不執行所需的功能，支援或不支援指定的協定等。 但對效能需求和其他一些需求，則不太清楚。 例如，假設可用性被指定為 99.9%，並且全年測量為 99.7%。 在大多數業務環境中，這可能並不代表嚴重的差異。
一種方法是在一個簡單的尺度上對這些值進行評分，從不可接受到優秀，然後在記分卡上標記出來。 下圖顯示了A公司運作在雲端與地端機房的效能和可管理性參數的比較。
運作在雲端上的系統在幾個方面表現很好。 可恢復性和吞吐量得到改善。 地端系統一直在努力應對高峰工作負載，增加的CoD(Capacity on Demand)的可用性對系統在繁忙時段的效能產生了很大影響。 CSP的報告非常清晰，提供了比公司以前更好的使用資訊。 但有兩個方面值得關注。 系統停機一直是個問題，而且CSP在出現故障時的反應也不好。這是因為選擇了本地CSP的風險所致。
他們使用類似的方法來查看效能是在合同條款和 SLA 之內還是之外，如下所示。 （靠近中心的點表示效能好，靠近邊緣的點表示效能差。）
這證實了CSP在可用性和故障管理方面的表現並沒有像承諾的那樣好。 當續簽合約時，A公司將向CSP提出這一問題，並將更換CSP，除非它得到可用性和故障管理將得到改善的保證。
B公司的老闆現階段並不擔心效能和可管理性。 在他們產品將上線時，他主要擔心的是財務模型和風險。