서비스 수준 검토에서는 사용자가 실제로 받은 서비스가 무엇인지, 합의한 목표와 얼마나 차이가 나는지, 다음에 무엇을 해야 하는지 설명해야 합니다. 초록색 백분율 하나로는 부족합니다. 무엇을 세었는지, 어느 기간의 결과인지, 전체 수치와 달리 일부 사용자가 훨씬 나쁜 경험을 했는지 알 수 있어야 합니다.
검토할 수 있는 문장으로 시작하세요. “티켓 제출 서비스는 성공률 목표를 달성했지만, 대부분의 실패가 하나의 장애에서 발생했습니다. 목표를 높이기 전에 이 실패 경로를 조사할 것을 제안합니다.” 이어서 계산과 영향을 받은 업무 흐름을 보여 주세요. 설명 없는 숫자 열두 개가 담긴 대시보드 캡처보다 유용한 시작입니다.
승인된 검토 메모는 Presenti의 텍스트 기반 프레젠테이션 기능으로 편집 가능한 발표 자료로 만들 수 있습니다. 근거는 모니터링 시스템과 고객지원 시스템에서 가져오세요. Presenti는 슬라이드를 구성하고 편집하는 데 도움을 주지만, 서비스 관측 데이터를 수집하거나 SLO 달성 여부를 판단하지 않습니다.
서비스, 지표, 기간을 정의하세요
검토 범위를 사용자 여정 하나, 이를 지원하는 서비스, 보고 기간으로 좁히세요. 실제 근거가 티켓 제출에만 해당한다면 “플랫폼 신뢰성”은 너무 넓은 표현입니다. 제출이 성공했다고 로그인, 검색, 알림까지 정상 작동했다고 볼 수는 없습니다.
첫 결과 슬라이드나 옆의 작은 용어 설명에 세 가지 개념을 넣으세요. Google SRE의 서비스 수준 목표 설명은 측정값, 목표, 협약을 구분합니다.
| 용어 | 의미 | 보여 줄 내용 |
|---|---|---|
| SLI: 서비스 수준 지표 | 서비스 동작을 정량적으로 측정한 값 | 측정 결과와 계산 방법 |
| SLO: 서비스 수준 목표 | 정해진 기간에 해당 지표가 도달해야 할 목표 | 합의한 기준, 범위, 시간 구간 |
| SLA: 서비스 수준 협약 | 서비스 약속을 지키지 못했을 때의 조치를 포함하는 협약 | 계약 이행을 평가한다면 적용되는 협약과 그 협약의 측정 조건 |
백분율이 비슷하다는 이유로 내부 SLO 결과에 “SLA 준수”라고 이름 붙이지 마세요. 협약은 서비스 범위, 제외 조건, 계산 기간이 다를 수 있습니다. 운영 결과와 계약상 평가는 구분해야 합니다. 슬라이드만으로 계약 위반이나 크레딧 지급 권리가 확정되는 것은 아닙니다.
계산 예시: 티켓 제출 서비스
다음 서비스, 기록, 수치는 모두 가상입니다. 검토 자료를 구성하는 방법을 설명하기 위한 것이며 Presenti의 성능 데이터나 고객 사례가 아닙니다.
고객지원 플랫폼이 고객의 신규 티켓 제출 가능 여부를 검토한다고 해 보겠습니다. 합의한 성공률 SLO는 고정된 28일 동안 99.90%입니다. 아래 측정 정의 카드는 숨겨진 부록이 아니라 결과 옆에 두어야 합니다.
| 항목 | 이 사례의 정의 |
|---|---|
| 사용자 여정 | 새 지원 티켓을 제출하고 실제 사용할 수 있는 티켓 ID를 받음 |
| 기간 | 9월 1일 00:00 UTC부터 9월 29일 00:00 UTC 직전까지, 온전한 28일 |
| 집계 대상 이벤트 | 인증됐고 형식이 올바른 운영 환경의 제출 시도 중 게이트웨이가 받아들인 것. 각 시도에는 고유한 요청 ID가 있음 |
| 정상 이벤트 | 티켓이 저장되고 제출한 클라이언트가 사용할 수 있는 티켓 ID를 받음 |
| 제외 트래픽 | 상태 점검, 표시된 테스트 트래픽, 사전에 합의한 자격 규칙을 충족하지 못한 요청. 규칙은 검토 기간 전에 정함 |
| 근거 | 게이트웨이의 고정된 추출본과 티켓 서비스 결과를 요청 ID로 연결. 쿼리 버전과 추출 시각을 발표 자료에 첨부 |
| 측정 범위의 한계 | 요청이 게이트웨이에 도착하기 전의 실패는 이 SLI가 측정하지 않음 |
분모는 고객 수가 아니라 제출 시도 수입니다. 이 정의에서는 재시도도 새로운 시도입니다. 고객 한 명이 총 열 번 제출을 시도했다면 이벤트 열 건이지, 영향받은 고객 열 명이 아닙니다. 차트 이름과 발표자 노트에서도 이 차이를 유지하세요.
측정 범위의 한계도 중요합니다. 로그인 페이지가 고장 나 고객이 게이트웨이에 도달하지 못해도 이 SLI는 정상으로 보일 수 있습니다. 결과 옆에 이 빈틈을 표시하고, 더 넓은 사용자 여정은 별도의 근거로 확인하세요. 기간이 끝난 뒤 실패 요청을 제외해 백분율을 높이면 안 됩니다.
색상만 표시하지 말고 오류 예산을 계산하세요
Google의 SLO 도입 안내는 이벤트 기반 지표를 전체 이벤트 대비 정상 이벤트 비율로 설명합니다. 목표가 100% 미만이면 그 차이가 허용되는 실패 비율입니다. 완료된 예시 기간의 계산은 다음과 같습니다.
| 항목 | 계산 | 결과 |
|---|---|---|
| 집계 대상 시도 | 범위에 포함된 요청 ID 수 | 2,000,000 |
| 정상 시도 | 성공이 확인된 결과 | 1,998,600 |
| 실패 시도 | 2,000,000 − 1,998,600 | 1,400 |
| 측정된 성공률 | 1,998,600 ÷ 2,000,000 × 100 | 99.93% |
| 허용 실패 시도 | 2,000,000 × (1 − 0.9990) | 2,000 |
| 사용한 오류 예산 | 1,400 ÷ 2,000 × 100 | 70% |
| 이번 기간에 사용하지 않은 허용량 | 2,000 − 1,400 | 600회 |
99.93%가 99.90%보다 높으므로 성공률 목표는 달성했습니다. 차이는 0.03%p입니다. 전체 요청의 70%가 아니라 허용 실패량의 70%를 사용한 것입니다.
남은 600회의 의미는 주의해서 설명해야 합니다. 끝난 보고 기간의 잔여량일 뿐, 다음 달에 600회의 실패를 일으켜도 된다는 허가는 아닙니다. 이동 구간을 사용하는 운영 SLO라면 현재 구간으로 별도 계산해야 합니다. 이벤트 예산은 분 단위의 허용 중단 시간도 아닙니다. 트래픽이 많은 1분과 적은 1분에서 실패 시도 수는 크게 다를 수 있습니다.
원본 시트에는 정밀한 값을 보존하고 발표 자료에는 일관된 반올림을 적용하세요. 기준에 가까운 결과를 반올림해 미달을 달성처럼 만들지 마세요. 나중에 다른 사람이 재현할 수 있도록 쿼리와 시간 구간을 슬라이드와 함께 보관합니다.
실패가 누구에게 어떤 영향을 줬는지 설명하세요
가상 기록에서 실패 1,400회 중 1,200회는 하나의 장애와 관련됩니다. 이 1,200회는 서로 다른 계정 ID 140개와 연결됩니다. 따라서 이 장애는 전체 기간 오류 예산의 60%를 사용했습니다. 1,200을 2,000으로 나눈 값입니다. 나머지 실패 200회가 추가로 10%를 사용했습니다.
영향 슬라이드에는 “하나의 장애가 오류 예산 대부분을 사용했고 140개 계정에 영향을 줬습니다”라고 쓸 수 있습니다. 그러나 “140명이 일할 수 없었습니다” 또는 “티켓 1,200건이 사라졌습니다”라고 할 근거는 없습니다. 한 계정에 여러 사용자가 있을 수 있고, 반복 시도는 동일한 티켓을 만들려던 행동일 수 있으며, 실패 횟수만으로 최종 생성 여부는 알 수 없습니다.
숫자 옆에 영향을 받은 업무 흐름도 보여 주세요. 이 사례에서는 장애 중 고객이 티켓 접수 확인을 안정적으로 받지 못했습니다. 지원 기록은 그 뒤의 행동을 이해하는 데 도움이 되지만, 몇 번의 상담을 모든 계정의 경험으로 일반화해서는 안 됩니다.
작은 영향 요약 패널에는 다음 세 줄을 넣을 수 있습니다.
- 관측: 장애와 연결된 실패 시도 1,200회, 해당 기록에 나타난 서로 다른 계정 ID 140개
- 아직 확인되지 않음: 만들려던 티켓 중 성공적으로 재제출한 것과 제출을 포기한 것의 수
- 후속 조치: 포기 건수를 보고하기 전에 시도 기록과 최종 티켓 생성을 대조
전체 결과와 사용자 영향을 함께 다뤄야 하는 이유입니다. 목표 달성 여부와 특정 업무에 집중된 불편은 서로 다른 질문에 답합니다. 어느 한쪽이 다른 쪽을 지워서는 안 됩니다.
결과를 신뢰성 개선 결정으로 연결하세요
검토는 가장 높은 목표를 고르는 경쟁이 아닙니다. 어떤 조치가 관측된 문제를 해결할 수 있는지, 무엇이 이를 뒷받침하는지, 그 대신 어떤 일을 미뤄야 하는지 물으세요. 99.90%를 99.99%로 바꾸자는 제안만으로 서비스가 개선되지는 않습니다.
이 사례에서 서비스 책임자는 다음 대안을 비교할 수 있습니다.
| 대안 | 대응하는 문제 | 추가 실행 전에 필요한 근거 |
|---|---|---|
| 실패가 집중된 경로 조사 | 실패 시도 1,200회를 발생시킨 장애 | 재현 가능한 실패와 완화 대안 비교 테스트. 시점이 같다는 이유만으로 원인을 확정하지 않음 |
| 게이트웨이 이전까지 측정 확대 | 고객 브라우저와 현재 SLI 사이의 사각지대 | 측정 범위, 데이터 처리, 구현 노력을 명시한 한정된 제안 |
| 지금 SLO 강화 | 더 엄격한 신뢰성 약속 | 새 목표가 사용자 요구와 맞는다는 근거와 추가 신뢰성 작업에 대한 합의된 계획 |
첫 두 대안은 구체적으로 발견한 문제에 대응합니다. 세 번째는 기대 수준과 비용에 대한 별도 결정이 필요합니다. 보고서를 초록색으로 보이게 하려고 목표를 몰래 낮추거나, 슬라이드를 야심 차게 보이게 하려고 높이지 마세요.
조직에 오류 예산 정책이 있다면 그 정책이 요구하는 조치와 예외 승인권자를 밝히세요. 없다면 정책 제안을 어디까지나 제안으로 표시합니다. 발표자가 임의로 자동 출시 중단 규칙을 만들고 이미 모두 합의한 것처럼 보여서는 안 됩니다.
회의 후에도 쓸 수 있는 6장짜리 검토 자료를 만드세요
세부 자료를 근거 묶음에 보관하면 본 발표는 간결하게 유지할 수 있습니다. 각 슬라이드에 한 가지 역할을 맡기세요.
- 결과와 결정: 목표 99.90% 대비 성공률 99.93%, 한 장애에 집중된 실패, 승인을 요청하는 구체적 작업
- 측정 경계: 사용자 여정, 날짜, 대상·정상 이벤트, 출처, 측정에서 빠진 부분
- 오류 예산: 분자, 분모, 허용 실패량, 70% 사용 계산
- 사용자 영향: 영향을 받은 업무, 관측된 계정 ID 140개, 아직 모르는 내용
- 대안: 선택 가능한 조치, 각각 필요한 근거, 그 대신 미뤄지는 작업
- 결정 기록: 책임자, 승인 범위, 다음 검토 시점, 그때 필요한 근거
지표 추출본과 쿼리 세부 사항은 발표 자료와 함께 보관하되, 고객 개인정보를 슬라이드에 복사하지 마세요. 더 넓은 청중에게는 민감한 정보를 가린 영향 요약을 사용합니다. 정의 변경을 제안한다면 미래 버전으로 표시하고, 현재 결과는 그 값을 산출한 기존 정의에 연결해 두세요.
가상 회의의 완료된 결정 기록은 다음과 같을 수 있습니다.
서비스 리드 책임 아래 티켓 접수 확인 실패 경로를 조사하는 데 엔지니어 2인일의 작업을 승인한다. 재현 결과, 완화 대안, 테스트 근거를 가져온다. 아직 향후 실패 감소를 주장하지 않는다. 성공률 SLO 99.90%는 유지한다. 다음 검토에서는 게이트웨이 이전의 제출 실패를 측정하는 범위가 정해진 제안도 제시한다. 조사 범위를 넘어서는 구현은 별도의 인력 배정 결정이 필요하다.
이 기록이 다음 회의의 구체적인 출발점이 됩니다. 같은 초록색 백분율을 보여 주고 같은 약속을 반복하는 대신, 정해진 작업에서 얻은 근거를 검토할 수 있습니다.
