設計多雲環境的效能與韌性

32 min readJun 18, 2022

任何多雲架構中的一個重要主題是"雲端環境的效能和韌性"。雲端供應商 ( 以下簡稱 CSP)提供了多種解決方案。我們必需決定適合業務需求並降低環境的不可用或不安全的風險的解決方案類型。我們可能會問的一些問題包括，我們如何提高可用性，我們如何確保雲端發生outage時資料不會丟失，以及我們如何安排DR(災難恢復)？這些問題源於對與轉移到雲端環境相關的業務風險可以有很好的理解。

在本文中，我們將收集和驗證業務對雲端運算效能韌性的需求。我們還將學習如何使用工具和支援計劃來優化我們的環境。我們將會介紹以下主題:

具韌性與效能的架構
從業務需求面開始
優化我們的多雲環境
建立業務連續性與災難復原的解決方案
公有雲中的效能KPI

具韌性與效能的架構

韌性與效能不管是在地端機房或雲端都是重要的議題，因為這是關乎企業的系統能否能如期、如質的運作。不過CSP提供了更多比地端環境的工具來達成這兩個目標。

我們可以用AWS的Well-architected Framework針對韌性的定義是:

the capability to recover when stressed by load, attacks, and failure of any component in the workload’s components.

簡單來說，就是當企業的系統中有任何組件掛掉時，回復的速度與程度如何，最好能回到系統良好的狀態並且不會遺失資料。顯然的，這需要經過測試，Chaos Monkey就進到我們的視野當中。而這個方式也可以用於資安的面向中，更多資訊可參閱資安混沌工程一文。

定義系統的韌性首先要了解這個系統對企業業務的重要性以及要達到哪一種服務等級。首先要清楚地了解業務需求。但重要的是要認識到一件重要的事情：韌性和與效能並不只是技術問題。它還涉及維運責任，這是建構和管理應用程式的所有團隊的共同責任。

從業務需求面開始

在設計，實現與管理多雲的著陸區文章中，我們談到了可用性、備份和災難恢復等問題。在本文中，我們將仔細研究雲端平台可以提供的各種解決方案，以確保我們的環境是可用的、可存取，最重要的是，也可以安全使用。在深入研究這些解決方案和各種技術之前，我們必須了解如果沒有明確定義需求，企業的業務可能面臨哪些潛在風險。

在多雲中，我們認識到不同層級的風險，我們需要再次對準企業架構的原則。

資料風險

與資料有關的最大風險是"資料所有權的模糊性"。這種所有權需要在合約以及 CSP 中進行規範和記錄。 GCPR 等跨國和國家法律和框架已經定義的資料所有權方面的法規，但無論如何，確保它也包含在服務協議中。首先，讓企業的法務部門參與此過程。

我們還應該"區分資料類型"。是業務資料、metadata還是與我們的雲端環境維運相關的資料？如果是維運資料，我們可以想到我們在雲端中託管的VM的監控日誌。對於所有這些類型的資料，為了遵守法律法規，我們可能需要遵守單獨的規則。

我們需要知道並記錄我們的資料到底在哪裡。 AWS、Azure 和 GCP 在全球各地都有資料中心，並將通過從具有相應容量的資料中心提供資源來盡可能優化其容量。這可能是一個風險。例如，許多歐洲國家規定特定資料不能離開歐盟邊界。在這種情況下，我們需要確保將資料存儲在位於歐盟的資料中心。因此，我們需要指定我們在公有雲中使用的位置：資料中心所在的區域和實際國家。

我們還需要確保在恢復資料時，資料的格式和可讀狀態是我們所要的。損壞或不完整的資料是這裡的風險。我們應該定期執行復原測試，並調整恢復計劃和實際測試結果。這是為了確保始終保護資料完整性。這對於交易型資料尤為重要。如果我們回復交易型資料，我們需要確保所有交易都被回復，而且交易在回復過程中不會有重複。為此，我們還需要定義誰對資料質量負責，尤其是在使用 SaaS 的情況下。

為了構建所有這些需求，一個好的起點是建立資料分類模型。分類幫助我們決定需要部署哪種類型的解決方案來保證特定資料集的 CIA(Confidentialily/Integrity/Availability)。一些最常用的資料類別是對外資料、公司機密資料和個人資料。

應用程式風險

