시스템 관리자, 개발자 및 테스터가 DevOps 사례를 배워야 하는 이유는 무엇입니까?

Express 42의 관리 파트너이자 저자인 Alexander Titov는 이 지식을 어디에서 얻을 수 있는지, 프로젝트에서 무엇을 해야 하는지, 얼마를 벌어야 하는지, 인터뷰에서 무엇을 말하고 질문해야 하는지를 말합니다. 온라인 과정 "DevOps 사례 및 도구".

안녕하세요! DevOps라는 용어는 2009년부터 존재했지만 러시아 커뮤니티에서는 아직 합의가 이루어지지 않았습니다. DevOps를 전문 분야로 생각하는 사람도 있고, 철학으로 생각하는 사람도 있고, 기술 집합이라는 용어로 생각하는 사람도 있다는 사실을 눈치채셨을 것입니다. 나는 이미 여러 번 공연을 해왔다. 강의 이 방향의 발전에 대해서는 다루지 않으므로 이 기사에서는 자세히 다루지 않겠습니다. Express 42에는 다음이 포함되어 있습니다.

DevOps는 팀의 모든 전문가가 생산에 참여하여 디지털 제품을 만드는 구체적인 방법론이자 문화입니다.

전통적인 기업 개발에서는 프로그래밍, 테스트, 운영 등 모든 것이 순차적으로 진행되며 아이디어에서 생산까지의 프로세스 속도는 3개월입니다. 이는 고객으로부터 신속하게 피드백을 받는 것이 불가능하기 때문에 디지털 제품의 세계적인 문제입니다.

DevOps에서 도구와 접근 방식은 개발, 테스트 및 운영 프로세스가 동시에 실행되도록 설계되었습니다.

이 접근 방식의 결과는 무엇입니까?

• 와서 생산과 관련된 모든 문제를 해결할 "엔지니어"를 고용할 수는 없습니다. 팀 전체가 이 기술을 적용해야 합니다.

  

• DevOps는 업그레이드할 다음 형태의 시스템 관리자가 아닙니다. "DevOps 엔지니어"는 "Agile 개발자"와 거의 동일하게 들립니다.

  
  

• 팀이 Kubernetes, Ansible, Prometheus, Mesosphere 및 Docker를 사용한다고 해서 DevOps 관행이 거기에 구현되었다는 의미는 아닙니다.

  
  

DevOps 이후의 삶은 결코 같지 않을 것입니다

DevOps 접근 방식은 무엇보다도 다른 사고 방식, 전체 개발에 대한 인식 및 프로세스에서의 자신의 위치입니다. 우리는 온라인 과정을 2개의 블록으로 나누었습니다:

1. 자기결정

먼저 DevOps 접근 방식의 본질을 자세히 검토하고 학생들은 팀에서 새로운 역할을 발견하고 어느 것이 더 많이 반응하는지 확인하고 어떤 방향으로 발전할지 스스로 결정합니다.

2. 도구 및 사례

학생들은 DevOps 방법의 관점에서 특정 기술을 습득합니다.

DevOps 도구는 DevOps 접근 방식과 기존 개발 모두에서 사용할 수 있습니다. 가장 확실한 예는 Ansible 구성 관리 도구를 사용하는 것입니다. DevOps 방식인 "코드로서의 인프라"를 구현하기 위해 만들어지고 고안되었습니다. 즉, 운영 체제 설정부터 애플리케이션 소프트웨어까지 시스템의 다양한 상태가 설명된다는 의미입니다. 설명은 여러 레이어로 나누어져 있으며 이를 통해 복잡하고 끊임없이 변화하는 구성을 관리할 수 있습니다. 그러나 엔지니어는 여러 시스템에서 bash 스크립트를 실행하는 방법으로 Ansible을 사용하는 경우가 많습니다. 이는 나쁘지도 좋지도 않지만, Ansible의 존재가 회사 내 DevOps의 존재를 보장하지는 않는다는 점을 이해해야 합니다.

우리는 진행 중입니다 강의 모놀리식 버전부터 시작하여 단계별로 마이크로서비스로 이동하면서 유명한 Reddit과 유사한 애플리케이션을 개발하는 과정에 몰입하게 됩니다. 단계별로 우리는 Git, Ansible, Gitlab과 같은 새로운 도구를 익히고 Kubernetes 및 Prometheus로 마무리합니다.

