EWA 시스템을 위한 SLA: 약속해야 할 30가지 지표

EWA 시스템을 위한 SLA에 필요한 것? 출퇴근 기록부터 급여까지 30가지 지표

“빠른 입금” 약속은 SLA가 아닙니다. EWA는 인력, 근무, 승인, 신원 확인, 은행, 대조 및 급여에 의존합니다. 애플리케이션 가동 시간만 측정하면, 기업은 앱이 열리지만 근무가 업데이트되지 않거나 거래가 처리되지 않거나 급여가 맞지 않는 상황을 겪을 수 있습니다.

> 간단히 말해: EWA SLA는 사용자 여정과 최종 결과에 따라 측정되어야 합니다: 기록이 제때 업데이트되고, 근무가 승인되며, 지불 명령이 상태를 가지고, 보류된 항목이 처리되며, 명세서가 일치하고 급여가 정확한 데이터를 받는 것.

> 경고: Nguyen Minh Tuan — Chuyên viên ban chiến lược, Nhan Kiet이나 VPBank의 공식 SLA가 아닙니다. 각 약속은 측정 공식, 데이터 소스, 서비스 일정, 예외, 책임 및 제재가 승인되어야 합니다.

1. SLA는 SLO, KPI 및 OLA와 어떻게 다른가요?

• SLA: 계약과 연결된 당사자 간의 서비스 수준 약속.
• SLO: 특정 지표에 대한 내부 운영 목표.
• KPI: 더 넓은 결과 평가 지표로, 항상 서비스 약속은 아님.
• OLA: SLA를 달성하기 위해 내부 팀 간의 운영 협약.

예: 고객과의 SLA는 보류 거래를 특정 시간 내에 처리해야 한다고 요구할 수 있으며, OLA는 고객 서비스, 은행 팀 및 기술 팀 간의 시간을 분배합니다.

2. 각 SLA 지표의 필수 구성 요소 6가지

1. 이름과 목적.
2. 계산 공식.
3. 데이터 소스.
4. 측정 창과 서비스 일정.
5. 목표/임계값.
6. 제외, 책임 및 보고 메커니즘.

“빠르게”, “적시에”, “거의 즉시”라는 단어를 시작과 끝을 정의하지 않고 사용하지 마세요.

3. 시작–종료 시계 설정

예를 들어 “입금 시간”은 다음에서 시작할 수 있습니다:

• 근로자가 확인 버튼을 누를 때;
• 서버가 요청을 수락할 때;
• 명령이 은행으로 전송될 때.

그리고 다음에서 종료됩니다:

• API가 성공을 보고할 때;
• 근로자의 계좌에 입금될 때;
• 거래가 명세서에 나타날 때;
• 근로자가 돈을 받았다고 확인할 때.

정의가 확정되지 않으면, 양측은 서로 다른 결과를 보고할 수 있습니다.

4. 그룹 A — 가용성과 성능 (SLA 1–5)

1. 근로자 애플리케이션의 가용성 비율

서비스 창에서 로그인, 가용 금액 보기 및 요청 생성 가능성을 측정합니다.

2. 고객 포털의 가용성 비율

보기, 승인, 거부 및 근무 수정 기능을 측정합니다.

3. 핵심 화면/API 응답 시간

평균만이 아닌 P95/P99와 같은 백분위수를 측정해야 합니다. 평균은 매우 느린 경우를 숨길 수 있습니다.

4. 서버 오류 비율

시스템 오류, 입력 데이터 오류, 사용자 오류 및 제3자 오류를 분리합니다.

5. 유지보수 창

일정, 사전 통보 시간, 긴급 유지보수 및 영향을 받는 기능을 규정합니다.

5. 그룹 B — 인력 및 출퇴근 기록 (6–10)

6. 인력 기록 동기화 지연

소스에 변경이 있을 때부터 EWA가 이를 반영할 때까지, 특히 퇴사/이동한 사람에 대해 측정합니다.

7. 출퇴근 기록 동기화 지연

Google Sheet 일정이 30분마다 있으며 즉시 동기화 버튼이 있습니다. 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. 보류 거래의 나이

