一、前言：為何要將主機搬遷上 GCP？

其實將主機搬遷上雲的理由和好處很多，這裡提供三個最重要的理由如下：

(一) 降低成本

GCP 是每月依使用量計費，每月付款，企業可以從一次性大額採購的「資本支出」，轉變成每月的「費用支出」，減低現金流的壓力。

此外，實體機要考慮機房、水電相關設備的建置和維護成本，在管理上也是耗費不少心力。

而公司採用雲端，等於就是把基礎建設外包給專業的 Google，你可以省下許多寶貴的時間，然後專注在開發公司產品或提供服務，為公司創造更大的價值。

(二) 彈性擴充

在地端，你的機器數量是固定的，如果碰到活動期間，需要緊急擴充機器，往往要走採購流程包含詢價、議價、選商，以及後續的安裝建置，等到機器準備好了，活動都結束了。

而在雲端上有所謂的自動擴充 (Autoscale)，你可以在 GCP 主控台上設定擴充的功能，指定要擴充的數量，接著 GCP 會依照當前主機的負載，如果主機太過於忙碌，GCP 會立即增加主機來對外服務。當活動結束，人潮退去時，機器也能自動縮減，不會讓它閒置導致額外的花費。

(三) 創新整合

和其他公有雲相比，Google 的強項就是大數據分析與人工智慧。如果你的系統在 GCP 上運作，可以輕易導出資料到 BigQuery 來分析，發現洞察。你也可以將資料用來訓練模型，開發 AI 應用程式。不需要尋找外部工具，從頭到尾都在 GCP 做完。

當你開發完成，也可以直接在 GCP 上部署 AI 應用，或是做為  API 讓外部來呼叫，這些都是 GCP 內建的功能，讓你從收集資料、開發模型、測試模型到部署 AI 應用，都可以透過 GCP 來達成。

從商業的角度來看，就是加速你回應市場的速度，當市場上有新的技術或是新的商機出現，你就可以快速的在 GCP 取得各種創新資源，讓你可以快速的開發出應用程式，提供給廣大的使用者。 

以上只列出常見的上雲理由，如果你想知道更多，可以參考《企業上雲的10大理由、15個評估面向與6大好處》和《上雲比較貴？雲端和地端的成本詳細比較》這兩篇文章。

二、主機搬遷類型

將主機搬遷上雲有很多方法，我們可以依照系統的狀況 (例如好不好搬遷)，和公司的時間表 (有沒有急迫性或是足夠的人力) 來選擇適合的搬遷類型，這裡分別介紹如下： 

(一) 更換主機 (Rehost)：照原來樣子搬遷 (Lift And Shift)

這種搬遷方式就像是單純的搬家，把所有東西從舊環境搬到新環境，期間只做最少必要的調整。就像是把傢俱從舊房子搬到新房子，只需要因應新房子的格局做一些微調而已。

當你的系統可以直接在新環境運作，或是當業務上沒有需要對系統做太多更改，又或者當你需要快速完成搬遷時，這種方式就特別適合。

這種方式的優勢在於執行起來最簡單，團隊可以繼續使用熟悉的工具和技能，而且支援現成的軟體，最重要的是搬遷速度最快。

但這種方式也有其侷限性，系統無法充分發揮雲端環境的優勢，也無法善用 GCP 的特殊功能，包括自動擴充的能力、更靈活的計費方式。這就像是把老房子整棟搬到新地點，雖然可以快速入住，但無法享受新社區提供的現代化設施。

不過企業會因為各種因素，不得不採用這種方式，例如程式碼太老舊或複雜而不容易修改，或是重新編譯程式很困難，又或者必須持續維持系統運作而沒辦法停機重做。

(二) 更換平台 (Replatform)：重新優化 (Lift And Optimize)

想像一下，這不只是單純的搬家，而是搬家時順便整修。就像是搬到新房子時，不只是搬運傢俱，還會順便更換一些老舊的設備，或是重新規劃空間跟裝潢，讓新家更好用。

把主機內的系統搬到 GCP 上，讓它能用上更新、更有效率的工具和服務。這種搬遷方式最適合那些希望充分運用雲端核心功能的組織，包括彈性運算能力、系統備援、提升效能和加強安全性等優勢。

舉例來說，你可以將應用程式轉移到 GCP，以便使用 Google Kubernetes Engine 提供的微服務架構或容器服務。這樣一來，系統在雲端運行時就能發揮更好的效能和效率。

不過呢，這種搬家方式當然會比單純搬家麻煩許多。因為新環境的設備和系統都不太一樣，所以需要多花時間測試、調整，確保所有東西都能完美運作。就像是要學習使用新家裡的各種 AI 電器，需要一段適應期一樣。

(三) 重構 (Refactor)：徹底改造升級 (Move And Improve)

重構這種搬遷方式就像是趁搬家時，不只是簡單改裝，而是徹底翻新改造，讓系統能充分運用雲端的各種優點，已經不是針對「主機」來搬遷了。你可以針對效能、功能、成本和使用體驗，把每個部分都改造得更好。

這個改造工程可以選擇在搬到雲端時一起進行，也可以提前先做好。就像是裝修房子，如果你是第一次做大規模裝修，可能會想等搬家時再一起處理。但如果你有經驗，就能提前規劃好需要改造的部分，讓系統更好地運用雲端的功能。

有時候你會被迫選擇重構，因為舊系統的架構可能無法直接在新環境中運作。又或者是趁這個機會，你想要對系統做一次大規模的更新和改進。

重構的好處是你的系統可以充分運用雲端平台的特色，例如自動擴充 (Autoscale) 的功能，或是提高系統的穩定性。你還可以讓系統變得更容易在不同平台間轉移。

不過呢，重構需要花比較多時間，畢竟要把整個系統重新改造一番。而且你的團隊可能需要學習新的技術和工具，就像是要學習使用全新的裝修工具和材料一樣。

(四) 重新設計架構 (Re-architect)：全面改頭換面 (Continue To Modernize)

這種搬遷方式和前面說的重構有點像，但更加徹底。它不只是改變系統程式碼的運作方式，而是完全重新設計整個系統的運作模式。

這就像是不只是翻修房子，而是把整棟房子拆掉重建，讓它能充分運用新環境的優點，像是更好的擴充性、安全性和靈活度。

最經典的例子就是從單體式架構（Monolithic）轉換成微服務（Microservices）架構。單體式架構就像是一間大型百貨公司，所有部門（功能）都在同一棟大樓裡，所有服務都綁在一起，任何一個小改動都要動到整個系統。並且擴充時必須整個系統一起擴充，如果有一個地方出問題可能影響整個系統。

而當我們改成微服務架構後，就像是把大百貨拆分成許多專賣店，每個服務都是獨立的小系統，可以個別更新和維護，當需要擴充時，可以只擴充需要的服務。

某個服務出問題時不會影響其他服務，不同的服務可以使用最適合的技術，不一定都要使用虛擬機器，有的可以用 Cloud Run，有的可以用 GKE。