SaaS 的使用正變得越來越流行。許多公司的策略是的首選 SaaS 而不是 PaaS 也不是 IaaS。在可操作性方面，這可能是優先的路線，但 SaaS 確實存在風險。在 SaaS 中，整個解決方案堆疊由SaaS業者管理，包括應用程式本身。許多SaaS解決方案都使用共享組件，我們必須應對我們的應用程式是否可以被其他人訪問或者我們的資料是否可以通過這些應用程式訪問的風險。減輕這種風險的解決方案是在 SaaS 中擁有我們自己的Application runtime。

與整個技術堆疊（直到應用程式本身）由SaaS提供商管理這一狀況相關的另一個風險是，提供商可能會倒閉。現今(2022年六月)世界正面臨新冠病毒/烏俄戰爭/高通膨等因素，許多中小型企業正在努力求生存。我們看到企業正在衰退，甚至在 IT 領域也是如此。當嚴重的危機席捲全球時，並不能保證一家公司始終保持領先或是不倒閉。隨時準備好保護我們的資料，因為 SaaS 提供商的服務可能無法再更新與維護了，或更糟的是，直接關門。

此外，還存在應用程式掛掉且必須恢復的風險。我們必須確保可以檢索應用程式代碼並且可以將應用程序回復到健康狀態。

技術風險

我們在共享許多組件的雲端平台中配置我們的環境，例如資料中心、存儲層、運算層和網路層。通過配置我們的環境，我們是一個孤島(silo)。這意味著我們正在建立一個獨立的環境 — — 這些共享服務的某個區域。這個區域將是我們的虛擬資料中心。但是，我們仍在使用 AWS、Azure、GCP 或任何其他 CSP 的基礎架構。

這就像一個社區大樓，我們在其中租了其中一戶，然後聲明這一戶現在是我們的財產，而整個大樓仍然屬於某個地主。我們如何確保沒有人在未經我們同意的情況下進入那我們的門戶？在雲端中，我們有這方面的技術解決方案，例如account management、IAM、firewall和network segmentation。

即使是主要的 CSP 也會受到中斷(outage)的影響。企業有責任確保他們的環境保持可用，例如，在使用多個資料中心、區域甚至不同的全球區域實施冗餘解決方案。

監控是必須的，但如果我們只查看技術堆疊(tech stack)中的一個事物或錯誤的事物，它就沒有任何附加價值。錯誤的監控配置是一種風險。由於具有安全性，這些平台為其我們提供這一些工具，但雲端配置取決於在該平台上託管其環境的公司(也就是我們)。

說到安全性，最大的風險之一可能是安全性薄弱。公有雲作為平台得到很好的保護，但保護我們的環境始終是我們的責任。請記住，雲端是駭客的絕佳目標，因為它們是託管數百萬個企業系統的平台。這正是 AWS、Azure 和 GCP 花大錢保護其雲端平台的原因。確保我們在這些平台上的環境也得到適當保護，並實施端點保護、系統強化、網路分段、防火牆和漏洞掃描，以及告警、入侵偵測和預防。我們還需要確保我們了解系統上發生的任何事情。

但是，不要使事情過於復雜。保護需要保護的內容，但要使其易於管理和理解。最大的問題是，我們需要保護什麼、保護到什麼程度以及要付出哪些代價？這些需要從分解業務需求開始。

儘管我們談論的是技術、應用程式和資料風險，但說到底，它是關於業務需求。這些業務需求驅動資料、應用程式和技術，包括風險。到目前為止，我們還沒有回答如何收集這些業務需求的問題。

首先，此過程的主要目標是收集所有相關資訊，這些資訊將幫助我們建立架構、設計環境、實施正確的政策，並將我們的多雲資產配置為最終產品或服務。這不是一次性的作業。需求會隨著時間而變化，尤其是在雲端時代，業務要求(demand)和需求(requirement)都在以越來越快的速度不斷變化。因此，收集需求是一個持續不斷的過程。

我們如何收集我們需要的資訊？為此，我們可以使用一些關鍵技術：

評估 —
做到這一點的一個好方法是評估我們是否正在從應用程式層面評估韌性和效能。應用程式將使用甚麼資源以及哪些參數？如何排程和操作備份？回復程序是什麼？是否定期對環境進行稽核，稽核結果是什麼，是否記錄、評分和解決了這些問題？我們還應該包括重新評估應用程式效能的終端用戶體驗以及在什麼條件下，例如上下班高峰時間、工作日開始時間和正常時間。
利害關係人訪談 —
這些訪談是了解業務需求的好方法。不過，我們應該謹慎。利害關係人可能對業務關鍵系統是什麼等方面有不同的看法。
工作坊(workshop) —
這些對於深入研究現有架構、系統設計、需求背後的基本原理非常有效，同時也給了我們執行決策的機會，因為理想情況下所有利害關係人都在一個會議室中。這樣做的一個風險是工作坊上的討論可能變得過於詳細。主持人(促進者)可以幫助引導這個過程並獲得預期的結果。

