Google Cloud 的治理、管理與維運

很多人在雲端平台建立服務之後，他們的治理與維運心態還是停留在地端機房的時代。這一篇我們要來介紹GCP在雲端服務的治理架構概念與相關管理的維運服務。

治理GCP Resource

GCP的資源階層等同於一般企業組織架構的對映(如下圖所示)。從Organization(公司) →Folder(部門/團隊) →Project →Resource。Resource是在Project內被創造的，而Folder可以包含多個Project(也可以包含多層/多個 sub folder)，而Organization可以包含多個Folder。

一般企業在治理其GCP資源階層時有以下的建議

1. 針對不同的運作環境(正式/測試/開發等等)建置於不同的Project。
2. 個別系統建立於個別的Project中。
3. 每個部門/團隊都有自己的Folder，但有一些整個公司的shared resource可以建立在Shared Folder中。

這麼做有兩個效益:

1. 安全性 — 每個系統與環境都有自己的Access Control機制。
2. 費用容易分開，因為是以Project為based來統計不同的雲端費用。

Billing Account

每一個GCP Organization 可以掛多個Billing Account。Billing account會幫我們細分每一個部門、團隊、專案、系統、資源等等的細分資訊。有關關於雲端費用的相關議題可參閱本部落格FinOps相關的文章。

關於到底一間企業要掛多個的Billing account，則要取決於企業的財務要求。因為一間企業可能是新創(可能一個billing account就夠了)，也可能是一間超大集團，要有多個Billing account。因為每個子公司的金流與付款方式不盡相同。

而企業付款給GCP的雲端費用有兩種

1. Self Service — 掛公司的信用卡。但是會有境外稅的問題
2. Invoiced — 找一間台灣SI幫忙處裡帳務問題。所以跟一般企業在台灣買商品一樣，只付5%的營業稅即可

一般帳務管控的機制(不論我們是看GCP的帳務系統或是SI的)，通常需要以下基本作法:

1. 針對每個目的或系統設定每個月的預算，並設定告警。這對剛開始使用雲端的企業非常有用
2. 告警的閥職可以是預算的50%、90%或100%。一般會將告警的email傳送給有Billing admin/ Billing account users角色的人。如果運作到後期，也可以將告警透過Pub/Sub傳送，進行一些自動化操作
3. 如果有需要將運費資料進行後續分析或歸檔，可以將資料一次性或使用排程的方式匯出到Bigquery(分析)或Cloud Storage(歸檔)。如果將費運資料匯出到Bigquery，請參閱本部落格"使用BigQuery來分析GCP費用"一文。

IAM的最佳實踐

我們在"Google Cloud — 安全服務簡介"一文有介紹到了甚麼事IAM及其功能。在其安全的治理上IAM有一些最佳實踐可供參考:

1. Principle of Least Privilege(這個只要是對資安有常識的，應該已經聽到不想聽了，但能嚴格遵守的卻少之又少)。在GCP上的操作就是不要在Production環境上使用Basic Role，並且針對不同目的不同系統使用不同的Service account
2. Separation of Duties(這個一樣，資安有常識的，應該已經聽到不想聽了，但能嚴格遵守的一樣少之又少)。在GCP的操作上，以App Engine來說，有App Engine Deployer與App Engine Service Admin兩種role。App Engine Deployer只能佈署新版本，但無法轉移流量。而App Engine Service Admin則是反過來。
3. 持續監控
   檢視 Cloud Audit Log來稽核 IAM policies的變更以及對service account key的存取

User Identity Management

一般我們在開通GCP服務時，第一個註冊的email addrses會被GCP認定成Super Admin。這個account可以在整個GCP Organization做任何他想做的事，而管理其他的使用者用的是gmail account。

不過這種管理方法不適合企業管理GCP的方式，因為它無法進行統一的管理與稽核。通常有兩種方式來對使用GCP的人員進行管理:

1. 使用Google workspace。一旦企業使用的workspace與GCP。google就會自動將這兩個服務連接起來。super admin也就位在worpskace中。
2. 使用Identity Provide，這也是符合哪些已經有使用Windows AD當作帳號管控的企業使用。這種方式稱為Fedoration。

Directory Federation

我們需要將Windows AD(或類似的LDAP)，稱之為IdP(Identity Provider)與GCP 的Cloud Identity 聯合(federate)起來。然後再Cloud Identity啟用SSO(Single Sign On)。User的驗證會被導到IdP，當在IdP驗整完成之後。IdP送回一個驗證成功的訊息(SAML assertion)給GCP。

Cloud Identity與AD聯合驗證的範例有GCDS(Google Cloud Directory Sync)與ADFS(Active Directory Federation Services)還有Azure AD。

IAM members / identities

以下是IAM中的各種成員與身分:

• Google account — 人類用的，用email address代表
• Service Account — 機器/系統用的
• Google group — google account/service account的集合。通常會有一個unique email address可以將policy套用在這個email address
• Workspace domain — 與IAM高度整合。我們可以用worspace domain的方式來進行權限控管
• Cloud Identity domain — Cloud Identity其實就是一個IDaaS(Identity as a Service)。我們可以使用 IAM 管理每個 Cloud Identity 帳號對資源的存取

以下是一些IAM的使用場景與相對應的解決方案

Organization Policy Service

如果有用過Azure Policy，哪其功用是相同的。它是用來強制執行企業的政策與標準並大規模評估合規性。例如它在整個Ogranization下可以禁用某些GCP的資源，或是因為資料合規性只能在某些Region使用GCP的服務。

這一個功能的設定，要進行執行的帳號需要有”Organization Policy Administrator”的角色權限。Organization Policy Service與IAM不同的在於:

• IAM是針對WHO — “Principal “(人或機器)可以對資源採取具體行動?
• Organization Policy Service是針對What — 針對特定資源可以做些什麼?

資源階層與IAM Policy

如上圖，我們可以看到IAM Policy 可以設定在任何層級上。資源是繼承所有上層的Policy。資源的有效Policy是該資源及其上層Resource Policy的結合。Policy繼承是可傳遞的：例如：Policy在資源層級套用。如果在較高層級授予了權限，則無法限制較低層級的Policy。所以較高層級的限制應該較低層級要多。

維運(Operation)

GCP提供的整套雲端平台維運服務稱為 Operation Suite。以下我們將介紹Operation suite裡各個套件功能與特徵。

Cloud Monitoring

這是用來監控我們的雲端基礎設施，不只包含GCP本身，其他的雲端平台與地端機房一樣可以用此服務進行監控。它與我們一般認知的監控軟體一樣有:

• 量測某些服務的指標
• 用視覺化圖形介面來呈現
• 可以設定告警
  根據某些條件來觸發，並使用多種管道來通知我們，而這些都會有歷史紀錄

一開始啟用Cloud Monitoring通常會建立一個Workspace。Worksapce是用來統整我們整個雲端平台與地端的監控資訊。一般性的步驟如下:

1. 在一個特定的Project建立workspace，該Project可以稱為Host Project
2. 將其他的GCP project或其他雲端平台加入到該workspace

Cloud Monitoring用得最多的服務就是VM了(不管是哪裡的VM)，但前提是需要在該台VM安裝agent。一般性的VM監控指標有:

• CPU utilization
• disk traffic metrics
• Network traffic
• Uptime information

Cloud Logging

這是一個log 管理與分析的全託管式服務，Log可以來自任何地方(不一定是GCP)。它所儲存的量能比我們一般地端機房大得多。也因為如此大量的log資料，Cloud logging提供了在如此大量資料(Exabyte等級)的儲存/搜尋/分析/告警等能力。主要的功能如下:

• Logs Explorer — 使用類似SQL語法的方式來搜尋，儲存與分析資料
• Logs Dashboard — 視覺化介面
• Logs Metrics —從log中擷取指標 (用queries/matching strings)
• Logs Router — 路由不同類型的log到不同的目的地