不過要注意的是，這種全面改造比一般的重構更複雜，需要投入更多時間和心力。而且在重建的過程中，可能會不小心引入一些程式錯誤或安全漏洞。

因此，需要進行多次測試，確保新系統的每個部分都能完美運作，就像是新蓋好的房子需要仔細檢查每個管線和設備是否安全可靠。

(五) 重建 (Rebuild)：完全推倒重來 (Remove and Replace or Rip and Replace)

重建就是重寫，就是先把現有的系統停用，然後重新設計並開發一個完全針對雲端優化的全新系統。

什麼時候會選擇重建呢？通常是在這些情況：

• 當你覺得舊系統已經不值得繼續維護
• 當其他改造方式的成本太高
• 當舊系統根本無法在 GCP 上運作

重建的好處是，新系統可以完全發揮 GCP 的優點，像是自動擴充、完整的雲端服務支援，以及超高的系統穩定性。而且因為是從頭開始，你不用被舊系統的技術包袱拖累。就像蓋新房子可以使用最新的建材和設計，不用被舊房子的格局限制。

但是呢，重建需要最多的時間，比其他方式都久。而且因為要重寫整個系統，所以不適合用在現成的軟體上。你需要把重新設計和重寫的時間都算進整個專案的生命週期裡。

另外，你的團隊可能需要學習全新的技術和工具，因為要用新的工具來設定環境並部署系統。這就像是要學習使用全新的建築工法和工具來蓋房子一樣。

(六) 重新購買 (Repurchase)

這種方式最簡單，就像是不想修理舊電器，直接去買新的雲端服務來用，其實就是不搬遷了，直接買新的來用。

舉例來說，與其維護公司自己的郵件系統和檔案系統，不如直接改用 Google Workspace (就是 Google 的企業版 Gmail、雲端硬碟等服務)。

從資源投入的角度來看，這種方式比重構、重建或重新設計架構簡單多了。就像是比起修理老舊的冰箱，直接去買一台新的智慧冰箱來用比較不費心。

不過要注意的是：

• 這種方式的花費可能比較高，因為要持續付費使用服務
• 你可能無法完全掌控系統，因為是用人家現成的服務，就像是租用別人的設備，雖然方便，但無法像自己的設備那樣隨意改造和調整，自由度比較低。而且有可能會被綁住，沒有辦法輕易更換系統，或是匯出資料。

綜上所述，我們可以把各種搬遷類型整理如下：

如果想完整了解搬遷類型，可以參考這份文件。

三、主機搬遷步驟

根據 GCP 官方部落格提到，搬遷的步驟如下圖：

(一) 盤點 (Assess)

在進行搬遷之前，請評估您的應用程式以及它們對 GCP 的適合程度。

需要考慮的事項包括 (但不限於) 硬體和效能需求、使用者、授權、合規性需求和應用程式相依性。

一般來說，應用程式大概分種三種：很好搬、很難搬和不能搬。通常建議先選最好搬的，或是測試中的系統，或是較不重要的應用程式，因為搬遷中碰到問題，畢竟不是核心系統，對公司影響較小。

(二) 測試 (Pilot)

這步驟主要是讓你在搬遷過程中熟悉整個操作流程和 GCP 的搬遷介面，對於複雜的系統也可以測試，尤其是有授權議題的主機，如果搬遷有問題也可以試著回溯 (Roll Back)，確保到時候正式搬遷會有一個 (Plan B) 備用計畫。

(三) 搬遷資料

根據Google官方的說法，建議先搬遷資料到 GCP，再搬遷應用程式，因為你的應用程式要能正常運作，必須要先存取到資料，否則應用程式即使搬上去，因為它撈不到後端的資料，還是會出問題。

在下一段會先分享搬遷主機的方法，你可以先試著搬遷不需要連接外部資料庫的主機，確認都沒問題的話，再搬遷資料庫，最後再搬遷應用程式。

(四) 搬遷應用程式

正式搬遷的時候，盡量保持用最簡單的流程和方法，並且執行最少的操作。 

(五) 優化

在搬遷完成之後，你可以考慮讓你的系統運作的更好。例如增加可用性 (HA)，或是使用自動擴充 (Autoscale) 以及使用監控程式 (OPs Agent)，或是把靜態資料放在 Cloud Storage。

而在實務上，我們通常不會等到搬遷完成才開始優化，而是在搬遷之前，就會依照應用程式的特性，來判斷他適合在什麼樣的 GCP 服務上面運作。前面規劃的越多，後面花在調整的時間越少。 

如果想完整了解搬遷步驟，可以參考這份文件。

四、主機搬遷具體方法

由於大多數使用者在地端運作的系統，都是單台虛擬機器的形式，本段針對大家最常用的「更換主機」 (Rehost) 這一類型，依照使用的工具，分成 Migrate to Virtual Machines 和 VMware HCX 來說明如下。

(一) Migrate to Virtual Machines

Migrate to Virtual Machines 是一個代管的服務，就是一個網頁介面，讓你可以直接在網頁上操作並監控整個搬遷的過程，操作起來非常簡單。

你可以直接匯入主機的映像檔，也可以讓主機平行運作，就是讓地端主機還在運作的同時，複製主機的資料到 GCP 上，複製並確認完後再進行切換動作。

如果你有大量主機要搬遷，你不用一台一台機器手動設定搬遷，你可以把多台主機設定為同一批次，讓他們同時複製資料到 GCP。

不過要注意的是，並非任何作業系統的主機都可以搬遷，目前支援各種 Linux 和 Windows Server 作業系統的 64 位元 x86 虛擬機器，另外也支援 Oracle Linux 作業系統。

但是要注意版本，像是太舊的版本像是 CentOS 6 雖然可以搬上 GCP，但是主機有問題，GCP 是無法提供技術支援的喔！對於支援的作業系統完整清單，可以參考這份文件。

以下分別描述 Migrate to Virtual Machines 各種搬遷方法：

1. 匯入主機檔案

(1) 匯入虛擬機磁碟映像檔 (Virtual Disk Images)

如果你手上有現成的虛擬機磁碟映像檔，可以直接匯入，完成之後可以馬上用這個映像檔，在 GCP 建立和地端一樣的虛擬機器。

虛擬機磁碟映像檔支援的格式包含：VMDK、VHD、VHDX、VDI、QCOW、QCOW2、QED 等，也支援 .tar.gz 檔案，你要確保壓縮檔案包含名為 disk.raw 的單一檔案。

不過要注意的事，這個虛擬機磁碟映像必須要先儲存在 Cloud Storage，所以你必須要先上傳檔案，然後再去 Migrate to Virtual Machines 的主控台上匯入它。

而在匯入之前，由於 Migrate to Virtual Machine 這個服務背後是有一個 Service Account 在運作，而它目前沒有權限去 Cloud Storage 存取任何檔案，所以我們就先去給它賦予權限。

我們進入「IAM 與管理」=>「身分與存取權管理」=>再勾選「包含 Google 提供的角色授予項目」：

