路由（Routing）是網路世界裡「決定資料封包要走哪條路」的機制。

每一筆網路請求——不管是你打開網頁、傳訊息還是下載檔案——背後都是一包一包的資料在傳送。

這些資料包不會自己知道要去哪，需要有人告訴它「往這個方向走」。這個「決定方向」的過程，就叫路由。

用生活類比理解路由：郵差怎麼決定走哪條路

想像你寄一封信給台北市大安區的朋友。

郵差不會隨機亂走，他會查地址，然後依照規則：

1. 台北市的信先送到台北郵局
2. 大安區的信再分配到大安郵局
3. 最後才送到那條街

這個「查地址、決定往哪送」的流程，就是路由在做的事。

網路裡的路由器（Router）就是那個郵差。

它負責看每一個資料包的目的地 IP，然後決定要從哪個介面把它轉出去。

路由和交換器的差別：別再搞混了

很多新手會把路由器和交換器（Switch）搞混。這兩個東西做的事完全不同。

交換器工作在第二層（Layer 2）。

負責在同一個區域網路（LAN）內，根據 MAC 地址把資料送到對的設備。

路由器工作在第三層（Layer 3）。

負責在不同網路之間，根據 IP 地址決定資料要往哪個方向走。

簡單說：交換器負責同一棟大樓裡的傳遞，路由器負責跨城市的快遞。

路由器、路由表、路由協定：三個核心名詞一次搞懂

學路由會遇到三個常見名詞，先把它們搞清楚。

路由器（Router） 是負責轉發資料包的設備或系統，可以是實體硬體，也可以是軟體模擬的。

路由表（Routing Table） 是路由器內部存的一張「地圖」，記錄了「去哪個網段，要走哪個介面、經過哪個 Gateway」。路由器每次轉發資料包，都是查這張表做決定。

路由協定（Routing Protocol） 是路由器之間互相溝通、交換路由資訊的規則，常見的有 OSPF、BGP、RIP。這篇文章不深入這個主題，你只需要知道它的存在。

學路由對你的職涯有什麼幫助？

路由不是只有網路工程師才需要懂，它的應用範圍比你想的寬。

懂路由基礎，能讓你在排查問題、評估架構、技術面試這三個場景，明顯比不懂的人更有效率。

哪些工作會用到路由知識？

以下這些職位，在日常工作中都會直接或間接碰到路由。

IT 支援／網路管理員：

公司網路出問題，第一個被叫去查的就是這個職位。能看懂路由表、會用 traceroute 追蹤封包，排查速度至少快 3 倍。

後端工程師：

部署服務到雲端時，常遇到「服務起來了但連不到」的問題。這類問題中，超過 80% 和網路設定有關，路由是最常見的原因之一。

懂路由，能自己排查，不用每次都等網路部門。

DevOps／SRE 工程師：

管理 Kubernetes 叢集、設定 VPC、處理跨區域連線，每天都在和路由打交道。

這個職位對路由的要求是「不只懂概念，還要能動手設定」。

雲端架構師：

設計多雲或混合雲架構時，路由決定了不同環境之間怎麼互通。架構設計錯了，後面的問題會很難收拾。

資安工程師：

滲透測試、網路隔離、零信任架構，都需要理解路由才能判斷流量走向和攻擊面。

就算你現在的工作完全不碰網路，懂路由基礎也能讓你在跨部門溝通時更有效率。

你看得懂網路部門在說什麼，他們說的問題你能快速判斷是不是和你有關。

懂路由，能讓你在團隊裡做什麼？

懂路由不會讓你變成網路專家，但會讓你在以下 3 個場景明顯不同於不懂的人。

場景一：服務上線後出現連線問題

不懂路由的人：「我的程式沒問題，是網路的事，讓網路部門來看。」

懂路由的人：先跑 ip route show 和 traceroute，3 分鐘內確認問題是在路由層還是應用層，再決定要找誰。

這個差異在緊急事故（Incident）時非常明顯。

場景二：評估雲端架構方案

不懂路由的人：看著架構圖點頭，但不知道兩個 VPC 之間的流量怎麼走。

懂路由的人：能直接問「這兩個網段之間的路由是怎麼設定的？有沒有非對稱路由的風險？」，讓討論更具體。

場景三：技術面試

後端、MIS、網管 的技術面試，網路基礎幾乎是必考題。

能說「我實際操作過 ip route 和 traceroute」，比只說「我知道路由的概念」有說服力得多。

為什麼要學路由指令？

工程師遇到網路問題，路由是第一個要查的地方

當你遇到「連不到某台主機」「某個服務突然無法訪問」這類問題，在 90% 的情況下可以用路由指令在 3 分鐘內縮小範圍。

不是說路由一定是問題所在，而是查路由表的成本最低、最快能排除或確認。

常見的排查邏輯是這樣：

1. 查路由表，確認有沒有通往目標網段的路徑
2. 如果路徑存在，用 traceroute 看封包卡在哪一跳
3. 根據結果判斷是路由問題、防火牆問題還是目標主機問題

路由指令能幫你做什麼：診斷、追蹤、設定

路由指令不只能「查」，還能做 3 件事。

診斷：確認目前這台機器的路由表長什麼樣，有沒有缺少某個網段的路徑。

追蹤：用 traceroute 看資料包實際走了哪幾跳，每一跳花了多少時間，找出延遲或中斷的位置。

設定：手動新增或刪除靜態路由，讓特定流量走特定的路徑。

用 GCP Cloud Shell 練習路由指令：不用付費、不用安裝環境

什麼是 GCP Cloud Shell？

GCP Cloud Shell 是 Google Cloud Platform 提供的免費線上終端機環境，讓使用者直接在瀏覽器裡執行指令，不需要在自己的電腦安裝任何工具。它的底層是一台 Debian Linux 虛擬機，預裝了 gcloud、git、python、vim 等常用工具，每個 Google 帳號都可以免費使用，不需要信用卡。

如何開啟 GCP Cloud Shell：只需要 Google 帳號

不需要建立任何 GCP 專案，也不需要輸入付款資訊，只要有 Google 帳號就能開啟。

Step 1：登入 Google Cloud Console

打開瀏覽器，前往 console.cloud.google.com，用你的 Google 帳號登入。

如果是第一次使用，Google 會要求你同意服務條款，接受即可，不會產生任何費用。

Step 2：點擊右上角 Cloud Shell 圖示

登入後，畫面右上角有一個「>_」的圖示，點擊它。

這個圖示在通知鈴鐺的左邊，滑鼠移過去會顯示「啟用 Cloud Shell」。

Step 3：等待環境啟動

點擊後，畫面下方會出現一個終端機視窗，Cloud Shell 環境需要約 30 秒啟動。

啟動完成後，你會看到類似這樣的提示符：

user@cloudshell:~ (your-project-id)$

這代表你已經在 Cloud Shell 環境裡了，可以開始輸入指令。

Cloud Shell 的限制與注意事項：路由設定重啟後會還原

開始操作之前，有一件事要先說清楚。

Cloud Shell 是臨時環境，每次關閉視窗或閒置超過 20 分鐘後，系統可能會重置。

你用指令手動新增的路由，重啟後會消失。這是正常行為，不是你操作錯誤。

對學習來說這反而是好事：你可以放心嘗試各種指令，不用擔心把環境搞壞。

但如果你是要在正式環境設定路由，Cloud Shell 不適合，要改用固定的伺服器或網路設備。

安裝路由相關套件

確認環境：Cloud Shell 預裝了什麼

Cloud Shell 的底層是 Debian Linux，部分路由工具已經預裝，部分需要手動安裝。

先執行以下指令確認目前有哪些工具可用：

which ip route traceroute netstat

有出現路徑的代表已安裝，顯示空白的代表需要手動安裝。

安裝 net-tools（提供 route、netstat 指令）

net-tools 是舊版網路工具套件，提供 route 和 netstat 這兩個指令。

雖然這些指令在新版 Linux 上已被 iproute2 取代，但很多教學文件和舊系統還在用，學起來有備無患。

在 Cloud Shell 執行：

sudo apt-get install -y net-tools

安裝完成後確認：

route --version

有顯示版本號代表安裝成功。

安裝 iproute2（提供 ip route 指令）

iproute2 是現代 Linux 的標準網路工具套件，提供 ip 這個主指令，包含路由管理、網路介面管理等功能。

Cloud Shell 通常已預裝 iproute2，但還是確認一下：

ip -V

目前看來應該已經有安裝了

如果顯示「command not found」，執行以下指令安裝：

sudo apt-get install -y iproute2

安裝 traceroute（提供封包追蹤功能）

traceroute 用來追蹤資料包從你的機器到目標 IP 經過了哪幾個節點。

Cloud Shell 不一定預裝這個工具，執行以下指令安裝：

sudo apt-get install -y traceroute

安裝完成後確認：

traceroute --version

基本路由指令實作

套件都裝好後，現在開始實際操作。

查看目前的路由表：ip route show

ip route show 是查看路由表最常用的現代指令，在 Cloud Shell 執行：

ip route show

你會看到類似這樣的輸出：

default via 10.88.0.1 dev eth0 
10.88.0.0/16 dev eth0 proto kernel scope link src 10.88.0.4 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

輸出結果怎麼看：每個欄位的意思

這些看起來很陌生的文字，其實每個欄位都有明確意思：

第一段：如果包裹要寄到「外縣市」或「國外」怎麼辦？

當你的 Cloud Shell 需要連上網際網路（例如去 Google 抓資料），它通常不知道全世界每一台電腦的確切位置。這時候，它需要一個「預設」的處理方式，這就帶出了第一行輸出：

default via 10.88.0.1 dev eth0

• default（預設路由）：這代表「其他所有不知道該送去哪裡的包裹」。只要目的地不在我們家附近，就套用這個規則。
• via 10.88.0.1（經由）：把包裹交給 10.88.0.1 這個 IP 位址。這個角色叫做 Gateway（通訊閘 / 閘道器），你可以把它想成是「郵件總處理中心」。你的電腦只要把包裹丟給總中心，總中心就會幫你轉送到外部網路。
• dev eth0（網路介面卡裝置）：dev 是 device（裝置）的縮寫。eth0 是你這台電腦主要對外的Network Interface（網路介面卡）。你可以把它想成是郵局的「大門」或「主要的送貨卡車」。

小結一下這行的意思：「只要不知道送去哪的資料，一律從大門 (eth0) 送出去，交給總中心 (10.88.0.1) 幫忙處理。」

第二段：如果包裹只是要寄給「同一個社區的鄰居」呢？

