데이터 SLA 설정 및 달성을 위한 11가지 체크리스트(SLA 템플릿 포함)

데이터 서비스 수준 계약, 즉 데이터 SLA를 체결하기에는 너무 작은 규모의 팀은 없다고 감히 말씀드릴 수 있습니다. 데이터 SLA란 무엇인가요? 정량화 가능한 수준의 서비스를 제공하겠다는 공약입니다. 서비스형 인프라(IaaS) 제공업체가 99.99% 가동 시간을 약속하는 것처럼, 특정 매개 변수 내에서 특정 품질의 데이터를 제공하기로 약속하는 것입니다.

약속을 공개하는 것이 중요합니다. (적어도 회사 내에서는 말입니다.) 홍보를 통해 책임감을 높이고, 모든 팀이 가장 중요한 일에 집중할 수 있도록 하며, 품질을 지원하는 구조를 구축할 수 있습니다.

이 가이드에서는 자체 데이터 SLA를 설정하는 방법을 살펴봅니다.

공식화된 서면 데이터 SLA는 비공식 약속을 구체적이고 상호 합의할 수 있도록 합니다. 모든 데이터 관계에는 명시하든 말든 비공식적인 약속이 포함되며, 두 당사자가 서로 다른 것에 대해 이야기하고 있다는 사실을 깨닫지 못한 채 무언가에 동의할 수 있는 경우가 많습니다.

그렇다면 데이터 SLA란 정확히 무엇인가요? 일반적으로 250~500단어로 구성된 간단한 서면 문서로, 회사 위키 또는 Google 문서와 같은 공유 공간에 게시됩니다. 여기에는 6가지 요소가 포함되어야 합니다.

• 목적: 이 데이터 SLA가 존재하는 이유는 무엇인가요? 어떤 문제가 해결될 것으로 기대하며, 어떻게 활용되기를 기대하시나요?

• 약속: 다른 팀에 무엇을 약속하고 계신가요?

• 측량: 데이터 SLA를 어떻게 측정하고, 누가 측정하고, SLA 기간은 어떻게 되나요?

• 파급 효과: 데이터 SLA를 놓치면 어떻게 됩니까? 누가 책임을 지며 어떤 종류의 해결 방법을 사용할 수 있나요?

• 요구 사항: 그 대가로 무엇을기대하나요? 조건부 약속은 어떻게 되나요?

• 서명: 누가 데이터 SLA를 준수하나요?

데이터 SLA를 작성할 때 의미를 변경하지 않고 가능한 한 적은 단어로 전달하세요. 이 작업에는 많은 편집이 필요하지만, 한 번에 모두 작성하고 나중에 다시 편집하는 것이 좋습니다. 그 이유는 페이지를 너무 오래 쳐다보면 작가들이 '빈 페이지 불안증'이라고 부르는 증상이 나타나 계속 미루게 될 수 있기 때문입니다. 기다리지 말고 품질이 좋지 않더라도 지금 바로 초안을 작성하세요.

다음은 데이터 서비스 수준 계약의 예입니다.

이 문서는 IBM 팀이 정확한 기준 내에서 뛰어난 데이터 품질을 유지하겠다는 공개적인 약속을 다른 사람들에게 알리기 위한 목적을 지닙니다. 이를 통해 서로를 이해하고, 함께 협력하며, 팀이 상호 책임감을 가질 수 있기를 바랍니다.

저희의 약속: "어제 매출은 어땠나요?"와 같은 질문에 답할 수 있도록 매일 오전 5시(동부 표준시)까지 데이터 품질 점수가 95% 이상인 영업 데이터를 제공하겠습니다. 영업일 기준 1일 이내에 모든 요청을 확인하고 단순 티켓과 복잡한 티켓별로 정렬합니다. 간단한 요청은 영업일 기준 3일 이내에 해결하고 복잡한 요청은 2주 이내에 해결해 드립니다.

실행 시작 시간 및 실행 완료 시간, 레코드 수 및 Null 대 레코드 수의 비율, 배포 및 드리프트 점수와 같은 데이터 전송 KPI와 데이터 최신성, 데이터 완전성, 데이터 충실도에 대해 사전 정의된 표준과 비교하여 데이터 품질을 측정합니다.

