DevOps를 측정하는 데 어떤 핵심 성과 지표 (KPI)가 사용됩니까?

DevOps 변환 프로그램 내에서 올바른 행동을 유도하려고 노력하고 있으며이를 지원하기 위해 운영 분야에 대한 실행 가능한 메트릭을 식별하려고합니다.

• 문제 및 사고 관리
• 용량 관리
• 변경 및 릴리스 관리

명확하게 말하면, 이들은 운영 조직에 속해 있었고 현재 Agile / DevOps 조직이 소유 한 기능입니다. 잘못된 동작을 유발하는 기존 KPI는 다음과 같습니다.

• 근본 원인 분석 완료 :
  • 불완전한 RCA를 적시에 시스템으로 가져 오도록합니다.
• 테스트 실행 기간 :
  • 비즈니스 가치에 관계없이 장기 실행 테스트를 비활성화합니다.
• 클라우드 서비스의 평균 활용도 :
  • 컴퓨팅 리소스를 과도하게 커밋하여 응답 시간이 느려집니다.

DevOps 프로그램에서 좋은 행동을 장려하기 위해 어떤 핵심 성과 지표를 사용할 수 있습니까?

"유니버설"DevOps KPI가 없다고 생각합니다. 예를 들어, 비즈니스의 핵심 동인이 아닌 한 속도는 훌륭합니다. 아마존은 대규모 소매업이 있기 때문에 속도에 대해 많은 관심을 가지고 있습니다. 사용자가 100 명인 작은 앱에는 그다지 중요하지 않습니다.

어떻게이 질문 구걸 하면 관련 최선의 KPI를 선택 하여 사업을? 그것은 전체 엔터프라이즈를 포함하는 연구 및 발견 프로세스입니다.

무엇에 관심이 있습니까?

• 품질
• 신뢰할 수 있음
• 유지 보수성
• 속도
• 프로세스 개선
• 서비스 수준

밤에 비즈니스 이해 관계자를 유지하는 것은 무엇입니까? 이번 분기에 돈을 버는 지 여부는 어떻게 결정됩니까? 위의 목록에는 그러한 것들 중 일부가 포함되거나 그렇지 않을 수 있습니다. 목록을 작성한 다음 모든 부서 에서 인센티브를 조정 하여 달성 할 수있는 방법을 찾으십시오 .

인센티브는 행동을 유발하므로 SMART 목표에 대해 공동으로 결정하십시오. 브레인 스토밍 목록에서 2 ~ 3 개의 항목을 선택하고 각각에 대해 측정 / 수정 피드백주기를 시작하십시오. 한 번에 너무 많이 선택하지 마십시오. 두세 가지에 집중하면 성공할 가능성이 높아집니다.

DevOps 에는 KPI 가 없습니다 . 그것은 사랑의 KPI가 무엇인지 묻는 것과 같습니다. 그러나 언급 한 문제 ( 문제 및 사고 관리 , 용량 관리 , 변경 및 릴리스 관리 ) 중 일부는 KPI가 우수하며 일부는 DevOps의 이론을 기반으로합니다.

일반적으로 모든 비즈니스 프로세스에 대해 고객 을 통해 기업을 통해 고객 에게 다시 가치가 전달되는 방식을 설명하는 Value Chain Map을 만들 수 있습니다 . 전체 루프는 항상 고객으로 시작하고 끝나야하지만 때로는 서비스 조직의 경우 고객이 내부에있을 수 있습니다. 값의 처리량 과 같은 체인을 통해이 변조 방지 방식으로 KPI를 설계하는 좋은 방법이 될 수 있습니다. 특정 링크가 프로세스 의 병목 현상 이고 병목 현상 을 악용하거나 높이려는 경우에만 가치 사슬의 개별 링크에서 KPI를 측정하는 것이 좋습니다.

KPI의 일반적인 문제는 체인 중간에서 시작될 때입니다. 예를 들어 변경 및 릴리스 프로세스는 종종 개발자로 시작하여 배포로 끝납니다. 이 프로세스는 제외되었습니다.

• 문제가있는 고객
• 문제를 식별하는 지원 팀
• 백 로그 문제를 정의하는 제품 팀
• 고객 배치를 사용자 정의하는 솔루션 팀
• 솔루션에서 가치를 실현하는 고객

문제는 사이클 시간 만 측정하면 두 가지 주요 문제가 발생할 수 있다는 것입니다.

1. 병목 현상은 위에서 언급 한 제외 된 부분에 있으며 고객이 가치를 실현하지 못하고 사이클 시간 속도에 비례하여 수익을 실현하지 못하고 있습니다. 따라서 엔지니어링은 우수하지만 비즈니스는 어려움을 겪습니다.

2. 고객과의 연결이 끊어지면 변경주기에도 불구하고 가치를 창출하지 못하고 릴리스 요구 사항이 빈 상태로 돌아가거나 고객의 요구에 부응하며 수행중인 작업에 부정적인 비즈니스 가치가있을 수 있습니다.

KPI의 또 다른 문제점은 고객을 시작하고 종료하는 동안 실제로 고객의 가치를 측정하지 못할 수 있다는 것입니다. KPI로서 문제 및 사고 대응 프로세스와 MTTR (Mean Time To Repair)이 좋은 예입니다. 문제가 누구에게도 영향을 미칩니 까? 고객에게 어떤 가치가 있습니까? 100 건의 사건에서 3 시간의 우수한 MTTR을 가질 수 있습니다. 그러나 대부분의 고객이 내부에 있거나 거의 영향을 미치지 않고 몇 분만에 해결 된 경우 고객에게 큰 영향을 미치는 대규모 사건이 처리하는 데 3 일이 걸리지 만 MTTR이 1 일인 경우보다 비즈니스 가치가 낮습니다. 대부분의 내부 사고는 무시하지만 1 시간 내에 고객에 대한 큰 영향 사고에 응답했습니다.

참고 : 내부 고객의 경우 지원 팀 비즈니스 프로세스의 경우 파생 값은 내부 고객의 작업 가치가 아니라 자체 비즈니스 프로세스에서 내부 고객을 차단 해제함으로써 비즈니스가 얻는 가치입니다. 자체 프로세스에서 병목 현상이 발생한 팀을 차단 해제하면 병목 현상이없는 팀 또는 개인을 차단 해제하는 것보다 더 높은 가치가 도출됩니다. 이러한 지원 팀의 모든 KPI는 비즈니스 가치를 계산에 포함시켜야합니다.

1. 배포 빈도
2. 배포 속도
3. 배포 성공률
4. 배포 실패 후 서비스를 얼마나 빨리 복원 할 수 있으며
   마지막으로
5. 실제로 측정 할 수없는 DevOps Culture