코드 커밋 에서 배포 운영까지 CI/CD 프로세스 Data 를 수집및 시각화 방안에 대한 고민이 필요 함.
DORA Metrics
- DORA Metrics (DevOps Research and Assessment) : Google Cloud에서 개발 및 운영 프로세스 측정연구팀에 제공하는 분석 보고서.
소프트웨어 딜리버리 성과를 정량적으로 측정하기 위한 핵심 지표 체계 연구, 검증된 4가지 핵심 지표 정의 ( DORA Four Keys )
1.변경 리드 타임 (Lead time for changes) : 코드 커밋 또는 변경 사항이 성공적으로 프로덕션에 배포되는데 걸리는 시간.
2.배포 빈도 (Deployment Frequency) : 애플리케이션 변경 사항이 프로덕션에 얼마나 자주 배포 되는지를 측정.
3,변경 실패율 (Change Fail Rate) : 프로덕션에 배포된 변경 사항 중 실패를 유발해 핫픽스나 롤백이 필요한 배포의 실패비율.
4.실패한 배포 복구 시간 (Failed Deployment Recovery Time): 프로덕션에서 발생한 실패로부터 복구하는 데 걸리는 시간.
도구 선정
- Dora Metrics 수집과 시각화를 위해 다양한 도구 검토
- 오픈소스 여부 : 비용 최적화 및 커스터마이징 가능성
- 시각화 연동성: Grafana 등 기존 대시보드와의 통합 여부
- 데이터 연동 범위: Github, Jira 등 기존 도구와의 통합 가능성
- 설치/운영 제약 : 클라우드 의존성, 설치 복장도, 유지보수 상태 등
주요 도구 비교 표
위 결과를 바탕으로 Apache DevLake 구성을 추천 함.
DevLake 구성
- DevLake는 다양한 DevOps 도구로부터 데이터를 수집하고 정제한뒤, 이를 시각화하여 인사이트를 제공 하는 오픈소스 플랫폼 입니다.
-
대시보드 (적용 예시 )
-
커밋, PR 사이클 통계
- PR 리뷰 받는데 걸리는 시간, 병합 후 배포까지 걸리는 시간에 대한 PR사이클을 볼수 있는 대시보드.
PR의 크기, PR당 코멘트 개수에 대한 추이
적용시 생각해볼 문제들.
장애 시간 정의
- GitHub 배포 시점은 실제 배포 완료 시점이 아니다.
- 배포 환경에서 GitHub 을 통한 tag 수정 후, ArgoCD를 통해 최종 배포되기 때문에 실제 배포 완료 시점과 시간 차이가 존재.
- 배포 시점을 복구 시작 시점으로 삼기 어렵다.
- 배포 이후 서비스는 정상적으로 운영되는 것처럼 보이다가, 특정 사용자 시나리오나 특정 API 호출, 특정 조건에서만 문제가 발생하는 경우가 존재.
- incident 이슈 생성 부분에 대해서는 좀더 논의가 필요!!
Incident 이슈 생성 관련 살펴볼 부분.
배포된 서비스 모듈기준으로 이슈 생성이 가능 한가?
Github repository 기준으로 label 정의 필요.
배포관련 장애에 대한 label 정의 필요.
레퍼런스
[번역] DORA 지표(DORA Metrics)를 계산하는 방법 - fromundefined by Tony
Sleuth | Align business and engineering
