빠른 속도의 팀을 위한 인시던트 관리
오류 예산이란 무엇이며 왜 중요합니까?
모든 개발, 운영 및 IT 팀은 인시던트가 발생하기 마련이라는 것을 알고 있습니다.
최고의 인재를 보유하고 가동 시간이 거의 100%에 가까운 것으로 알려진 대기업조차 시스템이 중단될 때 무기력하게 당하고는 합니다. Apple, Delta 또는 Facebook만 해도 모두 지난 5년 동안 인시던트로 인해 수천만 달러의 손해를 입었습니다.
이러한 현실을 통해 알 수 있는 점은, 서비스 수준 계약(SLA)은 절대로 100% 가동 시간을 약속해서는 안 된다는 것입니다. 어떤 회사도 지킬 수 없는 약속이기 때문입니다.
또한 회사가 인시던트를 방지하거나 해결하는 데 매우 능숙하다면 가동 시간 목표를 지속적으로 달성할 수도 있다는 뜻입니다. 어쩌면 99%의 가동 시간을 약속하고 실제로 99.5%에 가까워질 수도 있습니다. 아니면 99.5%의 가동 시간을 약속하고 일반적인 달에 실제로 99.99%에 도달할 수도 있습니다.
그렇게 되는 경우, 업계 전문가는 계속해서 약속한 수준을 초과하여 사용자의 기대치를 너무 높게 세우는 대신 그 추가적인 0.99%를 오류 예산, 즉 팀이 위험을 감수하는 데 사용할 수 있는 시간으로 간주할 것을 권장합니다.
오류 예산이란 무엇입니까?
오류 예산이란 계약상의 부정적인 결과 없이 기술 시스템에 장애가 발생할 수 있는 최대 시간입니다.
예를 들어, 서비스 수준 계약(SLA)에서 시스템이 99.99%의 시간 동안 작동할 것이며 그렇지 않으면 비즈니스가 고객에게 서비스 중단에 대한 보상을 지불한다고 명시된 경우 오류 예산(또는 부정적인 결과 없이 시스템이 중단될 수 있는 시간)은 연간 52분 35초라는 뜻입니다.
SLA에서 99.95%의 가동 시간을 약속하는 경우의 오류 예산은 4시간 22분 48초이며, SLA에서 99.9%의 가동 시간을 약속하는 경우의 오류 예산은 8시간 46분 12초입니다.
기술 팀에 오류 예산이 필요한 이유는 무엇입니까?
언뜻 보기에 오류 예산은 그다지 중요하지 않아 보일 수 있습니다. 모든 것이 원활하게 실행되도록 IT 및 DevOps 팀에서 추적해야 하는 또다른 하나의 메트릭일 뿐이라고 생각할 수 있습니다.
하지만 그렇지 않습니다. 오류 예산은 단순히 계약상 약속을 지키고 있는지 편리하게 확인하기 위한 방법이 아니라, 개발 팀이 혁신을 이루고 위험을 감수할 수 있는 기회이기도 합니다.
Atlassian의 SRE 관련 문서에서 설명한 바에 따르면,
"개발 팀은 이 오류 예산을 원하는 방식으로 '지출'할 수 있습니다. 현재 오류가 거의 또는 전혀 없이 제품이 완벽하게 실행되고 있는 경우, 언제든지 원하는 대로 제공할 수 있습니다. 반대로 오류 예산을 초과했으며 정의된 SLA 이하로 운영되는 경우, 제공을 진행할 수 있는 수준으로 오류의 개수가 줄어들 때까지 모든 제공은 중지됩니다."
이 접근 방식의 이점은 팀이 허용 가능한 한도 내에서 위험을 감수하여 실제 인시던트를 최소화하고 혁신을 최대화하도록 장려한다는 것입니다. 또한 혁신과 애질리티를 목표로 하는 개발 팀과 안정성 및 보안에 중점을 두는 운영 팀 간의 격차를 해소해 줍니다. 가동 중지 시간이 적은 한 개발자는 애자일한 상태를 유지하고 운영으로 인한 마찰 없이 변경 사항을 푸시할 수 있습니다.
오류 예산을 사용하는 방법
먼저 SLA 및 SLO를 찾아봐야 합니다. 가동 시간이나 성공적인 시스템 요청을 위해 이미 세운 목표는 무엇입니까? 회사는 고객과 어떤 약속을 했습니까? 오류 예산은 이러한 요소에 따라 결정됩니다.
가동 시간 기반의 오류 예산
대부분의 팀은 월 단위로 가동 시간을 모니터링합니다. 가용성이 SLA/SLO에서 약속한 수치보다 높으면 팀이 새 기능을 릴리스하고 위험을 감수할 수 있습니다. 가용성이 목표치보다 낮으면 목표 수치를 다시 충족할 때까지 릴리스가 중단됩니다.
이 방법을 효과적으로 사용하려면 SLO 목표(일반적으로 백분율로 표시)를 개발자가 작업할 수 있는 실제 수치로 변환해야 합니다. 즉, 허용되는 가동 중지 시간의 1%, 5% 또는 0.1%가 실제로 몇 시간, 몇 분으로 변환되는지 계산해야 합니다. 일반적인 목표는 다음과 같습니다.
SLA 목표 | 연간 허용되는 가동 중지 시간 | 월간 허용되는 가동 중지 시간 | |
|---|---|---|---|
| 99.99% 가동 시간 | 연간 허용되는 가동 중지 시간 52분 35초 | 월간 허용되는 가동 중지 시간 4분 23초 | |
| 99.95% 가동 시간 | 연간 허용되는 가동 중지 시간 4시간 22분 48초 | 월간 허용되는 가동 중지 시간 21분 54초 | |
| 99.9% 가동 시간 | 연간 허용되는 가동 중지 시간 8시간 45분 57초 | 월간 허용되는 가동 중지 시간 43분 50초 | |
| 99.5% 가동 시간 | 연간 허용되는 가동 중지 시간 43시간 49분 45초 | 월간 허용되는 가동 중지 시간 3시간 39분 | |
| 99% 가동 시간 | 연간 허용되는 가동 중지 시간 87시간 39분 | 월간 허용되는 가동 중지 시간 7시간 18분 | |
성공적인 요청 기반의 오류 예산
SLO는 SLA보다는 반감을 덜 사지만 모호하거나, 지나치게 복잡하거나, 측정이 불가능하면 SLA만큼이나 많은 문제를 유발할 수 있습니다. 엔지니어를 골치 아프게 만들지 않는 SLO의 핵심은 단순성과 명확성입니다. 가장 중요한 메트릭만 SLO 상태로 사용하고, 목표는 평이한 표현으로 설명되어야 하며, SLA와 마찬가지로 고객 측의 지연 같은 이슈를 항상 고려해야 합니다.
Jira Service Management를 통해 우선 순위에 따라 요청을 해결하여 SLA를 전체적으로 관리하고, 자동화된 에스컬레이션 규칙을 사용하여 적절한 팀원에게 알리고 SLA 위반을 방지하세요.