혼돈 관리: 기술 지도의 도움을 받아 정리하기

그림: Unsplash

모두 안녕! 우리는 회사의 자동화 엔지니어입니다. 긍정적 인 기술 그리고 우리는 회사의 제품 개발을 지원합니다. 우리는 개발자가 코드 라인을 커밋하는 것부터 완제품 및 라이선스를 업데이트 서버에 게시하는 데 이르는 전체 어셈블리 파이프라인을 지원합니다. 비공식적으로 DevOps 엔지니어라고 합니다. 이 기사에서는 소프트웨어 생산 프로세스의 기술 단계, 이를 보는 방법 및 분류하는 방법에 대해 이야기하고자 합니다.

이 자료에서 다중 제품 개발 조정의 복잡성, 기술 지도가 무엇인지, 솔루션을 간소화하고 복제하는 데 어떻게 도움이 되는지, 개발 프로세스의 주요 단계 및 단계는 무엇인지, 책임 영역은 어떻게 되는지에 대해 배우게 됩니다. 우리 회사의 DevOps와 팀 간의

혼돈과 DevOps에 대하여

간단히 말해서 DevOps의 개념에는 개발 도구 및 서비스뿐만 아니라 사용 방법론 및 모범 사례가 포함됩니다. 글로벌을 선별하자 골 우리 회사의 DevOps 아이디어 구현에서: 이는 양적 측면(인시 또는 기계 시간, CPU, RAM, 디스크 등)에서 제품의 생산 및 유지 관리 비용을 지속적으로 절감하는 것입니다. 회사 전체 수준에서 전체 개발 비용을 줄이는 가장 쉽고 확실한 방법은 일반적인 직렬 작업 수행 비용 최소화 생산의 모든 단계에서. 그러나이 단계는 무엇이며 일반 프로세스와 분리하는 방법은 무엇이며 어떤 단계로 구성됩니까?

회사가 하나의 제품을 개발할 때 모든 것이 다소 명확합니다. 일반적으로 공통 로드맵과 개발 계획이 있습니다. 하지만 제품 라인이 확장되고 제품이 더 많아지면 어떻게 해야 할까요? 언뜻 보기에 프로세스와 조립 라인이 비슷하고 로그와 스크립트에서 "X차이점 찾기" 게임이 시작됩니다. 그러나 활성 개발 중인 프로젝트가 이미 5개 이상 있고 몇 년에 걸쳐 개발된 여러 버전에 대한 지원이 필요한 경우에는 어떻게 해야 합니까? 제품 파이프라인에서 가능한 최대 수의 솔루션을 재사용하고 싶습니까, 아니면 각각 고유한 개발에 비용을 지출할 준비가 되어 있습니까?

독창성과 직렬 솔루션 간의 균형을 찾는 방법은 무엇입니까?

이러한 질문은 2015년 이후 점점 더 자주 발생하기 시작했습니다. 제품의 수는 늘어났고 이러한 제품의 조립 라인을 지원하는 자동화 부서(DevOps)를 최소한으로 확장하려고 했습니다. 동시에 우리는 제품 간에 가능한 한 많은 솔루션을 복제하기를 원했습니다. 결국, 왜 같은 것을 XNUMX개의 제품에서 다른 방식으로 수행합니까?

개발 이사: "여러분, DevOps가 제품에 대해 수행하는 작업을 어떻게든 평가할 수 있습니까?"

우리: "모르겠습니다. 그런 질문을하지 않았지만 어떤 지표를 고려해야합니까?"

개발 이사: "누가 알아! 생각하다…"

그 유명한 영화에서와 같이 : "나는 호텔에 있습니다! .."- "어 ... 길을 보여줄 수 있습니까?" 심사숙고 끝에 우리는 먼저 제품의 최종 상태를 결정해야 한다는 결론에 도달했습니다. 이것이 우리의 첫 번째 목표가 되었습니다.

그렇다면 10명에서 200명으로 구성된 상당히 큰 팀으로 구성된 XNUMX개 제품을 분석하고 솔루션을 복제할 때 측정 가능한 지표를 결정하는 방법은 무엇입니까?

Chaos 또는 견갑골의 DevOps에 찬성하는 1:0

우리는 BPwin 시리즈의 IDEF0 다이어그램과 다양한 비즈니스 프로세스 다이어그램을 적용하려는 시도로 시작했습니다. 혼란은 다음 프로젝트의 다음 단계의 다섯 번째 사각형 이후에 시작되었으며 각 프로젝트에 대한 이러한 사각형은 50+ 단계 아래의 긴 비단뱀 꼬리에 그려질 수 있습니다. 나는 슬프고 달에 울부 짖고 싶었습니다. 일반적으로 적합하지 않았습니다.