有一些GCP的服務，預設上已經會將log送到Cloud logging了。例如: GKE/App engine/ Cloud Run。而如果是GCP的VM，則需要安裝”Logging Agent(基於 fluentd的開源蒐集軟體)”。但若是地端或其他雲端的VM則建議使用BindPlane方案。

Cloud Logging也提供了使用在稽核與安全類型的log服務:

• Access Transparency Log(也就是廠商的對服務的存取稽核)
  擷取 GCP 團隊對我們的GCP平台執行的操作（but並非所有服務都支援）。而且這是要錢的，因為只有Standard support以上才有。
• Cloud Audit Logs(“誰”在"何時"、"何地"幹了"何事")。基本上分為四類的Audit log:
  1.Admin activity Logs
  2.Data Access Logs
  3.System Event Audit Logs
  4.Policy Denied Audit Logs

下表是4種audit logs的用途/範例/儲存地/應該使用的role

哪麼既然不同的Audit logs有不同的儲存地，GCP是如何來進行分類處理的呢?首先Cloud Logging會使用Log router根據不同的規則來路由(或丟棄)不同類型的log。如下圖所示。

其中在上圖的左下角，我們看到logs bucket分為兩種:

1. _Required : 用來儲存Admin activity/System Events/Access Transparency Logs這三種logs。這一類的Log，Cloud logging會保留400天並且不收任何費用。但這一個log bucket我們無法做任何的更動(這由GCP直接管轄)，只有view的權力。
2. _Default: 其他任何的Logs(包含Data Access logs)。這是要錢的，我們可以做任何異動(除了刪掉這個bucket之外)。我們可以暫停收log或修改保存期限(從1 -3650天)。

Log雖然可以在Log bucket保存非常久的時間，但是出於某些目的(合規/稽核)，我們還是需要將Log匯出bucket之外(如上圖的右下角)。要將資料export出bucket，首先我們需要create “sinks”來告訴cloud router要將log送到哪裡。我們可以使用 include/exclude來篩選要匯出甚麼樣的log。

案例 1：使用 VM 日誌進行故障排除：
在所有VM中安裝 Cloud Logging agent 並將日誌傳送至 Cloud Logging
在 Cloud Logging 中搜尋日誌

案例 2：將VM 日誌匯出到 BigQuery，以便使用SQL-like 的語法進行查詢：
在所有VM中安裝 Cloud Logging agent 並將日誌傳送至 Cloud Logging
建立用於儲存日誌的 BigQuery dataset。

用例 3：希望以最低成本保留外部稽核員的稽核日誌
在 Cloud Logging 中建立export sink，並使用 Cloud Storage bucket作為接sink destination。然後為稽核員提供bucket上的Storage Object Viewer role。也可以使用 Google Data Studio（用於視覺化）。

上圖是一個Audit Logs的範例，以JSON檔案格式呈現。從上面的範例中，我們由上往下可以看到:

1. 甚麼服務: protoPlayload.serviceName
2. 是誰呼叫的: protoPlayload.authenticationInfo.principalEmail
3. 做了甚麼: protoPlayload.methodName
4. 對誰做: resource.type

Cloud Trace(類似AWS的 X-Ray)

GCP 的分散式追蹤系統：可以從以下位置收集延遲資料：

• 支援的Google Cloud Services
• 使用 Cloud Trace API 檢測應用程式（使用tracing libraries）

這可以協助我們檢查出：

• 服務處理請求需要多長時間？
• 請求的平均延遲是多少？
• 隨著時間的推移，效能如何？ （增加/減少趨勢）

這可以用於GCE、GKE、App Engine（Flexible/Standard）等。tracing libraries支援C#、Go、Java、Node.js、PHP、Python 和 Ruby。

Cloud Profiler

這是用來識別生產環境中的效能瓶頸，它是一種具統計功能、低度管理的分析器。Cloud Prifiler能持續收集生產系統的 CPU 和記憶體使用情況，並且將分析資料與應用程式原始碼連接起來。這樣能夠讓我們很輕易地識別效能瓶頸。Cloud Profiler由兩個主要組成部分：

