2020년 러시아의 DevOps 현황

사물의 상태를 이해하는 방법?

예를 들어 웹 사이트의 출판물이나 경험과 같은 다양한 정보 출처에서 형성된 귀하의 의견에 의존할 수 있습니다. 동료, 지인에게 물어볼 수 있습니다. 또 다른 옵션은 컨퍼런스의 주제를 살펴보는 것입니다. 프로그램 위원회는 업계를 적극적으로 대표하므로 관련 주제를 선택할 때 그들을 신뢰합니다. 별도의 영역은 연구 및 보고서입니다. 그러나 문제가 있습니다. DevOps 현황에 대한 연구는 전 세계에서 매년 수행되고 있으며 보고서는 외국 회사에서 게시되며 러시아 DevOps에 대한 정보는 거의 없습니다.

그러나 그러한 연구가 수행되는 날이 왔으며 오늘 그 결과에 대해 이야기하겠습니다. 러시아의 DevOps 상태는 "익스프레스 42"그리고"온티코". Express 42는 기술 회사가 DevOps 사례 및 도구를 구현하고 개발하는 데 도움을 주며 러시아에서 DevOps에 대해 처음으로 언급한 회사 중 하나입니다. 이 연구의 저자인 Igor Kurochkin과 Vitaly Khabarov는 Express 42에서 분석 및 컨설팅에 참여하고 있으며 다른 회사에서 운영 및 경험에 대한 기술적 배경을 가지고 있습니다. 8년 동안 동료들은 스타트업에서 기업에 이르기까지 다양한 문제와 문화적, 엔지니어링 성숙도가 다른 수십 개의 회사와 프로젝트를 살펴보았습니다.

그들의 보고서에서 Igor와 Vitaly는 연구 과정에서 어떤 문제가 있었는지, 어떻게 해결했는지, DevOps 연구가 원칙적으로 어떻게 수행되고 Express 42가 자체적으로 수행하기로 결정한 이유를 설명했습니다. 보고서를 볼 수 있습니다. 여기에.

DevOps 연구

대화는 Igor Kurochkin이 시작했습니다.

우리는 정기적으로 DevOps 컨퍼런스에서 청중에게 "올해의 DevOps 상태 보고서를 읽었습니까?"라고 묻습니다. 손을 드는 사람은 거의 없었으며, 우리의 연구에 따르면 XNUMX분의 XNUMX만이 손을 들었습니다. 그러한 보고서를 본 적이 없다면 모두 매우 유사하다고 즉시 말합시다. 대부분 "작년과 비교하여 ..."와 같은 문구가 있습니다.

여기에 첫 번째 문제가 있고 그 다음에 두 가지 문제가 더 있습니다.

1. 작년 데이터가 없습니다. 러시아의 DevOps 상태는 누구에게도 관심이 없습니다.
2. 방법론. 가설을 테스트하는 방법, 질문을 구성하는 방법, 분석하고 결과를 비교하고 연결을 찾는 방법이 명확하지 않습니다.
3. 술어. 모든 보고서는 영어로 작성되고 번역이 필요하며 공통 DevOps 프레임워크는 아직 발명되지 않았으며 모든 사람이 자신의 프레임워크를 제시합니다.

DevOps 상태 분석이 전 세계적으로 어떻게 수행되었는지 살펴보겠습니다.

역사 정보

DevOps 연구는 2011년부터 수행되었습니다. 구성 관리 시스템의 개발자인 Puppet이 이를 처음 수행했습니다. 당시에는 인프라를 코드 형식으로 설명하는 주요 도구 중 하나였습니다. 2013년까지 이러한 연구는 단순히 비공개 설문조사였으며 공개 보고서가 없었습니다.

2013년에는 DevOps에 관한 모든 주요 서적의 출판사인 IT Revolution이 등장했습니다. Puppet과 함께 첫 번째 State of DevOps 간행물을 준비했으며 여기에서 4가지 주요 지표가 처음으로 나타났습니다. 이듬해 산업 관행 및 도구에 대한 정기적인 기술 레이더로 유명한 컨설팅 회사인 ThoughtWorks가 참여했습니다. 그리고 2015년에는 방법론 부분이 추가되어 어떻게 분석을 하는지 명확해졌습니다.

