DevOps 지표 - 계산을 위한 데이터를 얻을 수 있는 위치

솔직히 말해서 Ivan은 모니터링 부서 동료들의 헛된 노력을 자주 비웃었습니다. 그들은 회사 경영진이 달성하도록 지시한 측정 기준을 구현하기 위해 많은 노력을 기울였습니다. 그들은 너무 바빠서 다른 사람이 아무것도 하기를 원하지 않았습니다.

그러나 경영진에게는 그것만으로는 충분하지 않았습니다. 그들은 지속적으로 점점 더 많은 새로운 측정 항목을 주문했으며 이전에 수행된 작업을 매우 빠르게 사용을 중단했습니다.

최근에는 비즈니스 기능을 제공하는 시간인 LeadTime에 대해 모두가 이야기하고 있습니다. 측정항목은 하나의 작업을 전달하는 데 200일이라는 말도 안되는 숫자를 보여주었습니다. 모두가 얼마나 기뻐하고 아아하며 손을 하늘로 들었습니까!

얼마 후 소음은 점차 줄어들었고 경영진은 또 다른 지표를 만들라는 명령을 받았습니다.

Ivan에게는 새로운 지표가 어두운 구석에서 조용히 사라질 것이라는 것이 완전히 분명했습니다.

사실 이반은 그 숫자를 아는 것이 누구에게도 아무 것도 알려주지 않는다고 생각했다. 200일이든 2일이든 숫자로 이유를 판단하고 좋은지 나쁜지 파악하는 것이 불가능하기 때문에 차이가 없습니다.

이것은 전형적인 측정법의 함정입니다. 새로운 측정법은 존재의 본질을 알려주고 비밀스러운 비밀을 설명하는 것 같습니다. 모두가 이것을 너무나 바라고 있지만 어떤 이유로 아무 일도 일어나지 않습니다. 예, 그 비밀은 메트릭에서 발견되어서는 안 되기 때문입니다!

Ivan에게 이것은 통과된 단계였습니다. 그는 그것을 이해했다 측정항목은 평범한 나무 눈금자일 뿐입니다 측정을 위해서는 모든 비밀을 찾아야 합니다. 영향의 대상, 즉. 이 측정항목이 형성된다는 것입니다.

온라인 상점의 경우 영향을 받는 대상은 돈을 버는 클라이언트가 될 것이고, DevOps의 경우 파이프라인을 사용하여 배포판을 만들고 출시하는 팀이 될 것입니다.

어느 날 Ivan은 홀의 편안한 의자에 앉아 영향을 받는 대상이 팀이라는 사실을 고려하여 DevOps 측정 항목을 어떻게 보고 싶은지 신중하게 생각하기로 결정했습니다.

DevOps 지표의 목적

모든 사람이 배송 시간을 단축하고 싶어하는 것은 분명합니다. 200일은 물론 좋지 않습니다.

하지만 그게 어떻게 문제인가요?

회사는 수백 개의 팀을 고용하고 있으며 매일 수천 개의 배포판이 DevOps 파이프라인을 통과합니다. 실제 배송시간은 분포로 나타납니다. 각 팀에는 고유한 시간과 특성이 있습니다. 이 혼란 속에서 어떻게 뭔가를 찾을 수 있습니까?

대답은 자연스럽게 나왔습니다. 문제가 있는 팀을 찾아 그들에게 무슨 일이 일어나고 있고 왜 그렇게 오래 걸리는지 파악하고, "좋은" 팀으로부터 모든 것을 신속하게 수행하는 방법을 배워야 합니다. 이를 위해서는 각 DevOps 스탠드에서 팀이 소요한 시간을 측정해야 합니다.

“시스템의 목적은 스탠드를 통과하는 시간을 기준으로 팀을 선택하는 것입니다. 결과적으로 숫자가 아닌 선택한 시간이 포함된 명령 목록을 얻어야 합니다.

스탠드에서 소요된 총 시간과 스탠드 간 가동 중지 시간에 소요된 시간을 알아내면 팀을 찾아 전화를 걸어 이유를 더 자세히 파악하고 제거할 수 있습니다.”라고 Ivan은 생각했습니다.

DevOps의 제공 시간을 계산하는 방법

이를 계산하려면 DevOps 프로세스와 그 본질을 탐구해야 했습니다.

회사는 제한된 수의 시스템을 사용하며 정보는 해당 시스템에서만 얻을 수 있으며 다른 곳에서는 얻을 수 없습니다.

회사의 모든 업무는 Jira에 등록되었습니다. 작업이 수행되면 해당 작업에 대한 분기가 생성되고 구현 후 BitBucket 및 Pull Request에 대한 커밋이 이루어집니다. PR(Pull Request)이 수락되면 배포판이 자동으로 생성되어 Nexus 저장소에 저장됩니다.

다음으로 배포판은 Jenkins를 사용하여 여러 스탠드에 배포되어 배포의 정확성, 자동 및 수동 테스트를 확인했습니다.

Ivan은 스탠드에서의 시간을 계산하기 위해 어떤 정보를 가져올 수 있는지 설명했습니다.

• Nexus에서 - 배포판 생성 시간 및 명령 코드가 포함된 폴더 이름
• Jenkins에서 – 각 작업의 시작 시간, 기간 및 결과, 스탠드 이름(작업 매개변수), 단계(작업 단계), Nexus의 배포 링크.
• Ivan은 Jira와 BitBucket을 파이프라인에 포함하지 않기로 결정했습니다. 왜냐하면... 이는 완성된 배포판을 스탠드에 출시하는 것이 아니라 개발 단계와 더 관련이 있습니다.

이용 가능한 정보를 바탕으로 다음 다이어그램이 그려졌습니다.

배포판을 생성하는 데 걸리는 시간과 각 배포판에 소요되는 시간을 알면 전체 DevOps 파이프라인(전체 주기)을 통과하는 데 드는 총 비용을 쉽게 계산할 수 있습니다.

Ivan이 최종적으로 얻은 DevOps 측정항목은 다음과 같습니다.

• 생성된 배포 수
• 스탠드에 "와서" 스탠드를 "통과"한 배포 비율
• 스탠드에서 보낸 시간(스탠드 사이클)
• 전체 주기(모든 스탠드의 총 시간)
• 작업 기간
• 스탠드 간 가동 중지 시간
• 동일한 스탠드에서 작업 실행 사이의 가동 중지 시간

한편으로는 시간 측면에서 DevOps 파이프라인을 매우 잘 특성화하는 측정항목이 있는 반면, 다른 한편으로는 매우 단순한 것으로 간주되었습니다.

잘 수행된 작업에 만족한 Ivan은 프레젠테이션을 작성하여 경영진에게 발표했습니다.

그는 우울한 표정으로 손을 내리고 돌아왔습니다.

아이러니한 동료는 "이건 대실패다"라고 웃었다.

기사에서 더 자세히 읽어보세요.빠른 결과가 Ivan에게 얼마나 도움이 되었는가".

출처 : habr.com