일반적인 생산 작업

생산 프로세스 모델링은 매우 복잡하고 힘든 작업입니다. 다양한 부서와 생산 체인에서 많은 데이터를 수집, 처리 및 분석해야 합니다. " 기사에서 이에 대한 자세한 내용을 읽을 수 있습니다.IT 회사의 생산 프로세스 모델링".

우리가 생산 프로세스 모델링을 시작했을 때 회사 제품 개발에 관련된 모든 직원과 프로젝트 관리자에게 다음을 전달한다는 구체적인 목표가 있었습니다.

• 코드 라인 커밋에서 시작하여 제품 및 해당 구성 요소가 설치 프로그램 및 업데이트의 형태로 고객에게 도달하는 방법,
• 제품 생산의 각 단계에 어떤 자원이 제공되는지,
• 각 단계에서 어떤 서비스가 관련되어 있는지,
• 각 단계의 책임 영역을 구분하는 방법,
• 각 단계의 입구와 출구에 어떤 계약이 존재하는지.

이미지를 클릭하면 전체 크기로 열립니다.

회사에서의 업무는 여러 기능 영역으로 나뉩니다. 인프라의 방향은 부서의 모든 "철"자원 운영 최적화와 가상 머신 및 그 환경의 배포 자동화에 관여합니다. 모니터링 방향은 24/7 서비스 성능 제어를 제공합니다. 또한 개발자를 위한 서비스로 모니터링을 제공합니다. 워크플로 방향은 개발 및 테스트 프로세스를 관리하고 코드 상태를 분석하며 프로젝트에 대한 분석을 얻을 수 있는 도구를 팀에 제공합니다. 마지막으로 webdev 방향은 GUS 및 FLUS 업데이트 서버에 대한 릴리스 게시와 LicenseLab 서비스를 사용하는 제품 라이센스를 제공합니다. 프로덕션 파이프라인을 지원하기 위해 개발자를 위한 다양한 지원 서비스를 설정하고 유지 관리합니다(이전 모임에서 일부에 대한 이야기를 들을 수 있습니다. 옵!데브옵스! 2016년 и 옵!데브옵스! 2017년). 또한 다음과 같은 내부 자동화 도구를 개발합니다. 오픈 소스 솔루션.

지난 XNUMX년 동안 우리 작업은 동일한 유형과 일상적인 작업을 많이 축적했으며 다른 부서의 개발자는 주로 소위 일반적인 작업, 솔루션은 완전히 또는 부분적으로 자동화되어 연주자에게 어려움을 일으키지 않으며 상당한 양의 작업이 필요하지 않습니다. 주요 영역과 함께 이러한 작업을 분석하고 개별 작업 범주를 식별할 수 있었습니다. 생산 단계, 단계는 분할 할 수없는 단계로 나뉘며 여러 단계가 합산됩니다. 생산 공정 체인.

기술 체인의 가장 간단한 예는 회사 내 각 제품의 조립, 배포 및 테스트 단계입니다. 예를 들어 빌드 단계는 GitLab에서 소스 다운로드, 종속성 및 타사 라이브러리 준비, 단위 테스트 및 정적 코드 분석, GitLab CI에서 빌드 스크립트 실행, 내부 ChangelogBuilder 도구를 통한 Artifactory 및 릴리스 노트 생성.

Habré의 다른 기사에서 일반적인 DevOps 작업에 대해 읽을 수 있습니다. "개인적인 경험: 지속적 통합 시스템의 모습"그리고"개발 프로세스 자동화: Positive Technologies에서 DevOps 아이디어를 구현한 방법".

많은 일반적인 생산 체인이 형성됩니다. 제조 공정. 프로세스를 설명하는 표준 접근 방식은 기능적 IDEF0 모델을 사용하는 것입니다.

제조 CI 프로세스 모델링의 예

지속적인 통합 시스템을 위한 표준 프로젝트 개발에 특별한 관심을 기울였습니다. 이를 통해 프로젝트의 통일을 달성할 수 있었고 소위 프로모션이 포함된 릴리스 빌드 계획.

작동 방식은 다음과 같습니다. 모든 프로젝트는 일반적으로 보입니다. 여기에는 Artifactory의 스냅샷 리포지토리에 속하는 어셈블리 구성이 포함되며, 그 후 테스트 벤치에서 배포 및 테스트된 다음 릴리스 리포지토리로 승격됩니다. Artifactory 서비스는 팀과 다른 서비스 간의 모든 빌드 아티팩트에 대한 단일 배포 지점입니다.

