一、當 Day 19 的四問告訴你「極限是你自己」

這個場景遲早會遇到：目標是 500 個 VU 的 load test，跑到 300 VU 時，Day 19 的四問亮燈了——施壓機 CPU 90%、http_req_blocked 開始肥大。你已經知道這時候的數據不能信：量到的是自己的極限，不是系統的。筆電就這麼大一台，然後呢？

先別急著找更大的機器。這一天叫「導覽」而不是「實作」，因為第一步永遠是問：你真的需要那個量嗎？這題有三個檢查，很多「壓不出來」的問題在這裡就解掉了。

檢查一：目標 VU 是怎麼來的？如果 500 VU 是 Day 12 從業務數據推出來的（尖峰同時在線、有依據），那它是真的；如果是「取整數比較好看」或「別人家都測 500」，回去重推。很多目標砍半之後，本機就夠了。

檢查二：能不能用更少的 VU 製造同樣的壓力？Day 12 講過負載模型的本質是「單位時間的請求數」。同樣的 rps，可以用 500 個慢慢想的 VU 達成，也可以用 150 個不想事情的 VU 達成——把 sleep 縮短、用 arrival-rate 型的執行器直接指定每秒請求數，常常能在本機做出你要的壓力。這一步請 Claude Code 幫你改，說清楚你要的是「固定每秒 N 個請求」。

檢查三：瓶頸是不是可以搬走的？Day 19 教過先看 blocked——如果肥大的是連線建立，換有線網路、關掉 VPN、把施壓機搬到和目標同一個網段（跟 RD 借一台跳板機），常常就過了。CPU 真的滿了，跟 RD 借一台規格好的閒置機器跑 k6，成本是一杯咖啡的人情。

三個檢查都過了、目標量還是壓不出來——好，你是少數，往下看三條路。

圖 1：本機壓不出來時的判斷流程——多數團隊停在前兩層，走到雲端的是少數

二、三條路：換條件、多台機器、雲端

第一條路：一台更大的機器。最便宜、最少新概念。k6 是出了名的省資源，一台規格普通的雲端虛擬機（例如 8 核 16G）跑上千個協定層 VU 通常不是問題。跟公司要一台、或租一台按小時計費的，把 Day 14 的 repo 拉下來就能跑——你在 Day 23 已經看過「測試跑在別人機器上」長什麼樣子了，這只是手動版。

第二條路：多台機器分散跑。k6 開源版沒有內建的「一鍵分散」，土法是多台機器各跑一份腳本、各分一段參數化資料，結果再合併——做得到，但資料切分、時間同步、結果合併都是自己扛；正規做法是 k6-operator 跑在 Kubernetes 上，那需要有 K8s 的團隊和願意幫忙的 RD。這條路的成本不是機器錢，是工程協作。團隊已經有 K8s 又有人力，它很划算；沒有，跳過。

第三條路：雲端執行，今天的主角。Grafana Cloud k6 是 k6 官方（Grafana Labs）的雲端服務：你把同一份腳本交給它，測試跑在 Grafana 的機器上，從你選的地理區域發出流量，結果進雲端儀表板。對你來說的改變只有一行指令——腳本完全不用改，Day 4 到 Day 24 學的東西全部適用。

三條路並排：

三、Grafana Cloud k6 導覽：它替你做掉什麼

就算今天不註冊，這三件事也值得知道——它們解釋了雲端執行在什麼情況下是「值得付錢的懶」。

第一，機器不再是你的問題。Day 19 整天在教的施壓端自我懷疑——CPU 滿沒滿、連線夠不夠、網路穩不穩——在雲端執行裡由服務方扛。它的機器規格與網路出口是為壓測設計的，四問裡的前三問基本不會是你。注意「基本」：Day 19 的思維不是失效，是換了對象——你還是要看它回報的施壓端指標，只是紅燈的機率低很多。

第二，多地理位置的流量。這是雲端執行真正獨有、本機無論如何做不到的事。你的使用者不在你的筆電旁邊：台灣的使用者連到你在美西的機房，先付 130ms 的來回延遲，這是物理，誰都免不掉；而你從本機壓測，量到的永遠是「機房隔壁鄰居」的體驗。雲端執行讓你選 load zone——從東京、新加坡、美西、法蘭克福同時發流量，各地的延遲、CDN 有沒有生效、WAF 對不同地區的行為，全部變成可以量測的東西。什麼時候需要：你的使用者真的分佈在多個地區，或你想驗證 CDN／多區部署有沒有用。使用者全在台灣、機房也在台灣？那多地理位置對你是名詞，不是需求。

第三，儀表板與留存。Day 20 你手工做的事——存 HTML、留 raw.json、Day 24 的分桶畫趨勢——雲端服務內建：每次測試自動留下可分享的網頁報告、歷次比較、依端點與地區拆解的曲線。判讀仍然是你的工作（Day 18 到 21 沒有一天白學），它只是把「整理數據」這一段做掉了。

順帶一提，同一個帳號還有另一個常被搞混的用法：測試照樣在你本機跑、只把結果串流到雲端儀表板（本機執行、雲端輸出）。它不解決「壓不出來」的問題——流量還是從你的筆電出去——但免費解決「Day 20 的報告想給團隊看歷史比較」的問題。分清楚這兩種模式，很多「要不要付錢」的討論會清楚很多。

四、成本：VUh 是什麼、免費額度夠做什麼