既然我們知道怎麼把資料送到外部網路了，那如果你的 Cloud Shell 只是想跟「同一個 GCP 內部網路」裡的其他機器講話呢？這時候把包裹送到「總中心」就太繞路了，我們應該直接走社區通道送過去就好。這就是第二行規則存在的目的：

10.88.0.0/16 dev eth0 proto kernel scope link src 10.88.0.4

• 10.88.0.0/16（目標網段）：這代表你所在的「本地社區」，在網路術語中稱為 Subnet（子網路）。只要目標地址是 10.88 開頭的，就代表是鄰居。
• dev eth0：一樣，要出門還是得走郵局的大門（主要的網路卡）。
• proto kernel（通訊協定）：這表示這條規則是由作業系統的 Kernel（核心） 自動建立的，不是人類手動輸入的。
• scope link（範圍）：這代表目的地跟我們是在同一個實體或虛擬網路上（Link-local），可以直接對話，不需要經過剛剛那個總中心（Gateway）。
• src 10.88.0.4（來源 IP）：這個資訊非常關鍵！src 是 source（來源）的縮寫。它告訴我們，你現在正在使用的這台 Cloud Shell，它自己的 IP Address（IP 位址） 就是 10.88.0.4。這就像是你寄信時，寫在信封背面的「寄件人地址」。

小結一下這行的意思：「如果資料是要寄給同社區的鄰居 (10.88.0.0/16)，就直接從大門 (eth0) 送過去，並在信封寫上我的地址 (10.88.0.4)。」

第三段：電腦裡面如果還有「房中房」，該怎麼送信？

現在我們知道怎麼對外（第一行）和對鄰居（第二行）溝通了。但是，Cloud Shell 是一個專門給工程師用的環境，它裡面內建了一個叫做 Docker 的工具。Docker 可以在你的電腦裡面再切出很多個獨立的「虛擬小房間」（稱為 Container 容器）來跑程式。

既然是獨立的小房間，它們就需要專屬的內部信箱系統。這就自然接到了最後一行規則：

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

• 172.17.0.0/16：這是專門保留給 Docker 虛擬小房間（容器）使用的「內部專用網段」。
• dev docker0：這是一個 Virtual Bridge（虛擬網橋）。你可以把它想成通往那些內部小房間的「專屬內部門」。這扇門的名字叫 docker0。
• proto kernel scope link：跟上一段一樣，這是系統核心自動建立的直接連線規則。
• src 172.17.0.1：這是這扇「內部門」本身的 IP 位址，也就是小房間們的內部管理員地址。
• linkdown（連線狀態中斷）：這是一個很重要的狀態提示。它代表 docker0 這扇門目前是「關閉 / 未啟用」的狀態。為什麼呢？因為你現在可能還沒有在 Cloud Shell 裡面啟動任何 Docker 容器（小房間裡沒人），所以系統暫時把這個內部通道關閉以節省資源。

小結一下這行的意思：「如果要送信給內部的 Docker 小房間 (172.17.0.0/16)，要走專屬的內部門 (docker0)，不過這扇門目前是關著的 (linkdown)。」

總結

這三行連貫起來，就是你的 Cloud Shell 完整的網路溝通藍圖：

1. 對外交給閘道器（Gateway）。
2. 對鄰居自己直接送（並秀出了你自己的 IP 是 10.88.0.4）。
3. 對內部虛擬容器有專屬通道，但目前沒在使用中。

查看路由表（舊指令）：route -n

route -n 是舊版的路由表查詢指令。-n 代表不要解析 hostname，直接顯示 IP 數字，速度比較快。

route -n

輸出格式像這樣：

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.88.0.1       0.0.0.0         UG    0      0        0 eth0
10.88.0.0       0.0.0.0         255.255.0.0     U     0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

ip route 和 route -n 的差別

這兩個指令看的是同一份路由表，只是顯示格式不同。

ip route show 是現代指令，輸出用 CIDR 格式（如 /28），功能更完整，建議優先使用。

route -n 是舊指令，輸出用傳統子網路遮罩格式（如 255.255.255.240），在舊系統或舊教學文件上比較常見。

兩個都會，在任何環境下都不會被卡住。

新增靜態路由：ip route add

靜態路由（Static Route）是指你手動告訴系統「去這個網段，要走這個 Gateway」，不透過任何路由協定自動學習。

Step 1：確認目標網段

假設你要新增一條路由，讓去 192.168.100.0/24 這個網段的流量，走 Gateway 10.88.0.1。

先確認這個網段目前沒有路由：

ip route show | grep 192.168.100

如果沒有輸出，代表目前沒有這條路由，可以新增。

Step 2：指定 Gateway

確認你的 Gateway IP 是否可以到達：

ping -c 3 10.88.0.1

看到 3 packets transmitted, 3 received 代表 Gateway 可以連通。

Step 3：執行新增指令並確認結果

執行以下指令新增路由：

sudo ip route add 192.168.100.0/24 via 10.88.0.1

新增後，立刻確認有沒有成功加進路由表：

ip route show | grep 192.168.100

如果看到：

192.168.100.0/24 via 10.88.0.1 dev eth0

代表新增成功。

刪除路由：ip route del

刪除路由的語法和新增幾乎一樣，只是把 add 換成 del：

sudo ip route del 192.168.100.0/24 via 10.88.0.1

刪除後確認：

ip route show | grep 192.168.100

沒有輸出代表刪除成功。

追蹤封包走哪條路：traceroute

traceroute 會顯示封包從你的機器出發，每經過一個路由節點就記錄一次，讓你看到完整的路徑。

試著追蹤到 Google DNS 的路徑：

traceroute 8.8.8.8

輸出：

每一行是一個「跳」（hop），左邊的數字是第幾跳，後面是那個節點的 IP 和三次往返時間。

* * * 代表那個節點沒有回應，可能設定了不回應 ICMP，不一定是問題。

實際案例：用路由指令診斷網路問題

情境：連不到某個 IP，怎麼用路由指令找出問題

假設你在 Cloud Shell 裡 ping 192.168.50.1 完全沒有回應，不知道問題出在哪。

以下是標準的排查流程。

Step 1：先查路由表，確認有沒有對應路徑

ip route show | grep 192.168.50

如果沒有輸出，代表路由表裡根本沒有去 192.168.50.0/24 的路徑。

這時封包會走 default 路由（default via 10.88.0.1）。

但如果 default Gateway 也不知道怎麼到那個網段，封包就會被丟棄。

這種情況下，問題就是「缺少路由」。解法是新增一條靜態路由，或確認這個網段是否真的可達。

Step 2：用 traceroute 找出封包卡在哪一跳

如果路由表有對應路徑，但還是連不到，執行：

traceroute 192.168.50.1

看封包在哪一跳停下來（顯示連續的 * * *）。

如果第 1 跳就是 * * *，問題在 Gateway 這層。

如果走了幾跳後才停，問題在中間某個路由節點或目標主機。

Step 3：根據結果判斷是路由問題還是其他問題

排查路由問題後，如果路徑是通的但還是連不到，問題通常在以下 3 個地方：

1. 目標主機的防火牆擋掉了 ICMP（ping 不通但服務可能正常）
2. 目標主機根本沒有在監聽
3. 兩邊的路由不對稱（你能到它，但它的回程路由不知道怎麼回到你）

路由指令能幫你排除「路徑本身」的問題，剩下的就要用其他工具（如 curl、telnet、nmap）繼續追查。

常見錯誤與排查

指令找不到（command not found）：套件沒裝好

執行指令時出現 command not found，代表那個套件還沒安裝。

對照前面「安裝路由相關套件」的章節，確認對應套件有沒有裝好。

如果安裝過程中出現錯誤，先執行：

sudo apt-get update

更新套件清單後再重新安裝。

新增路由後 ping 還是不通：Gateway 設定錯誤

新增路由成功，但目標還是 ping 不通，最常見的原因是 Gateway IP 設錯了。

確認你指定的 Gateway 在路由表裡是可達的：

ip route get <你的 Gateway IP>

正常會看到像這樣：

如果顯示 RTNETLINK answers: Network is unreachable，代表這個 Gateway 本身就不可達，路由設定沒有意義。

Cloud Shell 重啟後路由消失：這是正常行為

手動新增的路由，Cloud Shell 重啟後會消失。

這是 Cloud Shell 的設計限制，不是你的操作問題。

如果你需要每次啟動 Cloud Shell 都自動套用路由設定，可以把指令寫進 ~/.bashrc：

echo "sudo ip route add 192.168.100.0/24 via 10.88.0.1" >> ~/.bashrc

這只適合學習和測試用途，正式環境不應該這樣做。

總結：路由指令你只需要記住這幾條

學路由不需要記很多東西。把這 5 條指令在 GCP Cloud Shell 跑過一遍，下次遇到網路問題，你就有具體的排查起點。

1. ip route show — 查看路由表
2. route -n — 查看路由表（舊格式，舊系統適用）
3. sudo ip route add <網段> via <Gateway> — 新增靜態路由
4. sudo ip route del <網段> via <Gateway> — 刪除路由
5. traceroute <目標 IP> — 追蹤封包路徑

常見問題（FAQ）

Q1：我沒有 GCP 帳號，可以用 Cloud Shell 嗎？ A：只要有 Google 帳號（例如 Gmail）就可以使用 GCP Cloud Shell，不需要額外申請 GCP 帳號，也不需要信用卡。前往 console.cloud.google.com 登入後，點右上角「>_」圖示即可開啟，整個流程不會產生任何費用。

Q2：Cloud Shell 的免費額度會用完嗎？ A：Cloud Shell 每個月提供 50 小時的免費使用時間，一般學習和練習完全夠用。這篇文章示範的所有路由指令都在免費額度內，不會產生任何費用。

Q3：ip route 和 route -n 哪一個比較建議用？ A：優先使用 ip route show。它是現代 Linux 的標準路由查詢指令，輸出格式更清楚、功能更完整。route -n 在舊系統或舊文件上還是很常見，兩個都知道，在任何環境下都不會被卡住。

Q4：靜態路由和動態路由有什麼差別？ A：靜態路由是你手動設定的，告訴系統「去這個網段走這條路」，不會自動更新。動態路由透過路由協定（如 OSPF、BGP）讓路由器之間自動學習路徑，網路拓撲改變時會自動調整。學習階段用靜態路由就夠了，大型正式環境幾乎都用動態路由。

Q5：traceroute 輸出中的 * * * 是什麼意思？ A：* * * 代表那個節點在規定時間內沒有回應。這不一定是問題——很多路由器或防火牆設定為不回應 traceroute 的封包。如果最終能到達目標，中間出現 * * * 通常不影響實際連線。