실습 측면에서 우리는 DevOps 핸드북에 설명된 세 가지 경로(지속적인 제공 실습, 피드백 실습)의 전술을 따를 것이며, 전체 과정의 본질은 시스템과 함께 지속적인 학습을 실천하는 것입니다.

이 지식은 각 전문가에게 무엇을 제공합니까?

시스템 관리자용

실습을 통해 관리에서 벗어나 지속적인 전달 파이프라인 및 소프트웨어 전달을 위한 인프라 플랫폼을 생성할 수 있습니다. 요점은 그가 제품, 즉 개발자가 변경 사항을 신속하게 프로덕션에 적용하는 데 도움이 되는 인프라 플랫폼을 만든다는 것입니다.

이전에는 시스템 관리자가 마지막 보루였으며 그 이후에는 모든 것이 생산에 들어갔습니다. 그리고 기본적으로 그들은 지속적인 소방 활동에 참여했습니다. 이를 고려하면 비즈니스 요구 사항을 조사하고 제품과 사용자 이점에 대해 생각하는 것이 매우 어렵습니다.
DevOps 방식 덕분에 생각이 바뀌었습니다. 시스템 관리자는 구성을 코드로 변환하는 방법과 이에 대한 관행이 무엇인지 이해합니다.

이는 기업이 모든 것을 자동화할 필요가 없다는 사실을 점점 더 깨닫고 있기 때문에 중요합니다. 기존 시스템 관리자가 기본적으로 수행했던 작업에서 이 관리자는 거의 의사소통을 하지 않았으며 모든 변경 사항에 대해 팀에 알리지 않았습니다. 이제 팀은 내부 인프라 제품의 제조업체가 되어 분리된 프로세스를 하나로 결합하는 데 도움을 줄 사람을 찾고 있습니다.

개발자

개발자는 알고리즘에서만 생각하지 않습니다. 그는 인프라 작업 기술, 풍경에 대한 건축 인식 기술을 습득합니다. 이러한 개발자는 애플리케이션이 작동하는 방식, 지속적인 전달 파이프라인을 통과하는 방식, 모니터링하는 방법, 클라이언트에 도움이 되도록 등록하는 방법을 이해합니다. 결과적으로 이 모든 지식을 통해 관련 코드를 작성할 수 있습니다.

테스터용

테스트는 오랫동안 자동 모드로 전환되어 왔습니다. 우리 모두는 많은 테스트를 수행하는 것이 아니라 작성해야 한다고 말합니다. :) 테스트는 제품의 전체 전달 파이프라인의 일부가 됩니다. 테스터는 코드 작성 방법을 배울 뿐만 아니라 코드를 지속적인 전달 시스템에 통합하는 방법, 전달의 모든 단계에서 코드로부터 피드백을 받는 방법, 오류를 감지하기 위해 지속적으로 테스트를 개선하는 방법을 이해해야 합니다. 가능한 한 일찍.

그래서 밝혀졌습니다 세 단계가 모두 동시에 발생합니다.. 예를 들어 다음과 같을 수 있습니다.

개발자는 코드를 작성하고, 즉시 이에 대한 테스트를 작성하고, 실행해야 하는 코드에 대한 Docker 컨테이너를 설명합니다. 또한 프로덕션에서 이 서비스의 작동을 모니터링하고 이 모든 것을 커밋하는 모니터링에 대해 즉시 설명합니다.

지속적인 통합이 시작되면 프로세스가 동시에 실행됩니다. 서비스가 시작되고 구성됩니다. 동시에 Docker 컨테이너가 시작되고 실행 중인지 확인됩니다. 동시에 모든 정보는 로깅 시스템으로 이동됩니다. 그리고 개발의 모든 단계에서 이는 시스템 관리자, 개발자 및 테스터의 진정한 팀워크로 드러납니다.

DevOps를 공부했습니다. 다음은 무엇인가요?

