山葵組 SLA 服務水準協議

為客製化系統、後端 API 與 APP 維運打造的透明承諾

客製化系統與 APP 的維運，不同於套裝軟體，也不是單純「修 Bug」或「更新版本」即可完成。系統上線後，任何環節的變動都可能影響到營運效率，因此山葵組制定了一套明確、可執行、符合客製化開發特性的 SLA（Service-Level Agreement）。

這份 SLA 旨在讓雙方在事件發生時擁有共同語言，並能以一致標準處理。

山葵組維運理念--「上線後才是真正的開始」

系統不是「做好就結束」

因此我們的維運原則是：

1. 把「影響程度」當作唯一優先順序

不依功能大小分級，而是依實際營運影響做判斷。

2. 回應時效明確、責任邊界清楚

降低誤會，確保雙方在事件發生時能快速同步。

3. 可選配更進階的監控與預警服務

如 API 健康度偵測、流量異常警示、Log 報警等。

山葵組的 SLA 是一份長期合作的承諾，讓客製化系統與 APP 在上線後仍能穩定、透明、可預期地運行。

山葵組的事件分級模型（Impact-based Model）

山葵組採用「依影響範圍與急迫性」做分級，而不是按功能或頁面類型劃分。

分級目的只有一個：協助把資源優先投入真正會影響客戶營運的地方。

Level 1 緊急優先（Critical）

營運受阻、需立即處理、核心流程無法進行，造成業務停擺或大規模

例如：

• API 全面無回應、系統完全無法登入

• 金流流程無法完成付款

• 會員功能或認證系統中斷

• 資料庫無法連線、嚴重錯誤導致系統反覆崩潰

• APP 無法啟動或開啟後即閃退

回應時間：

• 30 分鐘內開始進行處理

處理重點：

• 優先恢復用戶可正常操作的最小可用狀態（Minimum Usable State）。

Level 2 主要 (Major）

系統可使用，但部分流程異常、對營運造成阻礙或延誤

例如：

• 後台部分操作無法完成（例：匯出、資料編輯、部分模組無法載入）

• 第三方 API 回傳錯誤，導致某些資料未能更新

• 前台購物流程可執行，但部分輔助功能異常

• 部分 APP 模組開啟後無資料或行為不正確

回應時間：

• 4 小時內回覆

處理方式：

• 依複雜度排入 1～3 個工作日內處理或排定修補時程。

Level 3 次要 (Minor）

屬於「可使用但不完美」，不阻礙主要業務，不影響主要流程的異常或一般諮詢

例如：

• 非關鍵頁面 UI 顯示瑕疵、跑版

• 少量使用者會遇到的前端互動錯誤

• 特殊操作情境下偶發性異常

• 後台設定協助、流程詢問

• 小型改善需求或優化建議

回應時間：

• 1 個工作日內

處理方式：

• 排入版本迭代開發時程中統一處理

SLA 不包含的範圍（不可抗力與責任邊界）

為維持公平與專業，以下情況為「外部因素」或「非系統本身造成」，不納入 SLA 的時效計算，也不屬於保固責任。

Ⅰ. 雲端與第三方供應商的異常（Force Majeure）

若依賴之外部平台出現問題，山葵組無法直接介入，只能協助監測與回報。

包含但不限於：

• AWS、GCP、Azure 任一區域故障或封鎖

• Cloudflare DNS、CDN、WAF、R2 等異常

• Email/SMS 服務商故障（如 SES、Every8D）

• 金流供應商中斷（ECPay、iPay88 等）

• Google / Meta / LINE Login 或 OAuth 服務失效

• ERP/物流/報稅/政府平台 API 無回應或改版造成錯誤

我們會協助查核與提供臨時性建議，但此類屬於平台維運問題，無法納入 SLA 保固範圍。

Ⅱ. 因客戶端環境或操作造成的中斷

例：

• 自行調整 DNS、Cloudflare、網域設定造成服務不可用

• 未經通知修改伺服器設定、防火牆規則、套件版本

• 自行安裝無法相容的外掛、程式碼、APP 資源

• 自行匯入異常格式／大量資料造成效能下降

Ⅲ. 政策、法規、平台規範變動造成的非預期影響

例：

• Apple/Google 調整 APP 審查政策

• 金流平台強制升版（如 TLS、3DS2.0）

• 政府 API 變更資料結構、憑證規範等

• 第三方服務停止支援某版本或功能 (如 金流方更新 API 串接方式或端口連結)

此類通常需進行額外開發或調整。