Q6：怎麼知道我的預設 Gateway 是什麼？ A：執行 ip route show，找開頭是 default via 的那一行，後面的 IP 就是預設 Gateway。例如 default via 10.88.0.1 dev eth0，預設 Gateway 就是 10.88.0.1。

Q7：新增路由時出現 Error: any valid prefix is expected rather than，是什麼問題？ A：這個錯誤代表網段格式有誤。路由指令的網段必須用 CIDR 格式，例如 192.168.100.0/24，不能只寫 192.168.100。確認網段後面有加 /數字 的子網路遮罩，再重新執行。

Q8：可以用 Cloud Shell 練習路由以外的網路指令嗎？ A：可以。Cloud Shell 是完整的 Linux 環境，ping、curl、nslookup、dig、netstat、ss 等常見網路指令都能在這裡使用，部分需要先安裝套件。對於想從零學習 Linux 網路指令的人，Cloud Shell 是免費又方便的練習環境。

Q9：路由表裡的 Metric 數字代表什麼？ A：Metric 是路由的優先權分數，數字越小代表優先權越高。當路由表裡有超過 2 條都能到達同一目標的路由時，系統會選擇 Metric 較小的那條。在有多張網路卡或多個 Gateway 的環境裡，Metric 的設定會直接影響流量走向。

Q10：這篇文章的路由指令可以直接用在 GCP 的 VM 上嗎？ A：可以，但要注意：GCP VM 的網路由 VPC 管理，單純在 VM 內新增路由不一定能讓流量真正改道，還需要在 GCP Console 的 VPC 路由設定裡同步調整。Cloud Shell 適合學習路由指令語法，正式環境需要搭配 GCP 網路架構一起考慮。

The post 路由是什麼？網路必學基礎知識 first appeared on 東東 GCP 教學 - GCP 實戰講師.

雲端架構師（Cloud Architect）是規劃和設定雲端環境 （GCP、AWS、Azure） ，讓系統可以在雲端上順暢地跑起來的人。

也是根據公司要運作程式的需求（例如：想要架設電商網站），提出雲端解決方案（例如：自動擴充搭配負載平衡） 的人。

你可以把雲端架構師想像成「雲端世界的建築師」——一般建築師設計房子，雲端架構師設計的是一棟棟跑在雲端上的數位建築物。

雲端架構師的核心職責

雲端架構師的日常工作，主要包含以下幾個面向：

1. 評估需求：與業務單位溝通，了解系統規模、流量、安全需求
2. 設計架構：規劃雲端網路（Virtual Private Cloud; VPC）、Kubernetes 叢集、資料庫佈署方式
3. 成本管理：透過預算、長期的承諾使用折扣 （Committed Use Discount）、短期的續用折扣（Sustained Use Discount） 等機制降低雲端使用成本
4. 資安規劃：設定 Cloud IAM 權限和角色、防火牆、金鑰管理服務（KMS）設定加密、Security Command Center 監控雲端環境
5. 技術支援：協助開發團隊解決各種雲端疑難雜症
6. 維運監控：建立 Cloud Monitoring、Cloud Logging 警告機制

雲端架構師 vs 一般軟體工程師的差異

很多人會問：「雲端架構師跟工程師哪裡不一樣？」

最簡單的區分方式是：軟體工程師「寫程式解決問題」，雲端架構師「設計環境讓程式可以穩定運行」。工程師關注的是程式的各項功能運作，架構師關注的是基礎設施和整體系統架構。

兩者的互動是：工程師寫好程式，但不知道如何放到雲端上跑，由雲端架構師把環境設定好，然後幫工程師把程式放上去。

在薪資上，架構師普遍高於同年資的開發工程師，這也是為什麼許多工程師選擇往雲端架構師方向發展的主要原因。

2026 年台灣雲端架構師薪水行情

根據台灣 1111 人力銀行、104 人力銀行、CakeResume 及 LinkedIn 等平台的職缺資料，台灣雲端架構師月薪範圍約落在 8 萬到 20 萬新台幣之間，年薪含獎金可達 120 萬到 250 萬元，具備多雲認證者更有談判高薪的籌碼。

以下依照資歷分三個等級說明：

初階雲端架構師薪資（0～3 年雲端經驗）

初階雲端架構師通常來自系統工程師、網路工程師或軟體工程師轉職而來。這個階段的工作以「執行」為主，配合資深架構師的規劃進行實作。

初階薪資提升關鍵： 拿到第一張雲端 Associate 等級認證後，月薪通常可立即提升 5,000 至 15,000 元，對應聘資格影響非常大。

中階雲端架構師薪資（3～8 年雲端經驗）

這個階段的架構師已經能獨立主導專案，開始帶領小團隊，並且有能力與客戶直接溝通技術方案。如果你同時具備兩張以上 Professional 等級認證，薪資談判空間會更大。

資深雲端架構師薪資（8 年以上 / 特殊專長）

資深架構師的薪水往往不只來自技術能力，更來自「業務開發能力」——能不能幫公司拿到大型雲端專案，直接決定你的市場價值。

很多高薪的雲端架構師，其實就是售前（Presales），主要職責就是協助公司推廣雲端產品，拿到雲端開發或建置案，除了能賺取專案的人力費用，客戶每個月使用雲端產生的被動收益，也是公司的主要收入來源。這種能夠幫公司賺錢的雲端架構師，薪水就遠遠超過只是操作內部系統的雲端架構師。

台灣雲端架構師的薪資天花板遠高於一般工程師職位。初階月薪 6～9 萬，中階 9～15 萬，資深可達 15～25 萬，年薪突破 200 萬並非少見。具備 GCP Professional Cloud Architect、AWS Solutions Architect 等 Professional 等級認證，是突破薪資瓶頸最直接有效的方式。

全球雲端架構師薪水比較

如果你有考慮出國工作或遠端接案，以下是各主要市場的薪資對比：

美國、日本、新加坡薪資比較

從這份比較表可以看出，台灣雲端架構師的薪資雖然相對美國偏低，但如果跟台灣其他 IT 職位相比，仍屬於高薪族群。尤其新加坡市場對台灣雲端架構師的需求相當高，是值得關注的出海選項。

像我個人也曾經收到要去新加坡建置大型雲端架構的案子，客戶會願意為此進行大筆投資。

影響雲端架構師薪水的關鍵因素

同樣是雲端架構師，為什麼薪水可以差到兩倍以上？以下是最關鍵的幾個因素：

GCP / AWS / Azure 認證的薪資加乘效果

雲端認證是影響架構師薪資最直接的因素之一，如果你沒有證據證明你在雲端的能力和經驗，持有證照就是唯一客觀的評估標準。持有 GCP Professional Cloud Architect 認證的工程師，平均薪資比未持有認證者高出 20%～40%。若同時持有 GCP + AWS 雙認證，在台灣的求職市場幾乎是「有求必應」的狀態。

主要認證對薪資的影響如下：

GCP 系列認證：

• Associate Cloud Engineer：月薪提升 5,000～15,000 NTD
• Professional Cloud Architect：月薪提升 15,000～30,000 NTD
• Professional Data Engineer / Security Engineer：額外加給 10,000～20,000 NTD

AWS 系列認證：

• AWS Solutions Architect – Associate：月薪提升 8,000～18,000 NTD
• AWS Solutions Architect – Professional：月薪提升 20,000～40,000 NTD

關鍵提醒： 認證只是敲門磚，沒有實戰經驗搭配的認證說服力有限。最理想的狀況是邊工作邊考證，讓認證為你的實戰能力背書。

產業別薪資差異

不同產業對雲端架構師的需求和出價也有明顯差異：

如何成為雲端架構師？轉職路徑完整說明

從非技術背景轉職的真實案例

我自己的經歷就是一個很好的例子。我大學念統計系、研究所念企管，完全沒有資工背景，後來卻成為 GCP 的雲端架構師，現在在 YouTube 和部落格上教別人 GCP。

我的轉職路徑大概是這樣：

1. 2008年：花十萬元自費學習 Windows Server + SQL Server，考取 MCSA、MCDBA、RHCE 證照
2. 2009年：進入系統整合商，實際接觸政府 IT 系統，寫過 C# 和 Java
3. 2013年：透過前主管介紹，進入 Google 合作夥伴公司做 Presales
4. 2014年：GCP 在台灣開始大力推廣，轉型為 GCP 雲端架構師
5. 2023年：跳出來做自媒體「東東 GCP 教學」，分享 GCP 知識

轉職雲端架構師不一定需要資工本科背景。許多成功的雲端架構師來自系統工程師、網路管理員、甚至非技術職位（如 IT Presales、專案經理）。關鍵在於「取得認證 + 累積實戰案例 + 持續學習」這三個同步進行的動作，缺一不可。

接近 40 歲的時候，我也非常擔心機會越來越少。但事實證明，只要在一個特定的技術領域持續深耕，即使非本科也能建立別人難以取代的競爭優勢。

需要哪些技能與證照？

成為雲端架構師需要的技能可以分成「硬技能」和「軟技能」兩大類：

硬技能（技術能力）：

1. 網路基礎：TCP/IP、DNS、VPC、防火牆規則
2. Linux 系統管理：基本指令操作、權限管理、Log 分析
3. 容器技術：Docker、Kubernetes（GKE）
4. IaC（基礎設施即程式碼）：Terraform、Kubernetes YAML 撰寫
5. 資安概念：IAM 設計、加密金鑰管理、Zero Trust 架構
6. 資料庫：Cloud SQL、BigQuery、Spanner 的使用情境
7. 監控：Cloud Monitoring、Cloud Logging、告警設定

軟技能（非技術能力）：

1. 溝通能力：能把技術翻譯給非技術主管聽
2. 問題分析：面對客戶疑難雜症時的邏輯思維
3. 成本意識：設計架構時要同步考量 ROI
4. 文件撰寫：架構圖、技術提案、RFP 回覆

建議取得的認證順序（以 GCP 為例）：

1. 第一步：GCP Associate Cloud Engineer（建立基礎）
2. 第二步：GCP Professional Cloud Architect（主力認證）
3. 第三步：依照工作方向加考 Professional Data Engineer 或 Professional Security Engineer

雲端架構師薪水成長策略

光知道「雲端架構師薪水高」還不夠，你需要一套具體的薪資成長策略：

如何用 GCP 認證快速提升薪資

策略一：先考再談，用證照打開門

很多公司對認證持有者有加薪機制，甚至有證照獎金（有些公司每張證照獎勵 1 萬到 3 萬不等）。拿到認證後，跳槽或內部升遷都有更多籌碼。

策略二：做出可量化的成果