接著視窗往下滑，會你看到像這樣的 Service Account：

service-xxxxxxxxxx@gcp-sa-vmmigration.iam.gserviceaccount.com

接著點擊 VM Migration 服務代理右邊的鉛筆圖示：

接下來就可以把你準備好的 VMDK 檔案上傳到 Cloud Storage：

上傳完成之後，你就可以點擊 Compute Engine 的 Migrate to Virtual Machines。接下來可以點擊「映像檔匯入作業」：

接著再點擊「建立映像檔」：

接著它就會進入建立映像檔的畫面，首先就是在 Cloud Storage 選擇要匯入的檔案，接著由於虛擬機映像檔會轉換成 GCP 格式的映像檔，所以我們要另外選擇儲存的位置，看你要多區域 (例如 Asia) 或是單一區域 (例如 asia-east1) 都可以：

當我們選好檔案跟儲存位置後，再選擇要儲存映像檔的專案，因為你手上可能有不只一個專案，它讓你不一定只能使用現有的專案，可以選擇匯入到其他你有權限的專案。

但你點擊下拉選單之後，你會發現沒有目標專案可以選，因為它必須要事先勾選起來，才會在這個畫面看到可以選擇的專案。但是沒關係，我們也可以在這裡直接設定，點擊「管理目標專案」：

點擊之後，它會開啟新的視窗，我們再點擊「新增目標專案」：

接下來它會彈出一個視窗，讓你勾選目標專案，我們勾選後就按下新增：

接著畫面會跳轉到目標專案，你可以再確認一次：

再回到原來的分頁，按下「重新整理」：

等待幾秒之後，專案就秀出來了，選擇這次要建立映像檔的目標專案：

上述相關欄位設定好之後，會看到像這樣的結果。其中還有兩個選項需要注意。

(1) 略過 OS 調整作業：

指的是為了讓你在地端的主機可以在雲端上運作，它需要做一些調整，才能讓它在 GCP 上開起來。包含：

・Serial Console (讓你在SSH無法連線時還能操作主機)

・網路設定 (讓主機可以連到 VPC 內的主機、其他 API 和上網) 

・Cloud SDK (讓你可以下 gcloud 指令操作 GCP的資源)

如果你匯入的映像檔不是拿來當作開機碟，那可以勾選「略過 OS 調整作業」，如果是，就不能勾選，要不然主機會無法在 GCP 成功開啟。更多細節可以參考這份文件。

(2) 一般化：

通常是針對 Windows 作業系統，因為 Windows 作業系統會有一些「針對該主機的識別資訊」，例如 SID (Security Identifier)，勾選「一般化」可以將其識別資訊洗掉，以便部署到其他地方，才不會有識別碼衝突的問題，而 Linux 沒有這方面的問題，不用勾選。更多細節可以參考這份文件。

如果都沒問題的話，可以按下「建立」：

接下來畫面跳轉到 Migrate to Virtual Machines 主頁，看到正在匯入映像檔的訊息：

我們等待一下，因為這個動作都在 GCP 上進行，我們可以關掉視窗，稍後再回來查看即可。

接著我們就看到 VMDK 檔案已經匯入成功，看到它已經成為 Compute Engine 的 Image 了。

接下來我們可以直接點擊箭頭圖示，直接轉到 Image 的頁面：

然後點擊「建立執行個體」，把它開成一台 GCP 的主機：

就跟一般建立機器的步驟一樣，我們給主機取名字，並選定規格：

其他參數可依照你的需求設定，沒問題就可以按下「建立」。

過幾秒後看到主機建立完成，我們點擊 SSH 按鈕：

看到 SSH 視窗成功開啟，代表我們從地端匯入 VMDK 檔案成功囉！

如果你的機器能開機，但是連不進去的話，先不要慌，你還是可以透過 Serial Console 調整一下主機，可以參考這份文件。

(2) 匯入機器映像檔 OVF, OVA

這個方法跟前一個幾乎一樣，都是先把檔案上傳到 Cloud Storage。但不同的地方是，前段的映像檔只有開機磁碟而已，如果你的主機有加掛磁碟的話，你就必須再匯入另一個映像檔，等到兩個映像檔都匯入完成，再用第一個映像檔來開機，再手動掛載另一個映像檔的磁碟。

機器映像檔則是直接包含一台主機所有的磁碟，如果你匯入機器映像檔，你就不用手動匯入多個檔案了。

首先我們點擊「建立機器映像檔」：

我們一樣設定作業名稱、來源、部署區域、目標專案等等，沒問題就按下建立：

接著就等它開始作業，我們可以在畫面上確認機器映像檔匯入的進度：

確認匯入成功後，一樣進入機器映像檔管理控制台，用機器映像檔來建立機器：

我們在主機列表看到機器成功建立，接著點擊 SSH 按鈕：

接下來就看到 SSH 連線成功的畫面，確認匯入成功。

關於匯入映象檔或是機器映象檔，還有一個更簡便的方法，不過它是使用 gcloud 指令來操作 你可以參考這份文件。 

上述方法最容易卡住的地方，就是我們要匯入的檔案有問題，可能是作業系統或是檔案格式的問題，造成匯入失敗的機率很高，所以請再匯入之前多確認映像檔的內容。

2. 從地端 VMware 環境搬遷主機或 Disk

這個方法的前提是你在地端必須要有一個 vSphere 資料中心，然後再搬遷之前會有一系列的前置作業，讓你的地端和雲端可以連接在一起，之後才能開始搬遷，如下圖：

雖然比較麻煩，但是它可以針對大批的主機一口氣快速搬遷，而不是像上述方法一台一台操作。

此外，因為主機是在 VMware 環境，搬遷到 GCP 有比較高的相容性，所以這個方法成功率高很多。 如果你在地端有大量的主機需要搬遷，強烈推薦使用這種方法。

搬遷的前置作業分述如下：

(1) 挑選一個主要專案 (Host Project)

如上圖，我們在雲端上有多個 GCP 的專案，你可以挑選一個主要的專案 (Host Project) 來負責執行搬遷工作，但是你搬上來的主機不一定要部署在這個專案上，你也可以部署到另外一個專案上去。

(2) 啟用相關的 API
由於搬遷過程中會呼叫 GCP 各種不同的 API，所以我們要事先啟用，這裡提供一個快速的指令，讓你可以直接複製貼上，然後在 Cloud Shell 或是你有安裝 gcloud CLI 的電腦執行：

gcloud services enable vmmigration.googleapis.com servicemanagement.googleapis.com servicecontrol.googleapis.com iam.googleapis.com cloudresourcemanager.googleapis.com compute.googleapis.com

(3) 授權給相關人員

如果有許多人員要參與搬遷，你可以授權這兩個角色給相關的人員：

VM Migration Administrator：是給執行搬遷的人員使用。

VM Migration Viewer：如果其他的人想要查看搬遷的相關資訊，不直接動手操作。

(4) 在 vCenter 建立使用者帳號