一旦我們有了需求，我們就可以對應到我們解決方案的功能參數。業務關鍵型環境可能需要一年 24 小時、每週 7 天都是可用的。系統可以持續產生金錢交易，其中每筆交易都值一定數量的金錢。每筆交易的失敗都意味著公司正在虧損。系統每分鐘處理大量交易，因此每分鐘的資料丟失就等於實際的財務損失。這可以定義 RPO — — 它可能接近於 0。這意味著我們必須設計一個高度可用、冗餘且由 DR 保護的解決方案，該解決方案具有保證 RPO 接近 0 的回復解決方案。

那麼，它總是與關鍵系統有關嗎？不必要。如果我們有很多開發人員正在開發一些系統，那麼這些系統的故障實際上可能會引發公司的財務災難。專案被拖延，危及新服務或產品的上市時間，然後開發人員就沒事幹了，但公司仍需支付費用。它始終與商業案例、公司願意接受的風險以及公司為減輕這些風險願意支付的成本有關。

探討不同雲端倡議中的韌性解決方案

現在我們已經收集了業務需求並識別了風險，我們可以開始考慮解決方案並將這些與需求保持一致。做到這一點的最佳方法是建立一個包含系統、韌性需求和選擇的技術矩陣，以獲得所需的韌性。下表顯示了一個非常簡單的範例，純屬虛構：

韌性系統的設計方式使其能夠承受服務中斷。不管系統的設計和配置有多好。遲早，他們將面臨服務掛掉，甚至可能遭到破壞。因此，韌性通常與冗餘和可用性等品質(quality)屬性相關。

使用Azure Backup與Site Recovery

Azure Backup使用快照原理。首先，我們必須定義運行備份的計劃。 Azure 將根據該計劃啟動備份作業。在作業的初始執行期間，在我們環境中的系統上配置了backup VM snapshot extension。

Azure 具有適用於 Windows 和 Linux VM 的extension。這些extension的作業方式彼此不同：Windows snapshot extension是用到 Windows VSS(Volume Shadow Copy Services)。這個extension實際上擷取了 VSS volume的完整副本。在 Linux 機器上，Azure Backup會快照底層的system files。

接下來，我們可以Azure Backup掛載到 VM 的Disk。快照被傳送到backup vault。預設情況下，OS和Disk的備份使用 Azure Disk Encryption進行加密。下圖顯示了 Azure Backup Service的基本設置：

Azure backup可以用在Azure Cloud中，但也可能用在不是 Azure的環境中．

備份一個非Azure的系統

Azure Backup可用於OS不是放在Azure中的備份。為此，它使用不同的解決方案。 MARS(Microsoft Azure Recovery Services) 是一個簡單的解決方案。在 Azure portal中，我們必須建立一個Recovery Service vault並定義備份目標。

接下來，我們需要下載vault credentials，並且必須在地端機房的OS中安裝一個agent。使用vault credentials，讓我們註冊該台機器並啟動備份方案。更廣泛的方案是MABS(Microsoft Azure Backup Server)。 MABS 是一個真正的 VM — — 運行 Windows Server 2016 或 2019 — — 它通過 Azure 內外的環境控制備份。它可以在許多不同的系統上執行備份，包括 SQL server、sharepoint 和 Exchange，但也可以在 VMware VM 上執行備份 — — 所有這些都來自一個單一控制台。

MABS 與 MARS 一樣，使用recovery vault，但在這種情況下，備份預設存儲在geo-redundant設置中。下圖顯示了 MABS 的設置：

在深入探討 Azure 和其他 CSP 的Recovery solution之前，我們將討論 DR(Disaster recovery) 的一般過程。 DR 分為三個階段：偵測、回應和回
復。首先，我們需要進行適當的監控，以偵測關鍵系統是否出現故障以及它們是否不再可用。如果隨後需要觸發操作以執行緩解操作，例如故障轉移到可以接管所需功能的備用系統，並確保業務連續性得到保障。最後一步是將系統恢復到發生故障之前的狀態。在這最後一步中，我們還需要確保系統沒有損壞到無法回復。