• Profiling agent（收集分析資訊）
• Profiler interface（可視化）

Error Reporting

這是一種即時異常監控服務，能聚合並顯示從雲端服務報告的錯誤（使用stack traces）。它有著集中式錯誤管理控制台：識別並管理最常見的錯誤或最近的錯誤。另外也使用 Firebase Crash Reporting來報告來自 Android 和 iOS 用戶端應用程式的錯誤，支援 Go、Java、.NET、Node.js、PHP、Python 和 Ruby。可以透過以下方式報告錯誤：

• 將它們傳送到 Cloud Logging
• 透過呼叫Error Reporting API

可以從桌面存取錯誤報告，也可在 iOS 和 Android 的 Cloud Console 行動應用程式中使用。

Cloud Scheduler

這是與Linux 的Cron job一樣的功能，只是它不是對VM中的作業。而是對整個GCP platform的Cron Job，用的也是"Unix cron format"。

它可以與App Engine, Cloud Pub/Sub, Cloud Logging 還有任何HTTP endpoint進行整合，並提供"automated retries"的功能。

Cloud Emulators

技術人員在開發自有的程式時，大多都會與GCP中的各項資源進行互動。但是這通常會花錢。GCP提供了這一類的工具安裝在本地端來模擬我們開發的應用程式與其GCP resource互動的模擬測試。目前該工具支援的模擬服務有:

• Cloud Bigtable
• Cloud Datastore
• Cloud Firestore
• Cloud Pub Sub
• Cloud Spanner

資料生命週期的設計

我們在"Google Cloud — 資料的儲存與處理服務"一文中，簡介了GCP各項的資料儲存服務。而本節要來設計在整個GCP資料生命週期管理的四個基本步驟:

1. Ingest: Stream/Batch資料匯入
2. Store: 以方便的格式持久且經濟高效地儲存資料
3. Process and analyze: 將資料轉換為資訊(normalizations或aggregations)
4. Explore and visualize: 靈活地處理資料/資訊。 獲取並分享見解

Ingest(匯入)

Streaming的方式可以使用Pub/Sub ，而Batch則有Storage Transfer Service, BigQuery Transfer Service, Transfer Appliance, gsutil 等工具。Database migration: 將資料從別處移到GCP，則可以用以下方式/服務:

• Database Migration Service (從其他DB轉移到Cloud SQL)
• Batch transfer to Cloud Storage
• 使用DataFlow將資料從Cloud Storage轉移到DB

Store(儲存)

根據不同的資料格式與使用方式，可以參照下表。

Process and analyze

Raw data轉變成資訊(可以讓我們有下一步行動的)，通常資料是經過整理/轉換的。而GCP提供了以下這一類的託管式服務讓我們使用。

Explore and visualize

處理與分析之後，就是探索資料的見解與視覺化了。GCP也提供了以下相關的服務讓我們使用。

而有關於大數據的處理與分析的工具使用，則可參考下表:

範例 1: Big Data Flow — Batch Ingest into BigQuery

運用ETL的方式來將資料匯入BQ。GCP提供三種服務來做到這一點:

• Dataprep: 資料的清理與準備
• Dataflow: 建立data pipelines (與 ETL)
• Dataproc: 使用Spark and Hadoop來進行複雜的資料處理

範例2 :Streaming Workflow — Enable Realtime Querying

及時的資料查詢則可使用以下服務來達成:

• Pub/Sub and Dataflow: 在資料進入BQ之前，對資料進行分析、聚合(aggregate)與篩選
• 對於預先定義的時間序列(time series)分析，將資料儲存在 Bigtable 中就可讓執行快速分析
• 對於臨時(ad hoc)複雜分析，使用 BigQuery

Data Lake(資料湖)

