Close

DevOps 지표

DevOps에서 성공을 측정하는 이유, 내용 및 방법

TOM HALL

DevOps 애드보케이트 및 실행자


측정할 수 없는 것이라면 개선할 수 없다는 예전의 명언은 다른 관행과 마찬가지로 DevOps에도 해당됩니다. 더 높은 품질의 제품을 더 빠르게 출시한다는 DevOps의 약속을 이행하려면 팀은 수많은 메트릭을 수집, 분석 및 측정해야 합니다. 이러한 DevOps 메트릭은 DevOps 팀이 개발 파이프라인에 대한 가시성과 제어를 확보하는 데 필요한 데이터를 제공합니다.

DevOps 메트릭이란 무엇입니까?


DevOps 메트릭은 DevOps 소프트웨어 개발 파이프라인의 성과를 직접 드러내고 프로세스의 병목 현상을 빠르게 식별하여 제거하는 데 도움이 되는 데이터 포인트입니다. 이러한 메트릭은 기술 역량과 팀 프로세스를 추적하는 데 사용할 수 있습니다.

DevOps는 개발팀과 운영팀 간의 경계를 흐리게 만들어 개발자와 시스템 관리자 간의 협업을 강화하는 데 중점을 둡니다. 메트릭을 사용하면 DevOps 팀은 협업 워크플로를 측정 및 평가하고 품질 향상, 릴리스 주기 단축, 애플리케이션 성능 개선 등 주요 목표의 진행 상황을 추적할 수 있습니다.

4가지 핵심 DevOps 메트릭


DevOps 성능을 측정하는 데 사용되는 메트릭은 여러 가지가 있지만 모든 DevOps 팀이 측정해야 하는 4가지 주요 메트릭은 다음과 같습니다.

1. 변경의 리드 타임

추적해야 하는 중요한 DevOps 메트릭 중 하나는 변경의 리드 타임입니다. 사이클 타임(아래에서 설명)과 혼동될 수도 있는 변경의 리드 타임은 코드 변경이 트렁크 브랜치에 커밋되는 시점부터 배포 가능 상태가 되기까지의 시간입니다. 예를 들어, 코드가 필수 사전 릴리스 테스트를 모두 통과한 경우입니다.

2. 변경 실패율

변경 실패율은 프로덕션 후 긴급 수정 또는 기타 수정이 필요한 코드 변경에 대한 비율을 나타냅니다. 테스트에서 발견되어 코드 배포 전에 수정된 오류는 측정하지 않습니다.

3. 배포 빈도

새로운 코드를 프로덕션에 배포하는 빈도를 이해하는 것은 DevOps 성공을 이해하는 데 매우 중요합니다. 많은 실행자는 사전 프로덕션 스테이징 환경에 릴리스되는 코드 변경 사항을 의미할 때 “제공”이라는 용어를 사용하며, “배포”라는 용어는 프로덕션으로 릴리스되는 코드 변경을 의미할 때 사용합니다.

4. 평균 복구 시간

MTTR(평균 복구 시간)은 부분적인 서비스 중단 또는 전체 장애로부터 복구하는 데 걸리는 시간을 측정합니다. 이것은 중단이 최근 배포로 인한 것인지 또는 격리된 시스템 장애로 인한 것인지 여부와 관계없이 추적해야 하는 중요한 메트릭입니다.

솔루션 보기

최고 수준의 DevOps 팀을 위한 도구

관련 자료

DevOps에서 팀 구조의 중요성

DevOps 메트릭을 측정, 사용 및 개선하는 방법


DevOps 수명 주기의 다른 요소와 마찬가지로, 지속적인 개선 문화는 DevOps 메트릭에 적용됩니다. 개발의 각 단계에서 빠른 피드백을 받을 수 있는 능력과 피드백을 구현하는 기술 및 권한은 성과가 높은 팀의 대표적인 특징입니다. DevOps 책 “Accelerate”에서, 저자들은 위에 나열된 4가지 핵심 메트릭은 높은 능력을 가진 소프트웨어 팀이 채택한 24가지 기능으로 뒷받침된다는 점에 주목합니다. 아래에 나와 있는 대부분의 기능(CI/CD, 테스트 자동화, 소규모 배치의 작업, 모니터링 및 지속적인 학습)은 여기서 다루지만, 이러한 관행을 뒷받침하는 연구에 대해 자세히 알아보려면 “Accelerate”를 읽어보는 것도 좋습니다.

변경의 리드 타임

중간에서 낮은 수준의 성과를 내는 팀은 보통 일, 주 또는 심지어는 월 단위로 리드 타임을 측정하는 데 비해, 성과가 높은 팀은 리드 타임을 시간 단위로 측정합니다.

테스트 자동화, 트렁크 기반 개발 및 소규모 배치의 작업은 리드 타임를 개선하는 핵심 요소입니다. 이러한 관행을 통해, 개발자는 자신이 커밋한 코드의 품질에 대한 피드백을 빠르게 받아 결함을 찾고 수정할 수 있습니다. 개발자가 별도의 브랜치에서 대규모 변경 작업을 수행하며 품질 관리를 위해 수동 테스트를 사용하는 경우, 리드 타임이 길어질 수 있습니다.

변경 실패율

성과가 높은 팀의 변경 실패율은 0~15% 범위 안에 있습니다.

