服務事故
事故是指任何對 EvoMap 服務的可用性、可靠性、延遲、正確性或安全態勢產生實質影響的非計劃性情況。
生命週期
| 階段 | 含義 |
|---|---|
| Investigating | 團隊正在確認影響、範圍和可能的原因。 |
| Identified | 受影響的組件或依賴已定位。 |
| Mitigating | 正在實施修復、回滾、流量切換或變通辦法。 |
| Monitoring | 服務看起來已恢復，團隊正在觀察是否復發。 |
| Resolved | 事故已關閉，不再對客戶造成影響。 |
| Postmortem | 正在準備或已發佈後續總結或更深入的分析。 |
嚴重程度
| 嚴重程度 | 客戶影響 | 示例 |
|---|---|---|
| P0 | 大面積生產中斷或存在數據安全風險。 | 所有客戶端的 OAuth 權杖交換不可用；公開 API 持續返回 5xx。 |
| P1 | 關鍵路徑嚴重降級。 | 大量應用的 webhook 投遞延遲；應用審核佇列被卡住。 |
| P2 | 影響有限，或存在可靠的變通辦法。 | 某一族端點變慢；狀態歷史陳舊但線上 API 正常。 |
| P3 | 輕微缺陷、文檔問題或個別支援個案。 | 文檔連結錯誤；更新記錄條目表述不清。 |
公開事故記錄
一份公開事故記錄應包含：
- 受影響的服務和客戶可見的症狀。
- 首次發現時間和恢復時間。
- 進展通報的時間線。
- 緩解措施或變通辦法（如果有）。
- 最終的解決總結。
- 當值得做更深入的書面分析時，附上事後檢討連結。
事故記錄不應包含客戶個人數據、密鑰、私密支援單、內部日誌或未脫敏的請求負載。
計劃內維護
計劃內維護應列明：
- 計劃的開始與結束時間（帶時區）。
- 可能受影響的服務。
- API 調用、OAuth 流程、webhook 投遞或應用審核是否可能中斷。
- 需要客戶採取的動作（如果有）。
維護通報應在窗口之前、窗口開始時和窗口完成時發佈。
支援單與事故的關係
支援單是圍繞某個具體開發者、組織、OAuth 客戶端、webhook 投遞或計費個案的私密對話。事故則是在影響面足夠大、需要在狀態頁上對外溝通時的公開運維記錄。
當一個支援單反映的是同一個底層平台問題時，它可以被關聯到某個事故。支援單仍然保持私密；事故記錄保持公開且已脫敏。
報告疑似事故
在提交支援單之前：
- 查看
/status。 - 查看更新記錄，看是否有近期的 API 或行為變更。
- 提交支援單或發郵件到
[email protected]，附上時間戳、request ID、受影響的端點和觀察到的錯誤碼。