在面試時，「我幫公司把雲端帳單降低 30%」比「我有三年雲端架構師經驗」有力得多。每做完一個專案，一定要記錄下來：做了什麼、節省多少成本、解決什麼問題。

策略三：建立個人品牌

我自己從 2023 年開始做「東東 GCP 教學」，透過 YouTube 頻道、部落格（dongdonggcp.com）、Linked-in、和 Threads 分享 GCP 知識。這不只帶來了額外的收入來源，更讓我在行業內建立了可信度。

對雲端架構師來說，公開展示自己的技術知識，是目前最有效的個人品牌策略之一。

策略四：專精一個垂直領域

與其成為「什麼都懂一點」的泛用型架構師，不如在某個特定領域（如金融雲、醫療雲、AI 基礎設施）成為領域專家。垂直深度往往比水平廣度更能帶來薪資溢價。

雲端架構師要有效提升薪資，最快的方法是：取得 Professional 等級認證（立即增加談判籌碼）、記錄可量化的成果（降低帳單、提升穩定性的具體數字）、以及在特定垂直產業建立深度專業。這三個動作同步進行，年薪提升 30%～50% 是可預期的。

雲端架構師薪水 FAQ 常見問題

Q1：沒有資工背景可以成為雲端架構師嗎？

A： 完全可以。許多優秀的雲端架構師來自非資工背景，包括統計、企管、甚至人文科系。關鍵是你願不願意主動考取認證、累積實戰經驗。台灣確實有很多成功案例，從統計系、商科出身轉職為 GCP 架構師的人並不少見。重要的是要有系統地學習：先從 GCP Associate Cloud Engineer 認證入門，邊學邊做，循序漸進。

Q2：雲端架構師和 DevOps 工程師的薪水哪個比較高？

A： 在台灣市場，雲端架構師的平均薪資略高於 DevOps 工程師，尤其在資深等級差距更明顯。因為 DevOps 工程師雲端架構師月薪區間約 8 萬～20 萬，DevOps 工程師約 7 萬～16 萬。不過兩者界線越來越模糊，很多公司的雲端架構師職位本身就包含 DevOps 工作，具備 CI/CD pipeline 設計能力的架構師，薪資競爭力會更強。

Q3：GCP 認證和 AWS 認證，哪個對薪資幫助更大？

A： 以台灣市場來看，AWS 認證的市場認知度略高，職缺數量也稍多；但 GCP 認證在特定產業（尤其是媒體、廣告科技、AI 應用）有明顯優勢，而且考試難度相對較高，持有者的含金量也相對較高。最理想的狀況是同時持有 GCP Professional Cloud Architect + AWS Solutions Architect，雙認證的組合在談薪水時最有底氣。

Q4：轉職雲端架構師大約需要多久？

A： 有技術基礎（如系統工程師、網路管理員）的人，通常 1～2 年可以完成轉型；從非技術職位（如 IT Presales、PM）轉職則需要 2～3 年。關鍵不是時間長短，而是「是否有機會接觸真實的雲端專案」。即使沒有，也可以透過 Google 官方的 Cloud Skills Boost 平台刷題目、做 Lab，累積實戰感。如果你覺得自學太慢了，可以加入雲端架構師養成班，藉由完整的學習和實作，加快考取證照並成功轉職的速度。

Q5：台灣雲端架構師的未來發展前景如何？

A： 非常樂觀。隨著台灣企業數位轉型加速、AI 應用崛起（Vertex AI、Gemini API 的整合需求），以及半導體產業上雲趨勢持續，雲端架構師的需求預計在未來 5 年內仍持續成長。特別是具備 AI/ML 基礎設施規劃能力的架構師，將成為市場上最搶手的人才之一。

結論：雲端架構師是值得投資的職涯方向

雲端架構師是目前台灣 IT 市場薪資成長最快的職位之一，年薪 120 萬到 250 萬的機會對有認證、有實戰的人來說相當實際。轉職門檻雖然存在，但並非不可跨越——只要系統性學習、取得認證、累積可量化成果，即使是非本科背景，也能在 2～3 年內完成轉型。

我自己從完全不懂 GCP，到成為雲端架構師、再到現在透過「東東 GCP 教學」分享這些知識，走了超過十年。這條路不一定要走那麼久——因為現在的學習資源、認證體系、社群支持都比十年前豐富太多了。

如果你對轉職雲端架構師有興趣，或者已經在雲端領域工作但想要加速薪資成長，歡迎來 dongdonggcp.com 看看我整理的 GCP 實戰教學，或是訂閱「東東 GCP 教學」的 YouTube 頻道，我們一起在雲端世界找到自己的位置。

如果還有什我疑問，也可以加 Line: @754xlakm 直接與我聯絡，透過線上諮詢來了解你的情況，並提供你適合的發展方向。

The post 雲端架構師薪水完整指南：薪資行情、加薪技巧與轉職攻略 first appeared on 東東 GCP 教學 - GCP 實戰講師.

當我們在瀏覽器輸入 www.youtube.com 按下 Enter 鍵時，網頁幾乎瞬間就載入了。但你有沒有想過，電腦是怎麼知道要連到哪台伺服器的呢？這背後的功臣就是 DNS（Domain Name System，網域名稱系統）。DNS 就像網際網路的電話簿，將我們容易記憶的網域名稱轉換成電腦能理解的 IP 位址。今天我們就來深入了解 DNS 到底是什麼、它如何運作，以及為什麼它對我們的上網體驗如此重要。

DNS 的基本概念

什麼是 DNS？

DNS 全名為 Domain Name System，中文稱為「網域名稱系統」。簡單來說，DNS 是一個分散式的資料庫系統，負責將人類容易記憶的網域名稱（例如 facebook.com）轉換成電腦網路中實際使用的 IP 位址（例如 157.240.1.35）。想像一下，如果沒有 DNS，我們每次想上 Facebook 就得記住一串數字，那上網會變得多麼麻煩啊！

我們可以把 DNS 比喻成一本巨大的通訊錄。當你想打電話給朋友時，你只需要記住他的名字，然後在通訊錄裡找到對應的電話號碼。DNS 做的就是類似的事情，只不過它查找的是網站的「電話號碼」——也就是 IP 位址。

這套系統採用階層式架構，從全球的根伺服器開始，一層層往下延伸到各個網域的權威伺服器。這種設計讓 DNS 能夠處理數十億個網域名稱，同時保持高效率的查詢速度。更重要的是，DNS 是分散式的，沒有單一故障點，這讓整個網際網路更加穩定可靠。

為什麼需要 DNS？

你可能會問，為什麼不直接使用 IP 位址就好？原因很簡單：IP 位址對人類來說太難記了。試想一下，如果你要記住常用的十個網站的 IP 位址，像是 142.250.185.46（Google）、13.107.42.14（Microsoft）等等，是不是很容易搞混？而且 IP 位址可能會改變，但網域名稱可以保持不變，這為網站管理者提供了靈活性。

DNS 的出現解決了這個問題。它讓我們可以用有意義、容易記憶的名稱來訪問網站。當網站需要更換伺服器或 IP 位址時，只需要更新 DNS 記錄就好，使用者完全不會察覺到任何變化。這就像你的朋友換了手機號碼，只要更新通訊錄就能繼續聯絡，不需要記新的號碼。

此外，DNS 還支援負載平衡 (Load Balance) 和故障轉移 (Failover) 功能。一個網域名稱可以對應到多個 IP 位址，當某台伺服器故障時，DNS 可以自動將流量導向其他正常運作的伺服器。這對於大型網站來說至關重要，確保了服務的高可用性。

DNS 的運作原理

DNS 查詢的完整流程

當我們在瀏覽器輸入一個網址時，DNS 查詢就開始了。這個過程看似簡單，實際上涉及多個步驟和不同的伺服器協作。讓我們一步步來看看當你輸入 www.example.com 時會發生什麼事。

首先，你的電腦會檢查本地快取，看看最近是否查詢過這個網域。如果有，就直接使用快取中的 IP 位址，這樣可以節省時間。如果沒有，查詢請求會被送到你的 ISP（網際網路服務供應商）提供的 DNS 解析器，或者你手動設定的 DNS 伺服器。

DNS 解析器收到請求後，它會先查看自己的快取。如果沒有找到，它就會開始一系列的查詢過程。首先，它會向根名稱伺服器詢問：「誰知道 .com 網域的資訊？」根伺服器會回覆：「你去找 .com 的 TLD 伺服器吧。」

接著，解析器向 TLD 伺服器詢問：「example.com 的權威伺服器在哪裡?」TLD 伺服器會提供權威名稱伺服器的位址。

最後，解析器向 example.com 的權威名稱伺服器查詢 www.example.com 的 IP 位址。權威伺服器回覆正確的 IP 位址後,解析器會將這個結果快取起來,並回傳給你的電腦。整個過程通常在幾十毫秒內完成,我們幾乎感覺不到任何延遲。

下圖是完整流程：

DNS 解析的四大伺服器

DNS 系統的運作依賴四種主要的伺服器類型,每一種都扮演著不可或缺的角色。了解這些伺服器的功能,可以幫助我們更深入理解 DNS 的工作機制。

遞迴解析器(Recursive Resolver)

遞迴解析器是 DNS 查詢的起點,也是最接近使用者的那一層。當你的電腦需要解析一個網域名稱時,它會將請求發送給遞迴解析器。這個解析器就像是一個勤奮的圖書館員,它會代替你去查找所需的資訊。

遞迴解析器的特點是它會「遞迴」地進行查詢,也就是說,它會一直追問下去直到找到答案。它會記住你查詢過的結果,下次有人查詢相同的網域時,就能直接提供答案,不需要再跑一遍完整的查詢流程。大多數 ISP 都會提供自己的遞迴解析器,但你也可以使用像 Google Public DNS 或 Cloudflare 這樣的公共 DNS 服務。

根名稱伺服器(Root Nameserver)

根名稱伺服器位於 DNS 階層架構的最頂端。全球只有 13 組根伺服器(標記為 A 到 M),但實際上透過任播技術,每組根伺服器在世界各地都有多個實體伺服器副本,總數超過數百台。

根伺服器不會直接告訴你某個網站的 IP 位址,它們的工作是指引查詢到正確的 TLD 伺服器。當遞迴解析器詢問 www.example.com 的位址時,根伺服器會說:「我不知道具體位址,但我知道誰負責 .com 網域,你去問它。」這就像是總機告訴你應該轉接到哪個部門。

TLD 名稱伺服器

TLD(Top-Level Domain)名稱伺服器負責管理頂級網域,像是 .com、.org、.tw 等等。每個 TLD 都有專門的名稱伺服器來處理該網域下的查詢。當你查詢 example.com 時,.com 的 TLD 伺服器會告訴你哪個權威名稱伺服器負責 example.com 這個網域。