因為我們會在 vSphere 建立一台主機，並且安裝 Migrate Connector，而這個 Migrate Connector 需要有一個使用者的帳號，並且要擁有相關權限，才能夠呼叫  vCenter的API，去把 VMware 主機的資料拉出來並且搬到雲端上。

(5) 在 GCP 準備一個使用者帳號和服務帳戶

這個使用者帳戶必須要有權限，才能註冊 VMware 上的 Migrate Connector 主機到 GCP。它只有在註冊的那一刻需要相關的權限，只須執行一次性的註冊動作。

而在 GCP 上面也要有一個服務帳戶，用來存取 19 項 GCP 資源，來完成搬遷的動作。 如下圖：

(6) 設定網路存取

在 GCP 這邊，因為都是開放的 API，比不需要特別再去設定，反而是地端那台 Migrate Connector 主機，要確保網路流量可以存取得到 vCenter、vSphere 和上網存取 GCP 相關服務。如下圖：

如果防火牆也有限制，要記得開放存取到 *.googleapis.com 和 gcr.io 這兩個網域喔！

(7) 建立連線到 Migrate Connctor 所需的 Key

為了要安全的連到 Migrate Connctor ，你必須建立一組金鑰，等到這台機器建立完成，你就要透過這個金鑰連線進去操作。你可以在任何地方使用 ssh-keygen -t rsa 這個指令來建立金鑰，如下圖我們是用 Mac 本機電腦來建立的：

(8) 安裝 Migrate Connctor
接下來環境切換到 vSphere，點擊 Deploy OVF Template 然後貼上 Migrate Connector 機器映像檔的網址：

接下來等它安裝完成，看到主機的資訊如下：

(9) 連線到 Migrate Connector 主機並註冊到 GCP 

我們使用 SSH 連到 Migrate Connector 主機之後，輸入 m4c register 開始註冊，經過一連串的互動操作，可以看到註冊成功的畫面：

我們回到 Console 上就會看到地端的機器列表，這時我們就可以選定要搬遷的主機：

雖然是將主機一模一樣的搬到 GCP，但是我們並不一定要使用一模一樣的規格，我們可以設定部署的規格跟環境：

接下來就開始進行資料複製的動作，等到複製完成，我們可以先點擊「Test-Clone」，來觀察資料是否都複製完成，它會建立一台測試機，讓你進去檢查。如果確定都沒問題的話，我們再點擊「Cut-Over」 ：

最後我們可以在 Console 上看到主機切換完成的相關訊息：

這裡要注意的是，它的「切換」會把原來的地端主機「直接關機」，如果你不希望機器被關，目前的方法就是再手動把它開起來。 

很多使用者會藉由這個功能，執行雲地資料同步的動作，不過不算正規方法，所以沒有備份的保證喔！只是因為做起來很方便，單純分享給各位參考！

(二) VMware HCX 

GCP 本身可以建立一個純粹的 VMware 環境在雲端，叫做 VMware Engine，而這個環境可以和地端的 VMware 環境連結在一起。既然兩邊都是 VMware，就可以使用 VMware 本身的 HCX 將地端的主機無縫的搬遷到雲端上，但不是 Compute Engine 主機的形式，而是 VMware 格式的主機。

所以它具體的搬遷方法是由 VMware 所發展的， GCP 就只是提供基礎建設，讓 VMware 可以在 GCP 上面順利運作，整合概念圖如下：

而這樣的服務要在 GCP 上開起來，必須要使用通過 VMware 認證的主機，我們可以從「VMware Engine」進入「私有雲」，然後點擊「建立私有雲」 ：

接下來你會發現台灣 (asia-east1) 並沒有提供這樣的環境，VMware Engine 離台灣最近的資料中心在新加坡 (asia-southeast1)：

另外我們在設定節點數量的時候，系統會要求至少要三個節點以上，而每個節點的規格是 72 個 vCPU和 768 GB 的記憶體，以及1.92 TB 的 Disk 空間，可以知道它的費用不低，有一定規模的跨國企業才有機會使用這樣的服務：

我們在 YouTube 看到有人示範 HCX 操作的畫面，功能和 Migrate to Virtual Machines 很像，首先就是勾選要搬遷的主機：

接著我們就設定主機要搬遷的目的地：

在設定的過程當中，也可以設定目的地的主機規格和環境參數，你還可以設定搬遷的排程，例如在幾月幾號的幾點開始搬遷。

開始搬遷之後，你也可以在畫面上看到搬遷的進度：

關於更多 HCX 的操作細節，可以參考這份文件。

另外這樣的規模通常都不小，我們可以聯絡代理商或是 Google 原廠，來提供相關的技術服務喔！

五、結論

最後我們總結從地端搬遷主機到 GCP 的方法，整理比較表如下：

不管你是哪一種企業規模或是場景，都建議你先從匯入映像檔的方式開始，不是真的要你在正式搬遷都用這個方法，而是要你藉由這個動作，去熟悉整個搬遷的流程、細部操作和相關的注意事項，讓你了解搬遷過程的全貌。

這樣才能在正式搬遷之前，做好完整的評估和規劃，和搬遷失敗的處理方式，讓你確保在公司系統照常運作，影響最小的前提之下，讓搬遷順利成功。

本文同時刊登於：

【東東老師 X 思想科技】地端主機如何搬上 GCP？（上）

【東東老師 X 思想科技】地端主機如何搬上 GCP？主機搬遷具體方法（下）

The post [GCP 教學] 地端主機如何搬上 GCP？各種方法和步驟詳解 first appeared on 東東 GCP 教學 - GCP 實戰講師.

很多 IT 人員在比較雲端和地端成本的時候，

通常都會直接比較主機的費用，忽略了許多地端環境隱性的成本，

每次計算的結果都顯得雲端好像比較貴，

導致上雲的決策一直被延後，失去先機。

我們就來好好分析一下，如何徹底比較雲端和地端的成本。

一、機房建置成本

1.辦公室租金

如果公司具有一定規模，通常會隔出一大間，

甚至一層樓專門來營運機房，

既然佔用辦公空間，就會有租金的成本，

要知道，租金佔公司每月支出的比例是不小的，

如果能夠省下來，對公司的財務負擔必能減輕很多。

2.空調系統

機器運轉容易過熱，過熱就容易造成機器毀損，或引發火災，

為了防止事件發生，都會安裝冷氣系統來維持機房適當的溫度，

而機器吹的冷氣溫度都比我們人類還低，因此本身的耗電量也很大。

3.電力系統

機房擺滿各式各樣的機器，

電壓和電量不是一般辦公室的電源就能供應，

尤其很多對外服務、24小時運作的主機，

不能因為任何「不可抗力因素」(例如跳電、停電) 就停止服務，

就算要停電，也要有能力讓主機能夠「正常關機」，

例如資料讀寫完成，或是使用者都正常登出，

確保不會有資料不一致，或硬碟損壞的情形，

因此 UPS (不斷電系統) 就是必備，

再來是發電機和配電系統，來確保機房持續供電。

