EWA 系統的 SLA：30 個需要承諾的指標
EWA 系統的 SLA 需要什麼？從考勤到薪資的 30 個指標
“快速到賬”承諾並非 SLA。EWA 依賴於人力資源、工時、審核、身份識別、銀行、對賬和薪資。如果僅測量應用程序的正常運行時間，企業可能會遇到應用程序可以打開但工時未更新、交易掛起無人處理或期末薪資不匹配的情況。
> 簡而言之： EWA 的 SLA 必須根據用戶旅程和最終結果進行測量：檔案按時更新，工時審核計算，指令有狀態，掛起的款項得到處理，對賬匹配，薪資接收到正確的數據。
> 警告： 本文中的閾值是設計示例，並非 Nhan Kiet 或 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/CCCD 驗證響應時間
區分自動處理和需要人工檢查的例外情況。
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 · 企業日薪預支