2016년 연구 저자들은 자체 회사인 DORA(DevOps Research and Assessment)를 만들어 연례 보고서를 발표했습니다. 이듬해 DORA와 Puppet은 마지막 공동 보고서를 발표했습니다.

그리고 흥미로운 일이 시작되었습니다.

2018년에 회사가 분할되고 두 개의 독립적인 보고서가 발표되었습니다. 하나는 Puppet에서, 두 번째는 Google과 함께 DORA에서 나왔습니다. DORA는 핵심 지표와 전사적 성과에 영향을 미치는 주요 지표, 성과 프로필, 엔지니어링 관행을 통해 방법론을 계속 활용해 왔습니다. 그리고 Puppet은 DevOps의 프로세스 및 진화에 대한 설명과 함께 고유한 접근 방식을 제공했습니다. 그러나 이야기는 뿌리를 내리지 못했습니다. 2019년에 Puppet은 이 방법론을 포기하고 주요 사례와 그들의 관점에서 DevOps에 미치는 영향을 나열한 새로운 버전의 보고서를 발표했습니다. 그런 다음 또 다른 사건이 발생했습니다. Google이 DORA를 인수하고 함께 또 다른 보고서를 발표했습니다. 당신은 그를 본 적이 있을 것입니다.

올해는 상황이 복잡해졌습니다. Puppet은 자체 설문 조사를 시작한 것으로 알려져 있습니다. 그들은 우리보다 일주일 일찍 그것을했고 이미 끝났습니다. 우리는 그것에 참여하여 그들이 어떤 주제에 관심이 있는지 살펴보았습니다. 이제 Puppet은 분석을 수행하고 보고서 게시를 준비하고 있습니다.

그러나 DORA와 Google의 발표는 아직 없습니다. 보통 설문조사가 시작되던 XNUMX월에 DORA 창립자 중 한 명인 Nicole Forsgren이 다른 회사로 옮겼다는 정보가 왔습니다. 따라서 올해는 DORA의 연구 및 보고가 없을 것으로 가정했습니다.

러시아 상황은 어떻습니까?

우리는 DevOps 연구를 수행하지 않았습니다. 우리는 회의에서 다른 사람들이 발견한 내용을 다시 말했고, Raiffeisenbank는 2019년 "State of DevOps"를 번역했습니다(Habré에서 발표 내용을 찾을 수 있음). 그들 덕분입니다. 그리고 그게 다야.

따라서 우리는 DORA 방법론과 결과를 사용하여 러시아에서 자체 연구를 수행했습니다. 우리는 용어와 번역의 동기화를 포함하여 연구를 위해 Raiffeisenbank 동료들의 보고서를 사용했습니다. 그리고 업계 관련 질문은 DORA 보고서와 올해의 Puppet 설문지에서 가져왔습니다.

연구 과정

보고서는 마지막 부분일 뿐입니다. 전체 연구 프로세스는 네 가지 주요 단계로 구성됩니다.

준비 단계에서 업계 전문가를 인터뷰하고 가설 목록을 준비했습니다. 이를 바탕으로 6월 내내 질문이 수집되고 설문조사가 시작되었습니다. 그런 다음 보고서 자체를 분석하고 준비했습니다. DORA의 경우 이 프로세스가 3개월이 걸립니다. 우리는 XNUMX개월 이내에 만났고 이제 시간이 거의 없다는 것을 이해합니다. 분석을 수행해야만 어떤 질문을 해야 하는지 이해할 수 있습니다.

참가자

모든 외국 보고서는 참가자의 초상화로 시작되며 대부분 러시아 출신이 아닙니다. 러시아 응답자의 비율은 해마다 5%에서 1%로 변동하며 이로 인해 어떤 결론도 도출할 수 없습니다.

Accelerate State of DevOps 2019 보고서의 지도:

우리 연구에서 우리는 889명을 인터뷰할 수 있었습니다. 이는 꽤 많은 수입니다(DORA는 보고서에서 매년 약 천 명을 조사합니다). 여기서 우리는 목표를 달성했습니다.

