Ivan이 DevOps 측정항목을 수행한 방법. 영향의 대상

Ivan이 처음 DevOps 지표에 대해 생각하고 이들의 도움으로 제품 배송 시간을 관리해야 한다는 것을 깨달은 지 일주일이 지났습니다. (시장 출시 시간).

주말에도 그는 측정 항목에 대해 생각했습니다. “그럼 시간을 측정하면 어떨까요? 나에게 무엇을 줄 것인가?

실제로 시간에 대한 지식은 무엇을 줄 것입니까? 배송은 5일 걸린다고 합시다. 그럼 다음은 무엇입니까? 좋은가요, 나쁜가요? 이것이 나쁘더라도 어떻게든 이 시간을 줄여야 합니다. 하지만 어떻게?
이런 생각이 그를 괴롭혔지만 아무런 해결책도 나오지 않았습니다.

Ivan은 자신이 본질에 이르렀다는 것을 이해했습니다. 그가 이전에 본 셀 수 없이 많은 측정항목 그래프는 표준 접근 방식이 작동하지 않을 것이며 단순히 그래프를 그리면 (그것이 집단이라 할지라도), 아무 소용이 없을 것입니다.

어떻게 될 것인가?…

미터법은 일반적인 나무 눈금자와 같습니다. 도움을 받아 측정한 결과는 이유를 알 수 없습니다. 이유 측정되는 물체의 길이는 정확히 그녀가 보여준 길이입니다. 눈금자는 크기만 표시할 뿐 그 이상은 표시하지 않습니다. 그녀는 철학자의 돌이 아니라 단순히 측정할 나무 판자일 뿐입니다.

자신이 가장 좋아하는 작가 해리 해리슨의 "스테인리스 강철 쥐"는 항상 다음과 같이 말했습니다. 생각은 뇌의 바닥까지 도달하여 거기에 놓여 있어야 합니다. 그래서 며칠 동안 고통을 겪어도 아무 소용이 없자 Ivan은 다른 일을 시작하기로 결정했습니다...

며칠 후 Ivan은 온라인 상점에 대한 기사를 읽다가 갑자기 온라인 상점이받는 금액이 사이트 방문자의 행동에 따라 다르다는 것을 깨달았습니다. 매장에 돈을 주고 그 원천이 되는 것은 바로 방문자/고객입니다. 매장이 받는 현금의 수익은 다른 어떤 것도 아닌 고객 행동의 변화에 ​​의해 영향을 받습니다.

측정된 값을 변경하려면 이 값을 형성하는 사람들에게 영향을 미치는 것이 필요하다는 것이 밝혀졌습니다. 온라인 상점의 금액을 변경하려면 이 상점의 고객 행동에 영향을 미칠 필요가 있었고, DevOps에서 배송 시간을 변경하려면 이번에 "창조"하는 팀, 즉 업무에 DevOps를 사용합니다.

Ivan은 DevOps 측정항목이 그래프로 표시되어서는 안 된다는 것을 깨달았습니다. 그들은 스스로를 대표해야 한다 검색 도구 최종 배송 시간을 결정하는 "뛰어난" 팀.

이 팀이나 저 팀이 배포판을 전달하는 데 오랜 시간이 걸린 이유를 어떤 지표로도 보여줄 수 없다고 Ivan은 생각했습니다. 왜냐하면 실제로는 수백만 개의 작은 카트가 있을 수 있고 기술적인 것이 아니라 조직적인 것일 수 있기 때문입니다. 저것들. 측정항목에서 얻을 수 있는 가장 큰 것은 팀과 그 결과를 보여주는 것입니다. 그런 다음 여전히 이 팀을 직접 따라가며 무엇이 문제인지 알아내야 합니다.

반면 Ivan의 회사에는 모든 팀이 여러 벤치에서 어셈블리를 테스트하도록 요구하는 표준이 있었습니다. 팀은 이전 스탠드가 완료될 때까지 다음 스탠드로 이동할 수 없었습니다. DevOps 프로세스를 일련의 스탠드 통과로 상상하면 측정항목을 통해 팀이 이러한 스탠드에서 보낸 시간을 보여줄 수 있다는 것이 밝혀졌습니다. 팀의 입장과 시간을 알면 그 이유에 대해 좀 더 구체적으로 이야기할 수 있었다.

주저하지 않고 Ivan은 전화를 들고 DevOps의 모든 것을 잘 알고 있는 사람의 전화번호로 전화를 걸었습니다.

— 데니스, 팀이 이 입장 또는 저 입장을 통과했다는 것을 어떻게든 이해할 수 있습니까?
- 틀림없이. Jenkins는 빌드가 벤치에서 성공적으로 롤아웃(테스트 통과)되면 플래그를 삭제합니다.
- 슈퍼. 플래그란 무엇입니까?
- "stand_OK" 또는 "stand_FAIL"과 같은 일반 텍스트 파일로, 어셈블리가 스탠드를 통과했거나 실패했음을 나타냅니다. 글쎄요, 이해하시죠?
- 그런 것 같아요. 어셈블리가 있는 저장소의 동일한 폴더에 기록됩니까?
- 예
— 어셈블리가 테스트 벤치를 통과하지 못하면 어떻게 됩니까? 새로 빌드해야 합니까?
- 응
- 네, 고마워요. 그리고 또 다른 질문: 깃발 제작 날짜를 스탠드 날짜로 사용할 수 있다는 것을 올바르게 이해하고 있습니까?
- 전적으로!
- 슈퍼!

영감을 받은 Ivan은 전화를 끊고 모든 것이 제자리에 있다는 것을 깨달았습니다. 빌드 파일 생성 날짜와 플래그 생성 날짜를 알면 팀이 각 스탠드에서 소비하는 시간을 초 단위까지 계산하고 어디에서 가장 많은 시간을 소비하는지 이해할 수 있었습니다.

"어디에서 가장 많은 시간이 소요되는지 파악하여 팀을 정확히 찾아 해당 팀으로 가서 문제를 파헤칠 것입니다." 이반은 미소를 지었다.

내일 그는 그려지는 시스템의 아키텍처를 스케치하는 임무를 맡았습니다.

계속 될 ...

출처 : habr.com