要知道，除了設備本身的費用，還有高昂的電費！

4.防火設備

像上面提到機器過熱、電源異常或電線走火，

都很有可能導致火災發生，

一方面是人員傷忙和公司財務損失，

另一方面則是主機的資料損失，

若丟失客戶重要資料，

極有可能面臨訴訟、賠償甚至公司倒閉的風險。

因此火災報警系統、滅火器、和自動灑水系統等，

也都是基本必備的建置成本。

5.安全設施

例如門禁系統，使用基本的門禁卡，或是人臉或指紋辨識，

依照公司或合規需求，有不同的安全等級。

還有監控系統，必須24小時不間斷錄影，

當事件發生時，必須能夠快速找到監控影片，

這有賴監視器穩定運作，並且能妥善儲存在可靠的儲存系統中。

6.網路設備和連接

包含交換機、路由器、防火牆，會依照公司網段規劃、

使用者人數和資安需求，有不同的規格和等級。

而機房設備之間的主機相連，同時要提供公司人員連線，

以及主機或設備更換時，要跟著調整線路，

因此也需要找專業廠商來規劃一個好的佈線方式，

以便後續的各項維護。

如果今天對外服務的流量很大，例如線上遊戲、直播或電子商務，

為了確保對外流量穩定，還需要有獨立的對外網路，

頻寬越大費用越高，都是要納入成本的考量。

7.機櫃成本

各種主要和網路設備，不是買來直接放地上，

然後電源和網路接上就可以了，

還要整齊放在機櫃上，方便人員收納和維護機器，

而機櫃還要配合機房大小，和各種設備的尺寸，

各種考量之下才能挑選合適的規格。

由此可知光是機房本身，就可以有這麼多成本，

而今天如果使用雲端的話，就不用機房了，

當然不可能完全不用，但至少不用空出這麼大一間，

只需要提供人員上網所需的設備即可，成本是可以大幅下降的。

二、主機成本

1.直接主機成本

這裡的主機包含伺服器，

還有儲存設備像是 NAS (Network Attached Storage)，

通常使用者會將一次性採購實體機的費用與雲端主機的單價來比較，

使用雲端主機的單價，乘上使用的時間，

得到的總費用往往高於一次性採購的金額。

其實這裡有很多可以討論的地方，

如果我們故意延長實體機攤提的年限，一台機器如果用個十年，

長期攤提下來，似乎地端主機比雲端主機的費用低很多，

但你可能會忽略後面會提到的隱藏成本。

另一方面，GCP 也有提供續用折扣 (Sustained Use Discount)

和承諾使用折扣 (Committed Use Discount)，

折扣最高可以達到 57% OFF，也就是 43 折，

對於長期用戶來說是很有競爭力的價格。

2.虛擬化軟體

伺服器不能直接運作虛擬機，必須先安裝虛擬化軟體 (Hypervisor)，

像 VMware 就是台灣企業在地端環境使用最多的虛擬化軟體，

而在台灣的用戶當中，約8~9成的用戶是直接購買永久授權，

只要 CPU 數量不變，硬體升級都不用額外購買授權。

而自從 VMware 在 2023 年底改成訂閱制，

硬體升級都要再購買軟體授權，直接墊高了企擬化的成本。

而在雲端上，「虛擬化」這件事是 Google 已經做好的，

你不需支付任何「虛擬化」的成本。

3.主機汰換

地端主機如果過了保固期，出了任何問題的話，

可能要請人來維修，或是乾脆再買一台新的，

請人來修會耗費時間，買新機器又是額外的主機成本，

這是很容易忽略的隱藏成本。

但是在雲端上，主機有問題的處理方式就是，

刪除重建就好，馬上就得到一台新的機器，幾乎不會增加任何成本。

(前提是你有先做好自動備份，而在雲端上做到自動備份非常容易)

4.閒置主機

雖然購買實體機，可以長期攤提來壓低成本，

但有一種狀況是，

一台高規格(例如 96 個 vCPU)的主機運作虛擬化環境，

但裡面只跑一台規格很小的虛擬機 (例如 4 個 vCPU)，

因為有虛擬機在跑，你又不能關機，但其他資源都閒置在那邊。

甚至，你可能根本不知道，那台小虛擬機是用來做什麼的，

你決定把它關機了，發現沒事，也沒人哀號，

但過了2個禮拜，有個同事跑來問某個系統為什麼進不去。

這是地端常有的問題，幾十台主機藏在機房各地，

有的甚至不在機房。

每一台主機是用來做什麼的，沒人知道，

反正不要停就好了，不知不覺浪費多少資源。

三、維運人力成本

1.維運人員或外包合約

像上述所有提到的每一個東西，全部都需要維護，

怎麼可能維護得完？

而且維護要有足夠的「人力」和「能力」，也要有時間，

但是不用擔心，不管你買的是軟體或硬體，

廠商都貼心地提供你維護合約，

東西壞了，請廠商來修就好，但是要付錢。

而在 GCP，只需評估尋找專業的代理商，

依照每月 GCP 使用費的固定比例，支付給代理商即可。

2.訓練費

雖然有維護合約，但有些東西還是要自己學會，尤其是軟體，

像是 VMware，你要設定虛擬網路環境，

要開幾台機器，不可能請廠商來幫你設定，

還有備份軟體、防火牆、路由器等等，

只有自己清楚公司內部的情況，

那怎麼辦？你可以加購原廠的課程，

有些廠商會送，有些還是請你付錢，

如果你怕工程師學到東西就跳槽了，

你還要簽約確保他能在在公司待得夠久。

那你可能會反駁，學 GCP 也要花錢去學啊！

不過學一套 GCP 可以抵消學地端好幾套，

虛擬化完全不用學，備份主機和設定防火牆也是滑鼠點幾下，

而路由是全自動的，有需要再調整就好。

所以你採用雲端之後，省下大量授權軟體的成本，

同時也省去教育訓練的成本。

四、綜合比較 

依照上述各項成本的比較，我們將雲端和地端成本項目整理如下表：

其中我們可以看到，伺服器和作業系統授權，

雖然在雲端上的費用稍微高一點，

但是完全沒有虛擬化軟體的費用，

也沒有主機汰換和閒置主機的浪費。

更不用說，完全沒有機房成本。

除此之外，採用雲端也會帶來支出方式的改變，

從財會角度來說，從資本支出轉變成營業費用，

和原本一次性採購大批軟硬體的方式不同，

因此減少了一口氣龐大支出的負擔。

更重要的是，雲端是每月依使用量計費，

公司每個月都會收到帳單，

管理人員很容易和前幾個月的費用做比較，

例如某個月費用突然變高，很快就能透過帳單報表去查明原因，

進而刪除不必要的資源，強化了費用控管，讓錢真正花在刀口上。

總結來說，由於地端的成本項目大多為一次性支出費用，

如果公司規模大到能夠以量制價，並且能提供大量人員使用，

就是要用量越大、越多人用、用得越久，才能壓低平均成本，

要不然使用雲端終究還是比較划算的。