通常的大數據解決方案很複雜，我們如何輕鬆收集、分析（報告、分析、機器學習）和視覺化龐大的資料集？如何設計可擴展的解決方案？如何在節省成本的同時建立彈性？

答案是:資料湖，這是單一平台與組合:
具有資料儲存、資料管理和資料分析解決方案大鍋炒方案

儲存：雲端儲存（低成本+耐用+效能+靈活處理）

資料擷取取：
Streaming — Cloud Pub/Sub + Cloud Dataflow
Batch— 傳輸服務 + 傳輸裝置 + gsutil

處理與分析：
使用 SQL 查詢執行就地查詢
BigQuery 或（Dataproc 上的 Hive）

資料探勘與探索：
使用 Dataprep 清理和轉換原始數據
使用 Cloud Datalab（資料科學庫，例如 TensorFlow 和 NumPy）進行探索

精實維運-Agile/DevOps/SRE

在雲端環境中，由於其複雜度與關聯性比傳統地端機房還要高。故使用敏捷與自動化的方式運作有其必要。

Soft ware development life cycle(SDLC) — Waterfall

傳統的SDLC的設計方式是瀑布式的流程(如下圖)，每一個階段都會耗費很久的時間。

後來的SDLC則採用螺旋式、小批量的作法來進行(如下圖)。每個階段都是一個小的迭代(Iteration)

而敏捷式的SDLC則有著以下原則:

• 透過流程和工具將每個個體交互
• 工作在軟體上勝過全面的文件
• 客戶協作勝過合約談判
• 回應變化而不是遵循計劃
• 12個因子設計

但是，但為關鍵安全軟體（飛行導航軟體、醫療設備軟體等）需要增加一些瀑布式開發的剛性。

DevOps

傳統上的系統維運通常是上面三個單位分而治之，各管各的。然而這麼做卻會產生嚴重的穀倉效應，而DevOps就是用來打破這種效應，是一種流程與文化的結合。

而提高“優秀軟體團隊的三要素”

1. 溝通－讓團隊成為一體
2. 回饋 — 越早發現問題，就越容易解決
3. 自動化 — 自動化測試、基礎設施配置、部署和監控

而DevOps又一定會提到CI/CD這個流程。名詞解釋如下:

• Continuous Integration-持續運行測試和打包
• Continuous Deployment-持續部署到測試環境
• Continuous Delivery-持續部署到生產

哪麼在這CI/CD的流程中，DevOps團隊通常都在做那些事呢?以下是一些建議參考。

• Static Code Analysis
  包括靜態安全檢查（原始碼安全分析器軟體，如 Veracode 或靜態程式碼分析器）
• Runtime Check
  執行弱點掃描程式（掃描 Web 應用程式是否有安全漏洞的自動化工具）
• 測試
  Unit Tests (JUnit, pytest, Jasmine 等)
  Integration Tests (Selenium, Robot Framework, Cucumber 等)
  System Tests (Selenium, Robot Framework, Cucumber 等)
  Sanity and Regression Tests

而根據上述的這些需求，GCP提供了一些關於在CI/CD工具的託管式服務。

• Cloud Source Repositories — 與GitHub的功能相同
• Container Registry — 存放Docker image的地方
• Cloud Build — 從原始碼和配置建置可部署的工件（jar 或 docker image）

另外Google也貢獻了一個Open source — 可以在多個雲端平台進行佈署，稱為Spinnaker:

• 快速、自信地發佈軟體變更
• 支援部署到Google Compute Engine、Google Kubernetes Engine、Google App Engine和其他雲端平台
• 支援多種部署策略

CI/CD是屬於軟體面的維運，而Infrastructure的維運則需要使用IaC(Infrastructure as Code)這一類的解決方案。

IaC以與應用程式代碼相同的方式來對應基礎設施。這麼做可以讓我們追蹤基礎設施隨時間的變化（也就是Infra的版本控制），也將可重複性導入基礎設施環境中。IaC有兩個主要的部份:

• Infrastructure Provisioning — 配置運算、儲存和網路
  這一類的工具有，支援多種雲端平台的 — Terraform。GCP則是Cloud Deployment Manager
• Configuration Management — 將軟體與工具正確的安裝與設定在啟用的資源中
  這一類較知名的工具有: Chef, Puppet, Ansible與SaltStack

有關更多IaC的介紹可以參考本部格IaC的相關文章。

透過Cloud Deployment Manager來建立與管理GCP中的Infrastructure有著以下的效益:

• 自動部署和修改 GCP resource
  以受控、可預測的方式取得資源
• 輕鬆部署在多個環境
• 避免配置漂移(Configuration drift)
• 避免手動配置錯誤
• 將其視為環境的版本控制
• 重要提示 — 永遠要使用 Deployment Manager來修改 Deployment Manager所建立的資源
• 所有配置都在一個簡單的文字檔案 — YAML 檔案中來定義
• Cloud Deployment Manage會知道依賴關係
  例如:首先建立 VPC，然後建立子網，最後建立資料庫
• 錯誤時自動rollback(預設)
  例如:如果建立資料庫失敗，會自動刪除子網路和VPC
• 對Configuration file進行版本控制並對其進行更改
• 這個服務是免費的 — 只需為啟用的資源付費

以下是一個Cloud Deployment Manage中簡單的YAML檔案呈現

而在此服務中我們需要了解一些專用名詞及其功用

• Configuration file:
  包含單一部署的資源定義的 YAML檔案
• Templates:
  可在多個Configuration中使用的可重複使用資源定義。例如可以使用Python 或JinJa2
• Deployment:
  一起部署和管理的資源集合
• Manifests:
  包含原始的deployment configuration（包括匯入的templates）的Read-only object。這是由Cloud Deployment Managert產生的，包括能完全擴展的資源清單。這有助於troubleshooting。

Site Reliability Engineering (SRE)

這是Google發展出來的詞彙。SRE 團隊專注於跟Application有關的每一個面向，包含:
availability/latency/performance/efficiency/change management/monitoring/emergency response/capacity planning。

團隊運作的主要的原則有:

• 依Service Level Objectives (SLO) 進行管理
• 減少勞累
• 透過降低失敗成本來快速行動
• 與開發人員分享所有權

SRE團隊在日常的運作中會專注於以下的指標:

• Service Level Indicator(SLI):某些服務的量化量測。
  這些指標類別是:availability, latency, throughput, durability, correctness (error rate)。通常是一分鐘統計一次。
• Service Level Objective (SLO)= SLI + 目標
  像是99.99% Availability/99.999999999% Durability/Response time: 99th percentile — 1 second。選擇一個正確的SLO是很複雜的。
• Service Level Agreement (SLA) = SLO + 合約
  如果沒滿足 SLO 的後果是什麼？ （在合約中定義）。通常內部 SLO 比外部 SLA 更嚴格。
• Error budgets: (100% — SLO)有多少錯誤空間可以犯
  團隊實現可靠性目標的情況如何？用於管理開發速度

而SRE的最佳實踐則有:

A.)處理超載:

1. 減載(Load Shedding)
   例如API call限流，根據不同客戶等級給予不同流量。Streaming data
   — 例如我們是聚合有時間序列的資料流。在某些狀況下可以刪除某些資料
2. 降低品質
   例如將流量導到一組hardcode的回應。像是 — 服務正在處理中之類的網頁

B. )不過最重要的是要避免Cascading Failures。避免連鎖性的各個服務掛掉，需要準備好斷路器(Circuit Breaker)或降低服務品質。

C. )Penetration Testing (Ethical Hacking)

• 模擬攻擊，目的是發現安全漏洞
• 需要取得Project Owner授權
• 無需通知Google，確保我們只測試我們的專案並遵守服務條款
• 可以是White Box（向駭客提供有關基礎設施和/或應用程式的資訊）或BBlack Box（不提供資訊）

D.)壓力測試(JMeter, LoadRunner, Locust, Gatling 等之類的工具)
盡可能接近模擬現實世界的流量。測試尖峰流量 — 流量暴增