回復是這個過程中的一個關鍵因素。但是，回復可能意味著系統完全回復備份到它們仍然可以完全運行的原始狀態，但我們也可以進行部分回復，僅回復關鍵系統，例如，在後期階段必須修復這些系統的冗餘部分。另外兩個選項是cold standby和warm standby(概念像是DR的 cold/warm/hot site)。通過cold stanby，我們將擁有保留的系統，我們可以在需要時啟動它們。在那之前，這些系統一直處於關閉狀態。在 Warm Standby 中，系統正在運行，但c還不是以正式環境的方式運作。與僅保留可用容量的cold standby server相比，warm standby server的接手正式環境的速度要快得多。

更多關於軟體工程產業的系統韌性，可參考 Donald Firesmith的blog文章．

認識Azure Site Recovery(ASR)

ASR 提供了一種有助於在 Azure 中設置 DR 的解決方案。從本質上講，它在我們的環境中擷取工作負載的副本，並將這些副本部署到 Azure 中的另一個region。如果我們託管環境的主站點由於中斷而無法使用，ASR 將執行故障轉移到我們系統副本所在的備用站點。一旦主站點再次上線，ASR 將再次執行故障回復到主站點。

從底層技術來說，ASR 使用 Azure Backup和快照技術來實現此解決方案。它是它適用於 Azure 中的工作負載，但我們也可以將 ASR 用於非 Azure 的工作負載，例如地端系統甚至 AWS 中的系統。我們可以將工作負載從一個 Azure region複製到另一個region、地端機房的 VMware 和 Hyper-V VM、託管在 AWS 中的 Windows insatnce以及實體機中的系統。

這說的會比做得容易。我們將需要設計一個recovery plan並評估工作負載是否可以真正從應用程式層面和資料層面進行故障轉移。然後，可能最棘手的部分是正確設置網路和網路邊界安全參數：考慮切換網路路由、保留 IP位置、DNS 和複製防火牆規則。

Azure 也為此提供了解決方案，例如帶有 DNS 路由的traffic manager，這有助於在發生故障轉移時進行 DNS 切換，但是，這仍然需要一些工程和測試才能實現。最後真正需要認真考慮的是我們將在哪個region設置我們的備用站點。很多 Azure region確實有dual zone（數據中心），但有些region只有一個zone，我們需要選擇另一個failover region。確保我們在這種情況下仍然合規。

下圖展示了 ASR 的基本概念。請務必記住，我們需要在來源環境中設置cache sotrage account。在replication期間，對 VM 所做的更改會先存儲在cache中，然後再發送到複製環境中的storage：

認識AWS的備份與DR

在本節中，我們將探討 AWS 中的備份和 DR 解決方案。我們將學習如何根據政策(policies)和tag來建立備份。我們還將探討 AWS 的混合解決方案。

建立一個基於策略的備份計畫
與在 Azure 中一樣，這裡需要建立一個備份計劃，該計劃由備份規則、備份頻率、備份時間點以及定義和建立backup valut以及應發送備份的目的地所組成。Backup valut在整個設置中是循環的：它是backup和存儲backup rules的組合。我們還在用於加密備份的valut中定義encryption key。Key本身是使用 AWS KMS建立的。 Valut 是AWS預設會提供的，但企業可以設置自己的valut。

有了這個，我們定義了一個備份計劃，在 AWS 中稱為備份策略(backup policies)。這些策略現在可以應用於 AWS 中的資源。對於每組資源，我們可以定義一個備份策略以滿足這些資源的特定業務需求。一旦我們定義了備份計劃或策略並建立了一個valut，我們就可以開始將資源分配給相應的計劃。資源可以來自任何 AWS 服務，例如 EC2、DynamoDB tables、EBS storage volumes、EFS floders、RDS instance和 storage gateway volumes．

建立一個基於標籤(tag)的備份計畫
只需標記計劃和資源，即可將備份計劃或策略應用於 AWS 中的資源。與標籤的這種整合使得組織資源並將適當的備份計劃應用於這些資源成為可能。然後，任何具有特定標籤的資源都將分配給相應的備份計劃。例如，如果我們為關鍵業務資源制定了策略，我們可以定義一個標籤，將 BusinessCritical 作為對這些資源進行分類的參數。如果我們為 BusinessCritical 定義了備份計劃，則帶有該標籤的每個資源都將分配給該備份計劃。

下圖展示了 AWS 備份的基本概念：