本文同步刊登於 思想科技官方網站 《上雲比較貴？雲端和地端得成本詳細比較》

The post 上雲比較貴？雲端和地端的成本詳細比較 first appeared on 東東 GCP 教學 - GCP 實戰講師.

近年來，企業使用雲端已是趨勢，

你常常會聽到某知名公司採用雲端之後，

加強了效率，或是提昇業績等等，好像上雲之後就更成功了。

但是那些內容，到底是真是假？能否相信？

其實到底要不要上雲，問你自己，不要看別人上，你就跟著上。

為此，本文以 GCP 為上雲標的，

給你10個充份的上雲理由、15個評估面向與6大好處，

讓你可以跟老闆報告下定決心。

一、企業上雲的十大理由

1.節省成本 – 單筆大額採購轉成按需付費 

雲端是每月依使用量計費，每月付款，

企業可以從一次性大額採購的「資本支出」，

轉變成每月的「費用支出」，減低現金流的壓力。

此外，實體機是放在機房，

因此也要考慮機房、水電的建置和維護成本。

還有一種看不見的成本，就是人力，

主機買來需要插上電源、連上網路、安裝作業系統，各種維護工作，

以及人員是否有足夠能力和意願維護各項基礎建設，

還有離職的風險，其成本可能更難以估算。

相對於不可控的維護人員，直接採用雲端就是比較省事的做法。

2.擴展性 – 根據業務需求隨時調整用量

例如在離峰時間，可保持 1~2 台機器維持服務的基本運作要求，

而尖峰時間，可以彈性增加機器數量來因應使用者需求。

而傳統地端環境無法即時擴充，缺機器的時候，

往往要走採購流程包含詢價、議價、選商，以及後結續的安裝建置，

和雲端相比之下，早就喪失了先機，

這是地端環境遠遠比不上雲端的一大因素。

3.自動化 – 串接各項服務完成工作

當你把系統各項元件，都部署在同一個 GCP 環境之後，

不同服務之間的串接，就變得非常方便。

尤其是自動化流程的設定，

除了最基本的 CI/CD 流程，可以觸發 Cloud Build 幫你測試程式、

建立容器映像檔和部署到 Cloud Run 或 GKE 之外，

還可以透過 Cloud Schduler 定期呼叫 Cloud Function，

來執行各項排程工作，例如自動開關機、擴展或縮減機器、

備份資料、生成報表、檢查閒置資源、

發送各種提醒、更新系統、資料處理等等，

你不再需要第三方工具，整合方便，

也不會因為某一台 Linux 主機異常，

導致內建的 Cronjob 無法執行。

4.業務持續性 – 內建備份備援輕易維持運作

地端系統的備份和備援，如果不仰賴第三方工具，

全部都由自己查資料、自己設定的話，通常耗時耗力。

一旦環境有任何變動，就必須隨之調整，以免備份或備援機制失效。

而在 GCP 上，主機和資料庫的自動備份只需簡單的滑鼠點擊，

萬一主機有問題，可以使用區域性永久磁碟，

讓重建的主機擁有最新的資料，

資料庫也可一鍵啟用高可用性 (High Availability)，

不管發生任何問題，備援的資料庫會自動頂替主要資料庫，

持續對外服務，不用人力介入修改連線資訊，非常方便。

5.攻擊防禦 – 各種防禦規則過濾流量

傳統地端環境總是必須購買資安設備，

並且依公司加以設定，才能防禦外部攻擊或入侵。

而在 GCP 上，即使你只有啟用負載平衡器，

就已經內建 DDoS 攻擊的機制，

如果想要再強化防禦，可再加上 Cloud Armor，

從 Layer 3、Layer 4 到 Layer 7 都可以設定規則，

過濾網路流量，保護後端主機。

尤其是 Cloud Armor 依使用量計費，不需一次性支出大筆金額購買。

6.遠端存取 – 任何地點都能安全連線

主機在雲端上，使用者勢必連上 Internet 才能連線，

而主機的外部 IP 曝露在外，也可能引來駭客入侵，

但 GCP 已經發展出各種連線方案，

方便使用者不論在何處，都能進行安全的連線。

除了使用 SSH Key 搭配防火牆限定來源 IP 的連線方式，

也能使用 OS Login 或是 Cloud IAP 來強制身份驗證，

代表你不是有 Key 就可以連線，你必須經過身份驗證才能連進主機，

甚至主機不需要外部 IP，完全阻絕駭客入侵的可能。

相較於 VPN 只能依照流量來源來決定放行，

GCP 的身份驗證機制嚴格且安全的多。

7.先進技術 – 輕易導入大數據分析與 AI

如果你的公司還沒有投入心力做資料分析、機器學習或人工智慧，

你要知道在 GCP 上做到根本太方便，

只要有 CSV、JSON 格式，可直接匯入 BigQuery，

用你本來就懂的 SQL 語法就能馬上分析資料，

並且透過免費的 Looker Studio 將分析結果做成圖表。

而傳統上需要有專家才能做到的機器學習或人工智慧，

Google 已經有現成的模型可以直接呼叫，

如果要客製化的模型，也不需要你懂演算法，

只要提供整理好的資料，就可以訓練你想要的模型，

並且直接部署上線，提供服務給用戶。

在生成式 AI 上，也有 Vertex AI Studio，

不管是生成文字、語音或圖片，

都已經準備好各種模型，

你可以直接調整參數來優化你想生成的內容。

8.環境友善 – 自動產生合規的碳足跡報告

當大家還在煩惱如何執行碳足跡的報告時，

GCP 早已整理好符合 GHGP 的減碳成果，

並且以報告直接呈現，你也可以再匯入 BigQuery，

依照公司需求，製作客製化的報告。

9.專注核心業務 – 將IT基礎設施外包給專業供應商

你不用再支出水電費、機房維護費，不用花時間採購機器。

你也不用再維護實體機了，不用再跑機房接網路線、買最新的乖乖，

機器有問題或設定錯誤，就直接刪除重建，隨時換新機器。

沒有什麼不能重新再來的，不用背負任何包袱或技術債。

10.合規性 – 雲端服務提供商遵循各種法規標準

Google 非常積極地向各大國際組織申請認證，

在台灣也遵守「FSC 銀行外包法規」和「FSC 保險外包行政規則」，

針對「個人資料保護法」，Google 也提供 Google Cloud 白皮書，

協助客戶建立完善的隱私權與安全性的保護機制。

以上希望可以給你充分的上雲理由。

二、企業上雲的15個評估面向

當你們公司決定要上雲了，總是要具體檢視公司現況，

確認是否可以上雲，以及上雲後是否能真正發揮效益。

這裡給你15個具體評估面向，幫助你完成一份強而有力的評估報告。

1.預估雲端成本是否低於地端IT成本

除了「地端一次性採購」 VS  「雲端每月支出」的比較，

你還要考慮攤提的年限，你用5年來比，可能雲端比較便宜，

你改成10年，就變地端便宜。