사실, 모든 참가자가 끝까지 도달한 것은 아닙니다. 완료율은 절반에 약간 못 미치는 것으로 나타났습니다. 하지만 이것만으로도 대표 샘플을 얻어 분석을 하기에는 충분했다. DORA는 보고서에 채우기 백분율을 공개하지 않으므로 여기에서는 비교하지 않습니다.

산업 및 직위

응답자들은 XNUMX개 산업을 대표합니다. 절반은 정보 기술 분야에서 일합니다. 그 다음에는 금융 서비스, 무역, 통신 등이 뒤따릅니다. 직책에는 전문가(개발자, 테스터, 운영 엔지니어) 및 관리 직원(팀장, 그룹, 영역, 이사)이 있습니다.

9명 중 40명은 중소기업에서 일한다. 세 번째 사람은 대기업에서 일합니다. 대부분은 최대 XNUMX명으로 구성된 팀에서 일합니다. 이와는 별도로 주요 활동에 대해 물었고, 대다수가 운영과 관련이 있으며 약 XNUMX%가 개발에 참여하고 있습니다.

그래서 우리는 다양한 산업, 회사, 팀의 대표자들을 비교하고 분석하기 위한 정보를 수집했습니다. 내 동료 Vitaly Khabarov가 분석에 대해 말할 것입니다.

분석 및 비교

Vitaly Khabarov: 설문 조사를 완료하고 설문지를 작성하고 추가 분석 및 가설 테스트를 위한 데이터를 제공한 모든 참가자에게 감사드립니다. 그리고 고객과 고객 덕분에 업계의 우려 사항을 식별하고 연구에서 테스트한 가설을 공식화하는 데 도움이 된 풍부한 경험을 보유하고 있습니다.

안타깝게도 한편으로는 질문 목록을 가져오고 다른 한편으로는 데이터를 가져 와서 어떻게 든 비교하고 "예, 모든 것이 그렇게 작동합니다. 우리가 옳았습니다"라고 말하고 분산시킬 수는 없습니다. 아니오, 우리가 착각하지 않고 우리의 결론이 신뢰할 수 있음을 확인하기 위해 방법론과 통계적 방법이 필요합니다. 그런 다음 다음 데이터를 기반으로 추가 작업을 구축할 수 있습니다.

주요 지표

우리는 DORA 방법론을 기반으로 삼았으며 "DevOps 상태 가속화"라는 책에 자세히 설명되어 있습니다. 주요 지표가 러시아 시장에 적합한지, DORA가 "러시아 산업은 외국 산업과 어떻게 일치합니까?"라는 질문에 답하는 데 사용하는 것과 같은 방식으로 사용할 수 있는지 여부를 확인했습니다.

주요 지표:

1. 배포 빈도. 애플리케이션의 새 버전이 프로덕션 환경에 얼마나 자주 배포됩니까(계획된 변경 사항, 핫픽스 및 사고 대응 제외)?
2. 배달 시간. 변경 사항을 커밋(기능을 코드로 작성)하고 프로덕션 환경에 변경 사항을 배포하는 데 걸리는 평균 시간은 얼마입니까?
3. 회복 시간. 사고, 서비스 저하 또는 응용 프로그램 사용자에게 영향을 미치는 버그 발견 후 응용 프로그램을 프로덕션 환경으로 복원하는 데 평균적으로 얼마나 걸립니까?
4. 실패한 변경. 프로덕션 환경에서 몇 퍼센트의 배포가 애플리케이션 성능 저하 또는 사고로 이어지고 수정이 필요합니까(변경 사항 롤백, 핫픽스 또는 패치 개발)?

DORA는 연구에서 이러한 지표와 조직 성과 사이의 연관성을 발견했습니다. 우리는 또한 우리 연구에서 그것을 테스트합니다.

그러나 XNUMX가지 주요 지표가 무언가에 영향을 미칠 수 있는지 확인하려면 이해해야 합니다. 즉, 서로 관련이 있습니까? DORA는 성공하지 못한 변경(변경 실패율)과 다른 세 가지 메트릭 간의 관계가 약간 더 약하다는 한 가지 주의 사항과 함께 긍정적으로 대답했습니다. 우리는 거의 같은 그림을 얻었습니다. 제공 시간, 배포 빈도 및 복구 시간이 서로 상관관계가 있는 경우(Pearson 상관관계 및 Chaddock 척도를 통해 이 상관관계를 설정함) 실패한 변경과 강력한 상관관계가 없습니다.

