SLA, SLO, SLI 비교: 차이점은 무엇입니까?

SLA란 무엇입니까?

SLA(서비스 수준 계약)는 가동 시간, 대응 및 책임과 같은 측정 가능한 메트릭에 대한 공급자와 고객 간의 계약입니다.

이 계약은 보통 회사의 신규 비즈니스와 법무 팀이 작성하며, 고객과의 약속 및 그 약속을 이행하지 못했을 때의 결과를 나타냅니다. 일반적으로 결과에는 재정적 불이익, 서비스 크레딧 또는 라이선스 연장이 포함됩니다.

SLA의 과제

SLA는 측정, 보고 및 달성하기 어려운 것으로 유명합니다. 일반적으로 기술 업계에 종사하지 않는 사람들이 작성한 이 계약은 팀이 측정하기 어려운 약속을 하고, 현재의 비즈니스 우선 순위와 끊임없이 변화하는 비즈니스 우선 순위와 항상 정렬되는 것이 아니며, 미묘한 차이를 고려하지 않는 경우가 많습니다.

예를 들어, SLA에서는 제품 X에 대해 보고된 이슈를 24시간 이내에 해결하겠다고 약속할 수 있습니다. 하지만 해당 SLA는 팀에서 문제를 진단하는 데 도움이 되는 답변이나 스크린샷을 고객이 보내는 데 24시간이 걸리는 경우 어떻게 되는지 설명하지 않습니다. 고객의 지연으로 인해 팀의 24시간이 소진되었다는 뜻일까요? 아니면 고객의 응답 시간에 따라 시간 계산이 시작되고 멈춘다는 뜻일까요? SLA는 이러한 질문에 답해야 하지만, 그러지 못하는 경우가 많아 IT 매니저는 SLA에 대한 반감을 가지게 됩니다.

대다수의 전문가는 이 문제에 대해 가장 중요한 것으로 SLA를 만드는 데는 기술 팀이 관여해야 한다고 답합니다. 실제 시나리오를 다루는 SLA를 개발하기 위해 IT 및 DevOps 팀이 법무 및 비즈니스 개발 팀과 더 많이 협업할수록 고객으로 인해 이슈 해결이 지연되는 것과 같은 주요 현실 상황이 SLA에 더 많이 반영됩니다.

SLA는 누구에게 필요합니까?

SLA는 공급업체와 유료 고객 간의 계약입니다. 사용자에게 무료로 서비스를 제공하는 회사는 무료 사용자에 대한 SLA를 원하거나 필요로 하지 않을 것입니다.

SLO란 무엇입니까?

SLO(서비스 수준 목표)는 가동 시간 또는 대응 시간과 같은 특정 메트릭에 대한 SLA 내의 계약입니다. SLA가 여러분과 고객 간의 공식적인 계약이라면, SLO는 해당 고객에게 하는 개별적인 약속입니다. SLO는 고객의 기대치를 설정하고 IT 및 DevOps 팀에게 어떤 목표를 달성하고 측정해야 하는지 알려줍니다.

SLO의 과제

SLO는 SLA보다는 반감을 덜 사지만 모호하거나, 지나치게 복잡하거나, 측정이 불가능하면 SLA만큼이나 많은 문제를 유발할 수 있습니다. 엔지니어를 골치 아프게 만들지 않는 SLO의 핵심은 단순성과 명확성입니다. 가장 중요한 메트릭만 SLO 상태로 사용하고, 목표는 평이한 표현으로 설명되어야 하며, SLA와 마찬가지로 고객 측의 지연 같은 이슈를 항상 고려해야 합니다.

SLO는 누구에게 필요합니까?

SLA는 유료 고객의 경우에만 관련이 있지만, SLO는 내부 및 외부 고객뿐만 아니라 유료 계정과 무료 계정 모두에 유용할 수 있습니다.

CRM, 고객 데이터 리포지토리, 인트라넷과 같은 내부 시스템은 외부 대상 시스템만큼이나 중요합니다. 그리고 내부 시스템에 SLO를 갖추는 것은 비즈니스 목표를 달성하는 것뿐만 아니라 내부 팀이 고객 대상 목표를 달성할 수 있도록 하는 데 중요한 부분입니다.

SLI란 무엇입니까?

SLI(서비스 수준 지표)는 SLO(서비스 수준 목표) 준수를 측정합니다. 예를 들어, SLA에 99.95%의 시간 동안 시스템을 사용할 수 있다고 명시되어 있으면 SLO는 99.95%의 가동 시간이고 SLI는 가동 시간의 실제 측정값입니다. 어쩌면 99.96%일 수도, 99.99%일 수도 있습니다. SLA를 준수하려면 SLI가 해당 문서에 명시된 약속을 충족하거나 초과해야 합니다.

SLI의 과제

SLO와 마찬가지로 SLI의 과제는 추적하기 적합한 메트릭을 선택하면서 단순하게 유지하고, 실제로 고객에게 중요하지 않은 메트릭을 너무 많이 추적하여 IT 팀의 업무를 지나치게 복잡하게 만들지 않는 것입니다.

