DevOps가 필요한 이유는 무엇이며 DevOps 전문가는 누구입니까?

응용 프로그램이 작동하지 않을 때 동료로부터 마지막으로 듣고 싶은 말은 "문제는 당신 편입니다."라는 말입니다. 결과적으로 사용자는 고통을 겪으며 팀의 어느 부분이 고장에 책임이 있는지 신경 쓰지 않습니다. DevOps 문화는 최종 제품에 대한 공동 책임을 중심으로 개발과 지원을 함께 가져오기 위해 정확하게 등장했습니다.

DevOps 개념에는 어떤 관행이 포함되어 있으며 왜 필요한가요? DevOps 엔지니어는 무엇을 하며 무엇을 할 수 있어야 합니까? EPAM의 전문가들은 시스템 엔지니어이자 DevOps 전도사인 Kirill Sergeev와 회사 DevOps 팀 중 하나의 수석 시스템 엔지니어이자 코디네이터인 Igor Boyko와 같은 질문에 답합니다.

DevOps가 필요한 이유는 무엇입니까?

이전에는 개발자와 지원(소위 운영) 사이에 장벽이 있었습니다. 역설적으로 들리겠지만, 같은 일을 하고 있어도 목표와 KPI가 달랐습니다. 개발 목표는 비즈니스 요구 사항을 최대한 빨리 구현하고 이를 작동하는 제품에 추가하는 것이었습니다. 지원팀은 애플리케이션이 안정적으로 작동하는지 확인하는 역할을 담당했으며, 변경 사항이 있으면 안정성이 위험해졌습니다. 이해 상충이 있습니다. 이를 해결하기 위해 DevOps가 등장했습니다.

DevOps란 무엇입니까?

좋은 질문이자 논란의 여지가 있는 질문입니다. 세계는 아직 이에 대해 최종적으로 동의하지 않았습니다. EPAM은 DevOps가 팀 내 기술, 프로세스 및 상호 작용 문화를 결합한다고 믿습니다. 이 협회는 최종 사용자에게 지속적으로 가치를 제공하는 것을 목표로 합니다.

키릴 세르게예프: “개발자는 코드를 작성하고, 테스터는 이를 검토하며, 관리자는 최종 제품을 프로덕션에 배포합니다. 오랫동안 팀의 이러한 부분은 다소 분산되어 있었지만 공통 프로세스를 통해 이들을 통합하려는 아이디어가 생겼습니다. 이것이 DevOps 관행이 나타난 방식입니다.”

개발자와 시스템 엔지니어가 서로의 작업에 관심을 갖게 되는 날이 왔습니다. 생산과 지원 사이의 장벽이 사라지기 시작했습니다. 이것이 관행, 문화 및 팀 상호 작용을 포함하는 DevOps가 등장한 방식입니다.

DevOps 문화의 본질은 무엇입니까?

사실 최종 결과에 대한 책임은 각 팀원에게 있습니다. DevOps 철학에서 가장 흥미롭고 어려운 점은 특정 사람이 자신의 작업 단계만 책임지는 것이 아니라 전체 제품이 작동하는 방식에 대해서도 책임이 있다는 점을 이해하는 것입니다. 문제는 누구의 편이 아닙니다. 문제는 공유되고 각 팀원이 문제 해결을 돕습니다.

DevOps 문화에서 가장 중요한 것은 DevOps 방식을 적용하는 것뿐만 아니라 문제를 해결하는 것입니다. 더욱이 이러한 관행은 '누군가 측'에서 구현되는 것이 아니라 제품 전체에 걸쳐 구현됩니다. 프로젝트에는 DevOps 엔지니어 자체가 필요하지 않습니다. 문제에 대한 솔루션이 필요하며 DevOps 엔지니어의 역할은 다양한 전문 분야를 가진 여러 팀 구성원에게 분산될 수 있습니다.

DevOps 방식에는 어떤 유형이 있나요?

DevOps 방식은 소프트웨어 수명 주기의 모든 단계를 포괄합니다.

이고르 보이코: “이상적인 사례는 프로젝트 시작과 동시에 DevOps 방식을 사용하기 시작하는 경우입니다. 우리는 아키텍트와 함께 애플리케이션이 어떤 종류의 아키텍처 환경을 갖게 될지, 어디에 위치할지, 어떻게 확장할지 계획하고 플랫폼을 선택합니다. 요즘에는 마이크로서비스 아키텍처가 유행하고 있습니다. 이를 위해 우리는 오케스트레이션 시스템을 선택합니다. 즉, 애플리케이션의 각 요소를 별도로 관리하고 다른 요소와 독립적으로 업데이트할 수 있어야 합니다. 또 다른 방법은 "코드로서의 인프라"입니다. 이는 서버와의 직접적인 상호 작용이 아닌 코드를 사용하여 프로젝트 인프라를 생성하고 관리하는 접근 방식의 이름입니다.