데이터 SLA를 놓친 경우, 영업일 기준 3일 이내에 팀에서 공개 사과문을 게시하여 그 이유와 이를 해결하기 위해 취하고 있는 정확한 조치를 설명합니다.

이 약속을 이행하기 위해서는 여러분의 도움이 필요합니다. 저희 팀은 데이터 사용 방법에 대한 시기적절한 방향, 의견 및 명확한 피드백이 필요하며, 복잡한 변경 요청에 대해 최소 4주 전에 통지해야 합니다.

모든 질문, 의견 및 우려 사항은 data-eng@team.com으로 보내주세요.

최선을 다하겠습니다.

– 데이터 엔지니어링 팀

SLA를 마련한 후(또는 편집하는 동안에도), 이를 지키기 위해 필요한 모든 사항에 대해 생각해 보세요.

예를 들면 다음과 같습니다.

이 문구에서 가능한 한 모호한 표현을 최대한 빼내려고 노력하세요. 구체적이고 명확한 용어로 정의하세요. 고품질 데이터를 정의하는 데 사용할 수 있는 네 가지 특성이 있습니다. 정의한 후에는 다른 팀의 동의를 얻어야 합니다.

다음과 같이 자문해 보세요.

• 좋은 데이터가 비즈니스에 어떤 결과를 가져오는가?
• 좋은 데이터를 정의하는 고유한 특성은 무엇인가?
• 불량 데이터를 정의하는 특성은 무엇인가?

추적을 위해서는 파이프라인의 일부가 다운되었는지 실제로 알 수 있는 관측 가능성 도구가 필요합니다. SLA가 없으면 SLA를 놓쳤는지 여부를 측정하기가 매우 어려우며 근본 원인을 진단하는 것은 훨씬 어렵습니다. 또한 오류를 이해하는 데도 도움이 되므로 훨씬 빠르게 문제를 해결할 수 있습니다.

데이터 SLA는 모든 사람을 안내하는 하나의 중심점인 북극성 지표처럼 취급할 수 있습니다. 하지만 그 안에는 많은 복잡성이 숨겨져 있으며 업스트림과 다운스트림에서 무슨 일이 일어나고 있는지 파악하는 데 도움이 되는 일련의 KPI를 추적해야 합니다.

다음은 몇 가지 구체적인 권장 사항입니다.

1. 4가지 차원에서 데이터 품질을 모니터링하도록 자동 테스트 설정
   • 데이터 사전 프로덕션 테스트
   • 각 단계에서의 테스트: 완전성, 이상 징후
2. 문제를 얼마나 잘 발견, 대응 및 해결하고 있는지 측정
   • 발견 시간
   • 해결 시간
   • 자산당 사고
3. 모든 문제의 근본 원인과 근본 원인 문서화
   • 전송을 놓친 데이터 파트너
   • 시간 초과
   • 대기열에 갇힌 작업
   • 예상치 못한 변화
   • 권한 문제
   • 런타임 오류
   • 일정 변경

약속한 내용에 신중을 기하세요. 모든 곳에 상주하며 모든 상황에 대비할 수는 없으며, 99.999% 가동 시간 SLA는 매년 단 5분의 다운타임만 허용한다는 의미입니다. 이를 달성하려면 더 많은 인원, 더 많은 가시성, 더 많은 중복성, 24시간 근무하는 사람들이 필요합니다.

Jira 또는 ServiceNow와 같은 티켓팅 도구가 필요할 수 있습니다. 이를 통해 데이터 사용자는 티켓을 만들고, 팀은 티켓을 추적하고, 해당 티켓의 특성을 이해하여 장기적인 수정 사항을 제시하고 문제 영역을 식별할 수 있습니다.

공용 데이터 SLA 문서에 지정하지 않고 데이터 원본 및 파이프라인 소유자를 정의할 수 있습니다. 문제가 발생하면 궁극적으로 책임을 져야 합니다. 또한 휴가를 보내거나 회사를 떠날 경우 어떤 일이 발생하는지 지정합니다.