릴리스 체계를 크게 단순화하고 일반화하면 다음 단계가 포함됩니다.

• 크로스 플랫폼 제품 조립,
• 테스트 벤치에 배치,
• 기능 및 기타 테스트 실행,
• Artifactory에서 리포지토리를 릴리스하기 위해 테스트된 빌드 홍보,
• 업데이트 서버에 릴리스 빌드 게시,
• 어셈블리 배송 및 생산 업데이트,
• 제품 설치 및 업데이트 시작.

예를 들어, 기능적 IDEF0 모델의 형태로 된 이러한 일반적인 릴리스 체계(이하 간단히 모델)의 기술 모델을 고려하십시오. CI 프로세스의 주요 단계를 반영합니다. IDEF0 모델은 소위 ICOM 표기 (입력-제어-출력-메커니즘) 수행되는 규칙 및 요구 사항 작업, 출력은 무엇이며 특정 단계를 구현하는 메커니즘, 서비스 또는 사람에 따라 각 단계에서 사용되는 리소스를 설명합니다.

이미지를 클릭하면 전체 크기로 열립니다.

일반적으로 기능 모델에서 프로세스 설명을 분해하고 자세히 설명하는 것이 더 쉽습니다. 그러나 요소의 수가 증가함에 따라 그 안에 있는 것을 이해하기가 점점 더 어려워집니다. 그러나 실제 개발에는 모니터링, 제품 인증, 작업 프로세스 자동화 등의 보조 단계도 있습니다. 이 설명을 포기한 것은 스케일링 문제 때문입니다.

희망의 탄생

한 책에서 우리는 기술 프로세스를 설명하는 구소련 지도를 발견했습니다(그런데 오늘날 많은 국영 기업과 대학에서 여전히 사용됨). 잠깐만요, 우리도 워크플로가 있으니까요!.. 단계, 결과, 메트릭, 요구 사항, 지표 등이 있습니다. 우리 제품 파이프라인에도 플로시트를 적용해 보세요. “이게 다야! 우리는 올바른 실을 찾았습니다. 이제 잘 당길 때입니다!

간단한 표에 제품을 열별로, 기술 단계와 제품 ​​파이프라인 단계를 행별로 기록하기로 했습니다. 이정표는 제품 빌드 단계와 같은 큰 것입니다. 그리고 단계는 빌드 서버에 소스 코드를 다운로드하는 단계나 코드를 컴파일하는 단계와 같이 더 작고 자세한 것입니다.

맵의 행과 열이 교차하는 지점에 특정 단계 및 제품에 대한 상태를 기록합니다. 상태의 경우 상태 집합이 정의되었습니다.

1. 정보 없음 - 또는 부적절합니다. 제품의 한 단계에 대한 수요 분석이 필요합니다. 분석이 이미 수행되었지만 현재 단계가 필요하지 않거나 경제적으로 타당하지 않습니다.
2. 연기 - 또는 현재 관련이 없습니다. 파이프라인의 단계가 필요하지만 올해 시행할 힘이 없습니다.
3. 예정. 무대는 올해 시행될 예정이다.
4. 구현. 파이프라인의 단계는 필요한 볼륨으로 구현됩니다.

테이블 채우기는 프로젝트별로 시작되었습니다. 먼저 한 프로젝트의 단계와 단계를 분류하고 상태를 기록하였다. 그런 다음 그들은 다음 프로젝트를 가져 와서 상태를 수정하고 이전 프로젝트에서 누락된 단계와 단계를 추가했습니다. 그 결과 전체 프로덕션 파이프라인의 단계와 단계 및 특정 프로젝트에서의 상태를 얻었습니다. 제품 파이프라인 역량 매트릭스와 비슷한 결과가 나왔습니다. 우리는 그러한 매트릭스를 기술 지도라고 불렀습니다.

기술 지도의 도움으로 우리는 올해의 작업 계획과 함께 달성하고자 하는 목표, 즉 올해 프로젝트에 추가할 단계와 나중을 위해 남겨둘 단계를 팀과 도량형으로 합리적으로 조정합니다. 또한 작업 과정에서 하나의 제품에 대해서만 완료한 단계에서 개선이 있을 수 있습니다. 그런 다음 맵을 확장하고 이 개선 사항을 단계 또는 새로운 단계로 소개한 다음 각 제품을 분석하고 개선을 복제할 가능성을 찾습니다.

