DevOps의 ROI를 측정하는 몇 가지 방법은 무엇입니까?

DevOps는 복잡하며 문화 및 프로세스와 같은 많은 비 결정적 측면을 포함합니다.
성공을 위해 DevOps 이니셔티브를 측정하는 몇 가지 방법은 무엇입니까?
그들이 투자 한 금액이 실제 달러를 반환 (또는 절약)하고 있다는 것을 어떻게 비즈니스에 증명합니까?

좋은 질문입니다! 우리 대부분은 DevOps 관행에 투자하는 것이 무수한 이유 때문에 가치있는 일이라는 것을 알고 있습니다. 우리는 종종 결론에만 영향을 미치는 데 DevOps를 정당화하지 않습니다.

참고 : 이것은 의견이 많은 질문이며 내 대답도 마찬가지로 의견이 있습니다.

Tensibai는 현명하게 우리가 올바른 지표를 찾도록 제안했으며, 시장 출시 시간을 예로 들었습니다. 이것은 큰 사진 접근 방식입니다.

다른 접근법으로서, 콩 카운터에 대한 나의 경험은 그들이 큰 그림을 알 필요가없고, 반드시 알고 싶어 할뿐 아니라 재정 책임의 증거를 원한다는 것입니다. 그들은 올바른 방향으로 트렌드를보고 싶어합니다.

다음은 몇 가지 재정적 인 승리입니다.

• 클라우드에서 자동 확장 을 활용하여 절감 된 서버 비용 계산
• 수입 사이트의 경우 다운 타임 분당 비용을 추정 한 다음 MTTI 및 MTTR의 개선 사항을 보여줍니다
• 다시 한 번 소득 창출 사이트의 경우 과거 사건을 기반으로 고 가용성 아키텍처를 활용하여 절감 된 분당 비용을 추정하십시오.
• 빌드 및 배포 파이프 라인을 개선 한 경우 이미 추적 된 결함으로 인한 프로덕션의 회귀 및 오류를 줄였습니다.
• 개발자 테스트 환경 또는 개발자 랩톱의 도구 및 구성을 개선 한 경우 새로운 엔지니어가 참여한 후 더 빨리 첫 번째 기여를하고 있는지 확인하기 위해 기록을 확인하십시오.
• Gitlab이 최근 에 했던 것처럼 클라우드와 온 프레미스 의 전체 비용 비교를 수행 하여 인프라 지출 (일명 저축)을 정당화하십시오.

돈을 의식하고 몇 가지 분명한 승리를 거두는 것으로 충분합니다. 분명히 몇 가지 명백한 예를 놓쳤습니다. 아래에 의견을 추가하십시오.

DevOps 파이프 라인의 주요 지표는 주기 시간 ( 리드 타임 이라고도 함 )입니다. 변경 (또는 아이디어가 시작될 때까지 추적하는 변경 요청)에 걸리는 시간입니다. 내가 아는이 개념의 가장 좋은 예는 "The Goal"이라는 책에서 나온 것입니다.

배포 빈도 도 유용합니다. 우리는 DevOps 파이프 라인에서 배포를 자주하고 싶습니다. "1 일이 좋고 2 일이 나쁘다"라는 마법은 없습니다. 이것은 의미있는 프로젝트의 역사적 맥락이 필요합니다.

배포 크기 : 개발자가 사용자 스토리, 스토리 포인트, 쿼터 등의 작업을 측정합니다. 다시, 당신은 절대 가치가 아니라 시간이 지남에 따라 추세를보고 싶습니다.

빈도와 규모 사이에 이야기가 있습니다. 릴리스가 점점 더 드물어지고 있습니까? 왜? 점점 작아지고 있습니까? 또 왜?

빈도 / 크기 추세가 양호한 지 설명하기 위해 실패한 배포 백분율 도 필요합니다 . 이 세 가지 메트릭에서 '이유'를 발견하면 프로젝트의 건강에 대해 많은 것을 알 수 있습니다.

내가 개인적으로 가장 좋아하는 것은 허영 측정법이지만 시간이 부족 합니다. 전체 사이트를 다시 배포 할 가치가있는 가장 작은 것을 발견 한 경우 아마도 CEO 이름의 오타가있을 것입니다 ... 얼마나 빨리 공황 전화에서 배포 된 사이트로 갈 수 있습니까? 위의 다른 메트릭스가 설명하는 것 이상으로 실제로 예측할 수는 없지만 가치를 좋아할 때 기분이 좋아지기 때문에 '허영'이라고 말합니다.