Slack과 같은 팀 메시징 앱이나 PagerDuty와 같은 사고 관리 시스템에 게시할 알림을 설정하세요. 해당 경고에 더 많은 사고 세부 정보를 담을수록 더 빨리 진단할 수 있습니다. 이러한 경고는 다른 사람을 데려와야 하는지 또는 분석을 시작할 위치를 조기에 알려줍니다. (IBM® Databand는 이러한 알림을 보내고 유용한 인사이트와 컨텍스트를 추가할 수 있습니다.)

데이터 소비자가 대시보드에서 테이블이 손상되었다고 알려준다고 가정해 보겠습니다. 어떻게 확인하고 대응하나요? 사고가 발생했을 때 모두가 다른 사람이 처리할 것이라고 생각하고 아무도 행동에 나서지 않는 방관자 문제가 발생하지 않도록 문서로 작성하세요.

팀의 규모와 전 세계에 분산된 방식에 따라 이 문제를 매우 심각하게 받아들이고 비상 대응 요원이 사고 지휘관이라고 부르는 사람을 임명하는 것이 좋습니다. 그 사람이 사고의 CEO가 되며 다른 모든 사고를 지시합니다. (이렇게 하면 조율된 대응이 보장되고 여러 사람이 동일한 문제를 해결하는 것을 방지할 수 있습니다.)

가능하다면 사람들의 대시보드에 경고 패널을 만들어 시스템 상태를 전달할 수 있습니다. 문제가 발생하면 "장애가 발생했습니다. 해결까지 예상되는 시간은 다음과 같습니다."라고 작성할 수 있습니다. 이렇게 하면 모든 데이터 소비자의 반복적인 경고가 분산되고 실제로 응답할 수 있습니다.

경고 패널을 만들 수 없다면 최소한 각 팀에서 말할 수 있는 핵심 사람을 지정하면 다른 모든 팀에 알릴 수 있습니다.

데이터 소비자가 데이터를 사용하는 방법(및 데이터를 사용하고 있는지 여부)을 모니터링합니다. 공식 또는 비공식 설문조사를 가끔 실시하여 해당 데이터에 대한 신뢰도를 측정하고 제안을 요청합니다. 관심이 있는 소비자에게는 로드맵에 무엇이 있는지 전달하세요.

팀이 문제가 발생한 이유를 후기하고 수정 사항을 브레인스토밍할 수 있는 정기적인 유지 관리 기간을 설정하세요. 이러한 문제가 발생할 수 있는 이유를 묻고, 무과실 사후 분석을 수행하고, 조사 결과를 문서화하고, 수정 사항을 할당하고, 작동 방식을 모니터링하세요.

모든 정보를 파악했다면 데이터 SLA를 편집하고 수정할 수 있습니다. 회사 위키나 공유된 곳에 공개적으로 게시하고, 모든 사람의 약속을 확보하고, 이를 지키세요.

데이터 SLA는 자신과 팀을 정직하게 유지하는 데 도움이 됩니다. 이는 다른 사람에 대한 공개적인 약속으로 표현되지만 실제로는 양자 간의 합의입니다. 특정 매개변수 내에서 데이터를 제공하는 데 동의하지만 그 대가로 사람들의 참여와 이해가 필요합니다.

데이터 엔지니어링에서는 많은 문제가 발생할 수 있으며 많은 부분이 잘못된 의사소통과 관련이 있습니다. SLA를 문서화하면 모든 것을 정리하는 데 큰 도움이 되므로 조직 내에 더 큰 데이터 신뢰를 심어주는 궁극적인 목표를 달성할 수 있습니다.

매번 데이터 상황 문제를 조기에 포착하고 데이터 SLA 미치로 인한 비용 손실을 방지하세요. 고급 알림 및 이상 감지 기능을 엔지니어에게 제공하여 품질 문제를 미리 방지하는 방법을 알아보세요. 더 자세히 살펴볼 준비가 되셨다면 지금 바로 데모를 예약하세요.