원칙적으로 대부분의 응답자는 프로덕션에서 발생하는 인시던트가 다소 적다고 대답하는 경향이 있습니다. 성공하지 못한 변경의 측면에서 응답자 그룹 간에 여전히 상당한 차이가 있음을 나중에 알게 되겠지만 아직 이 부문에 대해 이 메트릭을 사용할 수 없습니다.

우리는 (일부 고객과의 분석 및 커뮤니케이션 중에 밝혀진 바와 같이) 사고로 간주되는 인식에 약간의 차이가 있다는 사실에 기인합니다. 기술 창에서 서비스 성능을 복원한 경우 이를 사고로 간주할 수 있습니까? 아마 그렇지 않을 것입니다. 우리가 모든 것을 고쳤기 때문에 우리는 훌륭합니다. 일반적이고 친숙한 모드에서 응용 프로그램을 10번 다시 굴려야 하는 경우 사고로 간주할 수 있습니까? 그렇지 않은 것 같습니다. 따라서 실패한 변경과 다른 메트릭의 관계에 대한 질문은 여전히 ​​열려 있습니다. 우리는 그것을 더 다듬을 것입니다.

여기서 중요한 것은 배송 시간, 복구 시간 및 배포 빈도 사이에 상당한 상관 관계가 있음을 발견했다는 것입니다. 따라서 응답자를 성과 그룹으로 더 나누기 위해 이 세 가지 메트릭을 사용했습니다.

그램 단위로 매달리는 정도?

계층적 클러스터 분석을 사용했습니다.

• 우리는 응답자를 n차원 공간에 분산시켰습니다. 여기서 각 응답자의 좌표는 질문에 대한 답변입니다.
• 각 응답자는 작은 클러스터로 선언됩니다.
• 서로 가장 가까운 두 클러스터를 하나의 더 큰 클러스터로 결합합니다.
• 다음 클러스터 쌍을 찾아 더 큰 클러스터로 결합합니다.

이것이 모든 응답자를 필요한 클러스터 수로 그룹화하는 방법입니다. 덴드로그램(클러스터 간 연결 트리)의 도움으로 두 인접 클러스터 간의 거리를 볼 수 있습니다. 우리에게 남은 것은 이러한 클러스터 사이에 일정한 거리 제한을 설정하고 "이 두 그룹은 그들 사이의 거리가 거대하기 때문에 서로 상당히 구별할 수 있습니다."라고 말하는 것입니다.

그러나 여기에 숨겨진 문제가 있습니다. 클러스터 수에 제한이 없습니다. 2, 3, 4, 10개의 클러스터를 얻을 수 있습니다. 그리고 첫 번째 아이디어는 - DORA처럼 모든 응답자를 4개 그룹으로 나누지 않는 이유였습니다. 그러나 우리는 이러한 그룹 간의 차이가 미미하다는 것을 발견했으며 응답자가 실제로 이웃 그룹이 아니라 자신의 그룹에 속해 있는지 확신할 수 없습니다. 우리는 아직 러시아 시장을 네 그룹으로 나눌 수 없습니다. 따라서 통계적으로 유의미한 차이가 있는 세 가지 프로파일을 결정했습니다.

다음으로 클러스터별로 프로필을 결정했습니다. 각 그룹의 각 메트릭에 대한 중앙값을 가져와 성능 프로필 표를 작성했습니다. 사실, 우리는 각 그룹의 평균 참가자의 성과 프로필을 얻었습니다. 낮음, 중간, 높음의 세 가지 효율성 프로필을 확인했습니다.

여기에서 우리는 4가지 주요 메트릭이 성능 프로필을 결정하는 데 적합하고 서구 및 러시아 시장 모두에서 작동한다는 가설을 확인했습니다. 그룹 간에 차이가 있으며 통계적으로 유의합니다. 처음에 응답자를 이 매개변수로 나누지 않았음에도 불구하고 평균의 관점에서 실패한 변화의 척도 측면에서 성능 프로필 간에 상당한 차이가 있음을 강조합니다.