TLD 伺服器維護著該頂級網域下所有註冊網域的記錄。它們就像是各個城市的資訊中心,知道城市裡每條街道的負責單位。台灣的 .tw 網域就是由 TWNIC(台灣網路資訊中心)負責管理其 TLD 伺服器。

權威名稱伺服器(Authoritative Nameserver)

權威名稱伺服器是 DNS 查詢鏈的最後一站,它擁有特定網域的最終、最權威的資訊。如果說前面的伺服器都在指路,那麼權威名稱伺服器就是真正知道答案的那個人。

當查詢到達 example.com 的權威名稱伺服器時,它會查看自己的記錄,然後回覆:「www.example.com 的 IP 位址是 93.184.216.34。」這個答案就會一路傳回給遞迴解析器,最終到達你的電腦。網域的擁有者可以透過 DNS 管理介面來設定和更新權威名稱伺服器上的記錄。

DNS 記錄類型有哪些？

A 記錄與 AAAA 記錄

DNS 記錄是儲存在權威名稱伺服器上的資料,定義了網域名稱與各種資源之間的對應關係。最基本也最重要的是 A 記錄和 AAAA 記錄。

A 記錄(Address Record)是最常見的 DNS 記錄類型,它將網域名稱對應到 IPv4 位址。例如,www.example.com 的 A 記錄可能指向 93.184.216.34。當你在瀏覽器輸入這個網址時,DNS 會查詢 A 記錄來找到對應的伺服器。

AAAA 記錄(也讀作「quad-A」)則是 A 記錄的 IPv6 版本。隨著 IPv4 位址逐漸耗盡,IPv6 變得越來越重要。AAAA 記錄將網域名稱對應到 128 位元的 IPv6 位址,例如 2606:2800:220:1:248:1893:25c8:1946。現代網站通常會同時設定 A 和 AAAA 記錄,以支援使用不同 IP 協定的使用者。

CNAME、MX 與其他常見記錄

除了 A 和 AAAA 記錄,還有許多其他類型的 DNS 記錄服務於不同目的。CNAME 記錄(Canonical Name)用於建立別名。例如,你可以設定 www.example.com 為 example.com 的 CNAME,這樣兩個網址都會指向同一個地方。這在管理多個子網域時特別方便。

MX 記錄(Mail Exchange)指定了接收電子郵件的郵件伺服器。當有人寄信到 user@example.com 時,發送方的郵件伺服器會查詢 example.com 的 MX 記錄,找出應該將郵件送到哪台伺服器。MX 記錄還包含優先順序,讓你可以設定主要和備用郵件伺服器。

TXT 記錄可以儲存任意文字資訊,常用於網域驗證、SPF(Sender Policy Framework)設定來防止郵件欺騙,或是 DKIM 數位簽章。NS 記錄(Name Server)則指定了該網域使用哪些名稱伺服器。還有 PTR 記錄用於反向 DNS 查詢,SOA 記錄儲存網域的管理資訊等等。

DNS 的快取 (暫存) 機制

瀏覽器與作業系統快取

為了提升效能和減少網路流量,DNS 系統在多個層級實作了快取機制。最接近使用者的快取存在於瀏覽器和作業系統中。當你訪問一個網站時,瀏覽器會將 DNS 查詢結果儲存在記憶體中。下次你再訪問同一個網站時,瀏覽器就能直接使用快取的 IP 位址,不需要再進行 DNS 查詢。

每個瀏覽器都有自己的 DNS 快取管理機制。Chrome 瀏覽器的快取通常會保留數分鐘到數小時,你可以在網址列輸入 chrome://net-internals/#dns 來查看和清除快取。Firefox、Safari 等瀏覽器也都有類似的功能。

作業系統層級的 DNS 快取則由系統的 DNS 客戶端服務管理。Windows、macOS 和 Linux 都會維護自己的 DNS 快取。當瀏覽器的快取過期或沒有找到記錄時,就會詢問作業系統的快取。這層快取通常保留時間較長,能夠讓多個應用程式共享 DNS 查詢結果。

TTL 生存時間的重要性

TTL(Time To Live,生存時間)是 DNS 記錄中的一個重要參數,它決定了這筆記錄可以被快取多久。TTL 以秒為單位,例如 TTL=3600 表示這筆記錄可以被快取一小時。當 TTL 到期後,快取會被視為過期,下次查詢時就需要重新向權威伺服器取得最新資料。

設定適當的 TTL 值需要在效能和靈活性之間取得平衡。較長的 TTL(例如 86400 秒,即 24 小時)可以減少 DNS 查詢次數,降低伺服器負載,提升網站存取速度。但缺點是,當你需要更改 IP 位址時,更新會較慢生效,因為舊的記錄可能還在全球各地的快取中。

較短的 TTL(例如 300 秒,即 5 分鐘)讓你能快速更新 DNS 記錄,這在伺服器遷移或故障轉移時很有用。但代價是會產生更多的 DNS 查詢流量。一般建議是,在正常運作時使用較長的 TTL,而在計劃進行變更前幾天先降低 TTL 值,這樣變更時就能更快生效。

常見的 DNS 問題與解決方法

DNS 解析失敗怎麼辦？

有時候我們會遇到網頁無法開啟的情況,錯誤訊息顯示「DNS_PROBE_FINISHED_NXDOMAIN」或「找不到伺服器」。這通常是 DNS 解析出現問題。首先,你可以嘗試清除 DNS 快取。在 Windows 上,開啟命令提示字元並執行 ipconfig /flushdns;在 macOS 上使用 sudo dscacheutil -flushcache;Linux 用戶則可以重啟 systemd-resolved 服務。

如果清除快取後問題仍然存在,可能是你的 DNS 伺服器本身出了問題。這時候切換到其他 DNS 伺服器通常能解決問題。你也可以檢查網路連線是否正常,嘗試 ping 8.8.8.8 這樣的 IP 位址,如果能 ping 通但網頁打不開,就確認是 DNS 問題。

有時候問題出在網域本身。網域可能過期未續約,或是 DNS 記錄設定錯誤。如果你是網域管理者,可以使用 nslookup 或 dig 這類工具來檢查 DNS 記錄是否正確。線上工具如 DNS Checker 可以幫你從全球不同地點檢查 DNS 傳播狀況。Google 自己也有 Google Admin Toolbox 可以用喔！

如何更換 DNS 伺服器？

更換 DNS 伺服器是改善上網速度和安全性的簡單方法。在 Windows 10/11 上,進入「設定」>「網路和網際網路」>「乙太網路」或「Wi-Fi」,點擊你的連線,選擇「編輯 IP 設定」,然後手動輸入 DNS 伺服器位址。

macOS 用戶可以前往「系統設定」>「網路」,選擇你的網路連線,點擊「進階」,然後在「DNS」分頁中新增伺服器。你可以新增多個 DNS 伺服器,系統會依序嘗試使用它們。

在路由器層級更改 DNS 設定會影響連接到該路由器的所有裝置。登入路由器管理介面(通常是 192.168.1.1 或 192.168.0.1),找到 WAN 或網際網路設定,將 DNS 伺服器從「自動取得」改為「手動設定」,然後輸入你想使用的 DNS 伺服器位址。更改後記得重啟路由器讓設定生效。

公共 DNS 服務推薦

Google DNS、Cloudflare DNS 等選擇

市面上有許多優質的公共 DNS 服務可供選擇。Google Public DNS 是最早也是最受歡迎的公共 DNS 之一,主要 DNS 位址是 8.8.8.8 和 8.8.4.4(IPv4),或 2001:4860:4860::8888 和 2001:4860:4860::8844(IPv6)。Google DNS 以穩定性和全球覆蓋率著稱,在世界各地都有伺服器節點。

Cloudflare 的 1.1.1.1 是後起之秀,主打速度和隱私。Cloudflare 承諾不會記錄使用者的查詢資料,並在 24 小時後刪除所有日誌。他們的 DNS 服務在許多效能測試中都名列前茅,備用伺服器是 1.0.0.1。Cloudflare 還提供 1.1.1.1 for Families 服務,可以過濾惡意軟體和成人內容。

Quad9(9.9.9.9)注重安全性,會封鎖已知的惡意網域,保護你免受網路釣魚和惡意軟體威脅。OpenDNS(208.67.222.222 和 208.67.220.220)提供家長控制功能,可以過濾不適當的內容。台灣用戶可以考慮使用 HiNet 的 DNS(168.95.1.1 和 168.95.192.1),因為地理位置較近,理論上延遲會較低。

選擇 DNS 服務時,可以考慮速度、隱私政策、安全功能和可靠性。你也可以使用 DNS Benchmark 這類工具來測試不同 DNS 服務在你所在位置的實際表現,選擇最適合自己的那一個。

DNS 安全性議題

DNS 劫持與中間人攻擊

DNS 系統雖然便利,但也存在安全隱憂。DNS 劫持(DNS Hijacking)是指攻擊者透過修改 DNS 設定,將你導向錯誤的 IP 位址。這可能發生在你的路由器、電腦或 ISP 的 DNS 伺服器上。攻擊者可能將你導向偽造的銀行網站,竊取你的帳號密碼和個人資料。

DNS 快取污染(DNS Cache Poisoning)是另一種常見攻擊。攻擊者向 DNS 伺服器發送偽造的回應,讓伺服器快取錯誤的記錄。當其他使用者查詢這個網域時,就會得到錯誤的 IP 位址。這種攻擊可以影響大量用戶,而且很難被發現。

中間人攻擊 (Man-in-the-Middle) 利用 DNS 查詢未加密的特性。攻擊者可以攔截你的 DNS 查詢,並回傳偽造的回應。傳統的 DNS 查詢是明文傳輸的,任何人都能看到你查詢了哪些網站,這也是隱私方面的問題。要防範這些攻擊,可以使用有信譽的 DNS 服務、定期檢查路由器設定、保持系統更新,並注意網站的 SSL 憑證是否正確。

DNSSEC 是什麼？

DNSSEC (DNS Security Extensions) 是為了解決 DNS 安全問題而開發的一套擴充協定。它透過數位簽章來驗證 DNS 回應的真實性,確保你收到的 DNS 記錄確實來自權威伺服器,而且沒有被竄改過。

DNSSEC 的運作原理類似於 HTTPS 的數位憑證。網域擁有者會用私鑰對 DNS 記錄進行簽章,而查詢者可以用公鑰來驗證簽章。每一層的 DNS 伺服器都會驗證下一層的簽章,形成一條信任鏈,從根伺服器一直延伸到目標網域。