與 Azure 類似，我們還可以使用 AWS 的 hybird 備份解決方案建立在 AWS 之外的系統的備份。

AWS的Hybird backup
AWS 將 AWS 中的資源備份稱為原生備份(native backup)，但該解決方案也可用於地端機房的工作負載。這就是 AWS 所說的 Hybrid backup。為此，我們將使用 AWS Storage Gateway。我們可以將其與 Azure MABS 進行比較。本質上，地端系統系統通過 NFS、SMB、iSCSI 等產業標準存儲協議連接到物理或虛擬設備。這個設備（storage gateway）連接到 AWS S3，可以在其中存儲備份。我們可以對 Hybrid backup使用與原生備份相同的備份計劃。下圖顯示了Hybrid backup的原理。

AWS的DR與跨區域(region)備份
AWS 允許我們執行跨區域備份。這意味著我們可以根據我們的備份計劃進行備份，並將這些備份複製到多個 AWS 區域。但是，這只發生在資料層面上。我們可以對 AWS 中的任何資料服務執行此操作：RDS、EFS、EBS 和 Storage gateway volume。因此，在包含 Storage gateway的情況下，它也適用於地端機房備份的資料。除此之外，AWS 還有BCDR(Business Continuity and Disaster Recovery) 解決方案：CloudEndure DR。此解決方案不是用快照來作業的，CloudEndure DR 可使的目標系統與來源系統能夠具有持續資料的同步。通過這樣做，他們甚至可以實現一秒內的資料恢復點，並且幾乎不會遺失任何資料。 CloudEndure 支持許多不同的系統，包括實體機和虛擬機，而且不管是哪種hypervisor。它還支持Oracle和SAP等企業應用程式。

原理如下圖所示：

來源系統上的 CloudEndure agent和 AWS 中的暫存區域，系統副本存儲在低成本的insatnce上。在故障轉移的情況下，目標 DR 系統將從該暫存區域引導和同步到正式區域。故障回復是從 AWS 中的 DR 系統完成的。

認識GCP的備份計畫

GCP 還使用快照技術來執行備份。第一個快照是完整備份，而隨後的快照是變動的，只備份自上次快照以來所做的變動。如果我們想在 GCP Compute Engine中備份我們的資料，我們必須建立一個 Persistent disk snapshot。可以將資料複製到另一個zone或region的 PD(Persistent Disk)，從而建立地理性的冗餘和更強大的解決方案。

與 AWS 和 Azure 一樣，我們首先必須設計一個備份計劃，或者在 GCP 中的snapshot schedule，以便以基本頻率進行備份。接下來，我們必須設置存儲位置。預設情況下，GCP 會選擇離來源資料最近的region。如果我們想定義一個具有更高可用性的解決方案，我們將需要自己選擇另一個我們希望存儲 PD 的region。

需要注意，在 GCP 中，我們使用約束(constraints)條件。如果我們定義了一個限制資料不能存儲在某個region之外的政策，如果我們要操作違反政策的備份，那麼該政策將阻止備份進行。

GCP 建議在備份之前flush disk buffer作為最佳實踐。我們不需要在進行快照之前停止應用程式，但 GCP 確實建議這樣做，以便應用程式停止將資料寫入disk。如果我們停止應用程式，我們可以在建立快照之前flush disk buffer並同步檔案。

對於 Unix programmer來說，這將非常熟悉，因為 GCP 允許我們通過 SSH 連接到disk並使用 sudo sync 來執行同步過程。所有這些都是通過command-line界面完成的。

但是 Windows 呢？我們可以在 GCP 中運行基於 Windows 的系統，並且可以對這些系統進行備份。 GCP 為此使用 Windows的VSS。在我們這樣做之前，GCP 建議卸載filesystem，然後進行快照。我們可以為此使用 PowerShell。

DR計畫
GCP 讓我們在規劃 DR 策略時首先定義 RTO 和 RPO。根據要求，我們在 GCP 中定義"構建區塊(building block)"以實現該策略。這些構建區塊包括 Compute Engine和 Cloud Storage。在 Compute Engine 中，我們可以定義我們希望如何部署和保護我們的 VM 不會掛掉。這裡的關鍵組件是 PD、 Live Migration 和 Virtual Disk Import。我們討論了將 PD 創建為 GCP 中備份的一部分。 Live Migration 通過將 VM 遷移到運行狀態到另一台host來保持 VM 正常運作。 Virtual Disk Import 讓我們可以從多種類型的 VM 中導入Disk來建立新的 VM Compute Engine。這些新建立的機器將具有與原始機器相同的配置。支援的格式有 VMware 的 VMDK 和 Microsoft 和 RAW 的 VHD。