而且每批設備的採購都在不同時間點，

除了伺服器、防火牆、路由器，

還要計算機櫃、交換機、UPS、冷卻、監控系統等等，

計費方式不同，攤提年限不同，非常複雜，

這部分要動手腳很容易，務必謹慎計算。

此外，往年地端的支出是否都符合預算，

還是每年都有規劃之外的支出，

例如本來今年預算是200萬，

結果發生了資安事件造成資料外洩，

賠償150萬，導入資安工具再花120萬。

預估金額的準確性也會影響到成本的評估。

2.成本掌控程度提昇

如前段所提，地端設備成本計算複雜，

而採用雲端之後，是否能快速列出主機清單，

公司使用多少機器一目了然，

GCP 能針對使用率低的機器或閒置資源，

主動提供降規建議，幫你省錢。

在帳單方面，GCP 有分門別類的帳單明細報表，

還可以依專案、依服務設定不同的帳單警示，

這些都可以確認成本掌控度是否有效提昇。

3.是否能發揮長期策略效益

這部分可以分成「導入新系統」和「推出新產品」兩個面向，

在「導入新系統」部分，

例如公司平常儲存大量的資料，

但都沒使用機器學習或生成式 AI，

未來是否有機會立即採用 GCP 的相關服務，

訓練自己想要的模型，預測關鍵的訊息。

而在「推出新產品」部分，

代表上雲是否可以快速找到合適的資源，

例如品牌公司能否快速架設產品或活動頁面，

媒體公司能否快速上傳和發布內容，

遊戲公司能否部署大量機器供玩家連線使用。

和原始地端環境相比，是否更夠靈活地反應巿場。

4.敏感資料是否能有效控管

原本資料存在地端，只要不對外開放，

至少可以阻隔資料外洩的風險，

但如今上雲，雲端是否能夠建立各種安全機制，

防止駭客入侵，或內部人員堅守自盜？

這一點反而需要請雲端專業人員加以評估。

5.上雲後是否依然合規

你可能會害怕，目前在地端的系統都是合規，結果上雲之後反而不合規。

因此 Google 對於台灣的個資法有提供白皮書，

可以給企業在 GCP 上處理資料時做為指引；

另外金管會對於銀行、保險業者製訂了「銀行外包規定」和「保險外包行政規則」，

Google 也針對 GCP 在銀行業和保險業的規範製作對照表，

都可以幫助你評估是否能夠滿足法規要求。

6.是否能順利移植應用程式

許多經營數十年的企業，內部累積了各式各樣的舊系統和技術債，

(技術債：軟體開發為了便宜行事，短期方便但造成長期負擔的設定)

導致系統的移植變得非常困難。

再加上人員的流動，通常新人無法理解前人的程式碼，

對其就是「只要可以跑，就不要動它」的心態，

除非公司有足夠的開發能量，直接將系統「重寫」，

才能直接採用新的架構部署上雲。

另一個考量點是向外部購買的授權系統，

例如 ERP (企業資源規劃)、CRM (客戶關係管理)、簽核、財會或人資系統等，

可能需要找到廠商重新授權，額外多付一點費用還算小事，

如果該廠商早已倒閉，這才是真正麻煩的地方。

因此，這個面向需要考慮系統重寫的人力，

或是重新購買軟體授權的費用，公司是否可以承擔。

7.資料移轉是否容易

主要分成現有資料和新生成的資料，

現有的資料庫，在 GCP 上是否有對應的版本，

除了資料本身的遷移之外，

還要評估 Schema、Index、Stored Procedure 或 Trigger 是否都能順利重建。

對於新生成的資料，是否能夠接直指向雲端儲存位置，或是必須額外處理，

例如撰寫排程程式，每天夜間執行上傳。

還有移轉期間是否會中斷對外服務，都是要納入評估的重點。

8.是否能整合雲端服務

以監控系統為例，傳統上都是透過安裝在主機上的代理程式 (Agent) ，

來收集指標和 Log，再集中到伺服器端並以圖表呈現，

你也可以依照這個清單，來判斷是否能夠安裝 OPs Agent，

將指標和 Log 傳送到 Monitoring 和 Logging，

也不用再集中到某台機器上，也避免機器異常導致監控失效。

通知功能也能一併調整，像是主機異常或效能警示，

都可以透過 GCP 使用 Email、APP 或簡訊直接發送給相關人員。

另外關於身份驗證的部分，如果系統本身沒有驗證機制，只要搬上 GCP 之後，

也可以直接採用 Cloud IAP，系統本身不需做任何修改。

另外，公司電腦如果採用 Windows 10 專業版以上版本的話，

可以安裝 GCPW (Google Credential Provider for Windows)，

使用者連本機電腦都可以使用 Google 帳密登入，再搭配兩步驟驗證，

即使電腦被偷，他人也無法輕易登入電腦。

少記一組帳密之外，公司也能順勢將裝置納入管理，

例如禁用藍芽或禁用 USB 插槽等，更加提高了資訊安全。

上述提到的監控與身份驗證機制，

如果與 GCP 的整合性越高，未來在各個系統操作的方便性就越高。

9.是否能夠提升頻寬

公司系統的對外網路，是否曾經遇到頻寬限制，

例如使用者觀看影片總是塞車，

可以先確認向網路營運商購買的寬頻方案，

也可以直接在網站主機使用此 Fast 工具來測試當下頻寬大小。

另一方面關於網頁載入速度，

也可以透過 Google 提供的 PageSpeed Insights 來檢查網頁內容載入是否過慢。

此時可以評估透過 Cloud Storage 儲存影片，並使用 Cloud CDN 加速影片發布，

然後模擬大量人員湧入時，影片的觀看是否順暢，

確認是否能夠減少網路塞車的情況。

10.是否能夠降低延遲 

對於需要即時傳輸資料的場景，

例如金融交易、線上遊戲、直播串流和物聯網等等，

對延遲的敏感度非常高，

因此企業可以針對重要的對外服務，建立測試的架構，

測量延遲改善的程度，是否能增添上雲的必要性。

11.是否能提昇可用性

許多企業在上雲之前，應用程式都只部署在一台主機，

萬一碰到效能問題或其他異常，就是直接停止服務，需要人工介入處理。

而在雲端上，不論是主機、資料庫或檔案儲存，

都可以輕易設定成高可用性模式，

有任何一台機器異常，另一台機器仍然可以持續對外服務，不過要注意成本較高。

但即使企業因成本考量，只能部署一台，

也可以設定自動重建，有異常時直接重建，可讓中斷時間變短。

因此企業可以多加評估可用性的部分，是否也能提升用戶體驗。

12.是否能提昇災難復原能力

通常災難復原能力取決於企業的預算是否足夠，

對於較無預算的中小企業而言，災難復原能力總是不足，

如果公司機房因天災人禍造成巨大損害，幾乎影響公司的存續。

而在雲端上，公有雲資料中心通常具有完善的機房規劃，

機房遭逢天災人禍也不會輕易就被摧毀，