다음으로 개발 단계로 넘어갑니다. 여기서 가장 큰 사례 중 하나는 CI/CD를 구축하는 것입니다. 즉, 개발자가 변경 사항을 제품에 신속하게, 작은 부분씩, 더 자주, 쉽게 통합할 수 있도록 도와야 합니다. CI/CD에서는 코드 검토, 마스터를 코드 베이스에 업로드, 테스트 및 프로덕션 환경에 애플리케이션 배포를 다룹니다.

CI/CD 단계에서 코드는 품질 게이트를 통과합니다. 도움을 받아 개발자의 워크스테이션에서 나오는 코드가 지정된 품질 기준을 충족하는지 확인합니다. 여기에 단위 및 UI 테스트가 추가되었습니다. 빠르고 간편하며 집중적인 제품 배포를 위해 적절한 배포 유형을 선택할 수 있습니다.

DevOps 실무자는 완제품을 지원하는 단계에서도 자리를 잡습니다. 모니터링, 피드백, 보안 및 변경 사항 도입에 사용됩니다. DevOps는 지속적인 개선 관점에서 이러한 모든 작업을 살펴봅니다. 반복적인 작업을 최소화하고 자동화합니다. 여기에는 마이그레이션, 애플리케이션 확장, 성능 ​​지원도 포함됩니다.”

DevOps 방식의 이점은 무엇입니까?

현대 DevOps 사례에 대한 교과서를 작성한다면 첫 페이지에는 자동화, 릴리스 속도 향상, 사용자의 신속한 피드백이라는 세 가지 요점이 있을 것입니다.

키릴 세르게예프: “첫 번째는 자동화입니다. 우리는 팀의 모든 상호 작용을 자동화할 수 있습니다. 코드 작성 - 출시 - 확인 - 설치 - 피드백 수집 - 처음으로 돌아갑니다. 이 모든 것은 자동입니다.

두 번째는 릴리스 속도를 높이고 개발을 단순화하는 것입니다. 제품이 가능한 한 빨리 시장에 출시되고 경쟁사의 유사 제품보다 먼저 혜택을 제공하기 시작하는 것이 고객에게 항상 중요합니다. 제품 배송 프로세스는 시간 단축, 제어 표시 추가, 모니터링 개선 등 끝없이 개선될 수 있습니다.

세 번째는 사용자 피드백의 가속화입니다. 그가 의견이 있으면 즉시 조정하고 애플리케이션을 즉시 업데이트할 수 있습니다.”

"시스템 엔지니어", "빌드 엔지니어" 및 "DevOps 엔지니어"의 개념은 어떤 관련이 있나요?

서로 겹치지만 약간 다른 영역에 속합니다.

EPAM의 시스템 엔지니어 직위입니다. 그들은 주니어부터 수석 전문가까지 다양한 수준으로 구성됩니다.

빌드 엔지니어는 프로젝트에서 수행할 수 있는 역할에 더 가깝습니다. 이제 CI/CD를 담당하는 사람들을 이렇게 부릅니다.

DevOps 엔지니어는 프로젝트에서 DevOps 방식을 구현하는 전문가입니다.

모두 요약하면 다음과 같습니다. 시스템 엔지니어 위치에 있는 사람은 프로젝트에서 빌드 엔지니어 역할을 하며 그곳에서 DevOps 관행 구현에 참여합니다.

DevOps 엔지니어는 정확히 어떤 일을 하나요?

DevOps 엔지니어는 프로젝트를 구성하는 모든 부분을 하나로 모았습니다. 그들은 프로그래머, 테스터, 시스템 관리자의 작업 세부 사항을 알고 작업을 단순화하는 데 도움을 줍니다. 그들은 비즈니스의 요구 사항과 요구 사항, 개발 프로세스에서의 역할을 이해하고 고객의 이익을 고려하여 프로세스를 구축합니다.

우리는 자동화에 대해 많이 이야기했습니다. 이는 DevOps 엔지니어가 가장 먼저 다루는 문제입니다. 이것은 무엇보다도 환경 준비를 포함하는 매우 큰 요점입니다.

키릴 세르게예프: “제품에 업데이트를 구현하기 전에 타사 환경에서 테스트를 거쳐야 합니다. DevOps 엔지니어가 준비했습니다. 그들은 프로젝트 전체에 DevOps 문화를 심어줍니다. 즉, 프로젝트의 모든 계층에 DevOps 관행을 도입합니다. 자동화, 단순화, 가속화라는 세 가지 원칙은 도달할 수 있는 곳이면 어디든 가져옵니다.”

DevOps 엔지니어는 무엇을 알아야 합니까?

전반적으로 그는 프로그래밍, 운영 체제 작업, 데이터베이스, 어셈블리 및 구성 시스템 등 다양한 분야에 대한 지식을 가지고 있어야 합니다. 이는 클라우드 인프라, 오케스트레이션 및 모니터링 시스템을 사용하는 기능으로 보완됩니다.

1. 프로그래밍 언어

