Theme 商店的 storefront 基礎設施主要由 Shopify 管理；Headless 上線後，品牌還要負責前端 runtime、部署、CMS、搜尋、cache、API client、觀測和相依套件。建置團隊離場前若沒有明確 owner，第一個大促或 API 升級就會暴露缺口。
維運規劃應在架構階段開始，不等上線後再買一套監控工具。
建立服務與 owner 清單
列出 storefront、hosting、DNS/CDN、Shopify channel、CMS、搜尋、integration service、queue、analytics、consent、error tracking 和 secrets。每項記錄 owner、供應商、方案、管理 URL、production 依賴、續約日、資料和 escalation contact。
再畫出誰能部署、回復、輪替 token、修改 DNS 和發布內容。權限使用公司帳號與最小角色，離職和供應商離場有撤銷清單。
定義顧客旅程 SLO
Uptime 只證明首頁回應，不能證明能下單。為商品瀏覽、搜尋、加購、checkout redirect、登入與內容發布設定可觀察目標。可包含成功率、p95 latency、資料新鮮度和 error budget，門檻依真實商業需求制定。
Synthetic monitor 定期跑關鍵流程，real user monitoring 觀察真實裝置，server metrics 追 API 與 cache。三者互補，單一工具無法涵蓋整條旅程。
告警必須能採取行動
每個告警有嚴重度、接收人、初步檢查、降級與 escalation。搜尋結果下降、CMS webhook 積壓、Storefront API error 和 checkout redirect 失敗，處理方式不同。沒有 runbook 的告警容易在深夜變成猜測。
降低雜訊：重複告警合併，非緊急趨勢放入工作時段報表。定期檢查沒有人處理或永遠觸發的規則。
發布與回復標準化
所有程式變更經 Git、review、CI、preview/staging 和 production pipeline。Build artifact、環境變數和 migration 有版本；部署後自動 smoke test。若交易指標或錯誤超過門檻，能回到上一個已知版本。
內容 schema、搜尋 index 和 App backend 變更也需要相容順序。先發布能讀新舊 shape 的前端，再遷移資料，最後移除舊欄位，避免跨服務版本不一致。
管理 Shopify 與套件版本
固定 Storefront、Customer Account 和 Admin API version，建立季度檢查。追蹤 deprecation header、Shopify changelog、framework security advisory 和 CMS SDK。升級先在 staging 使用真實型別與 regression tests，不能等版本停止支援才處理。
Dependabot 類工具能提出更新，仍需要人判斷、測試與發布。重大 framework upgrade 應獨立排程，不和大促功能混在一起。
事件處理保留時間線
事故發生時先指定 incident lead、scribe 和技術 owner，建立狀態更新頻率。優先恢復顧客交易，必要時關閉推薦、搜尋進階功能或回復部署。保存 trace、request ID、deployment、第三方 status 和決策時間。
事故後做無責檢討，找出觸發、偵測、影響、回復與預防工作。每個 action 有 owner 和期限，並更新 runbook 與測試。
營運團隊也要演練
內容發布、商品上架、促銷、客服查單、退款和市場切換都可能跨 Shopify 與 Headless 系統。讓實際操作者在上線前完成任務，並知道出錯時該找哪個窗口。每季和大促前重跑演練。
將固定平台費、監控、工程容量、事件支援和版本升級放進年度預算。可用 Shopify 維護合約指南定義保固、維運與新需求，再把整套責任連回 Headless Shopify 架構。