# 沙盒實測口播稿

## 進入獨立練習空間

這次直接操作五零九零主機上的沙盒。先連上課堂的私有網路，再輸入個人帳號與密碼。所有訂單都是合成資料，密碼欄保持遮蔽。

## 四項服務真的串接

按下查詢我的訂單。流程先讀取資料定義，再檢查授權，接著取得短效憑證，最後查詢資料庫。畫面顯示實際回傳的步驟與訂單，教學代理採固定流程。

## 名稱不等於業務定義

進入資料脈絡，先把定義改成模糊的訂單資料。這會真的更新自己在資料目錄裡的紀錄。只知道資料表名稱，還不足以判斷逾期的意思。

## 補上日期、幣別與責任

接著補上完整業務定義。回傳內容明確寫出基準日、尚未出貨、台幣與負責角色。即使執行追蹤全部成功，語意不清楚仍可能產生錯誤答案。

## 撤權後，任務必須停止

先撤銷自己的查看權，再重新執行查詢。授權服務回傳拒絕，流程停在取得資料庫憑證之前。能夠呼叫工具，不代表有權讀取資料。

## 恢復教學授權後再驗證

恢復查看權，再次查詢就能成功。這裡允許學員調整自己的教學關係，正式系統應由獨立的管理角色處理授權變更。

## 發證後，以新連線查詢

取得一組有效六十秒的資料庫憑證，再用它開啟新連線。畫面只呈現租約與角色名稱，密碼保留在伺服器端。查詢成功證明這組憑證確實可以使用。

## 資料庫也要阻擋跨學員存取

同一組憑證嘗試讀取其他學員的資料區，資料庫拒絕存取。這是資料庫層的隔離檢查，讓上層流程出錯時，仍有另一道限制。

## 立即撤銷，再開新連線

按下立即撤銷，再嘗試開啟新連線。這次連線被拒絕。我們驗證的是新的連線，不能因此宣稱所有已經開啟的連線都會自動中斷。

## 重新簽發，開始計時

再簽發一組六十秒憑證，先確認新連線成功。接下來不手動撤銷，而是真的等待租約到期，觀察系統能否自動收回存取能力。

## 實際等待六十六秒，再驗證

這次等待六十六秒後，再開新連線，結果遭到拒絕。租約雖然標示六十秒，這個版本的資料庫到期時間還有五秒緩衝。因此必須實測，不能假設第六十秒就一定斷線。影片只剪去了靜止等待。

## 注入可核對的延遲

回到完整任務，注入零點八秒的慢查詢。訂單仍然成功回傳，但是完成時間變長。接著透過追蹤，判斷時間究竟花在哪一個步驟。

## 沿著實際 trace 找到瓶頸

讀取最近一次追蹤。資料庫查詢的區段包含剛才注入的延遲，可以和授權、發證等步驟比較。這些時間來自實際收集的追蹤資料。

## 故障後仍需撤銷憑證

這次注入工具錯誤。任務失敗之後，再查看追蹤，仍能看到憑證撤銷步驟。錯誤處理除了回報失敗，也必須完成資源與權限的善後。

## 允許的交易與冪等重送

在原創付款模擬中，向允許的商家支付二十美元。相同請求編號再送一次，系統回報重複請求，這次扣款為零，避免代理重試時重複付款。

## 超過單筆門檻，轉人工

換一個請求編號，把金額提高到四十美元。這超過單筆三十美元的門檻，結果轉為需要人工核准，而且沒有扣款。

## 未知商家被拒絕

再換一個請求編號，選擇未知商家，系統拒絕付款。這套演練沒有連接銀行，也不代表銀行的現成功能；重點是設計代理可以花錢的邊界。

## 把控制要求變成可重複測試

最後重設這個錄影帳號的練習，回復授權、租約、紀錄與模擬預算。請學員把每一項控制寫成可重複驗證的條件，再思考誰授權、誰負責，以及成果如何計價。