테스트 자동화, 트렁크 기반 개발, 소규모 배치의 작업과 같은 리드 타임을 단축하는 관행은 변경 실패율 감소와 상관 관계가 있습니다. 이러한 모든 관행을 통해 결함을 훨씬 쉽게 식별하고 수정할 수 있습니다.

변경 실패율에 대한 추적 및 보고는 버그를 식별하고 수정하는 데 중요할 뿐만 아니라 새로운 코드 릴리스가 보안 요구 사항을 충족하는지 확인하는 데 중요합니다.

배포 빈도

성과가 높은 팀은 필요에 따라 변경 사항을 배포할 수 있으며, 하루에 여러 번 배포하는 경우도 많습니다. 성과가 낮은 팀은 한 주 또는 한 달에 한 번 배포하는 데 그치는 경우가 많습니다.

온디맨드 방식으로 배포하려면 이전 섹션에서 참조한 자동화된 테스트 및 피드백 메커니즘을 포함하고 사람의 개입을 최소화하는 자동화된 배포 파이프라인이 필요합니다.

평균 복구 시간

성과가 높은 팀은 시스템 장애로부터 신속하게(일반적으로 1시간 이내) 복구할 수 있지만, 성과가 낮은 팀은 장애를 복구하는 데 일주일까지도 걸릴 수 있습니다.

장애 발생 시 신속하게 복구할 수 있는 능력은 장애 발생 시점을 신속하게 파악하고 수정 사항을 배포하거나 실패로 이어지는 변경 사항을 롤백하는 능력에 따라 달라집니다. 일반적으로 시스템 상태를 지속적으로 모니터링하고 장애 발생 시 운영 담당자에게 알리는 방식으로 이루어집니다. 운영 담당자는 인시던트 해결에 필요한 프로세스, 도구 및 권한을 가지고 있어야 합니다.

평균 장애 간격(MTBF)에 초점을 맞추던 과거의 관행에서 벗어나 이제는 MTTR에 더 중점을 두어야 합니다. 이것은 최신 애플리케이션의 높아진 복잡성과 이에 따라 높아진 장애 발생 확률을 반영합니다. 또한 지속적인 학습 및 개선의 관행을 강화합니다. 장애를 피하기 위해 배포가 “완벽”해질 때까지 기다리는 대신(이전의 MTBF 스코어보드를 초기화), 팀은 지속적으로 배포합니다. “완벽한” MTBF 기록을 망쳤다고 비난하기보다는, MTTR은 비난을 배제하고 팀이 업스트림 프로세스와 도구를 개선할 수 있도록 지원합니다.

기타 관련 메트릭


또 다른 관련 메트릭은 제공할 준비가 되기까지 팀에서 어떤 항목에 작업하는 시간을 나타내는 사이클 타임입니다. 개발의 세계에서 사이클 타임이란 개발자가 커밋을 한 시점부터 프로덕션에 배포되는 시점까지의 시간입니다. 이 주요 DevOps 메트릭은 프로젝트 리더 및 엔지니어링 관리자가 개발 파이프라인에서 어떤 것이 효과적인지 더 잘 이해하는 데 도움이 됩니다. 그 결과로, 작업을 이해 관계자 및 고객의 기대치에 더 잘 맞게 정렬하여 팀이 더 빠르게 출시하도록 보장할 수 있습니다.

사이클 타임 보고서를 사용하면 프로젝트 리더는 향후 프로세스를 평가하는 데 사용할 수 있는 개발 파이프라인 기준을 설정할 수 있습니다. 팀이 사이클 타임을 최적화하면 개발자는 일반적으로 진행 중인 작업이 적어지고 비효율적인 워크플로도 줄어듭니다.

린 제품 관리에서는 제품 또는 기능 개념에서 제공까지의 흐름을 시각화하는 가치 흐름 매핑에 중점을 둡니다. DevOps 메트릭은 효과적인 가치 흐름 매핑 및 관리를 위한 필수 데이터 포인트를 많이 제공하지만 진정한 엔드투엔드 평가를 위해 다른 비즈니스 및 제품 메트릭과 함께 사용해야 합니다. 예를 들어, 스프린트 번다운 차트 차트는 추정 및 계획 프로세스의 효과에 대한 통찰력을 제공하고, 순 추천 고객 점수는 최종 결과물이 고객의 요구를 충족하는지 여부를 나타냅니다.

결론...


지속적인 개선은 DevOps를 실천하는 팀의 핵심 신조입니다. 변경의 리드 타임, 변경 실패율, 배포 빈도 및 MTTR의 성과를 측정하고 추적하는 능력을 통해, 팀은 속도와 품질을 높일 수 있습니다.

Atlassian의 Open DevOps는 팀이 소프트웨어를 개발 및 운영하는 데 필요한 모든 것을 제공합니다. 팀은 선두 공급업체 및 Marketplace 앱과의 통합으로 원하는 DevOps 도구 체인을 구축할 수 있습니다. 지금 사용해 보세요.

Tom Hall
Tom Hall

Tom Hall은 DevOps 애드보케이트이며 실행자이며, 열렬한 독서가이며, 아마추어 피아니스트입니다.
지난 20년 동안의 업적에는 Novell, EMC, VMware 및 AWS의 인증이 포함됩니다. 그는 2016년에 애틀랜타에서, 그 이후로는 텍사스 오스틴에서 DevOpsDays를 조직했습니다.


이 문서 공유
다음 토픽

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

DevOps 학습 경로

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up