그들은 우리에게 반대 할 수 있습니다. “물론 이것은 모두 좋습니다. 시간이 지남에 따라 단계와 단계의 수가 엄청나게 커질 것입니다. 어떻게 될 것인가?

회사 내의 모든 사람이 동일한 방식으로 이해할 수 있도록 각 단계 및 단계에 대한 요구 사항에 대한 표준적이고 상당히 완전한 설명을 도입했습니다. 시간이 지남에 따라 개선 사항이 도입되면 단계가 다른 단계 또는 단계로 흡수된 다음 "붕괴"될 수 있습니다. 동시에 모든 요구 사항과 기술적 뉘앙스가 일반화 단계 또는 단계의 요구 사항에 맞습니다.

복제 솔루션의 효과를 평가하는 방법은 무엇입니까? 우리는 매우 간단한 접근 방식을 사용합니다. 새로운 단계를 구현하기 위한 초기 자본 비용을 연간 일반 제품 비용에 귀속시킨 다음 복제할 때 모두로 나눕니다.

개발의 일부는 이미 지도에 이정표와 단계로 표시되어 있습니다. 전형적인 단계에 대한 자동화 도입을 통해 제품 원가 절감에 영향을 미칠 수 있습니다. 그런 다음 질적 특성, 양적 지표 및 팀이 받는 이익(인시 또는 기계 시간 절감)의 변화를 고려합니다.

생산 공정의 기술 지도

모든 단계와 단계를 태그로 인코딩하고 하나의 체인으로 확장하면 매우 길고 이해할 수 없는 것으로 판명됩니다(기사 시작 부분에서 이야기한 바로 "파이썬 꼬리"). :

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

제품 빌드[Build], 테스트 서버에 배포[Deploy], 테스트[Test], 테스트 결과에 따라 리포지토리를 릴리스하도록 빌드 승격[Promote], 라이선스 생성 및 게시[License], 퍼블리싱[ GUS 업데이트 서버에 게시] 및 FLUS 업데이트 서버로 전달, 제품 구성 관리[설치]를 사용하여 고객의 인프라에 제품 구성 요소 설치 및 업데이트, 설치된 제품에서 원격 측정[원격 측정] 수집.

그 외에도 인프라 상태 모니터링[InfMonitoring], 소스 코드 버전 관리[SourceCodeControl], 빌드 환경 준비[Prepare], 프로젝트 관리[Workflow], 팀에 커뮤니케이션 도구 제공[Communication], 제품 인증[ 인증] 및 CI 프로세스의 자급자족 보장[CISelfSufficiency](예: 인터넷에서 어셈블리의 독립성). 프로세스의 수십 단계는 매우 구체적이기 때문에 고려조차 하지 않습니다.

전체 생산과정을 형식으로 제시하면 훨씬 이해하기 쉬울 것입니다. 기술지도; 이것은 모델의 개별 생산 단계와 분해된 단계가 행으로 기록되고 각 단계 또는 단계에서 수행되는 작업에 대한 설명이 열로 기록되는 테이블입니다. 주요 강조점은 각 단계를 제공하는 리소스와 책임 영역의 구분에 있습니다.

우리에게 지도는 일종의 분류기입니다. 그것은 제품 생산의 큰 기술적 부분을 반영합니다. 덕분에 자동화 팀이 개발자와 상호 작용하고 자동화 단계 구현을 공동으로 계획하고 이를 위해 필요한 인건비와 리소스(인력 및 하드웨어)를 이해하는 것이 더 쉬워졌습니다.

우리 회사 내부에서는 jinja 템플릿에서 일반 HTML 파일로 지도를 자동으로 생성한 다음 GitLab Pages 서버에 업로드합니다. 완전히 생성된 지도의 예가 포함된 스크린샷을 볼 수 있습니다. 링크.

이미지를 클릭하면 전체 크기로 열립니다.

요컨대, 기술 지도는 일반적인 기능을 가진 명확하게 분류된 블록을 반영하는 생산 공정의 일반화된 그림입니다.

로드맵의 구조

맵은 여러 부분으로 구성됩니다.