還有韌性測試 — 系統在壓力之下的行為是甚麼?所謂的韌性是指:即使系統的一個或多個部分發生故障，系統也能夠提供可接受的行為。這一類的測試方法有:

• 混沌測試（Chaos Testing）－導致一層或多層失敗
  想像方放一隻猴子到你的資料中心亂搞
• 在其中一層上施加巨大的壓力
• 在測試中包含網路（VPN、Cloud Interconnect等）
  如果Cloud Interconnect掛掉，我們會自動跳轉到 VPN 嗎？當Internet中斷時會發生什麼？
• 在GCP上進行disaster recovery演練

發布管理(Release Management)

發布管理的目的在於，因不同的應用程式我們需要做到:

• 零停機時間
• 一次只存在一個版本
• 最大限度地降低成本（以及所需的基礎設施）
• 上線前測試生產環境流量

最佳的作法是:

• 小的增量變化
• 自動化（盡可能）
• 處理新版本的問題：
  1.分析 Cloud Monitoring and Logging 中的日誌和指標
  2.Rollback到先前的版本並嘗試在其他環境中複製問題

佈署的方法: Recreate

刪掉版本1，做出第二個版本。這個方法有幾個特性:

1. 應用程式在發布期間要停機。Rollback需要重新部署和更多停機時間
2. 經濟有效且快速但具有破壞性
3. 避免向後相容的需要（資料和應用程式）

佈署的方法:金絲雀(Canary)

通常有兩個步驟:

1. 先做出版本二的一小部分的量能
2. 如果在版本二上運作沒問題，就將流量全部轉到版本二。如果再小部分的流量運作有問題也可以很快的rollback回來

這個方式的特性有:

• 更換快速
• 零停機時間
• 無需額外的基礎設施
• 最大限度地減少對用戶的影響（發布失敗時）
• 需要向後相容性（資料和應用程式）

佈署的方法:Rolling

有以下兩個步驟:

1. V2 推出到一定百分比的量能（例如5%）
2. 步驟 2..N：V2 逐漸更換掉到剩餘舊版本（範例：每次 5%的更換）

此方式的特性有:

• 更換緩慢
• 零停機時間
• 需要自動化和額外的設置
• 無需額外的基礎設施
• 最大限度地減少對用戶的影響（發布失敗時）
• 需要向後相容性（資料和應用程式）

佈署的方法: Blue / Green

有以下三個步驟:

1. V1 還活著
2. 建立V2（或複製）。V1/V2同時存在
3. 將所有流量從V1切換到V2（並刪除V1環境）

此方法的特性有:

• 更版是立即性的
• 零停機時間
• rollback很容易
• 需要額外的基礎設施（在發布期間）
• 服務量能不會減少
• 需要向後相容性（資料和應用程式）

測試的方法: A/B testing

這通常是我們想在新版本中驗證一些新功能。有以下兩個步驟:

1. V2（附新功能）向部分用戶推出
2. 測試成功後，V2 會向所有用戶推出，或者如果用戶不喜歡該功能，我們會返回 V1

測試的方法: Shadow

這個架構與Blue/Green一樣。但在第二步的作法稍有不同

1. V1 還活著
2. 建立V2 （或複製）兩個環境同時存在。 將流量mirror到 V1 和 V2
3. 將所有流量從V1切換到V2（並刪除V1環境）

這種方式的特性有:

• 對生產環境沒有影響：發布前使用真實生產流量測試 V2。還可以擷取並重播即時的生產流量
• 但複雜：如果是跟錢有關的，我們可不希望重複付款（可能需要存根）
• 需要大量額外的基礎設施（發布期間）

GCP 運算資源的部署支援

以上討論到這麼多種的佈署與測試策略。哪麼在GCP的各種運算資源又是怎麼實際執行的呢?

GCE — MIG的佈署與測試

App Engine的佈署與測試

GKE的佈署與測試