DevOps·SRE 지표 설계: 역할별 숫자보다 Delivery·Reliability 결과 보기

개발자, DevOps engineer, SRE가 보는 dashboard는 다를 수 있다. 그러나 역할마다 KPI를 따로 배정하면 delivery speed, reliability, cost가 서로 밀어내는 숫자가 되기 쉽다. 더 나은 출발점은 하나의 service를 함께 운영하는 team이 어떤 outcome을 개선하려는지 정하고, delivery와 user reliability 지표를 같은 화면에서 보는 것이다.

DevOps는 개발팀과 운영팀 사이의 전달 업무만을 뜻하지 않는다. software delivery의 flow와 feedback, automation, learning을 개선하는 조직적 practice와 capability에 가깝다. SRE는 reliability를 engineering problem으로 다루는 접근이고, 회사마다 실제 직무 경계는 달라질 수 있다.

지표를 세 층으로 나눈다

층	답하려는 질문	예시
사용자 결과	사용자가 기능을 성공적으로 쓸 수 있는가	availability SLI, latency SLI, correctness, freshness
delivery 결과	변경을 빠르고 안전하게 전달하는가	DORA delivery metrics, PR flow, rollback evidence
system·process 원인	결과가 나빠진 이유는 무엇인가	saturation, queue, test duration, dependency error, toil

CPU 사용률이나 pipeline 성공률은 중요한 diagnostic signal이지만 그 자체가 user value는 아니다. 원인 지표를 최종 목표로 승격하면 CPU를 낮추거나 build 수를 늘리는 데 성공하고도 서비스 경험은 나빠질 수 있다.

DORA의 현재 다섯 Software Delivery Performance Metrics

DORA는 software delivery performance를 throughput과 instability로 나눠 다섯 지표를 제시한다.

Throughput

1. Change lead time: version control에 commit된 change가 production에 배포될 때까지 걸린 시간
2. Deployment frequency: 일정 기간의 production deployment 수 또는 deployment 사이 시간
3. Failed deployment recovery time: 즉각적인 개입이 필요했던 실패 deployment에서 회복하는 데 걸린 시간

Instability

4. Change fail rate: rollback·hotfix 같은 즉각적 개입이 필요해진 deployment의 비율
5. Deployment rework rate: production incident 때문에 발생한 계획되지 않은 deployment의 비율

기존의 ‘MTTR’이라는 넓은 이름을 그대로 쓰면 repair, restore, respond가 섞일 수 있다. DORA metric을 구현할 때는 deployment failure와 recovery event의 시작·종료 조건을 명시한다. 평균 하나보다 median과 tail distribution, service·change type별 분포도 함께 보는 것이 좋다.

이 다섯 숫자는 개인 개발자의 성과 점수가 아니다. team과 service의 delivery system을 개선하기 위한 outcome metric이다. deployment를 잘게 쪼개 숫자만 늘리거나 incident를 누락하는 식의 gaming을 막으려면 정의와 data source를 공개해야 한다.

SLI·SLO·SLA와 Error Budget

• SLI는 실제로 측정한 service level indicator다. 예: 좋은 request 수 / 전체 유효 request 수.
• SLO는 일정 window에서 달성하려는 SLI target이다. 예: 28일 동안 99.9% 성공.
• SLA는 고객과의 계약적 약속이며 위반 시 credit 같은 consequence를 포함할 수 있다.

99.9% SLO라면 같은 정의와 window에서 0.1%가 error budget이다. error budget은 장애를 허용하자는 무책임한 숫자가 아니라 reliability와 change velocity를 데이터로 조정하는 장치다.

좋은 SLI는 사용자가 경험하는 ‘good event’를 표현한다.

availability = successful eligible requests / all eligible requests
latency      = requests completed under threshold / all eligible requests
freshness    = responses using data newer than threshold / all eligible requests

HTTP 4xx를 모두 service error로 볼지, scheduled maintenance를 window에서 어떻게 다룰지, retry를 request로 셀지부터 합의해야 한다. definition이 없는 99.9%는 비교 가능한 지표가 아니다.