그런 다음 질문이 생깁니다. 이 모든 것을 어떻게 사용합니까?

사용 방법

팀, 4가지 주요 메트릭을 테이블에 적용하면 85%의 경우 완전한 일치를 얻지 못할 것입니다. 이것은 실제 참가자가 아니라 평균적인 참가자입니다. 우리는 모두(그리고 모든 팀) 조금씩 다릅니다.

우리는 확인했습니다. 응답자와 DORA 성과 프로필을 가져와 이 프로필 또는 저 프로필에 맞는 응답자가 몇 명인지 살펴봤습니다. 우리는 응답자의 16%만이 프로필 중 하나에 확실히 속한다는 것을 발견했습니다. 나머지는 모두 다음 사이 어딘가에 흩어져 있습니다.

이는 효율성 프로필의 범위가 제한되어 있음을 의미합니다. 첫 번째 근사치의 위치를 ​​이해하려면 다음 표를 사용할 수 있습니다. "오, 중간 또는 높음에 더 가까운 것 같습니다!" 다음에 어디로 가야할지 이해한다면 이것으로 충분할 것입니다. 그러나 목표가 일정하고 지속적인 개선이며 어디에서 개발하고 무엇을 해야 하는지 더 정확히 알고 싶다면 추가 자금이 필요합니다. 우리는 그것들을 계산기라고 불렀습니다.

• 도라 계산기
• Calculator Express 42*(개발 중)
• 자체 개발(자신만의 내부 계산기를 만들 수 있음).

그들은 무엇을 위해 필요합니까? 이해하다:

• 우리 조직 내 팀이 우리 기준에 부합합니까?
• 그렇지 않다면 우리 회사가 보유한 전문 지식의 틀 내에서 그것을 돕고 속도를 높일 수 있습니까?
• 그렇다면 더 잘할 수 있을까요?

회사 내에서 통계를 수집하는 데 사용할 수도 있습니다.

• 어떤 팀이 있습니까?
• 팀을 프로필로 나눕니다.
• 참조: 오, 이 명령은 성능이 좋지 않지만(조금 당기지 않음) 훌륭합니다. 오류 없이 매일 배포되며 리드 타임이 XNUMX시간 미만입니다.

그리고 우리 회사에는 아직 수준에 미치지 못하는 팀에 필요한 전문 지식과 도구가 있다는 것을 알 수 있습니다.

또는 회사 내부에서 기분이 좋고 많은 것보다 낫다는 것을 이해하면 조금 더 넓게 볼 수 있습니다. 이것은 단지 러시아 산업입니다. 우리 자신을 가속화하기 위해 러시아 산업에서 필요한 전문 지식을 얻을 수 있습니까? Express 42 계산기가 여기에서 도움이 될 것입니다(개발 중임). 러시아 시장을 능가했다면 다음을 살펴보십시오. 도라 계산기 그리고 세계 시장으로.

괜찮은. 그리고 DORA 계산기에서 엘리트 그룹에 속해 있다면 어떻게 해야 할까요? 여기에는 좋은 해결책이 없습니다. 귀하는 업계의 최전선에 있을 가능성이 높으며 내부 R&D 및 더 많은 리소스 지출을 통해 더 많은 가속화와 안정성이 가능합니다.

가장 달콤한 비교로 넘어 갑시다.

비교

우리는 처음에 러시아 산업과 서구 산업을 비교하고 싶었습니다. 직접 비교하면 프로필이 더 적고 서로 조금 더 혼합되어 있으며 경계가 조금 더 흐릿함을 알 수 있습니다.

우리의 엘리트 성과자들은 높은 성과자들 사이에 숨겨져 있지만 그들은 거기에 있습니다. 이들은 상당한 높이에 도달한 엘리트 유니콘입니다. 러시아에서는 Elite 프로필과 High 프로필의 차이가 아직 충분히 크지 않습니다. 우리는 미래에 엔지니어링 문화의 증가, 엔지니어링 관행 구현의 품질 및 기업 내 전문성으로 인해 이러한 분리가 발생할 것이라고 생각합니다.