雖然 DNSSEC 提供了更好的安全性,但它的部署還不夠普及。啟用 DNSSEC 需要額外的設定和管理,而且會增加 DNS 回應的大小和處理時間。不過,越來越多的網域開始支援 DNSSEC,尤其是政府機關和金融機構的網站。GCP 的 Cloud DNS 也有提供 DNSSEC 的功能，說明文件在此。

除了 DNSSEC,DNS over HTTPS(DoH)和 DNS over TLS(DoT)也是提升 DNS 安全性的技術。它們透過加密連線來傳輸 DNS 查詢,防止被竊聽或竄改。Firefox 和 Chrome 等現代瀏覽器都已經支援 DoH,讓你的 DNS 查詢更加私密和安全。

結論

DNS 是網際網路基礎建設中不可或缺的一部分,它將複雜的 IP 位址轉換成我們容易記憶的網域名稱,讓上網變得簡單直覺。透過本文,我們了解了 DNS 的基本概念、運作原理、各種記錄類型,以及快取機制。我們也探討了常見的 DNS 問題和解決方法,介紹了值得信賴的公共 DNS 服務,並討論了 DNS 的安全性議題。

雖然 DNS 的運作過程複雜,涉及多層伺服器的協作,但對一般使用者來說,它就是默默在背後工作,讓我們能順暢地瀏覽網頁、收發郵件、使用各種網路服務。當你遇到連線問題時,現在你知道如何從 DNS 的角度來診斷和解決。選擇適合的 DNS 服務,注意安全性,就能享受更快速、更安全的上網體驗。

DNS 技術還在不斷演進,從 DNSSEC 到 DoH,都是為了讓這個系統更安全、更有效率。作為網路使用者,了解 DNS 的基本知識能幫助我們更好地掌控自己的上網體驗,也能在遇到問題時知道該如何應對。希望這篇文章能讓你對 DNS 有更深入的認識!

常見問題解答

Q1: DNS 和 IP 位址有什麼差別?

IP 位址是網路上每台裝置的實際地址,就像門牌號碼一樣。DNS 則是將容易記憶的網域名稱(如 google.com)轉換成 IP 位址的系統。簡單說,DNS 是翻譯機,IP 位址是目的地。我們輸入網域名稱,DNS 幫我們找到對應的 IP 位址,然後電腦才知道要連到哪台伺服器。

Q2: 更換 DNS 能提升網速嗎?

可以,但效果有限。更換到速度較快的 DNS 服務可以縮短網域解析時間,讓網頁開始載入得更快一點。不過 DNS 查詢通常只佔整個連線過程的一小部分,而且有快取機制。真正影響網速的主要是你的網路頻寬、伺服器距離和網站本身的效能。換 DNS 比較明顯的好處是提升穩定性和安全性。

Q3: 為什麼更改 DNS 設定後還是連不上網?

可能有幾個原因:首先,DNS 記錄有 TTL 設定,舊的記錄可能還在快取中,需要等待一段時間或手動清除快取。其次,可能是你輸入的 DNS 伺服器位址有誤,仔細檢查數字是否正確。也可能是網路連線本身有問題,或是防火牆阻擋了 DNS 查詢。試著用其他裝置測試,或暫時改回自動取得 DNS 來排除問題。

Q4: 什麼是 DNS 污染?如何避免?

DNS 污染是指 DNS 伺服器的快取被植入錯誤或惡意的記錄,導致使用者被導向錯誤的網站。這可能是遭受攻擊,或是某些地區刻意的網路管制。要避免 DNS 污染,可以使用可信賴的公共 DNS 服務如 Cloudflare 或 Google DNS,啟用 DNSSEC 驗證,或使用 DoH/DoT 加密 DNS 查詢。定期清除 DNS 快取也有幫助。

Q5: 企業需要架設自己的 DNS 伺服器嗎?

這取決於企業規模和需求。大型企業通常會架設內部 DNS 伺服器來管理內部網域和提供更好的控制。自己的 DNS 伺服器可以加快內部網域的解析速度,提供客製化的 DNS 記錄,並增強安全性。但小型企業可能不需要,使用網域註冊商提供的 DNS 服務就足夠了。架設 DNS 伺服器需要專業知識和持續維護,要考慮成本效益。

The post DNS 是什麼？就是把網址轉成 IP，你的手機和電腦才能找到網站 first appeared on 東東 GCP 教學 - GCP 實戰講師.

好消息是——這個限制，其實沒你想像的嚴重。

我將完整解析「非工程背景者」是否能轉職為雲端架構師，並提供清晰的學習路線與轉職策略。

雲端架構師是做什麼的？職責全面解析

雲端架構師是企業轉型雲端的關鍵推手，他可以依照企業的需求，負責設計可擴展、高可用、具備安全性的整體雲端系統架構。

「可擴展」，指的是能夠擴充資源。

因為地端的資源受限於你買的機器數量，但在雲端，你可以隨時依照公司的需求，或是突然飆升的用戶流量，即時擴充資源來應付廣大的需求。

「高可用」是什麼呢？

高可用是一個「結果」，指的是服務能夠保持運作的時間比例很高。

要做到高可用，並不是說要開一台規格很高或效能很好的主機 (因為單台主機可能因維護而被重開) 。

而是善用雲端上各種資源搭配，組合成強壯的系統架構，不管發生什麼事，都不會因為單個功能故障，讓整個服務無法運作。

例如建立一群機器，讓負載平衡器在最前面幫忙分流，即使有一台機器故障，負載平衡器也能把流量導向正常運作的主機。

或是資料庫有問題，馬上自動 Failover (容錯移轉)，讓 Stand by 的主機出來頂替， 保持整個服務正常。

所以雲端架構師會知道怎麼做出「可擴展」、「高可用」」且「安全」的雲端架構，這就要先了解雲端的各項功能了！

為什麼雲端架構師這麼搶手？

數位轉型已是企業標配

隨著全球企業數位轉型的浪潮不斷加速，雲端服務早已從「可選項」變成「必要條件」。

現在的新創公司，不可能一開始就花大錢建置機房並購買機器設備，幾乎都是買一台筆電就開始寫程式、打造產品。

那程式寫好放哪裡？當然是直接上傳雲端啊！直接下一個 git commit 就能上傳到雲端，甚至能夠自動部署上線對外服務。

大企業的話，因為地緣政治風險，有不少公司早已經採用「多雲策略」，因為雞蛋不會放在同一個籃子裡，不會把核心系統 100% 都放在某個雲端上。

可能各放 30%，甚至還留一些到地端。也不會集中在單一國家，可能把服務分散到日本、東南亞，甚至留一些服務到歐美去。

傳統產業，可能採用雲端的速度是最慢的，但由於近年來 AI 高度發展，逼得各個公司為了投入 AI，也開始紛紛上雲。

為什麼用 AI 要上雲呢？

因為你直接買機器和 GPU 太貴了！動輒幾十萬，買了也不會一直開著。

用雲端的話，只有要訓練模型時，才會短暫用到 GPU 和相關運算資源，用完就關掉，訓練 8 小時也才 1000 台幣，非常划算。

所以各行各業都在思考如何上雲，達成更高的效率、更強的彈性與更低的成本。

而在這個過程中，雲端架構師正是那位為企業「指路」的專業顧問。

企業急需懂得架構設計的人才

企業不再滿足於只會操作雲端平台的技術人員，他們更需要具備系統整合與架構設計能力的人才，能夠根據業務需求規劃出安全、可擴展且高可用的雲端解決方案。這樣的角色不只要懂技術，還要懂得與內外部團隊溝通，將業務與技術串聯起來。

多雲、混合雲環境日益複雜

再加上現在企業多採用「多雲」（multi-cloud）或「混合雲」（hybrid cloud）策略，也就是同時使用 GCP、AWS、Azure 等不同平台，或將本地系統與雲端資源整合。這讓整體架構更加複雜，需要有能力跨平台思考、規劃與管理的架構師。因此，雲端架構師的價值不斷攀升，成為 IT 領域最炙手可熱的職位之一。

雲端架構師與其他職位有何不同？

必須要會寫程式嗎？破解常見迷思

「不會寫程式就不行」的觀念從哪來？

多數人將「技術職位」與「寫程式」劃上等號，實則雲架構師更偏重架構規劃與整合，寫程式只是工具之一。

雲端架構師實際工作中需要寫多少程式？

• 少量腳本（如 Terraform、Cloud Shell）
• 理解 API 結構與部署流程
• 協助團隊整合 CI/CD 流程

基礎程式能力 v.s. 專職開發能力

具備程式基礎會是加分項，但不需達到軟體工程師的水準。更重要的是——你能否整合不同系統、解決架構瓶頸。

成為雲端架構師的關鍵技能有哪些？

系統設計與架構思維

能否依據需求設計出高可用、高效能、具備擴展性的架構，是核心關鍵。

雲端平台操作（GCP、AWS、Azure）

建議選定一個平台深入，如 GCP 的 Compute Engine、Cloud Run、BigQuery 等。

資訊安全與法規遵循

熟悉 IAM、資料加密、法規（如 GDPR、ISO 27001）等，是專業的重要體現。

溝通能力與專案協作

懂技術不夠，還得懂得與開發、主管、甚至客戶溝通架構設計邏輯。

不會寫程式的人該如何轉職？可行路線解析

起點建議：從雲端平台認證開始

• Google Cloud Digital Leader（零程式基礎也能考）
• AWS Cloud Practitioner
• 這些證照強調架構與平台基礎概念

銜接課程與學習資源推薦

• 選擇「非開發導向」的雲端架構課程
• 像是《東東 GCP 教學》提供的入門到架構師路線

找到轉職跳板的策略

• 先從雲端專案協作角色（如 PM、顧問、技術支持）切入
• 慢慢累積架構設計經驗

真實案例分享：他們都不是工程師出身！

MIS 主管轉職雲架構師的心路歷程

「我原本只會部署防火牆、設定備份，但開始接觸 GCP 後，才發現我可以不靠寫程式，也能設計一整套混合雲架構。」

專案經理成功進入雲端領域的轉折點

「我專長是專案管理，當我熟悉 GCP 的產品與整合策略後，我現在負責帶領跨國團隊打造多區架構。」

優勢與挑戰並存：非工程背景的強項在哪？

• 跨領域溝通能力強
• 站在使用者角度思考系統設計
• 懂流程、懂業務的人更容易設計實用架構

給未來雲架構師的五點建議

1. 選定一個雲端平台，深入學習
2. 建立技術部落格或學習筆記
3. 多參加實戰專案，累積架構經驗
4. 搭配證照驗證專業能力
5. 保持學習熱忱，並勇敢踏出第一步！