雲端執行按 VUh（virtual user hour，虛擬使用者小時）計費：一個 VU 跑一小時＝1 VUh。帳算起來很直觀：

VUh ＝ VU 數 × 測試時長（小時）

例一：Day 7 的 smoke，3 VU × 1 分鐘        ≈ 0.05 VUh   —— 幾乎免費
例二：Day 12 的 load，50 VU × 10 分鐘      ≈ 8.3 VUh
例三：本機壓不出來的那個 500 VU × 30 分鐘  ＝ 250 VUh
例四：Day 24 的 soak，20 VU × 4 小時       ＝ 80 VUh

撰稿當下，免費帳號每月含 500 VUh，不需要信用卡、也不會過期；超過免費額度後大約每 VUh 0.15 美元。數字以官網為準（額度與費率都改過版），但量級的直覺可以帶走：例三那種「本機真的壓不出來」的測試，一次 250 VUh，免費額度一個月夠跑兩次——當作驗證「到底需不需要雲端」的試用非常足夠；要月月常態跑，就開始是錢了，例如每週一次例三加一次例四，一個月約 1,320 VUh，超額部分約 120 美元。這也是為什麼 Day 23 的分層在雲端一樣成立：smoke 這種小東西留在 CI 的免費 runner 上跑，錢花在真正需要量與地理位置的那幾次 load 上。

跟主管提預算時，把這筆帳和替代方案並排：租一台大機器多少錢、RD 陪你搞分散跑要幾個人日、雲端一個月幾次要幾美元——三條路都標上價格，決策就從立場問題變回算術問題（Day 22 的老原則，換個地方再用一次）。

五、選做實作：用免費額度跑一次

願意動手的人，流程四步，全程不需要信用卡。目標沿用 QuickPizza——流量禮儀不變，雲端的量練習時一樣壓小，20 VU、5 分鐘以內。

Prompt 1｜第一次雲端執行

我要用 Grafana Cloud k6 的免費帳號執行現有的 tests/journey.js（目標是 QuickPizza 練習站）。
請告訴我目前正確的做法與指令：
1. 註冊免費帳號後，去哪裡拿認證用的 token、如何在本機登入
2. 用哪個指令把測試改到雲端執行（腳本不改的前提下），
   以及如何在 options 裡指定 load zone（請給我東京或新加坡的寫法）
3. 這次測試會消耗多少 VUh，怎麼在網頁上查看剩餘額度
4. 跑完之後，儀表板上我應該先看哪三個地方（對應我學過的 p95、錯誤率、依端點拆解）
請先查官方文件確認指令與參數的現行寫法，再回答。

幾個實作時的提醒。指令層面：雲端執行的指令在改版中曾經換過名字（k6 cloud 與 k6 cloud run），所以 Prompt 裡要求先查現行文件——這是 Day 23 的老習慣，版本會變，讓 Claude Code 查而不是背。告知層面：流量會從 Grafana 的機器與 IP 發出，如果對象是公司環境，Day 6 的告知要加一句「流量來源是雲端服務的 IP，不是我的機器」，白名單與 WAF 的問題（Day 23 遇過）會再次出現，先問過管網路的人。機密層面：腳本會上傳到雲端服務執行，Day 8 的原則升級——帳密與 token 不但不能寫死在腳本，連測試資料裡有沒有真實個資都要先檢查；用雲端壓正式或準正式環境前,把「資料出境」這件事講給資安或主管聽，讓該點頭的人點頭。

跑完之後做一件對照練習：把雲端儀表板看到的 p95，和你本機跑同腳本的 p95 並排。東京 load zone 打 QuickPizza 和你在新竹打,數字不會一樣——這個差就是地理位置的意義，你第一次把「使用者在哪裡」量化成了毫秒。

六、注意事項：走向雲端前的六個確認

給 RD 的一句話：QA 來討論雲端壓測時，值得一起確認的其實是前兩層：目標量是不是真的（Day 12 的推導）、以及能不能借一台內網機器解決（省錢又省白名單麻煩）。真的要上雲端，他需要你幫兩件事：白名單放行雲端來源的流量，以及確認測試資料沒有真實個資。多地理位置的結果出來後，最值得你看的是各區延遲差——那是 CDN 與部署拓撲的成績單。

七、觀念驗證：三個問題確認你有帶走今天的重點

• 「壓不出來」的三個檢查是什麼？各自對應前面哪一天的功課？（第一節）
• 多地理位置流量能量到哪些本機永遠量不到的東西？什麼樣的團隊其實不需要它？（第三節）
• 500 VU 跑 30 分鐘是多少 VUh？以免費額度估，這樣的測試一個月能跑幾次？這個算術對「要不要付費」的討論有什麼幫助？（第四節）

八、小結

本機壓不出來的時候，路有三條，但入口只有一個：先確認你真的需要那個量——重推目標、改用 arrival-rate、排除施壓端，多數團隊在這三個檢查裡就解決了。真的是少數，再選路：一台大機器最便宜、多台分散是工程活、雲端執行買的是機器與地理位置。Grafana Cloud k6 的免費額度足夠驗證「到底需不需要」，VUh 的算術讓預算討論回到數字；而多地理位置是雲端唯一無可取代的能力——前提是你的使用者真的分佈在多個地方。腳本一行都不用改，是這條路最好的消息：前面二十四天的功夫，搬到哪裡都算數。明天換一個方向的「本機做不到」：API 明明很快，使用者為什麼還是覺得慢——k6 browser，從協定層走進瀏覽器——Day 26 見。