러시아 산업 내에서 직접적인 비교로 넘어가면 유명 팀이 모든 면에서 더 낫다는 것을 알 수 있습니다. 우리는 또한 이러한 지표와 조직 성과 사이에 관계가 있다는 가설을 확인했습니다. 유명 팀은 목표를 달성할 뿐만 아니라 초과 달성할 가능성이 훨씬 더 높습니다.
유명한 팀이 되고 거기서 멈추지 마십시오.

그러나 올해는 특별합니다. 우리는 팬데믹 상황에서 기업이 어떻게 대처하고 있는지 확인하기로 했습니다. 유명한 팀이 업계 평균보다 훨씬 더 잘하고 있고 기분도 더 좋아졌습니다.

• 신제품 출시 확률 1,5~2배,
• 애플리케이션 인프라의 안정성 및/또는 성능을 개선할 가능성이 2배 더 높습니다.

즉, 그들이 이미 가지고 있는 역량은 그들이 더 빨리 개발하고, 신제품을 출시하고, 기존 제품을 수정하여 새로운 시장과 새로운 사용자를 확보하는 데 도움이 되었습니다.

그 밖에 우리 팀에 도움이 된 것은 무엇입니까?

엔지니어링 실습

우리가 테스트한 각 사례에 대한 중요한 결과에 대해 말씀드리겠습니다. 다른 것이 팀에 도움이 되었을 수도 있지만 우리는 DevOps에 대해 이야기하고 있습니다. 그리고 DevOps 내에서 프로필이 다른 팀 간에 차이가 있습니다.

서비스로서의 플랫폼

우리는 플랫폼 연령과 팀 프로필 사이에 중요한 관계를 찾지 못했습니다. 플랫폼은 낮은 팀과 높은 팀 모두에서 거의 동시에 나타났습니다. 그러나 후자의 경우 플랫폼은 프로그램 코드를 통한 제어를 위해 평균적으로 더 많은 서비스와 더 많은 프로그래밍 인터페이스를 제공합니다. 그리고 플랫폼 팀은 개발자와 팀이 플랫폼을 사용하도록 돕고, 문제 및 플랫폼 관련 사건을 더 자주 해결하고, 다른 팀을 교육할 가능성이 더 큽니다.

코드형 인프라

여기에서는 모든 것이 꽤 표준입니다. 우리는 인프라 코드 작업의 자동화와 인프라 리포지토리 내에 저장되는 정보의 양 사이의 관계를 발견했습니다. 상위 프로필 명령은 리포지토리에 더 많은 정보를 저장합니다. 이는 인프라 구성, CI/CD 파이프라인, 환경 설정 및 빌드 매개변수입니다. 이 정보를 더 자주 저장하고, 인프라 코드로 더 잘 작업하고, 인프라 코드 작업을 위해 더 많은 프로세스와 작업을 자동화합니다.

흥미롭게도 우리는 인프라 테스트에서 큰 차이를 보지 못했습니다. 나는 이것이 높은 프로필 팀이 일반적으로 더 많은 테스트 자동화를 가지고 있다는 사실 때문이라고 생각합니다. 아마도 그들은 인프라 테스트에 의해 별도로 산만 해져서는 안되며 오히려 애플리케이션을 확인하는 테스트 덕분에 이미 무엇을 어디에서 깨뜨렸는지 알 수 있습니다.

통합 및 전달

가장 지루한 섹션은 자동화가 많을수록 코드 작업이 더 잘되고 더 나은 결과를 얻을 가능성이 높다는 것을 확인했기 때문입니다.

구조

우리는 마이크로서비스가 성능에 어떤 영향을 미치는지 확인하고 싶었습니다. 실제로는 그렇지 않습니다. 마이크로서비스의 사용이 성과 지표의 증가와 관련이 없기 때문입니다. 마이크로서비스는 하이 프로파일 명령과 로우 프로파일 명령 모두에 사용됩니다.