상세한 재해 복구 계획 수립

가동 중지 시간이 발생하면 어떻게 하시겠습니까? 이 질문에 대한 답을 아직 모른다면 “무엇을 해야 할지 고민하는 데 소중한 시간을 낭비”하게 될 가능성이 높습니다.

올바른 인시던트 대응 계획을 세울수록 팀이 인시던트를 더 빠르고 효과적으로 처리할 수 있습니다. 따라서 새로운 인시던트 관리 프로그램의 첫 번째 단계는 프로세스와 계획이어야 합니다.

SLI는 누구에게 필요합니까?

SLO를 기준으로 성과를 측정하는 회사라면 측정을 하기 위해 SLI가 필요합니다. SLI 없이는 SLO를 얻을 수 없습니다.

고객 기대치를 중심으로 SLA를 작성

고객 계약의 모든 부분은 고객에게 중요한 사항을 중심으로 작성되어야 합니다. 백엔드에서 인시던트는 10개의 서로 다른 구성 요소를 다루는 것을 의미할 수도 있지만, 고객의 입장에서 중요한 것은 시스템이 예상대로 작동하는 것입니다.

SLA 및 SLO는 이러한 현실을 반영해야 합니다. 10가지 구성 요소 각각에 대해 세부적인 수준까지 개별적으로 약속하여 너무 복잡하게 만들지 마세요. 약속은 개략적인 사용자 대상 기능으로만 유지하세요. 그러면 고객의 만족도는 높아지고, 혼란은 줄이며, SLA 약속을 이행할 책임이 있는 IT 전문가가 편해집니다.

SLA에 평이한 표현 사용

고객이 항상 자세한 설명을 요구하지는 않기 때문에, SLA의 표현이 복잡하면 나중에 골치 아픈 오해가 생길 수 있습니다. 표현이 단순할수록 향후에 고객과의 갈등이 발생할 가능성이 낮아집니다.

적을수록 좋은 SLO

모든 메트릭이 고객의 성공에 꼭 필요한 것은 아니므로, 모든 메트릭이 SLO가 되어야 하는 것은 아닙니다. SLO를 최대한 줄이고 고객에게 가장 중요한 SLO에 집중하세요.

추적 가능한 모든 메트릭이 SLI일 필요는 없음

마찬가지로 10개의 SLO 각각에 대해 10개 구성 요소의 성능을 추적하는 일은 순식간에 어려워질 수 있습니다. 그 대신 핵심 SLO에 실제로 중요한 메트릭을 전략적으로 선택하고 그 메트릭을 효과적으로 추적하는 데 집중하세요.

IT 팀의 통제 범위를 벗어나는 요인을 포함

고객으로 인해 해결 시간이 늦어지는 경우 어떻게 될까요? SLA에서 이 내용이 명확하지 않으면 팀은 고객의 개입 없이 고객의 이슈를 해결한다는 불가능한 기준을 마주하게 될 수 있습니다.

오류 예산 구축

장애에 대한 여지를 남기면 SLA 위반과 막대한 결과로부터 비즈니스를 보호할 뿐만 아니라 애질리티를 위한 여지도 남겨, 팀이 변경 사항을 빠르게 적용하고 장애가 발생할 수도 있는 혁신적인 새 솔루션을 시도할 여유를 확보할 수 있습니다.

Google은 실제로 남은 오류 예산을 계획된 가동 중지 시간에 사용할 것을 권장합니다. 그러면 예상치 못한 이슈를 파악하고(예: 서버를 부적절하게 사용하는 서비스) 고객의 적절한 기대치를 유지하는 데 도움이 될 수 있습니다.

지나치게 높은 목표는 금물

팀이 99.99%의 가동 시간을 유지할 수 있다고 해서 SLO 수치가 99.99%여야 한다는 것은 아닙니다. 약속은 작게 하고 그 이상을 제공하는 편이 항상 낫습니다. 릴리스를 일찍, 자주 하고 빠른 속도를 유지하기 위해 오류 예산이 필요한 애자일 팀의 경우 특히 그렇습니다.

SRE에 어떤 영향을 줍니까?

개발 팀과 운영 팀 간의 격차를 해소하는 데 Google의 모델을 따르고 사이트 신뢰성 엔지니어링(SRE) 팀을 활용하는 경우라면 SLA, SLO, SLI는 성공을 위한 기본적인 요소입니다. SLA는 팀이 경계 및 오류 예산을 설정하는 데 도움이 됩니다. SLO는 업무의 우선 순위를 정하는 데 도움이 되며, SLI는 위험에 처한 오류 예산을 지키기 위해 모든 릴리스를 중단해야 할 때와 약간 여유를 가져도 될 때를 SRE에 알려줍니다.

Jira Service Management를 통해 우선 순위에 따라 요청을 해결하여 SLA를 전체적으로 관리하고, 자동화된 에스컬레이션 규칙을 사용하여 적절한 팀원에게 알리고 SLA 위반을 방지하세요.