DevOps 엔지니어는 자동화를 위한 몇 가지 기본 언어를 알고 있으며 예를 들어 프로그래머에게 다음과 같이 말할 수 있습니다. “코드를 직접 설치하지 않고 모든 것을 자동화하는 스크립트를 사용하여 설치하는 것은 어떻습니까? 이에 대한 구성 파일을 준비하겠습니다. 이 파일은 귀하와 우리 모두가 읽기 편리하며 언제든지 변경할 수 있습니다. 또한 누가, 언제, 왜 변경하는지 알아볼 것입니다.”

DevOps 엔지니어는 Python, Groovy, Bash, Powershell, Ruby, Go 중 하나 이상의 언어를 배울 수 있습니다. 이를 깊은 수준에서 알 필요는 없습니다. 구문의 기본, OOP 원칙 및 자동화를 위한 간단한 스크립트를 작성하는 능력이면 충분합니다.

2. 운영체제

DevOps 엔지니어는 제품이 설치될 서버, 제품이 실행될 환경, 상호 작용할 서비스를 이해해야 합니다. Windows 또는 Linux 제품군을 전문적으로 선택할 수 있습니다.

3. 버전 관리 시스템

버전 관리 시스템에 대한 지식이 없으면 DevOps 엔지니어는 어디에도 없습니다. Git은 현재 가장 인기 있는 시스템 중 하나입니다.

4. 클라우드 제공업체

AWS, Google, Azure - 특히 Windows 방향에 관해 이야기하는 경우.

키릴 세르게예프: “클라우드 제공업체는 CI/CD에 완벽하게 맞는 가상 서버를 제공합니다.

XNUMX개의 물리적 서버를 설치하려면 약 XNUMX번의 수동 작업이 필요합니다. 각 서버를 수동으로 시작하고 필요한 운영 체제를 설치 및 구성하고 이 XNUMX개의 서버에 애플리케이션을 설치한 다음 모든 것을 XNUMX번 다시 확인해야 합니다. 클라우드 서비스는 이 절차를 XNUMX줄의 코드로 대체하며, 훌륭한 DevOps 엔지니어는 이를 통해 작업할 수 있어야 합니다. 이를 통해 고객과 회사 모두의 시간, 노력, 비용이 절약됩니다.”

5. 오케스트레이션 시스템: Docker 및 Kubernetes

키릴 세르게예프: “가상 서버는 컨테이너로 나누어져 있으며 각 컨테이너에 애플리케이션을 설치할 수 있습니다. 컨테이너가 많으면 관리해야 합니다. 하나를 켜고, 다른 하나를 끄고, 어딘가에 백업해 두세요. 이는 매우 복잡해지고 오케스트레이션 시스템이 필요합니다.

이전에는 각 애플리케이션이 별도의 서버에 의해 처리되었습니다. 따라서 운영상의 변경 사항이 애플리케이션의 서비스 가능성에 영향을 미칠 수 있었습니다. 컨테이너 덕분에 애플리케이션은 격리되어 각각 자체 가상 머신에서 별도로 실행됩니다. 장애가 발생하면 원인을 찾는 데 시간을 낭비할 필요가 없습니다. 기존 컨테이너를 폐기하고 새 컨테이너를 추가하는 것이 더 쉽습니다."

6. 구성 시스템: Chef, Ansible, Puppet

전체 서버를 유지 관리해야 하는 경우 동일한 유형의 작업을 많이 수행해야 합니다. 시간이 오래 걸리고 어려우며, 수작업으로 인해 오류가 발생할 확률도 높아집니다. 구성 시스템이 구출되는 곳입니다. 이들의 도움을 받아 프로그래머, DevOps 엔지니어 및 시스템 관리자가 쉽게 읽을 수 있는 스크립트를 만듭니다. 이 스크립트는 서버에서 동일한 작업을 자동으로 수행하는 데 도움이 됩니다. 이렇게 하면 수동 작업(따라서 오류)이 줄어듭니다.

DevOps 엔지니어는 어떤 종류의 경력을 쌓을 수 있나요?

수평, 수직 모두 개발이 가능합니다.

이고르 보이코: “수평적 개발의 관점에서 DevOps 엔지니어는 이제 가장 광범위한 전망을 가지고 있습니다. 모든 것이 끊임없이 변화하고 있으며 버전 제어 시스템에서 모니터링, 구성 관리에서 데이터베이스에 이르기까지 다양한 영역에서 기술을 구축할 수 있습니다.

직원이 개발부터 지원까지 라이프사이클의 모든 단계에서 애플리케이션이 어떻게 작동하는지 이해하는 데 관심이 있다면 시스템 설계자가 될 수 있습니다.”

DevOps 엔지니어가 되는 방법은 무엇입니까?

1. Phoenix 프로젝트 및 DevOps 핸드북을 읽어보세요. 이는 DevOps 철학의 진정한 기둥이며 첫 번째는 허구입니다.
2. 위 목록의 기술을 직접 배우거나 온라인 과정을 통해 배우십시오.
3. 오픈 소스 프로젝트의 DevOps 엔지니어로 참여하세요.
4. 개인 및 업무 프로젝트에서 DevOps 사례를 연습하고 제공하세요.

출처 : habr.com