릴리스의 품질을 향상시키세요

릴리스 비율은 시간 경과에 따른 릴리스 수를 측정합니다. 릴리스 이벤트에는 다음 속성이 포함되어야 합니다.

• 애플리케이션 이름

• 릴리스의 고유 식별자(SHA 서명, 버전 번호 등)

• 추가된 코드 줄 수

• 제거된 코드 줄 수

• 릴리스가 발생한 날짜 및 시간

• 릴리스를 배포한 사용자 또는 프로세스

• 소스 코드 저장소에서 이 릴리스를 가리키는 URL

• 이 릴리스가 새로운 릴리스인지 롤백 버전인지를 나타내는 표시기

  목표: 출시 비율을 높입니다.

  모범 사례:

• 지속적인 개선 프로세스를 사용하여 릴리스 속도를 높이십시오.

• 릴리스 실패의 영향을 줄이기 위해 각 릴리스의 변경 수를 최소화합니다.

• 이 KPI를 비즈니스 영향에 다시 매핑하고 이해 관계자에게 보고합니다.

릴리스 크기/범위는 추가되거나 제거된 코드 줄 수를 측정합니다. 대안으로 변경된 코드 베이스의 백분율을 측정할 수 있습니다.

릴리스 비율 KPI에 정의된 대로 이 KPI를 릴리스 이벤트의 속성으로 포함해야 합니다.

목표: 각 릴리스의 크기/범위를 줄입니다.

모범 사례:

• 릴리스 실패의 영향을 줄이기 위해 각 릴리스의 변경 수를 최소화합니다.
• 이 KPI를 비즈니스 영향에 다시 매핑하고 이해 관계자에게 보고합니다.

앱 응답성 및 오류 KPI는 릴리스의 95번째 백분위수 응답 시간과 오류 볼륨을 측정합니다.

관찰 가능성 계측을 사용하여 애플리케이션의 서비스 경계에서 모든 트랜잭션에 대해 이 KPI를 수집해야 합니다. KPI의 속성에는 최소한 다음이 포함되어야 합니다.

• 트랜잭션 이름 및/또는 URI

• 트랜잭션 시작 벽시계 시간

• 거래 기간

• 요청을 처리한 컴퓨팅 리소스

  목표: 응답 시간을 개선하고 오류를 줄입니다.

  모범 사례:

• 서비스 수준 관리 기술을 사용하여 사용자에게 발생하는 오류가 더 적은 응답성 애플리케이션을 생성합니다.

• 이 KPI를 사용하여 엔지니어링의 성능 향상 노력의 우선 순위를 정하십시오.

• 관찰 가능성 솔루션을 사용하여 병목 현상에 대한 정보를 피드백하고 구성 요소를 개발 팀이 고칠 수 있도록 비난하십시오.

프로덕션 영향은 실패한 릴리스(예: 롤백되거나 배포에 실패한 릴리스)의 수를 측정합니다.

릴리스 비율 KPI에 정의된 대로 이 KPI를 릴리스 이벤트의 속성으로 포함해야 합니다.

목표: 실패한 릴리스의 수를 줄입니다.

모범 사례:

• 프로덕션으로 이동하기 전에 비프로덕션 환경에서 배포를 현실적으로 테스트해야 합니다.
• 실패한 배포에 대해 심층적인 회고를 수행하여 테스트 및 배포 프로세스의 격차를 발견하고 수정할 수 있습니다.

이 KPI는 관측 가능성 계측이 있는 애플리케이션의 백분율을 측정합니다.

목표: 100% 적용

모범 사례:

• 응용 프로그램의 주요 구성 요소에 진단 도구를 추가합니다.
• SLO 달성 실패를 사용하여 진단 프로세스를 구동하여 관찰 가능성 격차를 식별하고 채웁니다.
• 인시던트 회고를 사용하여 관찰 가능성 격차를 식별하고 채웁니다.

지원 티켓 볼륨은 이 릴리스에 대해 열린 지원 티켓 수를 측정합니다. 이것은 선택적 KPI입니다.

이 KPI는 다음 속성이 있는 시간별 또는 일일 지표로 수집해야 합니다.

• 애플리케이션 이름 및 릴리스

• 시간소인

• 심각도에 따라 열린 티켓 수

• 심각도별 평균 마감 시간

  목표: 티켓 수를 줄입니다.

  모범 사례:

• 특정 릴리스에 대해 지원 티켓을 상호 연결할 수 있는지 확인하세요.

• 지원 티켓을 분석하여 발생한 문제의 종류를 이해하고 해당 정보를 사용하여 지속적인 개선을 추진하세요.

이 KPI는 애플리케이션의 호스팅 비용을 측정합니다. 선택적 KPI입니다.

목표: 예측 가능하고 안정적인 비용 모델을 만듭니다.

모범 사례:

• 각 애플리케이션의 호스팅 인프라 비용을 측정합니다.
• 애플리케이션의 성능 대 비용 메트릭을 주기적으로 검토하여 애플리케이션이 기능 및 비즈니스 중요성에 적합한 리소스를 보유하고 있는지 확인하십시오.