그러나 중요한 것은 상위 팀의 경우 마이크로서비스 아키텍처로의 전환을 통해 독립적으로 서비스를 개발하고 출시할 수 있다는 것입니다. 아키텍처를 통해 개발자가 팀 외부의 누군가를 기다리지 않고 자율적으로 행동할 수 있다면 이는 속도를 높이기 위한 핵심 역량입니다. 이 경우 마이크로서비스가 도움이 됩니다. 그리고 그들의 구현은 큰 역할을 하지 않습니다.

이 모든 것을 어떻게 발견했을까요?

DORA 방법론을 완전히 복제하려는 야심찬 계획이 있었지만 리소스가 부족했습니다. DORA가 후원을 많이 하고 그들의 연구가 반년이 걸린다면 우리는 짧은 시간에 연구를 했습니다. 우리는 DORA와 같은 DevOps 모델을 구축하고 싶었고 앞으로도 그렇게 할 것입니다. 지금까지는 히트 맵으로 제한했습니다.

우리는 각 프로필의 팀 전체에서 엔지니어링 관행의 분포를 살펴보고 평균적으로 유명 팀이 엔지니어링 관행을 사용할 가능성이 더 높다는 것을 발견했습니다. 이 모든 것에 대한 자세한 내용은 당사에서 읽을 수 있습니다. 보고서.

변경을 위해 복잡한 통계에서 간단한 통계로 전환해 보겠습니다.

또 무엇을 발견했습니까?

도구

우리는 대부분의 명령이 Linux 제품군의 OS에서 사용되는 것을 관찰했습니다. 그러나 Windows는 여전히 추세입니다. 응답자의 최소 XNUMX/XNUMX이 해당 버전 중 하나 또는 다른 버전을 사용한다고 언급했습니다. 시장에 이런 니즈가 있는 것 같다. 따라서 이러한 역량을 개발하고 회의에서 프레젠테이션을 할 수 있습니다.

오케스트레이터 중 누구에게도 비밀이 아니며 Kubernetes가 선두(52%)입니다. 다음 오케스트레이터는 Docker Swarm(약 12%)입니다. 가장 널리 사용되는 CI 시스템은 Jenkins와 GitLab입니다. 가장 널리 사용되는 구성 관리 시스템은 Ansible이고 그 다음은 우리가 사랑하는 Shell입니다.

Amazon은 현재 최고의 클라우드 호스팅 제공업체입니다. 러시아 구름의 점유율이 점차 증가하고 있습니다. 내년에는 시장 점유율이 증가할지 여부에 관계없이 러시아 클라우드 공급자가 어떻게 느끼는지 보는 것이 흥미로울 것입니다. 그들은 사용할 수 있으며 좋습니다.

나는 더 많은 통계를 제공 할 Igor에게 바닥을 넘깁니다.

관행의 보급

Igor Kurochkin: 별도로 응답자들에게 고려된 엔지니어링 관행이 회사에 어떻게 배포되어 있는지 표시하도록 요청했습니다. 대부분의 회사에는 서로 다른 패턴 세트로 구성된 혼합 접근 방식이 있으며 파일럿 프로젝트는 매우 인기가 있습니다. 또한 프로필 간에 약간의 차이가 있었습니다. 높은 프로필의 대표자는 소규모 전문가 팀이 작업 프로세스, 도구를 변경하고 다른 팀과 성공적인 사례를 공유할 때 "아래로부터의 이니셔티브" 패턴을 더 자주 사용합니다. Medium에서 이것은 커뮤니티 및 우수 센터 생성을 통해 회사 전체에 영향을 미치는 하향식 이니셔티브입니다.

애자일 및 DevOps

Agile과 DevOps 간의 연결 문제는 업계에서 자주 논의됩니다. 이 문제는 2019/2020년 Agile 현황 보고서에서도 제기되었으므로 회사에서 Agile 및 DevOps 활동이 어떻게 연결되는지 비교하기로 했습니다. 애자일이 없는 DevOps는 드물다는 사실을 알게 되었습니다. 응답자의 절반은 Agile의 확산이 훨씬 일찍 시작되었고 약 20%는 동시 시작을 관찰했으며 낮은 프로필의 징후 중 하나는 Agile 및 DevOps 관행이 없다는 것입니다.

명령 토폴로지