보류 상태에 들어간 시점부터 최종 결론이 나올 때까지의 시간을 측정합니다. 가장 오래된 항목과 나이 그룹을 보고합니다.

EWA 시스템에서는 기술 수준에서 5분마다 보류 항목을 확인합니다. SLA는 은행/관련 당사자의 응답 시간을 포함해야 합니다.

9. 그룹 F — 대조 및 급여 (23–26)

(자세한 내용: EWA 거래 대조 및 급여와 회계을 참조하세요.)

23. T+1 대조 완료

EWA 시스템은 08:00에 명세서 파일을 읽도록 일정이 잡혀 있습니다. 약속은 파일 준비 시간, 결합 비율 및 예외를 결정하는 사람을 규정해야 합니다.

24. 자동 명세서 결합 거래 비율

고유하게 결합된 줄 수, 올바른 코드/금액/계좌를 유효한 줄 총수로 나눕니다.

25. 대조 차이 해결 시간

가치, 사람 수 및 중복/잘못된 지불 위험에 따라 수준을 나눕니다.

26. 급여 데이터 제때 전달

검토된 파일/API, 올바른 컷오프, 올바른 사람/고객/기간을 측정합니다. “이메일을 보냈다”는 것만으로는 충분하지 않습니다.

10. 그룹 G — 지원 및 문제 해결 (27–30)

(추가 정보: EWA 시스템에서 문제가 발생할 때 및 EWA 불만 처리 플레이북을 참조하세요.)

27. 첫 응답 시간

유효한 티켓이 기록된 시점부터 사용자가 사건 번호가 포함된 응답을 받을 때까지.

28. 복구/처리 시간

서비스 복구와 근본 원인 분석 및 완전한 해결을 구분합니다.

29. 문제 통보 시간

인식, 확인, 초기 통보 및 정기 업데이트의 기준을 규정합니다.

30. 근본 원인 분석 제공 시간

근본 원인 분석은 타임라인, 근본 원인, 영향, 수정 및 예방 조치를 포함해야 합니다.

11. 참고할 수 있는 문제 심각도 매트릭스

수준	예시	처리
P1	광범위한 중복/잘못된 지불, 잠금 제어 상실, 핵심 서비스 중단	문제 지휘, 적절한 중단, 지속적인 업데이트
P2	많은 사람이 거래 불가, 상당한 가용 금액/대조 오류	높은 우선순위, 다기능 팀
P3	소규모 그룹에 오류, 대체 방안 있음	표준 SLA에 따라 처리
P4	정보 요청/표시 오류	백로그/일반 지원

공식 수준은 금액, 사람, 데이터 및 시간의 임계값을 가져야 하며, 주관적인 느낌으로만 분류해서는 안 됩니다.

12. SLA 목표 예시 표

지표	목표 예시	주의사항
핵심 서비스 가동 시간	99.9%/월	예시일 뿐, 제외 사항 정의 필요
API 응답 P95	≤ 2초	은행 API 분리
Sheet 동기화	30분 주기	유효한 소스 데이터 시점부터 계산
P1 티켓 응답	≤ 15분	24/7 대기 일정 필요 시 약속
P2 티켓 응답	≤ 30분	처리 완료와 동일하지 않음
T+1 대조	마감 시간에 완료	은행 파일에 의존
급여 전달	승인된 컷오프 이전	체크섬/영수증 포함

표의 모든 숫자는 작성 방법을 예시하기 위한 것입니다. EWA 시스템의 약속으로 사용하지 마세요.

13. 정확한 가동 시간 계산 방법

일반적인 공식:

가동 시간 = (서비스 창 총 분 - SLA에 포함된 중단 분) ÷ 서비스 창 총 분 × 100%

계약은 다음을 규정해야 합니다:

• 어떤 기능이 측정되는지;
• 외부에서 측정하는지 내부 로그에서 측정하는지;
• 부분 중단이 어떻게 계산되는지;
• 유지보수가 제외되는지;
• 인터넷/은행 의존성;
• 반올림 및 시간대;
• 데이터 분쟁 처리 방법.