아시다시피 현장에 있는 사람은 전사가 아닙니다. 회사에서 이 방법을 사용하지 않으면 습득한 기술이 유휴 상태가 됩니다. 그리고 DevOps 접근 방식에 익숙해지면 기업 개발의 ​​톱니바퀴가 되고 싶지 않을 것입니다. 한 가지 예외가 있을 수 있습니다. 귀하는 팀의 시스템 관리자이며 모든 프로세스를 새로운 방식으로 다시 구축할 수 있습니다. 이 접근 방식을 사용하는 많은 회사가 있으며 폐쇄의 영향을 받지 않고 전문가를 찾고 있다는 점을 여기에 덧붙일 가치가 있습니다. DevOps는 온라인 제품을 만드는 것이기 때문입니다.

이제 좋은 점은 DevOps 관행과 도구를 숙달하면 노동 시장에서 귀하의 가치가 약 30% 증가한다는 것입니다. 급여는 140만 루블부터 시작하지만 당연히 주요 전문 분야와 기능에 따라 결정됩니다.

테스트 자동화, 클라우드 기술을 사용한 마이크로서비스 애플리케이션 개발, 인프라 엔지니어를 위한 공석 및 DevOps에 대한 모든 종류의 참조가 있는 "인프라 지향"으로 표시된 공석을 볼 수 있습니다. 각 회사는 이 정의에 따라 서로 다른 의미를 갖는다는 점을 기억하세요. 설명을 주의 깊게 읽어보세요.

과정을 시작하는 동안 나에게 통찰력이 생겼습니다. 과정을 마친 후 많은 사람들이 DevOps 엔지니어의 함정에 빠졌습니다. 그들은 위에서 언급한 제목의 공석을 찾고 좋은 제안을 받은 후 직장에 와서 Jenkins에서 3페이지 분량의 bash 스크립트를 유지해야 한다는 것을 깨달았습니다. Kubernetes, ChatOps, Canary 릴리스 등은 어디에 있나요? 하지만 회사에서는 방법론으로 DevOps가 필요하지 않고 개별 혁신을 사용하기 때문에 아무것도 없습니다.

이것이 소프트웨어 제공 프로세스가 어떻게 작동하는지, 기술 스택이 무엇인지, 어떤 책임을 수행할지 회사에서 집중적으로 알아내는 이유입니다.

고용주가 마치 책에서 나온 것처럼 세부 사항 없이 추상적으로 질문에 대답한다면 회사에 아직 DevOps 프로세스가 없을 가능성이 높지만 이것이 온라인에 있는지 여부에 관계없이 회사와 제품을 거부하고 연구할 이유는 아닙니다. 회사가 자체 개발하는 서비스, 모바일 애플리케이션, 제품 아이디어.

그렇다면 이러한 시스템을 직접 사용하여 작업해야 하는지, 아니면 DevOps 사례에서 좋은 결과를 보여주면서 이러한 서비스 팀으로 수평 이동이 가능한지 여부를 명확히 하세요. 그렇다면 적극적이고 유용하게 활동할 가치가 있으며, 우리 과정을 마치면 후자가 보장됩니다.

Devops 실무자는 개발/관리/테스트 경험을 통해서만 진정한 가치를 얻을 수 있다는 점에 유의하는 것이 중요합니다. 그래야만 지식이 추상적이지 않고 (모든 의미에서) 전문가를 풍요롭게 할 수 있습니다. 따라서 "DevOps를 처음부터 배운다"는 생각은 카메라를 손에 쥐거나 촬영을 지시한 적이 없다면 "처음부터 렌즈 사용"을 배우는 것과 거의 같습니다. 해당 과정이 귀하에게 적합한지 결정하는 데 도움을 주기 위해 우리는 귀하의 충분한 지식 수준을 확인하는 입학 시험을 만들었습니다.

제가 생각하는 비법 중 하나는 강의 — 훈련 과정에서 각 학생은 자신이 발전하고 싶은 방향을 스스로 결정합니다. 개발자가 인프라 엔지니어가 되고 관리자가 코드 작성에 관심이 있다는 것을 깨닫고 언어를 더 연구하고 습득한 DevOps 기술로 이를 보완하는 전환을 자주 볼 수 있습니다. 그러므로 우리는 특히 자신의 경력이 갈림길에 갇혀 있다고 느끼는 사람들을 환영합니다. 강좌는 28월 2일에 시작하지만, 강좌 시작 후 XNUMX주 후에 가입할 수 있습니다. 프로그램을 시청하고 시험을 치를 수 있습니다. 링크. 오투스에서 만나보세요!

출처 : habr.com