프로세스는 계속 살아 있는데 사용자는 요청 실패와 긴 대기를 겪습니다. SLO와 오류 예산을 무엇으로 정의하고 배포·안정화 우선순위에 어떻게 사용하나요?

SLO는 서비스 품질을 측정 가능한 목표로 표현한 것입니다. 프로세스가 살아 있는 비율만 보는 가동률과 달리, 유효한 사용자가 올바른 결과를 정해진 시간 안에 받았는지를 측정할 수 있습니다. 먼저 로그인 성공, 결제 완료, 메시지 전송처럼 사용자 흐름을 정하고 성공·실패·정상 거절을 분류해야 합니다.

예를 들어 로그인 API가 HTTP 200을 반환했지만 잘못된 토큰을 발급해 다음 요청이 모두 실패하면 사용자 흐름은 성공이 아닙니다. 반대로 잘못된 비밀번호를 401로 거절한 것은 서비스 오류가 아니라 정상적인 보안 결과일 수 있습니다. 지연 SLO도 평균 대신 정상 요청 중 99%가 300ms 안에 완료처럼 시간 경계와 대상 트래픽을 명시합니다. 외부 의존성 장애를 서비스 SLO에 포함할지는 사용자 책임과 측정 위치를 기준으로 정하겠습니다.

오류 예산은 목표를 달성하지 못해도 허용하는 실패량입니다. 예산이 빠르게 소진되면 배포를 늦추고 안정화 작업에 용량을 배정하는 식으로 운영 결정을 바꿉니다. 처벌 지표로만 쓰면 오류를 숨기거나 트래픽을 거절하는 부작용이 생기므로, 사용자 영향과 정상 거절을 분리하고 단기·장기 burn rate를 함께 보겠습니다.

검증은 실제 사용자 흐름의 성공률·지연·표본 수, 종속 서비스 오류, 경보 후 조치를 함께 확인합니다. 목표를 무조건 100%로 높이는 것이 아니라 사용자에게 미치는 영향과 그 목표를 달성하는 비용을 비교해 정하겠습니다.

대상 요청과 성공 조건을 정의합니다

프로세스가 살아 있어도 잘못된 응답, timeout, 토큰 발급 오류가 있으면 사용자 흐름은 실패입니다. 반면 잘못된 비밀번호 401이나 의도된 rate limit은 정상 거절로 분리할 수 있습니다. 로그인·결제·메시지 전송 같은 여정을 정하고, 정상 요청의 99%가 300ms 안에 완료처럼 백분위수·시간 창·측정 위치를 고정합니다. 저트래픽 기능은 비율만으로 흔들리므로 절대 실패 건수와 사용자 수를 함께 봅니다.

예산을 운영 결정으로 바꿉니다

오류 예산이 빠르게 소진되면 새 배포·대규모 변경을 늦추고 안정화·용량·테스트에 시간을 배정합니다. 단기 burn rate가 급등한 장애와 장기적으로 조금씩 소진되는 품질 저하를 다른 경보로 다룹니다. 예산을 지키려고 오류를 숨기거나 모든 요청을 거절하지 않고, 정상 제한과 사용자 실패를 분리합니다. 종속 서비스의 오류를 사용자 여정에 어떻게 포함할지 정하고, 배포 버전·경보·완화 조치가 같은 지표에 연결되는지 확인하겠습니다.

구체적인 경계 사례

예를 들어 30일 동안 유효 요청 100만 건에 성공률 목표가 99.9%라면 허용 실패는 1,000건입니다. 관측 오류율 1%는 허용 오류율 0.1%의 10배이므로 같은 비율이 유지되면 30일 예산을 약 3일 만에 소진합니다. 이를 소진 속도로 표현한 것이 burn rate이며, 트래픽 변화와 측정 창을 함께 해석해야 합니다.

정상 거절을 제외하는 기준은 장애 중 지표를 좋게 만들기 위해 바꾸지 않습니다. 잘못된 비밀번호의 거절은 정상일 수 있지만 용량 부족으로 유효 사용자를 막은 429·503은 사용자 가용성 실패일 수 있습니다. 지연 지표도 느린 실패를 분모에서 빼지 않도록 대상 요청과 좋은 이벤트 정의를 고정합니다. 집계 백분위수의 평균이 아니라 동일 경계의 성공 건수와 전체 대상 건수를 합산하겠습니다.