如我們所知道的，GCP 沒有為 DR 提供預定義的解決方案。因為GCP是把焦點放在容器上，GKE 對容器的關注度更高。 GKE 具有一些內建功能，可用於為容器建立高可用性cluster。節點自動修復檢查集群節點的健康狀態：如果節點在 10 分鐘內沒有回應，它們會被替換掉。如果我們在多region設置中運作節點， Anthos GKE cluster提供multi-cluster ingresse功能，作為cluster之間的負載平衡解決方案。該解決方案之前以 Kubemi(Kubernetes Multicuster Ingress) 的形式提供。對於以上這些，我們需要一個解決方案來運作跨 GCP region的網路流量，並確保 DNS 指向正確的環境。這是通過 Cloud DNS 使用 Anycast、Google 全球網路和 Traffic Director 完成的。

最後，當我們必須設置更複雜的 DR 基礎架構解決方案時，Google 確實建議使用第三方工具。文件中提到的一些工具包括使用 Spinnaker 的 Ansible 和使用 Google Cloud 上的 Chef 進行zero-to-deploy。

到目前為止，我們已經討論了三大CSP自己的備份解決方案。這樣做是有風險的：我們正在讓我們的業務完全依賴這些CSP的工具。從整合的角度來看，這可能很好，但許多企業更喜歡通過第三方工具交付他們的備份和 DR 方案。這樣做的原因可能來自合規要求，也可能來自技術角度。其中一些第三方工具確實專門用於這些特殊要求的企業雲端備份解決方案，可以處理更多不同類型的系統和資料，並且真正與雲端運算不相關。此類第三方工具的包括 Cohesity、Rubrik、Commvault 和 Veeam。

優化我們的多雲環境

系統需要活著，但如果它們的效能很差，它們仍然毫無用處。下一步是在效能方面優化我們的雲端環境。現在，效能可能是 IT 中最麻煩的術語之一。什麼是好的效能？還是可接受的效能？顯而易見的答案是，這取決於系統類型和企業業務設定的 SLA。儘管如此，我們每天都在使用所有的現代技術，我們希望每個系統在被呼叫時都能快速回應。同樣，這一切都與商業案例有關。企業認為什麼是"可接受的"，提高效能的成本是多少，企業是否願意投資於這些效能增強方案？

CSP提供了我們可以用來優化託管在其雲端平台上的環境的工具。在本節中，我們將簡要介紹這些不同的工具以及如何使用它們。

AWS的Trusted Advisor

老實說，從 AWS 或任何其他CSP中獲得最大效益確實不是那麼容易。這些CSP要有一堆的培訓和認證是有充分理由的。可能性幾乎是無窮無盡的，這些 CSP 的投資組合每天都在增長。我們可以在配置環境時使用一些指導。 AWS 通過 Trusted Advisor 提供該指導。這個工具會掃描我們的部署，將它們與 AWS 中的最佳實踐進行對比，並給予建議。它這樣做是為了成本優化、安全性、效能、容錯還有服務限制。

在我們更詳細地介紹之前，我們必須滿足一個要求才能開始使用 Trusted Advisor：我們必須要有一個AWS support plan，儘管有幾項檢查是免費的，例如檢查root account的 MFA 和IAM 使用。此外，對 S3 bucket的權限檢查是免費的。需要注意，Basic support始終包含在內，包括 AWS Trusted Advisor 對七項核心檢查的支援，主要側重於安全性。此外，Personal Health Dashboard的使用也包含在basic support中。

Support Plan分為三個級別：developer、business和enterprise。後者是支援項目最多的一種，它為well-architected framework的所有檢查、審查和建議提供全面的 7x24支援，並可以使用 AWS support team。然而，完整的服務確實是有代價的。每月在 AWS 上花費 150 萬美元的企業將在此enterprise support plan中每月支付約3%的月租費用。這是因為 AWS 通常根據客戶在平台上部署的使用量服務收費。developer和business遠低於此。

但是，這種full support確實包括對我們可以在 AWS 中部署的幾乎所有內容的建議。不過，最有趣的部分是服務限制和效能。服務限制對使用量和許多不同服務的容量進行檢查。當達到該服務量限制的 80% 時，它會發出告警，然後它會就補救方法提供建議，例如提供更大的 VM instance、增加頻寬或部署新的DB cluster。它與雲端環境的效能密切相關：Trusted Advisor 檢查資源的高使用率以及這種使用率對這些資源效能的影響。

