SLO가 알림 소음을 줄이는 경우
SLO가 알림 소음을 줄이는 경우 (When SLOs reduce alert noise)
프로덕션에서 알림 구성이 커지면 모든 알림이 기대대로 작동하지 않아요. 너무 자주 발화하거나, 누구도 응답하기 전에 즉시 해제되기도 해요. 이때 임계값이나 쿼리를 조정하거나 삭제하고 싶어지는데, 가끔은 그 알림이 신뢰성을 잘못 측정하고 있다는 신호이고 SLO(서비스 수준 목표)를 도입하는 것이 올바른 답일 수 있어요. 이 안내서는 SLO가 알림 소음을 줄이고 신뢰성 커버리지를 개선할 수 있는 세 가지 가장 흔한 패턴을 다뤄요.
출처: 문서
본문
SLO가 임계값 알림과 다른 점
임계값 알림은 평가 간격(예: 5m, 30m, 1h)마다 조건을 평가해요. 그 순간 쿼리 결과가 임계값을 넘으면 알림이 발화하고, 다음 평가에서 조건이 여전히 충족되면 발화 상태를 유지하며, 해결되면 정상으로 돌아가요. 이 관점에서 알림 상태는 이진적이에요: 발화 중이거나 아니거나.
SLO는 서비스가 지금 건강한지에 주로 초점을 두지 않아요. 오랜 기간(일주일 또는 몇 주) 동안 서비스가 신뢰할 수 있는지 측정해요. 예를 들어:
- 알림: 지난 10분 동안 요청의 50%가 3초 안에 응답했나?
- SLO: 지난 4주 동안 요청의 95%가 3초 안에 응답했나?
알림도 긴 평가 기간을 쓸 수 있지만, 서비스가 복구되면 재설정돼요. SLO는 서비스가 복구돼도 오류 예산(error budget)에 대해 실패를 추적해요. 얼마나 많은 저하가 누적됐는지 기록하고, 아직 얼마나 많은 실패가 허용되는지 보고해요.
또 다른 핵심 차이는 SLO 알림이 작동하는 방식이에요. 오류 예산이 소진되고 목표가 위반될 때 발화하는 대신, 목표가 위태로울 때(at risk) 발화해요. SLO 알림은 시스템이 빠르게 저하될 때 페이지를 울려, SLO를 위반하기 전에 행동할 시간을 줘요.
SLO와 임계값 기반 알림은 상호 보완적이에요. 어떤 경우에는 같은 신뢰성 신호를 알림과 SLO 둘 다에서 추적하는 게 합리적이고(즉시 대응은 알림, 장기 가시성은 SLO), 어떤 경우에는 알림을 SLO로 승격하는 게 옳아요. 다음 세 가지는 팀이 기존 알림에서 SLO를 도입하기 시작하는 가장 흔한 상황이에요.
알림에 실행 가능한 대응이 없을 때
알림은 실행 가능해야 해요. 아무도 행동하지 않는 알림은 운영 소음이에요. 알림이 지속적으로 대응을 트리거하지 않지만 그 메트릭이 팀에게 여전히 중요하다면, 이는 신뢰성 우려예요. 이 신뢰성 메트릭은 시간에 따른 서비스 건강을 나타낼 수 있어요. 운영 대시보드에서 추적할 가치가 있지만, 즉시 조치를 트리거하도록 설계되진 않았어요.
팀에게 물어보세요: 이 서비스의 건강에 목표를 커밋하고 성능이 저하되면 행동할 건가요? 답이 예라면 SLO가 적합해요. 실제로 이 질문은 메트릭이 SLI(서비스 수준 지표)로 실제 측정 가능한지 드러내는 경우가 많아요. SLO 목표 정의는 팀을 공유 목표에 정렬하고, 누적된 저하가 언제 조치가 필요할 만큼 심각한지 결정해요. 이는 종종 가장 어려운 부분이고, 목표가 현실을 반영하기 전에 몇 차례 반복이 필요할 수 있어요.
유효한 SLO에 고정할 SLI나 커밋이 없다면 알림을 삭제하는 것이 옳은 선택일 때도 있어요. 하지만 같은 메트릭이 팀 전체의 포스트모템에 계속 나타난다면, 그것은 공유 신뢰성 우려를 가리키는 다른 신호예요.
알림이 공유 신뢰성 우려를 반영할 때
때로는 여러 팀이 서비스 응답 시간 같은 같은 사용자 대면 메트릭에 대해 알림을 유지하면서, 각자 자기 서비스에 자기 임계값과 내부 메트릭을 적용하지만 엔드투엔드 사용자 경험을 평가할 목표는 없어요. 이는 같은 신호를 덮는 겹치는 알림을 만들 수 있어요. 서로 다른 팀이 서비스 성능·사용자 경험 메트릭에 자기 임계값을 정의할 때, 이는 명시되지 않은 공유 사용자 경험 우려를 드러내요.
다른 경우에는 SLO가 비즈니스(고객 커밋이나 SLA 같은)로부터 나와요. SLO는 고객이 기대하는 것에 맞춰 추적되는 공유 목표로 이를 공식화해요. 공유 SLO를 만들기 전에 팀은 명확한 소유권에 합의해야 해요. 두 경우 모두 원인이 아니라 증상을 우선시하라는 모범 사례에서 권장한 대로 내부 메트릭에서 사용자 대면 신뢰성 메트릭으로 이동하는 경우가 많아요.
공유 SLO를 만든다고 기존 관련 알림을 없애선 안 돼요. 이때 기존 알림이 즉시 조치를 트리거하는지 평가하기 좋은 순간이에요. 알림이 덜 실행 가능하고 그 기본 신뢰성 메트릭이 SLO로 측정하는 게 낫다면, 기존 알림을 팀 범위 SLO로 마이그레이션하세요. 팀 범위 SLO가 더 안전한 기본값이에요. 팀이 소유권에 합의한 후에만 공유 SLO로 이동하세요.
알림이 일시적 조건에서 발화할 때
알림이 인간의 개입 없이 발화하고 해제되는 패턴을 플래핑(flapping)이라 해요. 알림 모범 사례는 짧은 스파이크와 일시적 문제를 감지하지 않도록 규칙 설정을 조정해 플래핑 알림을 제거하라고 권장해요. 조정은 소음을 줄이지만 신호를 완전히 제거할 수도 있어요. 이 경우 플래핑 알림이 신뢰성 문제를 표면화했어요. 개별 발화는 무해해 보이지만 시간이 지남에 따라 누적된 저하가 사용자에게 영향을 줘요. 임계값 기반 알림은 이런 오류를 가릴 수 있어요.
SLO 오류 예산은 이 패턴을 포착해요. 각 일시적 실패가 예산의 일부를 소모해 SLO 창에 걸쳐 누적 영향을 보이게 해요. 이 패턴은 플래핑 알림에만 국한되지 않아요. 허용 가능한 일시적 실패가 있는 어떤 알림도 같은 트레이드오프에 직면해요: 소음을 줄이려 조정하고 가시성을 잃거나, 알림을 유지하고 무시하는 법을 배우거나. 대시보드에서 신뢰성 신호를 추적하고 긴 평가 기간에 알림을 거는 것이 해결책이 될 수 있어요. SLO가 더 나은 선택이에요: 오류 예산은 재설정되지 않고 SLO 창 내의 모든 실패를 추적해요.
결론
모든 알림이 효과적이지 않을 때 조정하거나 무음화해야 하는 건 아니에요. 일부는 다르게 추적할 가치가 있는 것을 측정하고 있어요. 알림이 SLO 준비가 됐다는 세 가지 흔한 패턴:
- 실행 가능한 대응 없음: 신호가 서비스 신뢰성을 나타내지만 즉시 조치를 트리거하지 않음.
- 공유 신뢰성 우려: 팀이 유사한 사용자 대면 메트릭을 추적하지만 공유 목표가 없음.
- 일시적 조건: 수명이 짧은 실패가 자주 무시되지만 여전히 사용자에게 영향.
세 경우 모두 최근 기간에 걸쳐 임계값을 평가하는 것에서 장기간에 걸쳐 추적되는 신뢰성 목표를 평가하는 것으로 이동해요. 이는 운영 소음을 줄이고 알림이 서비스가 신뢰성 목표를 충족하는지에 초점을 맞추게 해요. SLO는 기존 알림을 대체하지 않아요. 서비스 신뢰성을 측정하는 뚜렷한 방법을 제공해요.