Day 25 提到，Berry AI 的 SRE 與純軟體公司的 SRE 有很大的差異。在 Edge AI 產業，SRE 最重要的任務是確保地端 (on-prem) 服務的品質，而硬體正是其中的首要難題：軟體層已有 Software Team 與 ML Team 各自的 unit test 把關，來到軟硬體整合層，又該如何把關？本篇介紹 SRE Team 負責的硬體評估 (HW Evaluation)，以及我們如何把每次評估前的環境架設與測試報告自動化。

測試金字塔的最頂層

依照這樣的分層分工，我們的測試金字塔 (test pyramid) 如下：

Unit 與 SW E2E 由各團隊的研發工程師 (RD) 負責；Integration 與 E2E 由 SRE 的 SDET (Software Development Engineer in Test，專責撰寫自動化測試的工程師) 負責；最頂端的 HW Evaluation 同樣由 SRE 負責，也就是本篇的主題。

我們的服務全部執行在地端的 edge server (部署在客戶現場的伺服器) 上，評估需求可能來自業務端或內部工程團隊。例如業務想知道 A 機型能否搭配 60 支監控相機賣給客戶，就需要透過 HW Evaluation 驗證這個組合下服務能否正常運作。

每次收到需求，都必須先在實驗室把整組軟硬體環境架設起來。短期內湧進好幾台 edge server 時，這是最繁瑣的重複作業。

每次評估都要重來的四項前置作業

一、把各個 team 的服務安裝到 edge server 上。
每個 team 都有自己的 playbook 與指令，最初只能在 Slack 上逐一 tag 各服務的 owner 協助安裝，高度仰賴人工，也相當耗時。

二、安裝服務之前，還要先架設硬體。
接線、接網路線、安裝硬碟、連接相機，在還沒有機器人之前，這些都只能靠人工。

三、設定 edge server 的網路並連接監控相機。
必須先了解實驗室的網路架構，以及每台 edge server 的相機網段與固定 IP 如何搭配，edge server 才能連上相機並開始錄影。

四、壓測結束後還要產出測試報告。
報告除了測試情境與 edge server 設定，還有一大部分是 Grafana 上的監控指標 (metrics)，每項指標都要附上截圖與連結，光是蒐集就相當耗時。

以一支 shell script 安裝各 team 的服務

於是我們把其中固定的流程自動化：各 team 的 playbook 整合成一支 shell script，測試報告則交給 Claude Skill 產出。

實作過程中最花時間的，是釐清每個 playbook 該開啟或關閉哪些 flag。為了把負載推到極限，必須覆寫 Day 23 介紹過的門市看板 (Drive-Thru Dashboard) 營業時間，讓它 24 小時運作，並關閉每週的重開機排程；為了不干擾 production 環境的監測機制，必須關閉錯誤追蹤服務 Sentry 與上傳服務。逐一釐清這些細節之後，SRE 對產品的掌握度也隨之提高。

./scripts/lab.sh list-hosts                                  # 列出可執行的實驗室 edge server
./scripts/lab.sh scenario plan stress1 --host test-server-1  # dry-run，列出將執行的 playbook 指令
./scripts/lab.sh scenario up   stress1 --host test-server-1  # 實際執行

script 只允許對實驗室內的 edge server 執行，list-hosts 會列出這些 edge server。plan 與 up 刻意分開：安裝一次壓測環境約需一小時，先以 dry-run (只列出將執行的動作，不實際執行) 確認內容，再正式開始。

以 env 檔定義壓測情境

stress1 是一個情境 (scenario)，內容寫在 env 檔中，ML 服務與門市看板所需的店家設定也從這裡傳入：

SCENARIO_STORES="BERRY1 BERRY2"                       # 載入的店家設定
SCENARIO_PRIMARY="BERRY1"                             # 門市看板顯示的店家
SCENARIO_DTVJ_ASSETS_VERSION="v20260910-ithome-test"  # ML 模型版本

SCENARIO_STORES 指定要載入哪幾間店家的設定，SCENARIO_PRIMARY 指定其中哪一間作為門市看板顯示的店家。SCENARIO_DTVJ_ASSETS_VERSION 指定 ML 模型的版本，ML 模型有較大的改版時，也會透過 HW Evaluation 測試新模型的效能。

要換一組壓測條件，只需要換一個 env 檔，不必修改 script。

以 Claude Skill 產出測試報告

Claude Skill (官方文件稱為 Agent Skills) 是把指令、範本與腳本打包成資料夾的擴充機制，Claude 會在任務相關時自動載入。

測試報告的做法是先讓 Claude 讀過報告範本，之後只要帶入當次的變數 (報告標題、時間區間、edge server 名稱)，就能產出格式一致的初稿，人工只需複核並補上觀察結論。

原本至少兩天的前置作業，現在工具執行完約需一小時；原本需要三、四小時的報告，現在產出初稿只要二十分鐘，加上人工補充觀察結論，總共約四十分鐘。

小結

HW Evaluation 位於測試金字塔的最頂層，由 SRE 在實驗室以完整產品驗證新硬體。我們把各 team 的 playbook 整合成一支 shell script，以 env 檔定義壓測情境，並以 Claude Skill 產出測試報告初稿，讓每次評估的重複作業交給工具執行。

HW Evaluation 的本質是重現真實客戶的環境，但實驗室複製不了客戶端的網路架構與網通設備，連電力品質都不一樣；實驗室也只是一個小房間，與真實的得來速門市差異很大。這些差異都可能影響服務最終的效能與穩定度。

因此 HW Evaluation 的價值，在於部署到客戶現場之前，把能控制的條件推到極限，盡早找出效能瓶頸、資源限制，以及軟硬體整合上的風險。對 SRE 來說，這也是這項工作最有趣、也最具挑戰的地方。下一篇轉向 SRE 在雲端服務端的工作，談 dashboard 的載入時間該從哪裡量。

參考資料

• The Practical Test Pyramid
• Agent Skills

本系列由 Berry AI 工程團隊出品。更多工程實戰紀錄都在 Berry AI 技術部落格。