모니터링에 들어가면 ' 가동 시간 ' 과 같은 모든 것을 포괄하는 것에서부터 요청-응답주기에 사용자 정의 HTML 을 재생성 하는 데 소요 되는 시간 과 같은 저수준의 것들에 이르기까지 추적 할 수있는 여러 가지가 있습니다 ... 그러나 이들은 DevOps 문화를 구성하는 데 특정 적이 지 않습니다.

이것들은 달러와 직접 관련이 없습니다. 그렇게하기 위해서는 제가 이런 포럼에서 제공 할 수있는 것보다 조직에 대한 더 많은 지식이 필요합니다. 그러나 그들은 그 질문에 답하기 위해 BEGIN의 열쇠입니다. 이벤트가 아닌 작업으로 정기적으로 작업을 릴리스 할 수 있다는 것을 알고 나면 이전에 얼마나 많은 노력을 낭비했는지 알 수 있습니다. "목표"라는 책에서 알 수 있듯이 (파이프 라인 제조 관련 사항), 로컬 최적화 는 비용을 절약하는 것처럼 보일 수 있지만 궁극적으로 인벤토리에 묶여있는 가치 (배치되지 않은 기능)를 만듭니다.

이 조언 외에도 지난 몇 년간 DevOps 보고서 를 살펴보아야합니다 . 에뮬레이션 할 수있는 실제 프로젝트에 대한 측정 값이 가득합니다.

캡틴 명백 : 출시 시간과 출시 결함을 줄임으로써.

이 하나의 라이너를 확장하기 위해 일반적인 함정은 참조없이 조직을 변경하는 것입니다.

문화 나 조직의 변화를 유도하면 사람들에게이 새로운 방법을 교육하고 소개하는 데 약간의 비용이 들게되는데, 이는 훈련 비용이 들지만 훈련 시간에 사람들이 아무 것도 생산하지 않기 때문에 생산성 손실을 의미합니다. 이것은 문화 변화의 투자 부분입니다.

ROI를 측정하려면 먼저 개선해야하는 관련 메트릭을 찾아야합니다 (비용이 많이 들거나 비용이 많이 드는 수익원 이해). 출시 기간이 단축되고 각 릴리스 후 패치가 줄어들어 제품 내 고객 참여가 향상 될 수 있습니다. 관련 측정 항목은 제품에 따라 크게 달라집니다.

ROI (교육 비용을 얼마나 빨리 충당했는지)를 측정한다는 것은 실제로 이러한 메트릭스에 대한 발전을 제시 할 수 있음을 의미하므로 변경에 참여하기 전에 해당 메트릭을 정의하고 객관적인 방식으로 측정해야합니다.
당신이 보여줄 진정한 진화가 이루어지면 훈련 비용을 충당하고 이전보다 더 수익성이 높은 방식으로 무언가를 개선했는지 알 수 있습니다.

일반적인 함정은 메트릭을 정의하기 전에 변경 사항을 적용하여 사실 데이터가 아닌 느낌에 대한 ROI를 평가하는 것입니다.

생산성은 메트릭이 될 수 있지만 측정은 일반적으로 객관적인 방식으로 수행하기가 매우 어렵 기 때문에 이러한 종류의 연구에서는 일류 메트릭이 아니어야합니다.

여기 게임에 늦었지만 차임 할 줄 알았습니다.

측정하지 않은 것을 관리 할 수 ​​없으므로 초보자를 위해 팀이 사고 대응을 위해 추적해야하는 주요 지표는 다음과 같습니다.

• 가동 시간 % : 사용 가능한 총 시간 % = [총 시간-가동 중지 시간] / [총 시간]
• MTTR : 평균 해결 시간 = [다운 타임] / [인시던트 #]
• MTTA : 평균 확인 시간 = [확인하는 총 시간] / [사고 횟수]
• MTBF : 평균 실패 시간 = [총 시간-다운 타임] / [사고 횟수]

이러한 측정 항목을 통해 운영 상태를 한눈에 확인할 수 있으며 더 자세히 조사해야 할 곳을 식별 할 수 있습니다.

이 주제에 대한 심층적 인 내용을 보려면 여기 에서 화이트 보드 애니메이션을보십시오 .

측정 항목을 알고 나면 가동 중지 비용과 비교할 수 있습니다 . 거기에서 팀의 ROI를 구축하기 시작하고 지속적인 개선을위한 정량적 지표를 설정할 수 있습니다.