14. 너무 넓은 제외를 피해야 합니다

“제3자에 의한 모든 오류”와 같은 조항은 은행과 인프라가 EWA의 필수 부분이기 때문에 SLA의 의미를 잃게 할 수 있습니다.

다음과 같이 분리해야 합니다:

• 공급자가 조정 책임을 지는 종단 간 SLA;
• 은행/고객에 의존하는 지표;
• 당사자 간의 OLA;
• 원인이 어디에 있든 통보 의무 및 대체 계획.

15. RTO 및 RPO

• RTO: 중단 후 서비스 복구 목표 시간.
• RPO: 시간에 따라 손실될 수 있는 최대 데이터 양.

EWA는 다음에 대한 별도의 RTO/RPO가 필요합니다:

• 기록/근무;
• 가용 금액;
• 거래;
• 감사 로그;
• 대조/급여.

금융 거래는 커뮤니케이션 콘텐츠보다 더 엄격한 요구 사항이 필요합니다. 목표는 연습이 완료되고 중복 지불이 없다는 증거가 있을 때만 의미가 있습니다.

16. 데이터 및 보안에 대한 SLA

(전체 프레임워크: EWA 도입 시 데이터 보안 및 개인정보 보호를 참조하세요.)

가동 시간 외에도 다음을 협의해야 합니다:

• 의심되는 계정 탈취 시 계정 잠금 시간;
• 퇴사자의 권한 회수;
• 심각도에 따른 취약점 패치;
• 데이터 위반 통보;
• 로그/증거 제공;
• 데이터 주체의 요청 처리;
• 백업 및 복구 테스트;
• 정기 권한 검토;
• 종료 시 데이터 삭제/반환.

공식적인 기한은 법률 및 위험 평가에 적합해야 하며, 국제 표본을 기계적으로 복사해서는 안 됩니다.

17. 서비스 크레딧이 충분한가요?

서비스 크레딧은 준수를 장려할 수 있지만 다음을 대체하지는 않습니다:

• 잘못된 금액 수정;
• 데이터 보호 의무;
• 불만 처리;
• 계약/법률에 따른 보상;
• 중단/확장 권리;
• 재발 방지 계획.

심각한 금융 오류의 경우, 작은 요금 할인보다 차단 조건 및 구체적인 책임이 더 중요합니다.

18. 월간 SLA 보고서에 포함해야 할 것

• 적용된 30가지 지표 결과;
• 3~6개월 추세;
• 위반 횟수 및 지속 시간;
• 고객/소스별 분석;
• 보류 거래 및 나이;
• 대조/급여 차이;
• P1~P4 및 근본 원인 분석;
• 주요 유지보수/변경;
• 불만 및 재개;
• 수정 조치, 소유자, 기한;
• 다음 기간의 예상 위험.

전체 대시보드는 아름다운 평균 숫자로 심각한 오류를 숨겨서는 안 됩니다.

19. SLA 구축 절차 6단계

1. 여정 및 종속성 그리기.
2. 근로자/기업에 중요한 결과 선택.
3. 메트릭, 소스 및 측정 시계 결정.
4. 약속 전에 기준선 측정.
5. 목표, 제외, OLA 및 제재 협상.
6. 파일럿, 검토 및 확장 전 조정.

시스템에 기준선이 없는 경우, 시장에서 일반적으로 기록된 것만으로 높은 수준을 약속하지 마세요.

20. SLA 검토 체크리스트

(문서 세트: Lương Ngày 검토 문서를 참조하세요.)

• 서비스 창 정의가 있음.
• 처리 시간의 시작/종료 지점이 있음.
• 독립적이고 추적 가능한 데이터 소스가 있음.
• 성능에 대한 백분위수가 있음.
• 제3자 오류가 무한히 제외되지 않음.
• 보류 거래에 대한 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.

기업을 위한 EWA 솔루션 상담: 핫라인 0937.022.655 · 이메일 info@nhankiet.vn · 기업을 위한 EWA