常見問題 FAQ

1. 需要考哪些證照才有機會轉職？

推薦先從入門證照開始，如 Google Cloud Digital Leader，再進一步挑戰 Architect 級別。

2. GCP 跟 AWS 哪一個比較好學？

GCP 的介面與邏輯較清楚，適合初學者；AWS 生態完整，但曲線略陡。

3. 非本科系可以嗎？

完全沒問題，重點是你的學習力與實作經驗。

4. 英文不好也能學嗎？

能，現在有大量中文教材與圖解式資源可用，但英文仍建議逐步增強。

5. 需要有雲端專案經驗才能轉職嗎？

不用。你可以先參與模擬專案、自學實作，逐步累積作品與信心。

The post 不會寫程式，可以轉職雲端架構師嗎？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

可以來了解一下這個職位必備的一些能力，

來確認看看你合不合適這份工作喔～

一、IT 的基本能力

例如 DNS 的概念、IP 網段的切割、HTTP 的回應碼、

容器的基本概念、各種專有名詞或術語 CRM、ERP、VPN、FTP、

Web Server、HA、SLA、DR、Kubernetes 等等。

如果都還不熟，簡單地講，至少 Linux 會各種基本的操作指令。

你可以找一些系統管理、網路管理或 Linux 的線上課程，

或是多看一些文章，來培養一些基本的 IT 概念。

二、學習能力

因為 GCP 的發展速度太快了，如果你有在操作 GCP，每1~2個禮拜你就會發現，耶怎麼界面又改了？

怎麼又多一個按鈕？又有一個新產品？

所以如果有時間，要趕快看原廠的文件來追進度，通常新產品剛出來只有英文，所以也需要能夠快速閱讀英文的文件。

有些規模比較大的客戶，看到產品更新的消息，就會跑來問你，這功能怎麼用。

你要趕快把環境建立起來做相關的測試，測完之後做成簡報，分享給同事跟客戶。

讓大家知道這個新功能會用在什麼樣的場景，有什麼優缺點或限制等等，所以學習能力也是很重要的喔！

三、傾聽能力

客戶有很多種，每個客戶都有自己熟悉的領域，他們會站在自己的角度問問題，有時候說的是 A，但他其實要的是 B。

例如資料備份就有很多種，他要的是VM裡的檔案備份、還是資料庫的資料備份、還是作業系統的備份。

或是客戶要 VPN，Google 的方案是 Site to Site VPN，需要客戶有機器，那客戶有嗎？還是他只是要 Client to Site VPN 就好？

這些就要用循循善誘的方式 (擠牙膏)，挖掘出客戶真正的需求，另一方面也是要對 GCP 的產品有足夠的了解，才有辦法知道客戶要的是什麼。

另一個場景是，做技術支援的時候，客戶說連不到主機，像這樣的問題牽涉到很多環節。

例如是目的地主機有問題，還是防火牆擋住，還是來源主機根本不能上網。

很多時候客戶根本就沒有表達清楚，這時就要有耐心再跟客戶來回確認問題，不然往錯的方向去解，就會浪費很多時間。

四、提案能力

有時候針對客戶的需求，我們會找不到完美的方案來完全滿足。

例如客戶想要最高級的防護或最高的可用性，但客戶自己預算可能不夠，沒錢做備份，或沒錢多開機器。

這時候就是要在多種限制底下，找到一個適合客戶的方案，然後清楚地告訴客戶可以使用的產品是什麼，可以做到什麼樣的程度等等。

雖然方案不完美，但能夠解決最核心的需求，就有可能說服客戶接受我們的解決方案。

有時候面對的需求是不合理的，例如在線上編輯20GB的資料表，100%機器不中斷之類。

我們也要直白跟客戶說，這個是做不到的，我們也不能硬著頭皮去接下一個不可能的任務。

五、表達能力

我們會有拜訪客戶的場合，或是舉辦研討會來介紹產品，客戶往往是聽不懂的。

因為我們每天都在摸GCP，對各個產品都很很熟悉，但客戶可能是第一次聽，他可能完全聽不懂，或是以為這個產品是萬能的，可以解決所有問題。

這時候就要想辦法跟客戶釐清，為什麼它可以解決A問題，原理是什麼，又為什麼 B 問題解決不了，關鍵是卡在哪裡，這時候表達能力就很重要。

同時這也取決於你對GCP的產品是不是真的了解透徹，如果你一知半解的話，你也很難跟客戶說清楚，所以又回到你的學習能力要好，才能了解產品。

六、實作和排錯能力

我相信大家都知道實作和排錯的重要性，但更重要的還有經驗，因為我們平常的測試環境是很單純的，每次自己做Lab，都是在一個乾淨的環境裡做。

但如果今天是幫客戶建置一個很大的架構，或是客戶在自己使用很久的環境碰到問題的話，這時候要做Troubleshooting，就很需要有足夠的經驗了。

對有經驗的人來講，可能一看到錯誤就馬上知道問題在哪裡，但對沒經驗的人來說，就可能要照步驟來一個一個拆解問題，花費的時間就會比較多。

但經驗這種東西又不可能憑空產生，只能靠我們平常做的 Lab 要夠多，有空就多測試各種 GCP 的東西，然後把不同的東西串連起來。

當架構變大的時候，就有各種奇奇怪怪的問題跑出來，這時候就有機會磨練各種經驗。

有一種方法可以試試，就是你去找 AWS 的範例架構，然後想想看在GCP上面能不能找到對應的產品或功能，然後直接在GCP上面做起來，這樣你就不用自己想題目來練。

以上就是幾個雲端架構師必備的技能，分享給各位～

The post [轉職 IT] 雲端架構師要具備的六大能力 first appeared on 東東 GCP 教學 - GCP 實戰講師.

但是你沒學過 IT 基礎知識，

例如 DNS、TCP/IP、Web Server 等，

可以先看一下這些影片，

先用輕鬆的方式體驗一下，

同時確認你是否看得下去 (確認你是不是真的有決心)，

我這邊就列一點點，各你參考看看，

你先可以挑有興趣的看，不用給自己壓力全部都要會。

網路基礎：

Linux 操作：

DNS 概念：

前端、後端、資料庫：

如果資料庫要學更完整：

如果想要寫程式可以先看這影片：

這邊要補充，要進資訊產業當工程師，不是只有軟體工程師，

還有 MIS、網路管理、資料庫管理 (PM)、系統工程師、DevOps 工程師等等，

所以我才把寫程式放後面一點，

怕大家想到 IT 就以為是要寫程式。

放輕鬆看喔，看不懂就多看幾遍，

當你看完影片，覺得可以適應這些 IT 術語，

可以再評估是不是真的要找個專業的課程來上，

才不會太早就花了冤枉錢喔！

The post 基本 IT 知識學習資源整理 first appeared on 東東 GCP 教學 - GCP 實戰講師.

我也是有過去的

我在工作的前幾年，對未來方向很不確定，一直跳來跳去。

我也是有迷茫過的人啊～

我後來在某系統整合廠商擔任專案經理，但因為那份工作太過忙碌，

以及要夜間職班的關係，傷了身體，就離職了。

我原本打算回去做 SAP 工程師的，

因為用人單位的系統已經上線了，我去就是維護而已，

心想應該會是個穩定的工作，當時的我就是沒有太大的企圖心。

被前主管挖角

我不知道為什麼，直接在 Facebook 公開我要找工作的消息。

結果！我的一家前公司主管打電話給我。(可見我做人還蠻成功的 XD)

他告訴我「公司現在跟 Google 合作，你回來的話，前途將會一片光明！」

他要我回前公司負責推展 Google 的業務。

我其實想了蠻久的，「真的要去嗎？」

當時真的非常掙扎，表面上聽起來很棒，

實際上就是要從無到有把從產品、售前到業務的流程建立起來，

後來我還是決定再衝一波看看，如果成功了，

也許就能擺脫之前跳來跳去的工作情況。

正式接觸 GCP

於是我開始擔任 Google 其他產品的 Presales，

但由於種種因素，產品沒有賣得很好。

後來公司調整策略和人力，開始賣 GCP，

當時我完全不懂 GCP，

只能厚著臉皮詢問資深的同事，慢慢學習 GCP 的各項功能。

不過當時沒有做案子的機會，碰到客戶就純粹報價，

然後客戶自己操作 GCP，有問題再問我們。

現在看起來，我們提供的服務也太差了！！

有案子都不試著接，所以 GCP 的技能提升非常慢，

我連 Load Balancer 都是自己瘋狂練習一個月才學會的。

跳槽去別家代理商

後來我就轉往另一家代理商工作，

(就是一般職場常見的原因，你懂的)

新的主管技術很強、人脈很廣，又很會接案，

在大量案子的壓力之下，不得不卯起來練習 GCP 的各項功能，

很多功能都是我從來沒做過的，怎麼辦？

就是自己上網查詢相關文件，自己從零開始設定，然後測試。

我做過了上巿遊戲公司、電子支付公司、區塊鏈公司、

大型政府單位、AI 公司、上巿電子商務、上巿零售公司等等，

因為當時人力不足，所以每個客戶我都做過，

累積不少架構經驗，薪水快速破百。

當時也成為公司研討會的主力，

從 Compute Engine、Load Balancer、Cloud CDN 到 Google Kubernetes Engine、BigQuery、AI 與機器學習等等，

每個主題我都講過，大量提升對抽象技術的表達能力，

讓我不是只會做，而且也很會講，只有我講的客戶才聽得懂，

我幾乎都是 Live Demo，直接在幾十位觀眾面前，

從零架設環境，如果出包還要想個辦法轉一下，

漸漸地，我也有機會站上大型研討會的舞台分享 GCP。

晉升架構師主管，培訓新人

後來我順利獲得晉昇成為架構師主管，開始招募人才，

不過巿場上碰過 GCP 的人非常少 (所以趕快來轉職吧)，

我們找到的人才也要再加以培訓，公司也沒有什麼學習資源，

還好我每個案子都有累積各種簡報和操作手冊，

我獨自整理出一整套新人學習的教材。

我也對每位新人手把手教學，定期在公司辦理讀書會分享技術，

後來他們都成為獨當一面的架構師，

幫公司接了更多更大的案子，成為公司營運的主力。

開始做自媒體

由於我這個人就是很想紅，

一直想做自媒體，我經過主管同意，

開始在業餘期間建立 Youtube 頻道，分享 GCP 的教學。

剛開始前幾支影片，都是 0 訂閱。

當時也會懷疑，我的影片這麼有價值，怎麼可能沒有人要看？