개발팀이 함께 볼 Flow와 Quality Signal

• PR cycle time을 coding, review wait, CI, merge wait로 나눈다.
• change lead time을 commit부터 production까지 같은 기준으로 측정한다.
• escaped defect와 change failure를 user impact·severity와 함께 본다.
• flaky test rate, build queue time, deploy duration을 bottleneck 진단에 쓴다.

code coverage가 높다고 test quality가 자동으로 높아지지는 않는다. assertion이 약하거나 위험 경로가 빠져도 coverage는 올라갈 수 있다. coverage는 changed code와 critical path의 test gap을 찾는 보조 지표로 사용하고 mutation test, defect evidence, review를 함께 본다.

Platform·DevOps에서 볼 Capability와 Guardrail

IaC 적용률, 자동화율, build 성공률은 쉽게 숫자를 채울 수 있지만 정의가 모호하면 행동을 왜곡한다. 다음처럼 실제 friction과 risk를 측정한다.

• environment provisioning lead time과 실패 후 복구 가능성
• CI queue time·execution time·flake rate
• deployment self-service 성공률과 manual exception 사유
• policy violation·secret exposure·supply-chain finding의 처리 시간
• cost per useful workload unit과 budget variance
• developer self-service task의 완료율과 지원 요청 재발률

‘자동화 비율 100%’보다 표준 경로가 빠르고 안전하며 예외가 추적되는지가 중요하다. platform metric은 developer experience와 production guardrail을 함께 가져야 한다.

Reliability dashboard는 결과와 원인을 연결한다

SLO dashboard는 user impact를 알려 주지만 원인을 모두 설명하지 않는다. alert가 울리면 traffic, error, latency, saturation과 dependency, deployment event, queue를 같은 timeline에서 연결한다.

• page는 user impact나 error-budget burn처럼 action이 필요한 signal에 건다.
• CPU·memory threshold는 단독 page보다 symptom과 결합하거나 investigation signal로 쓴다.
• p50만 보지 말고 p95·p99와 request volume을 함께 본다.
• backup 성공이 아니라 restore test의 성공·소요 시간·복구 지점을 검증한다.
• trace와 log는 sampling, retention, PII·secret masking 기준을 둔다.

시스템 원인 지표를 정리할 때는 RED와 USE 방법론 비교, 관측과 실험의 큰 흐름은 시스템 성능 엔지니어링 1장 학습노트로 이어갈 수 있다.

지표 정의서에 꼭 들어갈 항목

1. 질문과 의사결정: 이 숫자로 무엇을 바꿀 것인가
2. numerator·denominator와 제외 조건
3. data source와 owner
4. service·environment·window·timezone
5. target과 guardrail
6. 누락·지연·중복 data 처리
7. dashboard와 alert, review cadence

새 지표는 처음부터 KPI 보상에 연결하기보다 몇 주간 관찰해 data quality와 예상치 못한 유인을 확인하는 편이 안전하다.

자주 묻는 질문

개발자·SRE·DevOps의 지표를 따로 정해야 하나

소유한 운영 task에 따라 diagnostic dashboard는 달라질 수 있다. 하지만 user reliability와 delivery outcome은 공동 목표로 두고, 역할별 지표는 그 결과를 설명하는 하위 signal로 연결하는 편이 좋다.

MTTR이 낮으면 reliability가 좋은가

빠른 recovery는 중요하지만 incident 빈도와 user impact를 숨길 수 있다. failed deployment recovery time, change fail rate, error-budget consumption을 함께 본다.

CPU가 높으면 바로 scale-out해야 하나

CPU saturation과 queue, latency, error, workload 변화가 함께 있는지 먼저 확인한다. 높은 utilization이 항상 user impact나 자원 부족을 뜻하지는 않는다.

참고 자료

• DORA Software Delivery Performance Metrics
• Google SRE Workbook: Implementing SLOs
• Google SRE Workbook: Error Budget Policy
• Google SRE Workbook: Monitoring