SLA、稼動率與故障時的確認步驟
SLA
稼動率
故障
狀態頁面
本文的對象
適用於正式運用中的串接應用程式發生「無法運作」事象時的釐清負責人。
適用於正式運用中的串接應用程式發生「無法運作」事象時的釐清負責人。
稼動率目標
| 方案 | 月度稼動率目標 | SLA 保證 |
|---|---|---|
| Starter | 99.5%（盡力而為） | 無 |
| Growth | 99.9% | 有 |
| Enterprise | 99.95% 以上（個別簽約） | 有（有補償） |
狀態頁面
ReceiptRoller 以公開狀態頁面發布稼動狀況。
https://status.receiptroller.io
- API、Webhook、授權、開發者入口網站、各 SNS 串接會分別顯示
- 可查看過去 90 天的故障歷史
- 可透過 RSS / Webhook / 電子郵件訂閱
建議正式運用中的團隊將此頁面納入監控儀表板。
故障發生時的釐清步驟
步驟 1：釐清是自家還是外部
- 自家的其他功能是否有運作？
- ReceiptRoller 的狀態頁面上，該功能是否未出現故障？
- 近期是否有自家部署
步驟 2：疑似 ReceiptRoller 端故障時
- 確認狀態頁面
- 備妥過去 5 分鐘請求的
X-RR-Request-Id - 備妥錯誤回應的內容（HTTP 狀態、code、message）
- 確認影響範圍（所有請求失敗 / 一部分失敗 / 僅特定端點）
步驟 3：疑似自家環境時
- 檢討近期部署的回滾
- 環境變數、密鑰是否正確
- 網路、DNS、TLS 憑證
- 下游 DB、快取、外部 API 的狀態
支援升級
輕度（可自行釐清）
張貼至開發者社群。也可能從其他開發者獲得知識。
中度（自行無法特定原因）
寄信至支援窗口。請務必附上以下資訊。
- 應用程式ID（用戶端ID）
- 事象發生時刻範圍（UTC 或 JST 註明）
- 受影響的 API 端點與 HTTP 方法
- 數個
request_id - 錯誤回應的內容
- 自家端已確認的內容
重大（正式環境影響大）
Growth 以上的方案有緊急支援窗口。Enterprise 為專用 Slack 頻道等。
SLA 未達時的因應
Growth 以上的方案，若月度稼動率低於 SLA，會退還次月使用費的一部分（授予額度）。詳情請參閱合約書。
計畫維護的通知
- 原則上為無影響的滾動部署
- 若有大規模變更，會在最少 14 天前通知
- 通知透過狀態頁面、開發者入口網站的公告、電子郵件
相關指南
發布日: 2026-04-27
更新日: 2026-07-06