我們應該在本節中提到的另一項免費服務是 Personal Health Dashboard，它為我們提供了有關 AWS 中資源狀態的非常有價值的資訊。好消息是，它不僅會在問題發生並影響我們的資源時發出告警，而且還會指導我們進行補救。更好的是，當support plan的變更可能影響資源的可用性時，Personal Health Dashboard會主動通知我們。 Personal Health Dashboard與 AWS CloudWatch 整合，也可以與 Splunk 和 Datadog 等第三方工具整合。

Azure Advisor

與 AWS 一樣，Azure 提供support plan和一個工具來幫助優化環境，稱為 Azure Advisor。不過，我們無法真正將support plan和工具相互比較。這些服務的範圍完全不同。話雖如此，Azure Advisor在所有Azure的support plan中都不會產生額外費用。

從support plan開始。 Azure 提供四種類型的計劃：basic、developer、standard和Professional direct。basic是免費的，而等級最高的professional direct，每月 1,000 美元即可購買。但同樣，我們沒有辦法將其與 AWS 的enterprise support plan進行比較。換句話說，每個CSP都提供免費和付費服務 — — 每個CSP的區別在於”哪些服務是免費的或必須付費的”。

事實上，Azure Advisor無需額外費用。它提供了有關成本、高可用性、效能和安全性的建議。Advisor儀表板可以從 Azure portal啟動，它會立即生成我們在 Azure 中部署的資源狀態的概述，以及改進建議。對於高可用性，Azure Advisor會檢查 VM 是否部署在availability set中，從而修復 VM 的fault tolerance。需要注意的是，Azure Advisor僅建議雲端管理員需要進行真正的修復操作。我們還可以使用 Azure Policy 和 Azure Automation來自動化執行此操作，但 Azure Advisor尚未執行此操作是有充分理由的。補救措施可能會產生額外的成本，我們希望控制我們的成本。如果我們通過Azure Policy 和 Azure Automation實現自動化，那麼這就是一個業務決策和架構解決方案，這將包含在成本估算和預算中。

另一方面，Azure Advisor確實為我們提供了一些最佳實踐。在效能方面，我們可能會被建議開始為我們的應用程式使用managed Disks、重新設計存儲或增加 VNet 的大小。看是用手動的或自動的都是取決與我們。

不同的CSP提供了大量工具，以便我們可以密切關注平臺本身以及我們在這些平台上部署的環境。只用Azure Advisor是不夠的，我們將使用 Azure Monitor 來保護我們的資源，並使用 Azure Service Health 來監控 Azure 服務的狀態。 Azure 專門針對安全監控提供 Azure security center和稱為 Sentinel 的 Azure 原生 SIEM 工具。這些服務中的大多數都是pay-as-you-go的方式提供的：按每個受監控項目。

GCP的 Cloud Trace與Cloud Debugger

GCP 在優化環境方面提供了兩個有趣的功能：Cloud Trace 和 Cloud Debugger。兩者都可以從GCP protal找到。由此，我們可以看出 GCP 來自cloud-native和native app的世界。

Cloud Trace 確實是一個優化工具：它從我們在 GCP 中應用程式收集latency，無論這些應用程式是在VM、容器還是 App Engine 中的部署，還是 GCP 中的native app環境。 Cloud Trace 測量來自user或其他服務的incoming requests與處理請求的時間之間經過的時間量。它還保留日誌並提供分析，以便我們了解性能在較長時間內的演變情況。 Cloud Trace 使用transaction client從 App Engine、負載平衡器和 API 收集資料。它讓我們深入了解應用程式的效能、應用程式之間的依賴關係以及提高效能的方法。

Cloud Trace 不僅適用在 GCP ，也適用於非 GCP上。換句話說，我們可以將 AWS 和 Azure 中的 Cloud Trace 用作使用 JSON 的 REST API。