1. 제목 영역 - 여기에는 맵에 대한 일반적인 설명이 있으며 기본 개념이 소개되고 주요 자원과 생산 프로세스의 결과가 정의됩니다.
2. 대시보드 - 여기에서 개별 제품에 대한 데이터 표시를 제어할 수 있으며 모든 제품에 대해 일반적으로 구현된 단계 및 단계에 대한 요약이 제공됩니다.
3. 기술 지도 - 기술 프로세스에 대한 표 형식의 설명입니다. 지도에서:
   • 모든 단계, 단계 및 해당 코드가 제공됩니다.
   • 단계에 대한 짧고 완전한 설명이 제공됩니다.
   • 각 단계에서 사용되는 입력 자원 및 서비스가 표시됩니다.
   • 각 단계 및 개별 단계의 결과가 표시됩니다.
   • 각 단계 및 단계에 대한 책임 영역이 표시됩니다.
   • HDD(SSD), RAM, vCPU와 같은 기술 리소스와 이 단계에서 작업을 지원하는 데 필요한 작업 시간(사실상 현재와 향후 계획)이 결정되었습니다.
   • 각 제품에 대해 어떤 기술 단계 또는 단계가 구현되었는지, 구현 계획이 있는지, 관련이 없거나 구현되지 않았는지 표시됩니다.

기술지도 기반 의사결정

맵을 검토한 후 회사 직원의 역할(개발 관리자, 제품 관리자, 개발자 또는 테스터)에 따라 몇 가지 작업을 수행할 수 있습니다.

• 실제 제품 또는 프로젝트에서 누락된 단계를 이해하고 구현 필요성을 평가합니다.
• 서로 다른 단계에서 작업하는 경우 여러 부서 간의 책임 영역을 구분합니다.
• 단계의 입구와 출구에서 계약에 동의합니다.
• 작업 단계를 전체 개발 프로세스에 통합합니다.
• 각 단계를 제공하는 리소스의 필요성을 보다 정확하게 평가합니다.

위의 모든 내용을 요약하면

라우팅은 다양하고 확장 가능하며 유지 관리가 쉽습니다. 엄격한 학술 IDEF0 모델보다 이 형식으로 프로세스 설명을 개발하고 유지하는 것이 훨씬 쉽습니다. 또한 표 형식의 설명은 기능 모델보다 더 간단하고 친숙하며 더 잘 구성되어 있습니다.

단계의 기술 구현을 위해 CI 시스템, 서비스 및 인프라 간의 레이어 도구인 특별한 내부 도구인 CrossBuilder가 있습니다. 개발자는 자전거를 자를 필요가 없습니다. CI 시스템에서 CrossBuilder 도구의 스크립트 중 하나(소위 작업)를 실행하면 인프라의 기능을 고려하여 올바르게 실행됩니다. .

결과

글이 꽤 길어졌는데, 복잡한 프로세스의 모델링을 설명하는데 있어서 불가피한 부분입니다. 마지막으로 주요 아이디어를 간단히 수정하고 싶습니다.

• 우리 회사에서 DevOps 아이디어를 구현하는 목표는 양적 측면(인시 또는 기계 시간, vCPU, RAM, 디스크)에서 회사 제품의 생산 및 유지 관리 비용을 지속적으로 줄이는 것입니다.
• 전체 개발 비용을 줄이는 방법은 일반적인 연속 작업(기술 프로세스의 단계 및 단계)을 수행하는 비용을 최소화하는 것입니다.
• 일반적인 작업은 솔루션이 완전히 또는 부분적으로 자동화되어 수행자에게 어려움을 일으키지 않으며 상당한 인건비가 필요하지 않은 작업입니다.
• 생산 공정은 단계로 구성되며, 단계는 서로 다른 규모와 범위의 일반적인 작업인 분할할 수 없는 단계로 나뉩니다.
• 서로 다른 일반적인 작업에서 우리는 기능적 IDEF0 모델 또는 더 간단한 기술 맵으로 설명할 수 있는 생산 프로세스의 복잡한 기술 체인 및 다단계 모델에 도달했습니다.
• 기술 지도는 생산 공정의 단계와 단계를 표로 나타낸 것입니다. 가장 중요한 점: 지도를 사용하면 전체 프로세스를 자세히 볼 수 있는 큰 조각으로 볼 수 있습니다.
• 기술지도를 기반으로 특정 제품에 단계를 도입해야 할 필요성을 평가하고, 책임 영역을 정의하고, 단계의 입력 및 출력에서 ​​계약에 동의하고, 자원의 필요성을 보다 정확하게 평가할 수 있습니다.

다음 기사에서는 맵에서 특정 기술 단계를 구현하는 데 사용되는 기술 도구에 대해 자세히 설명합니다.

기사 작성자:

• 알렉산더 파즈드니코프 — Positive Technologies의 자동화(DevOps) 책임자
• 티무르 길멀린 - 차장 Positive Technologies의 자동화 부서(DevOps) 책임자

출처 : habr.com