沒關係啦，反正我就是硬著頭皮一直做，

直到發布第 4 支影片之後，剛好有事在忙沒再更新，

頻道突然從 0 爬到 13 訂閱，令我又驚又喜！

此時就確定我做的內容應該是對大家有幫助的，

更加強我持續發布影片的決心。

正式辭職創業

直到 2023 年 5 月時機成熟，辭職創業，

因為身上帶著豐富的 GCP 經驗，就有各種發展的可能性，

除了我自己開發的線上課程，

我也開始接到一些顧問案、企業內訓、線上諮詢等等，

最近還有專欄的邀約在洽談中。

由此可見，GCP 的需求是真的不斷在成長，

不管你是在公司擔任雲端架構師，還是創業接案或擔任顧問，

你都會有很好的發展機會。

像我帶過的幾位架構師，後來也跳槽到更好的公司去發展，

薪水也直接破百，每季都有很棒的旅遊福利。

連創業的我都反過來羨慕他們(因為沒人發年終給我哭哭)。

因此，走對產業很重要，找到快速提昇的路徑也很重要。

看到這裡，你是否願意給自己一個突破現狀的機會呢？

參考一下我累積多年經驗所開發的課程吧：

GCP 線上課程《雲端架構師養成班》早鳥優惠中

The post [GCP 轉職] 我的雲端架構師經歷 first appeared on 東東 GCP 教學 - GCP 實戰講師.

一、技術能力不足

這個最基本的，如果你對於雲端的相關知識或技能不夠，

就沒有辦法成為公司的即戰力，很容易就會被刷掉。

還有一種情況是，雲端的範圍實在是太廣了，

公司想要的可能是混合雲的網路管理，或是使用 Kubernetes。

而你熟悉的領域只在虛擬機器，那就依然無法符合公司的需求，

有時候需要一點運氣，

不然就盡可能要對大部分的雲端使用場景更熟悉一點。

二、做過什麼答不出來

我在面試新人的時候，深入研究他的履歷表，曾經有做過哪些工作，

尤其是和雲端相關的工作，我總是會順著他的工作內容往下深入追問，

例如他曾經做過負載平衡，我就會詢問他的主機可以自動擴充到幾台？

擴充判定的指標是什麼？是否碰到其他的問題，是機器數量的問題，

還是擴充速度的問題？我也會問他後來是使用什麼方法去克服。

三、非雲端工作，本來就沒有作品

這個情況通常會比較有挑戰性，目前可以做的方法，

就是多看一些行業的文章，是否有提到各種系統架構，

然後去思考這個架構要如何在雲端上面實現，

從零開始把整個架構在雲端上架設起來，然後測試看看有沒有問題。

四、產業 Know How 不懂

當然自己練習的話，通常都只能熟悉理論知識，

沒有辦法碰到實務上的狀況，所以比較沒有辦法了解太深。

你也可以多看幾種產業架構，不同架構之間的設計邏輯，

為什麼要選 A 架構，不用 B 架構，為什麼要用 C 服務，不用 D 服務，

多多去思考，也可以磨練基本的 Sense，

這個就是架構是最核心的能力。

在我的線上課程中，有提供一些範例架構的問題，

可以磨練你的思考，如果我這裡提供的問題你都有辦法立刻回答，

信相你的求職之路不會太困難。

五、不會寫程式

我可以跟你說，我現在還是不太會寫程式。

我當年找工作時，也有碰到要會雲端同時也要會寫程式的用人單位，

我也因為不會寫程式而被主管刷掉。

但是不用擔心，有些公司就是喜歡把一個人當多個人來用，

你還是可以持續在尋找只需要雲端技能的公司，這是完全沒問題的。

但是如果你願意多花一點時間學習寫程式，我相信對你還是有加分，

其實你不需要投入太多的心力在學習寫程式上，

因為它對於雲端架構師這個職位來說，只是一個「有了會更好的技能」，

你只需要買一本書，一堂線上課，

至少能寫得出 Hello World 在 Apache 或 Nginx 上，

也能夠讀寫雲端上的資料庫，差不多了，

只要能和 Coding 的同事溝通，就足夠了。

如果你未來的工作會處理到雲端架構，又同時需要寫很多程式，

我會先恭喜你，因為這樣的技能，在你的職涯會非常吃香，

你就是一個跨領域的工作者。

六、你對這個職位是否表達強烈的興趣或熱情

我有面試過一些人，他們前面的關卡都過關了，

但是無法讓我有很想要錄取他的衝動，也許只是單純的直覺，

擔心他無法融入團隊。

所以需要你除了回答各種問題之外，盡量展現你的個人特質，

例如說你會喜歡一個人深入研究問題，或者喜歡和同事討論，

喜歡人團隊合作，注重公司的工作氣氛。

你也可以詢問這個職位是否有持續成長的空間，

不管是技能的或職位的提升都可以。

你甚至可以表達未來的理想，例如獨當一面處理非常大的雲端架構、

你想要成為主管等等，都可以讓人覺得你有強烈的企圖心，

這也是你可以給公司帶來的價值。

說直白一點，就是畫一個大餅給公司，吸引公司想要吃下你給的這個大餅。

看到這裡，你準備好了嗎？

假如你決心要學習 GCP，參考一下這堂課程吧：

GCP 線上課程《雲端架構師養成班》早鳥優惠中

The post [GCP 轉職] 轉職雲端架構師失敗的原因有哪些？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

轉職前，你只是在自己的 Lab 環境底下學習，環境是可控制的，

而且你有最高權限，所以可快速測試各種功能。

轉職後，新公司的 GCP 環境可能有各種設定存在，

有些合理有些不合理，管理員可能是你的主管或資深同事，

你的權限可能不大，能做的事不多。

但既使你做了一點調整，可能會牽一髮而動全身，

影響到其他功能的運作，因此要非常小心，了解各種眉角。

如果你是負責地端系統上雲的，你就要考慮是否可以重新部署，

或是原封不動搬上雲，然後規劃上雲的時間表，

並且留時間做驗證，確保上雲之後沒有問題。

這部分會牽涉到所有的細節，

你可能做到一半會遇到「啊！還有這個沒確認」、

「現在才說要這個功能，可是都已經設下去了」，

過程中可能會覺得很煩，但是當你完成之後，會非常有成就感，

它就是你在公司的代表作。

二、考取證照的日常

GCP 或其他公有雲的證照，都是 2~3 年就必須要 Renew (重考)，

當你第一次考的時候，題目可能很簡單，但 2 年後再考的時候，

由於新功能的加入，讓整個題目大改版，

所以你 Renew 證照也會花費很多時間。

隨著你考取的證照越來越多，你就會跟我一樣，

三不五時都在 Renew 證照，才剛考完 A 證照，B 證照又要到期了。

所以請挑選工作上會用到，想要深入鑽研的科目去考，

例如必備的 Cloud Architect，或是資訊安全的 Security Engineer，

網路的 Network Engineer 等等。

不過考試確實有好處，它的題目都是從真實案例萃取出來的，

非常實用，每次考試都會打翻我既有的概念，

讓我在實務上可以做得更完善，設計出來的架構也符合大企業的格局。

同時證照也是你的護城河，別人想超越你，先考到證照再說。

三、充滿挑戰性的職涯

原本的 GCP 界面長這樣，怎麼下個禮拜說變就變？功能說改就改？

沒錯，這就是雲端架構師的日常，

在雲端的世界裡，沒有永遠不變的功能，

就算你使用同一台虛擬機器穩定運作，

幾年後可能也會被告知停止技術支援，逼得你不得不換到新的作業系統或環境。

每當 Google 宣布新的功能，可能馬上就有人問你，

可不可以幫忙介紹一下XX功能，或是測試看看。

很忙，但也很有趣，你會站在技術的風口浪尖上，

永遠跟大家有聊不完的話題，你會和整個巿場脈動有很深的連結，

也有很深的使命感。

所以，挑戰是壓力，也是推進你的動力，你準備好了嗎？

The post [GCP 轉職] 轉職雲端架構師後就平步青雲嗎？會不會遇到什麼挑戰？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

當你去公司報到之後，主管可能會提出一些需求，

然後請你去規劃雲端的架構。

例如主管說「幫我建一台 Linux的機器，要裝 Apache」，

這樣的需求很粗略，你必須把要問的問題一次向主管問清楚，

例如哪種型號？多少 vCPU 和記憶體？要怎麼連線？要不要外部 IP？

OS 版本？Apache 版本？Disk 多大？

你需要有快速回應的能力，知道對方少給什麼資訊，

趕快回覆跟他確認細節，或是自備一張常用規格表，

請對方填寫後再給你確認。

或者，客戶問「我的 Windows 能不能直接搬上雲？」

這需要你對於客戶環境、搬遷方式、成功機率，

和 Windows 授權機制都有一定的了解，才能完整回覆客戶。

二、跳槽機會

如果你在 104 或 Linked-in 詳細更新你的經歷，

你很快就會收到外商或獵人頭的面試邀請。

如果你工作還不夠久，不要急著跳，至少待滿2~3年，

並且利用時間加強英文，因為 Linked-in 上很多工作都是來自國際大廠，

這會是你的「下一站」。

三、深耕領域

當你做久了會發現， GCP 涵蓋的領域很廣，架構只是剛入門。

接下來你可以依照公司的需求或自己的興趣深耕，

如果對應用程式平台有興趣，可以研究 GKE 和 Anthos；

如果對資料有興趣可研究 BigQuery、Dataflow、Dataproc、

Data Fusion 還有 Cloud Composer 等。

如果對 AI 有興趣可以研究 AutoML、TensorFlow、

DialogFlow、生成式 AI 等，

只要能對上述任何一項非常專精，就能得到更專業的職位和錢途。

自立門戶：接案、顧問、企業內訓

當然，你也可以持續走架構師的工作，

因為光是這一塊已經吃不完了，而且隨著經驗的累積，

你可以收集到各種產業的商業模式和雲端架構，

這會有助於你變成一位充滿經驗的雲端顧問。

當你具備足夠的底氣和業界的名聲，

你也可以辭職創業，擔任講師、顧門或獨立接案。

不過這也需要你在網路上經營個人品牌，

選擇部落格、Youtube或 IG 來持續產生內容，讓案子自動找上你喔！

由此可知，雲端架構師的路是越走越寬的喔！

如果你已經下定決心的話，

可以來考慮加入GCP 線上課程《雲端架構師養成班》喔！

The post [GCP 轉職] 轉職雲端架構師之後會有怎麼樣的發展？ first appeared on 東東 GCP 教學 - GCP 實戰講師.