개발자의 생산성을 측정 하려는 시도는 과거부터 이어져 온 바람이자 지금도 꾸준히 연구되고 있는 주제입니다.
DORA 팀은 2014년부터 2020년까지 6년 동안 31,000명 이상의 조직 내 전문가를 대상하여 Nicole Forsgren 박사, Jez Humble 및 Gene Kim을 필두로 꾸준히 활동했던 연구팀으로, DevOps 기술의 발전을 위한 연구와 소프트웨어 개발 맥락에서 ‘고성능’이 무엇인지를 이해하고 이러한 ‘고성능’을 예측하는 요인에 대한 연구를 수행하기 위해 설립되었습니다. 이들의 연구 결과는 곧 기술 조직을 평가하고 벤치마킹하기 위한 다양한 데이터 기반 솔루션(Flow, Codacy, waydev …)들의 기초가 됩니다.
2018년에는 DORA가 Google에 인수되었습니다. Google Cloud의 일부가 된 DORA는 이제 데이터 기반 의사결정을 통해 개발자와 경영진 모두 즐거운 경험을 줄 수 있는 방법들을 계속해서 만들어가고 있습니다.
그 중에서도 Google Cloud 에서 이를 연구하는 DevOps Research and Assessment 팀이 있습니다. 각 대문자만 따서 “DORA” 팀입니다.
DevOps 지표의 점수를 개선하기 위한 팁을 포함하여 많은 DevOps 지표에 대해 설명합니다
DevOps 메트릭은 다음과 같은 주요 DevOps 사례 또는 프로세스의 성능을 측정하는 데 도움이 되는 데이터입니다.
- 지속적 통합(CI)
- 지속적 배포
- 자동화된 테스트
- 지속적인 모니터링
이러한 Metric을 통해 조직은 진행 상황을 모니터링할 수 있으며, 설정한 목표를 달성하고 있습니까?
또한 Metric은 DevOps 프로세스에서 애플리케이션 성능과 직원 생산성을 극대화하지 못하게 하는 병목 현상을 식별하는 데 도움이 됩니다. 이러한 메트릭을 활용하면 필요한 개선을 수행하고 투자 수익을 극대화할 수 있습니다.
이 문서에서는 이러한 Metric을 몇 가지 범주로 분류했습니다.
- DORA의 4가지 주요 지표
- 테스트 및 코드 품질 최적화
- 배포 최적화
- 지속적 통합 최적화
- 고객 만족도 측정
- 모니터링 관행 최적화
DORA DevOps Metric
알려진 DevOps 측정항목은 Google의 DevOps Research and Assessment(DORA) 팀인 DORA에서 제공합니다.
DORA는 7년 이상의 연구에 걸쳐 고성능 DevOps팀을 차별화하는 요소를 파악했습니다.
DORA 프레임워크는 4가지 주요 지표를 사용하여 DevOps의 두 가지 핵심 영역인 속도와 안정성을 측정합니다.
배포 빈도 및 변경에 대한 평균 리드 타임은 DevOps 속도를 측정하고,
변경 실패율 및 서비스 복원 시간은 DevOps 안정성을 측정합니다. 이 4가지 DORA Metric을 함께 사용하면 DevOps팀의 성과에 대한 기준과 개선할 수 있는 부분을 찾을 수 있습니다.
아래는 4가지 주요 DevOps Metric, 좋은 평가의 정의 및 개선 방법에 대한 간략한 설명입니다.
Change failure rate(CFR)
CFR은 서비스 성능 저하 또는 중단과 같은 즉각적인 수정이 필요한 장애를 유발하는 배포의 비율입니다.
CFR이 낮은 것은 팀이 새로운 기능과 고객 가치를 제공하는 데 시간이 줄어들기 때문에 바람직합니다.
CFR은 배포 수를 계산하고 그 중 핫픽스 또는 롤백을 초래한 배포 수를 계산하며 공식은 아래와 같습니다.
(배포 실패 횟수 / 총 배포 횟수) x 100
CFR 벤치마크는 다음과 같습니다.
- 엘리트: 0-15%
- 높음: 16-30%
- 중간: 16-30%
- 낮음: 16-30%
이 지표는 코드 품질과 테스트 방법의 효율을 나타내는 지표라고 볼 수 있습니다.
효과적인 DevOps 사례를 따르는 경우 CFR은 0~15% 사이여야 합니다.
Deployment frequency (DF)
DF는 변경 사항을 프로덕션에 배포하는 빈도를 측정한 것입니다. 성과가 높은 팀일수록 하루에 여러번 배포를 진행하게 됩니다. 매월, 매주 단위로 배포하면 DF가 낮아집니다.
이 Metric은 팀이 다음을 수행하는 데 도움이 됩니다.
- 변화하는 고객 요구 사항에 대응합니다.
- 버그를 더 빠르게 수정합니다.
- 기존 기능에 대한 개선 사항을 소개합니다.
- 덜 빈번하거나 더 큰 배포와 관련된 위험을 줄입니다.
배포 빈도 벤치마크는 다음과 같습니다.
- 엘리트: 하루에 여러 번 배포
- 높음: 일주일에 한 번에서 한 달에 한 번 배포
- 중간: 매월 1회에서 6개월에 한 번씩 배포
- 낮음: 6개월 배포 1회 미만
배포 빈도에 관한 가이드 https://www.splunk.com/en_us/blog/learn/deployment-frequency.html
Lead Time for changes(LT)
LT는 Commit이 사전 프로덕션 환경에서 필요한 모든 테스트를 통과하고 프로덕션 준비가 되는데 걸리는 시간입니다.
Commit 시간과 릴리즈 시작을 사용해 지표를 계산합니다.
Trunk-Based 배포, 소규모 Batch 작업 및 테스트 자동화 등을 구현해 LT를 개선 할 수 있습니다.
변경 벤치마크의 평균 리드 타임은 다음과 같습니다.
- 엘리트: 시간당 1회 미만
- 높음: 1일에서 1주일 사이
- 중간: 1개월에서 6개월 사이
- 낮음: 6개월 이상
Mean time to recover (MTTR)
MTTR은 프로덕션 환경에서 전체 장애 또는 부분적인 서비스 중단을 복구하는데 걸린 시간입니다.
MTTR은 장애 발생 시간과 이를 해결하는데 걸린 시간으로 계산 할 수 있습니다.
MTTR 점수는 장애가 발생할 때 얼마나 빨리 식별하고 이에 대한 수정 사항을 배포할 수 있는지에 따라 달라집니다.
시스템 및 서비스를 지속적으로 모니터링하고 사고가 발생하는 즉시 관련 담당자에게 경고하여 MTTR 점수를 높일 수 있습니다.
복원 시간 서비스 벤치마크는 다음과 같습니다.
- 엘리트: 1시간 미만
- 높음: 1일 미만
- 중간: 1일에서 1주일 사이
- 낮음: 6개월 이상
DORA Metric의 이점
DORA 메트릭은 조직의 소프트웨어 제공 성과와 이를 업계의 다른 회사와 비교하는 데 유용한 도구입니다. 이로 인해 다음과 같은 결과가 발생할 수 있습니다.
- 더 나은 의사 결정: DORA 메트릭을 지속적으로 추적하면 조직이 하드 데이터를 사용하여 개발 프로세스의 현재 상태를 이해하고 개선 방법에 대한 결정을 내리는 데 도움이 됩니다. DORA는 DevOps 팀이 모든 것을 모니터링하는 대신 특정 메트릭에 집중할 수 있도록 지원하기 때문에 팀은 프로세스에서 병목 현상이 있는 위치를 보다 쉽게 식별하고 이를 해결하는 데 노력을 집중하고 결과를 검증할 수 있습니다. 그 결과 직감이 아닌 데이터에 의해 더 빠르고 고품질의 제공이 가능합니다.
- 더 큰 가치: 엘리트 및 고성과 팀은 고객에게 가치를 제공하고 비즈니스에 긍정적인 영향을 미치고 있다는 확신을 가질 수 있습니다. 또한 DORA 메트릭은 성과가 낮은 팀에게 프로세스가 중단될 수 있는 위치를 명확하게 파악하고 더 큰 가치를 제공하기 위한 경로를 식별하는 데 도움이 됩니다.
- 지속적인 개선: DevOps 팀은 DORA 메트릭을 사용하여 성과의 기준을 설정하고 생산성을 저해하는 습관, 정책, 프로세스, 기술 및 기타 요인을 발견할 수 있습니다. 4가지 주요 지표는 팀의 성과를 최적화하고 이를 위한 가장 효과적인 방법을 결정하기 위한 목표를 설정하는 경로를 제공합니다.
'Engineering' 카테고리의 다른 글
K6 load testing (0) | 2024.04.05 |
---|---|
EKS Prometheus CPU & Memory DashBoard 구성 (0) | 2024.04.03 |
Prometheus란? helm을 이용해 EKS에 설치 (0) | 2024.04.02 |
Performance Test Metric 도구 간단 정리 (Promethus, Thanos, Cortex, Mimir, Victoria Metrics) (0) | 2024.04.01 |
Performance Test 환경구성 (0) | 2024.04.01 |