而且許多服務都可以設定跨區域 (Region) 儲存，

即使台灣資料中心嚴重損毀，仍然可由國外的另一個資料中心來恢復服務。

企業可依系統和資料的重要性，在可用的預算範圍內，

評估雲端服務是否能提昇災難復原能力。

13.具有備份和還原機制

各大企業通常對於現有系統都有基本的備份和還原機制，

而雲端不論是主機、資料庫和儲存，也都具備。

因此考量重點會著重在費用上，

因為地端的備份和還原機制通常會依賴第三方廠商，有額外花費，

而其在雲端就只是一個內建的功能，額外花費不多。

再來是設定的難易度，多一家廠商就多一個工具要學習，

在雲端上則可以輕易設定完成。

故企業可以從費用和設定的難易度切入，來評估備份和還原機制是否有加分效果。

14.公司人員是否有足夠的雲端維運能力

公有雲原廠，不管是 GCP、AWS 或 Azure，

由於面對全球大企業的需求，

其支援能力都能達到一定的標準，

反而是公司內部必須盤點現有人員，是否具備雲端維運能力。

雲端雖然很方便，但不代表可以完全不去管理，

或是把責任推托給原廠。

當面臨人力不足的情況下，可以評估是否委由專業的代理商協助。

企業可以就支援時間、回應速度、回覆內容專業性、解決問題能力和費用來綜合比較，

選擇具有專業技術，能夠快速解決問題的代理商。

15.服務水平協議是否保證高可用性

每個公有雲，對旗下各個雲端產品，都有相對應的 SLA，

而每一份 SLA 也有詳細說明服務中斷的認定標準、中斷時間的計算方法，

甚至求償方式也都有相對應的說明，務必看仔細。

簡單來說，不是斷線就會賠錢，你可能要設定 HA 才符合賠償標準，

賠錢也不一定會賠現金，可能只會折抵下月費用。

更重要的是，賠償金額遠遠無法覆蓋你的損失，

所以賠多少錢不是重點，你要做的是，

盡可能部署在 SLA 較高的服務，以減少服務中斷的時間。

這裡也提供你一張表格，讓你可以具體判斷目前適不適合上雲，輸入Email免費下載。

當你將各項評估完成之後，可以加總得到一個分數，滿分為75分，決策標準如下：

60分以上，強烈建議上雲。

45～59分，可以評估考慮上雲。

44分以下，暫時不考慮上雲。

當我們有了具體的評估分數，相信你可以更清楚地判斷上雲的必要性。

最後再提醒一點，上雲也不是一口氣全上，某些系統也可能永遠保持在地端，

你可以製作分階段的上雲計畫，先把非關鍵、或測試的系統上雲，

然後觀察一段時間，確認上雲的流程是否有需要調整或注意的地方，

再把核心系統搬上雲端，確保整個過程可以「平步青雲」。

三、上雲的 6 大好處

其實 GCP 還有很多額外的好處，是上雲之後才能慢慢發現的，

因為剛開始上雲，以穩定運作為首要考量，其他都是次要的，

等到系統穩定下來，並且熟悉雲端基本功能和操作後，

就能再擴展其他雲端的使用，並感受到更多好處。

這裡再分述如下：

1.快速部署和擴展新服務 

靈活應對巿場，才能抓住商機，機會是不等人的。

若某個商品爆紅，你在 GCP 可以馬上找到機器，部署銷售頁面。

若你的遊戲爆紅，GCP 可以馬上擴充，應付海量的玩家連線。

只要採用 GCP，你永遠比別人更一步進入巿場，搶佔先機。

2.全球部署，符合法規

你可以在最靠近使用者的位置部署服務，

減少資訊傳輸的延遲； 

也可以因應法規需求 (例如 GDPR)，

讓資料留在當地，不會外洩到其他地方。

3.快速掌握最新技術

生成式 AI 的軍備競賽，Google 早已大量投入，

讓你隨時可以站在巨人的肩膀上，

掌握最前沿的技術優勢。

此外面試日益嚴峻的資安環境，

Google 也在今年推出各種 AI 防禦方案，

讓你可以安心地使用 GCP。

4.營運不中斷，更好的客戶體驗

以往服務要更新，總是要對外公告，然後用戶被迫在某些時間不能使用服務，

但現在，你可以輕易在 GCP 上執行 Canary Deployment，

針對新版發送少部分流量，若碰到問題可以馬上把流量導回舊版，

若新版沒問題，也可以逐步增加流量，再慢慢把舊版下架。

新舊版無縫接軌，使用者渾然不知，達到更好的客戶體驗。

5.一致的環境，更安全的資料傳輸

GCP 統一使用 Google 帳號驗證，

即使你使用 Windows AD (Active Directory)，

也可以透過 AD FS (Active Directory Federation Service)，

讓使用者輸入 AD 的帳號密碼來登入 GCP，

不需要兩組帳密，避免忘記密碼或密碼被偷的風險。

而系統之間的串接和 API 的呼叫統一使用 Service Account 來驗證，

你再也不用把個人帳密放在程式碼裡面，

減少帳密被偷、系統被駭的機率。

另外在 GCP 的網路中，你可以透過內網存取或串接服務，

不需要把系統 IP 曝露在外，或是讓流量經過網際網路，

而且服務之間的傳輸，在 GCP 是預設加密的，

都可以讓你更安全地使用 GCP。

6.激發創新，快速迭代

以往員工有新的 Idea，想要快速開發 Prototype，

最麻煩的就是要找機器，以及設定對外服務的 IP 或網域。

甚至還要跑簽核流程，看主管的臉色跟心情。

現在你只要滑鼠點兩下，機器就開好了，

或是程式碼 Commit 出去，Cloud Run 就開始對外服務。

你再也不用找機器，也不用等簽核，

上線之前不用花半毛錢，測完之後可以馬上下架。

想做什麼都是立刻、當下，

快速試錯與驗證，根據巿場回饋快速迭代，

一周就推出一個版本，一年後你的產品已經搶下整個巿場。

結語

最後，近幾年有個非常紅的「思維黃金圈」理論，

你可以思考你們公司的「經營使命」或「創業初衷」是什麼？

例如 Google 「我們的使命是匯整全球資訊，供大眾使用，使人人受惠。」

Amazon 「努力成為地球上最以客戶為中心的公司。」

如果聽起來太虛無飄渺，我們來看便利商店的經營使命：

7-11 「提供消費者全方位的便利，創造引領消費者新優質生活型態」

全家 「以顧客為核心，成為無所不在的跨產業便利生活服務平台」

你可以回想，公司的使命是什麼？

而上雲的這些理由跟好處當中，是不是有些對公司的使命有所幫助。

如果是的話，你還在猶豫什麼呢？

本文同時刊登於 思想科技官方網站 《企業上雲的 10 大理由和 6 大好處》與《企業上雲必知的 15 個評估面向》。

The post 企業上雲的10大理由、15個評估面向與6大好處 first appeared on 東東 GCP 教學 - GCP 實戰講師.