Cloud Debugger 是另一個工具，它用於debug我們在 GCP 中運行的應用程式中的代碼。 Debugger將在應用程式運作時分析代碼。它通過對代碼進行快照來實現這一點，儘管我們也可以在source code上使用它。它與 GitHub 等版控工具整合。 Debugger支援最常用的開發語言來編寫應用程式，至少當它在 GKE 上的容器中運行時是這樣。在這種情況下，支持 Java、Python、Go、Node.js、Ruby、PHP 和 .Net Core。而在Compute Engine 不支持 .NET Core。而Cloud Debugger將在2023年五月底停止，取而代之的是Snapshot Debugger服務。Cloud Trace 和 Cloud Debugger 是 GCP 的StackDriver的一部分，是一項收費服務。

在公有雲的效能 KPI

正如我們在前面中提到的，效能是一個麻煩的主題，更大聲一點的說，如果有一個item會在SLA中引起爭論，那就是效能。就 KPI 而言，我們需要絕對清楚什麼是效能，要從可衡量的目標而言。

什麼定義了效能？這是使用者體驗。應用程式回應和處理請求的速度如何？請注意，快速不是一個可衡量的單位。我們很多人可能會聯想到這一點：老年人可能認為手機上的應用程式在 10 秒內回應很快，而年輕人可能會在點擊Icon後一秒鐘沒得到回應就會不耐煩地一直點擊手機。他們對快速有相對的看法。因此，我們需要定義和同意什麼是可測量的快速。要記住的一件事是，沒有可用性(availability)，就沒有什麼可以衡量的，所以韌性仍然是一個優先事項。

哪甚麼是我們可以衡量的?以下有幾個關鍵指標是我們必須考量的:

CPU and Memory: 所有CSP都提供各種大小的insatnce，有些還可以客製化。我們應該仔細查看針對特定工作負載建議使用哪些insatnce。例如，在memory中運行大量工作流程的應用程式首先需要大量的memory。例如，SAP S4/HANA insatnce可能需要高達 128GB 甚至更多的 RAM。對於這些工作負載，Azure、AWS 和 GCP 提供了大型且是memory-optimized insatnces，這些insatnce緊跟完整的 SAP 解決方案。如果我們有運行大量影像的應用程式，我們可能希望使用 GPU 的圖形工作負載的特定insatnce。因此，它歸結為正確類型的instance和基礎設施，以及規模。如果我們在重度應用程式下選擇少的 CPU數量、memory也很少的機器，我們不能因為效能很差而幹譙CSP。應該使用Advisor tools來實現最佳實踐。
Responsiveness(回應能力):伺服器需要多長時間才能獲得對request的回應？有很多因素決定了這一點。首先，它是關於正確的網路配置、路由和整個應用程式堆疊中的依賴關係。無論我們是通過低頻寬的 VPN 還是高速的網路專線進行連接，這都很重要。它還與負載平衡有關。如果在高峰時段負載增加，我們應該能夠處理它。在雲端中，我們甚至可以以完全自動化的方式scale out or scale up來對應。在這種情況下，我們需要對負載平衡解決方案進行適當的配置。
IO throughput:這是關於server或環境中的吞吐率(throughput rates)。吞吐量是RPS(request per second)、併發用戶數(concurrent users)和資源使用率的度量，例如伺服器、網路、防火牆和負載平衡器。架構中的關鍵要素之一是Sizing。從技術角度來看，解決方案可以設計得很好，但如果資源大小調整不正確，則應用程式可能無法正常運行或根本不能用。我們在本文中討論的各家CSP的Advisor tools在設置環境、準備資源大小和優化應用程式（代碼）方面提供了很好的指導。

為效能定義 KPI 最重要的是，所有利害關係人（業務、開發人員和雲端管理員等）都對效能應該是什麼樣子以及應該如何衡量效能有共同的理解。

總結

在本文中，我們討論了雲端環境的韌性和效能的定義。我們探討了三大CSP提供的各種備份和DR解決方案。我們還學習了如何使用CSP提供的不同Advisory tools來優化我們的環境。然後，我們學習了如何識別各個層面的風險：業務、資料、應用程式和技術。我們研究了可以用來減輕這些風險的各種方法。最大的風險之一是我們“失去”系統而無法從備份中取回資料或無法failover到其他系統。

為了防止系統掛掉，從而帶來資料遺失的風險，並導致業務無法運作，我們需要在我們的環境中設計韌性。對於真正的關鍵業務系統，我們可能希望進行DR，但至少，我們需要有適當的備份解決方案。因此，我們了解了主要雲端平台中可用的備份和災難恢復解決方案。

我們還學習了如何通過使用一些雲原生、方便的advisory tools來優化我們在雲端中的環境。最後，我們研究了 KPI 以及如何使用它們來衡量我們的系統在雲端中的效能。