EWA 系統的 SLA：30 個需要承諾的指標
EWA 系統的 SLA 應包含哪些內容？從考勤到工資單的 30 個指標
一個“快速到賬”的承諾並不是 SLA。EWA 依賴於人力資源、工資、審批、身份識別、銀行、對賬和工資單。如果僅測量應用程序的正常運行時間，企業仍可能遇到應用程序可以打開但工資未更新、交易掛起無人處理或期末工資單不匹配的情況。
> 簡而言之： EWA 的 SLA 必須根據用戶旅程和最終結果進行測量：檔案按時更新，工資審批被計算，指令有狀態，掛單被處理，對賬匹配且工資單接收正確數據。
> 警告： 本文中的閾值是設計示例，並非 Nhân Kiệt 或 VPBank 的正式 SLA。每個承諾必須有測量公式、數據來源、服務時間表、例外情況、責任和已批准的制裁措施。
1. SLA 與 SLO、KPI 和 OLA 有何不同？
- SLA： 各方之間的服務水平承諾，通常與合同相關。
- SLO： 針對某一指標的內部運營目標。
- KPI： 更廣泛的績效指標，不一定是服務承諾。
- OLA： 內部團隊之間的運營協議，以共同達成 SLA。
例如：與客戶的 SLA 要求在一定時間內處理掛起的交易；OLA 分配給客服、銀行團隊和技術團隊的時間。
2. 每個 SLA 指標的六個必備組成部分
- 名稱和目的。
- 計算公式。
- 數據來源。
- 測量窗口和服務時間表。
- 目標/閾值。
- 排除、責任和報告機制。
如果未定義開始和結束點，請勿使用“快速”、“及時”、“幾乎即時”等詞語。
3. 確定開始和結束時間
例如，“到賬時間”可以從以下時間開始：
- 勞動者按下確認鍵的時候；
- 服務器接受請求的時候；
- 指令被發送到銀行的時候。
並在以下情況結束：
- API 報告成功；
- 勞動者的賬戶被記入；
- 交易出現在對賬單上；
- 勞動者確認收到款項。
如果未確定定義，雙方可能報告兩個正確但不相同的結果。
4. A 組 — 可用性和性能 (SLA 1–5)
1. 勞動者應用程序的可用率
測量在服務窗口內登錄、查看可用餘額和創建請求的能力。
2. 客戶門戶的可用率
測量查看、審批、拒絕和修改工資的功能。
3. 核心屏幕/API 的響應時間
應測量百分位數如 P95/P99，而不僅僅是平均值，因為平均值會掩蓋非常慢的請求。
4. 服務器錯誤率
區分系統錯誤、輸入數據錯誤、用戶錯誤和第三方錯誤。
5. 維護窗口
規定時間表、提前通知時間、緊急維護和受影響的功能。
5. B 組 — 人力資源和考勤 (6–10)
6. 人事檔案同步延遲
從源頭變更到 EWA 反映的時間，特別是對於離職/調動的人員。
7. 工資表同步延遲
日薪預支目前有每 30 分鐘的 Google Sheet 日程和立即同步按鈕；SLA 必須說明如果作業延遲或文件錯誤的測量方法。
8. 應用程序工資延遲
應用程序中的考勤在設計上是實時記錄的；仍需目標反映在屏幕/審批源上。
9. 成功合併工資記錄的比例
正確合併到人員、客戶、日期/班次的記錄數除以有效記錄總數。
10. 錯誤工資記錄的處理時間
區分系統錯誤和源數據錯誤；規定誰負責修正和響應時間。
6. C 組 — 工資審批和可用餘額 (11–14)
11. 工資審批時間
這通常是客戶/監督的 OLA，不完全由平台控制。需要從工資準備好到審批的時間進行測量。
12. 審批後可用餘額更新延遲
從有效審批事件到服務器計算/顯示新餘額的時間。
13. 正確計算可用餘額的比例
通過從工資、單價、已接收、保留、限額和四捨五入的樣本重新計算進行檢查。
14. 政策變更應用時間
單價/限額/保留必須有生效日期、審批和變更後的檢查。
7. D 組 — 身份識別和賬戶 (15–17)
15. OCR/身份證驗證的響應時間
區分自動處理和需要人工檢查的例外情況。
16. 賬戶名稱查詢時間
測量系統部分和銀行部分；規定查詢服務中斷時的狀態。
17. 設備/賬戶更換處理時間
必須在用戶體驗和防止劫持之間取得平衡，並進行驗證和審批。
8. E 組 — 銀行交易 (18–22)
18. 成功處理請求的比例
必須區分系統、銀行、賬戶、數據或政策導致的失敗。
19. 確認後指令發送時間
從服務器接受到服務發送指令的時間。
20. 結果確認時間
與“到賬”不同。需要定義確認來源。
21. 轉入等待的交易比例
監控比例和原因；過低的比例也可能是系統過早得出結論。
22. 等待交易的年齡
從進入等待到最終結論的時間；報告最長的交易和年齡分組。
在日薪預支中，掛單的查詢按技術層面的五分鐘計劃運行。SLA 必須計算銀行/相關方的響應時間。
9. F 組 — 對賬和工資單 (23–26)
(詳情：見 EWA 與工資單和會計的交易對賬。)
23. T+1 對賬完成
日薪預支有 08:00 的對賬文件讀取時間表。承諾需要規定文件準備時間、合併比例和例外情況的確認人。
24. 自動對賬交易比例
唯一合併的行數，正確的代碼/金額/賬戶除以符合條件的行總數。
25. 對賬差異關閉時間
根據價值、人數和重複支付/錯誤支付的風險進行分級。
26. 按時交付工資單數據
測量已檢查的文件/API，符合截止時間，正確的員工/客戶/周期；不僅僅是“已發送電子郵件”。
10. G 組 — 支持和故障 (27–30)
(另見：當日薪預支發生故障時 和 EWA 投訴處理手冊。)
27. 首次響應時間
從有效票據記錄到用戶收到帶有事件編號的響應的時間。
28. 恢復/處理時間
區分服務恢復和徹底解決及 RCA。
29. 故障通知時間
規定識別、確認、初步通知和定期更新的時間點。
30. 提供 RCA 的時間
RCA 必須包含時間線、根本原因、影響、補救措施和預防行動。
11. 參考故障級別矩陣
| 級別 | 例子 | 處理 |
|---|---|---|
| P1 | 大範圍重複支付/錯誤支付，無法控制的鎖定，核心服務中斷 | 指揮故障，適當停止，持續更新 |
| P2 | 許多人無法交易，顯著的可用餘額/對賬錯誤 | 高優先級，跨功能團隊 |
| P3 | 小群體出現錯誤，有替代方案 | 按標準 SLA 處理 |
| P4 | 信息請求/顯示錯誤 | 待辦事項/常規支持 |
正式級別必須有金額、人員、數據和時間的閾值；不能僅根據感覺分類。
12. SLA 目標示例表
| 指標 | 目標示例 | 注意事項 |
|---|---|---|
| 核心服務正常運行時間 | 99.9%/月 | 僅供示例，需要定義排除項 |
| P95 API 響應 | ≤ 2 秒 | 區分銀行 API |
| Sheet 同步 | 每 30 分鐘循環 | 從有效數據源開始計算 |
| P1 票據響應 | ≤ 15 分鐘 | 如果承諾，需 24/7 值班時間表 |
| P2 票據響應 | ≤ 30 分鐘 | 不等於已完成處理 |
| T+1 對賬 | 按截止時間完成 | 取決於銀行文件 |
| 工資單交付 | 在批准的截止時間前 | 有校驗和/收據 |
表中的所有數字僅用於示例說明。不要用作日薪預支的承諾。
13. 正確計算正常運行時間的方法
一個常見的公式：
正常運行時間 = (服務窗口的總分鐘數 − SLA 計算的中斷分鐘數) ÷ 服務窗口的總分鐘數 × 100%
合同需要規定：
- 測量哪些功能；
- 從外部測量還是內部日誌；
- 如何計算部分中斷；
- 維護是否排除；
- 依賴於互聯網/銀行；
- 四捨五入和時區；
- 如何處理數據爭議。
14. 不應過度排除
像“所有第三方錯誤”這樣的條款可能會使 SLA 失去意義，因為銀行和基礎設施是 EWA 的重要組成部分。
應區分：
- 供應商負責協調的端到端 SLA；
- 依賴於銀行/客戶的指標；
- 各方之間的 OLA；
- 無論原因如何，通知義務和備用方案。
15. RTO 和 RPO
- RTO： 中斷後恢復服務的目標時間。
- RPO： 可以在時間上丟失的最大數據量。
EWA 需要針對以下內容的 RTO/RPO：
- 檔案/工資；
- 可用餘額；
- 交易；
- 審計日誌；
- 對賬/工資單。
金融交易需要比通信內容更嚴格的要求。目標只有在演練過並有證據顯示恢復不會重複支付的情況下才有意義。
16. 數據和安全性的 SLA
(完整框架：見 EWA 部署中的數據安全和隱私權。)
除了正常運行時間，還需要協議：
- 懷疑被劫持賬戶的鎖定時間；
- 撤銷離職人員的權限；
- 根據嚴重程度修補漏洞；
- 數據違規通知；
- 提供日誌/證據；
- 處理數據主體的請求；
- 備份和恢復測試；
- 定期權限審查；
- 終止時刪除/返回數據。
正式期限必須符合法律和風險評估，不應機械地從國際模板中複製。
17. 服務信用是否足夠？
服務信用可以鼓勵合規，但不能替代：
- 修正錯誤支付；
- 保護數據的義務；
- 處理投訴；
- 根據合同/法律賠償；
- 暫停/擴展的權利；
- 防止重複發生的計劃。
對於嚴重的財務錯誤，具體的阻止條件和責任比小額費用減免更重要。
18. 每月 SLA 報告應包含
- 應用的 30 個指標結果；
- 三到六個月的趨勢；
- 違規次數和持續時間；
- 按客戶/來源分析；
- 等待交易和年齡；
- 對賬/工資單差異；
- P1–P4 和 RCA；
- 重大維護/變更；
- 投訴和重新開啟；
- 補救措施、負責人、期限；
- 下期預計風險。
總體儀表板不應被漂亮的平均數掩蓋一個嚴重錯誤。
19. 建立 SLA 的六步流程
- 繪製旅程和依賴關係。
- 選擇對勞動者/企業重要的結果。
- 確定指標、來源和測量時間。
- 在承諾之前測量基線。
- 協商目標、排除、OLA 和制裁。
- 試點、審查和調整後擴展。
不要僅因市場通常這樣記錄而承諾高水平，如果系統尚無基線。
20. SLA 審核清單
(文件集：見 日薪預支的審核文件。)
- 有服務窗口的定義。
- 有處理時間的開始/結束點。
- 獨立且可追溯的數據來源。
- 有性能的百分位數。
- 第三方錯誤不被無限排除。
- 有掛起交易的 SLA。
- 有對賬和工資單的承諾。
- 有 P1–P4 和客觀的閾值。
- 有故障更新時間表。
- 有 RTO/RPO 和演練。
- 有數據/安全性的 SLA。
- 有定期報告和審查。
- 有審計/數據爭議的權利。
- 有適當的服務信用/責任。
- 有規模變化時的 SLA 修訂機制。
21. 常見問題
30 秒內到賬是否為 SLA？
只有當合同定義了開始點、結束點、交易達成率、賬戶/銀行條件和例外情況時才是。如果沒有，這只是體驗信息。
99.9% 的正常運行時間對 EWA 來說是否足夠？
不夠。應用程序可能在線，但工資未更新或銀行未處理。需要端到端的 SLA。
等待交易是否算作 SLA 違規？
必須有關於等待交易比例和年齡的單獨指標。一些等待狀態是安全控制，但不能無限期存在。
客戶延遲審批工資是否是供應商的錯誤？
通常是客戶的依賴/OLA。SLA 需要區分工資準備好之前和之後的時間。
是否應在網站上公開 SLA？
可以公開已批准的框架或服務狀態。詳細的合同目標可能因客戶而異；不應公開尚無證據的數字。
---
作者： Nguyen Minh Tuan — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.
企業日薪預支解決方案諮詢： 熱線 0937.022.655 · 電子郵件 info@nhankiet.vn · 企業日薪預支