작년 말, 책팀 토폴로지”, 명령 토폴로지를 설명하기 위한 프레임워크를 제안합니다. 그것이 러시아 회사에 적용 가능한지 여부가 흥미로워졌습니다. 그리고 우리는 "어떤 패턴을 찾았습니까?"라는 질문을 했습니다.

인프라 팀은 응답자의 절반과 개발, 테스트 및 운영을 위한 별도의 팀에서 관찰되었습니다. 별도의 DevOps 팀은 45%를 기록했으며 그 중 높음의 대표가 더 일반적입니다. 다음은 High에서 더 일반적으로 사용되는 교차 기능 팀입니다. 별도의 SRE 명령은 높음, 중간 프로필에 나타나고 낮음 프로필에는 거의 표시되지 않습니다.

DevQaOps 비율

우리는 Skyeng 플랫폼 팀의 팀 리더의 FaceBook에서 이 질문을 보았습니다. 그는 회사의 개발자, 테스터 및 관리자의 비율에 관심이 있었습니다. 우리는 그것에 대해 질문하고 프로필을 기반으로 응답을 살펴보았습니다. 유명 인사 대표는 각 개발자에 대해 더 적은 수의 테스트 및 운영 엔지니어를 보유하고 있습니다.

2021 년 계획

내년 계획에서 응답자들은 다음과 같은 활동에 주목했습니다.

여기에서 DevOps Live 2020 컨퍼런스와의 교차점을 볼 수 있습니다. 프로그램을 신중하게 검토했습니다.

• 제품으로서의 인프라
• DevOps 변환
• DevOps 사례 배포
• DevSecOps
• 사례 클럽 및 토론

그러나 모든 주제를 다루기에는 프레젠테이션 시간이 충분하지 않습니다. 비하인드 스토리:

• 서비스 및 제품으로서의 플랫폼
• 코드형 인프라, 환경 및 클라우드
• 지속적인 통합 및 제공
• 건축학;
• DevSecOps 패턴;
• 플랫폼 및 다기능 팀.

신고 50페이지 분량의 방대한 분량이 있으며 더 자세히 볼 수 있습니다.

합산

우리의 연구 및 보고서가 개발, 테스트 및 운영에 대한 새로운 접근 방식을 실험하는 데 영감을 주고 탐색하고, 연구의 다른 참가자와 자신을 비교하고, 자신의 접근 방식을 개선할 수 있는 영역을 식별하는 데 도움이 되기를 바랍니다.

러시아의 DevOps 상태에 대한 첫 번째 연구 결과:

• 주요 지표. 개발, 테스트 및 운영 프로세스의 효율성을 분석하는 데 주요 메트릭(배달 시간, 배포 빈도, 복구 시간 및 변경 실패)이 적합하다는 것을 확인했습니다.
• 프로필 높음, 중간, 낮음. 수집된 데이터를 기반으로 메트릭, 관행, 프로세스 및 도구 측면에서 고유한 기능을 사용하여 통계적으로 서로 다른 높음, 중간, 낮음 그룹을 구분할 수 있습니다. 높음 프로필의 대표자는 낮음보다 더 나은 결과를 보여줍니다. 그들은 목표를 달성하고 초과 달성할 가능성이 더 높습니다.
• 2021년 지표, 전염병 및 계획. 올해의 특별한 지표는 기업들이 팬데믹에 어떻게 대처했는지입니다. High 대표자들은 더 나은 성과를 거두었고 사용자 참여 증가를 경험했으며 성공의 주된 이유는 효율적인 개발 프로세스와 강력한 엔지니어링 문화였습니다.
• DevOps 관행, 도구 및 개발. 내년 기업의 주요 계획에는 DevOps 관행 및 도구 개발, DevSecOps 관행 도입 및 조직 구조 변경이 포함됩니다. 그리고 DevOps 관행의 효과적인 구현 및 개발은 파일럿 프로젝트, 커뮤니티 및 우수 센터 형성, 회사의 상위 및 하위 수준에서의 이니셔티브의 도움으로 수행됩니다.

귀하의 피드백, 이야기, 피드백을 듣고 싶습니다. 연구에 참여해주신 모든 분들께 감사드리며 내년에도 많은 참여 부탁드립니다.

출처 : habr.com