DevOps는 누구입니까?

현재 이 포지션은 시장에서 거의 가장 비싼 포지션입니다. "DevOps" 엔지니어를 둘러싼 소란은 상상할 수 있는 모든 한계를 넘어서며, 수석 DevOps 엔지니어의 경우 더욱 심합니다.
저는 통합 및 자동화 부서장으로 일하고 있는데 영어 디코딩-DevOps Manager를 추측합니다. 영어 성적표가 우리의 일상 활동을 반영할 가능성은 없지만 이 경우 러시아어 버전이 더 정확합니다. 활동 특성상 미래의 팀원들과 인터뷰를 해야 하는 것은 당연하고, 지난 50년 동안 XNUMX명 정도가 나를 거쳐갔고, 직원들과의 사전심사에서도 같은 숫자가 잘렸다.

DevOps라는 라벨 뒤에는 다양한 종류의 엔지니어가 숨어 있기 때문에 우리는 여전히 동료를 찾고 있습니다.

아래에 작성된 모든 내용은 제 개인적인 의견이므로 동의할 필요는 없지만 주제에 대한 귀하의 태도에 약간의 색상을 더할 것이라는 점을 인정합니다. 지지를 받지 못할 위험에도 불구하고 나는 그것이 있어야 할 자리가 있다고 믿기 때문에 내 의견을 발표합니다.

회사는 DevOps 엔지니어가 누구인지에 대해 서로 다른 이해를 갖고 있으며, 리소스를 신속하게 채용하기 위해 모든 사람에게 이 라벨을 붙입니다. 상황은 매우 이상합니다. 회사는 대부분의 경우 도구 관리자를 받아 이러한 사람들에게 비현실적인 보상을 지불할 준비가 되어 있기 때문입니다.

그렇다면 DevOps 엔지니어는 누구입니까?

등장의 역사부터 시작해 보겠습니다. 개발 운영은 예상되는 결과로 제품 생산 속도를 높이기 위해 소규모 팀의 상호 작용을 최적화하기 위한 또 다른 단계로 나타났습니다. 아이디어는 제품 환경 관리의 절차와 접근 방식에 대한 지식으로 개발 팀을 강화하는 것이었습니다. 즉, 개발자는 자신의 제품이 특정 조건에서 어떻게 작동하는지 이해하고 알아야 하며, 제품을 배포하는 방법, 성능 향상을 위해 조정될 수 있는 환경 특성을 이해해야 합니다. 그래서 한동안 DevOps 접근 방식을 사용하는 개발자가 나타났습니다. DevOps 개발자는 프로덕션 환경의 활동과 성능을 단순화하기 위해 빌드 및 패키징 스크립트를 작성했습니다. 그러나 솔루션 아키텍처의 복잡성과 시간이 지남에 따라 인프라 구성 요소의 상호 영향으로 인해 환경의 성능이 저하되기 시작했으며, 반복할 때마다 특정 구성 요소에 대한 점점 더 깊은 이해가 필요해 추가적인 작업으로 인해 개발자의 생산성이 저하되었습니다. 특정 작업을 위한 구성 요소 및 튜닝 시스템을 이해하는 데 드는 비용. 개발자 자신의 비용이 증가하고, 그에 따른 제품 비용도 증가했으며, 팀의 새로운 개발자에 대한 요구 사항도 급격히 높아졌습니다. 개발 "스타"의 책임도 감당해야 했기 때문이며, 자연스럽게 "스타"의 수가 줄어들었습니다. 그리고 더 적은 사용 가능. 내 경험상 운영 체제 커널, 패킷 라우팅 규칙 및 호스트 보안 측면에 의한 패킷 처리의 세부 사항에 관심이 있는 개발자는 거의 없다는 점도 주목할 가치가 있습니다. 논리적인 단계는 이에 대해 잘 알고 있는 관리자를 유치하고 그에게 유사한 책임을 할당하는 것이었습니다. 그의 경험 덕분에 "스타" 개발 비용에 비해 저렴한 비용으로 동일한 지표를 달성할 수 있었습니다. 이러한 관리자는 팀에 배치되었으며 그의 주요 임무는 특정 팀의 규칙에 따라 이 특정 팀에 할당된 리소스를 사용하여 테스트 및 프로덕션 환경을 관리하는 것이었습니다. 실제로 이것이 DevOps가 대다수의 마음 속에 나타난 방식입니다.

부분적으로 또는 완전히, 시간이 지남에 따라 이러한 시스템 관리자는 개발 분야에서 이 특정 팀의 요구 사항, 개발자와 테스터의 삶을 더 쉽게 만드는 방법, 업데이트를 출시하는 방법 및 금요일에 밤새 머물 필요가 없는 방법을 이해하기 시작했습니다. 사무실, 배포 오류 수정. 시간이 흘러 이제 "스타"는 개발자가 원하는 것을 이해하는 시스템 관리자였습니다. 영향을 최소화하기 위해 관리 유틸리티가 등장하기 시작했고, 모두가 OS 수준을 격리하는 오래되고 안정적인 방법을 기억하여 보안 요구 사항, 네트워크 부분 관리 및 호스트 구성에 대한 요구 사항을 최소화할 수 있었습니다. 전체적으로 결과적으로 새로운 "별"에 대한 요구 사항이 줄어 듭니다.

"멋진" 것이 나타났습니다. 바로 docker입니다. 왜 멋진가요? 예, OpenVZ뿐만 아니라 chroot나 감옥에서 격리를 생성하려면 OS에 대한 사소한 지식이 필요하기 때문에 이 유틸리티를 사용하면 필요한 모든 것을 내부 및 손으로 특정 호스트에 격리된 응용 프로그램 환경을 간단하게 만들 수 있습니다. 개발의 고삐를 다시 넘겨 시스템 관리자는 단 하나의 호스트로만 관리할 수 있으므로 보안과 고가용성이 보장됩니다. 이는 논리적 단순화입니다. 그러나 진전은 멈추지 않고 시스템은 점점 더 복잡해지고 구성요소는 점점 더 많아지며 하나의 호스트는 더 이상 시스템 요구 사항을 충족하지 못하고 클러스터를 구축해야 합니다. 우리는 다시 시스템 관리자에게 돌아가서 이러한 시스템을 구축할 수 있습니다.

주기마다 개발 및/또는 관리를 단순화하는 다양한 시스템이 나타나고 표준 프로세스에서 벗어나야 할 때까지 사용하기 쉬운 오케스트레이션 시스템이 나타납니다. 마이크로서비스 아키텍처는 위에서 설명한 모든 것을 단순화하려는 목적으로 등장했습니다. 즉, 관계가 적고 관리가 더 쉬워졌습니다. 내 경험상 완전한 마이크로서비스 아키텍처를 찾지 못했습니다. 마이크로서비스의 50~50%, 블랙박스가 들어와서 처리되고 나머지 50개는 찢어진 단일체이며 서비스는 다른 서비스와 별도로 작동할 수 없습니다. 구성 요소. 이 모든 것이 개발자와 관리자 모두의 지식 수준에 다시 제한을 가했습니다.

특정 자원에 대한 전문 지식 수준의 유사한 "스윙"이 오늘날에도 계속됩니다. 그러나 우리는 조금 벗어나서 강조할 만한 점이 많이 있습니다.

빌드 엔지니어/릴리스 엔지니어

소프트웨어 빌드 프로세스 및 릴리스를 표준화하는 수단으로 등장한 고도로 전문화된 엔지니어입니다. Agile을 널리 도입하는 과정에서 수요가 사라진 것처럼 보이지만 사실은 그렇지 않습니다. 이 전문화는 산업 규모의 소프트웨어 조립 및 제공을 표준화하는 수단으로 나타났습니다. 모든 회사 제품에 표준 기술을 사용합니다. DevOps의 출현으로 개발자는 제품 제공을 준비하기 시작한 것이 개발자 였기 때문에 부분적으로 기능을 잃었고, 변화하는 인프라와 품질에 관계없이 최대한 빨리 제공하는 접근 방식을 고려하여 시간이 지남에 따라 그들은 품질 표준을 준수하면 필연적으로 배송 속도가 느려지기 때문에 변화를 막을 수 있습니다. 따라서 점차적으로 빌드/릴리스 엔지니어의 기능 중 일부가 시스템 관리자의 어깨로 마이그레이션되었습니다.

옵스가 너무 다르네요

우리는 계속해서 다양한 책임을 맡고 자격을 갖춘 인력이 부족하여 엄격한 전문화를 향해 나아가고 있습니다. 비가 내린 후의 버섯처럼 다양한 작업이 나타납니다.

• TechOps - 헬프데스크 엔지니어라고도 알려진 enikey 시스템 관리자
• LiveOps - 프로덕션 환경을 주로 담당하는 시스템 관리자
• CloudOps - 퍼블릭 클라우드 Azure, AWS, GCP 등을 전문으로 하는 시스템 관리자입니다.
• PlatOps/InfraOps/SysOps - 인프라 시스템 관리자.
• NetOps - 네트워크 관리자
• SecOps - 정보 보안을 전문으로 하는 시스템 관리자 - PCI 규정 준수, CIS 규정 준수, 패치 적용 등

DevOps는 (이론적으로) 개발 주기의 모든 프로세스(개발, 테스트, 제품 아키텍처 이해, 보안 위험 평가 가능)를 직접 이해하고 최소한 높은 수준의 접근 방식 및 자동화 도구에 익숙한 사람입니다. 레벨은 이 외에도 제품 출시 지원 전처리 및 후처리도 이해합니다. 운영과 개발 모두에 대한 옹호자 역할을 할 수 있는 사람으로, 이 두 기둥 사이의 유리한 협력을 가능하게 합니다. 팀별 작업 계획 및 고객 기대 관리 프로세스를 이해합니다.

이러한 종류의 작업과 책임을 수행하려면 이 사람은 개발 및 테스트 프로세스뿐만 아니라 제품 인프라 관리 및 리소스 계획도 관리할 수 있는 수단을 가지고 있어야 합니다. 이러한 이해에서 DevOps는 IT, R&D 또는 PMO에 위치할 수 없으며 회사의 기술 이사, 최고 기술 책임자(CTO) 등 모든 영역에 영향력을 행사해야 합니다.

이것이 귀하의 회사에서도 사실입니까? - 의심스럽습니다. 대부분의 경우 이는 IT 또는 R&D입니다.

이러한 세 가지 활동 영역 중 적어도 하나에 영향을 미칠 수 있는 자금과 능력이 부족하면 문제의 무게는 이러한 변경 사항을 적용하기 더 쉬운 곳으로 옮겨질 것입니다. 분석기 시스템. 즉, PMO가 기능 출시에 대해 엄격한 기한을 정하면 R&D에서는 이 기한 내에 고품질의 결과를 내지 못하고 최선을 다해 생산하고, 리팩토링은 나중으로 미루고, IT 관련 DevOps에서는 기술적 수단을 이용해 출시를 막는다. . 책임 있는 직원의 경우 상황을 변경할 수 있는 권한이 부족하면 자신이 영향을 미칠 수 없는 것에 대한 과도한 책임이 나타납니다. 특히 이러한 직원이 실수를 이해하고 확인하는 경우 및 이를 수정하는 방법인 "행복은 무지입니다", 결과적으로 이러한 직원의 소진 및 손실이 발생합니다.

DevOps 리소스 시장

다양한 회사의 DevOps 직위에 대한 여러 공석을 살펴보겠습니다.

귀하가 다음과 같은 경우 우리는 귀하를 만날 준비가 되어 있습니다:

1. 당신은 Zabbix를 소유하고 있으며 Prometheus가 무엇인지 알고 있습니다.
2. IP테이블;
3. BASH 박사과정 학생;
4. 앤서블 교수;
5. 리눅스 전문가;
6. 개발자와 함께 디버깅을 사용하고 애플리케이션 문제를 찾는 방법을 알아보세요(php/java/python).
7. 라우팅이 당신을 히스테리하게 만들지는 않습니다.
8. 시스템 보안에 상당한 주의를 기울이십시오.
9. "모든 것"을 백업하고 이 "모든 것"을 성공적으로 복원합니다.
10. 당신은 최소에서 최대를 얻는 방식으로 시스템을 구성하는 방법을 알고 있습니다.
11. Postgres 및 MySQL에서 잠자리에 들기 전에 복제를 설정하십시오.
12. CI/CD 설정 및 조정은 아침/점심/저녁만큼 필요합니다.
13. AWS 사용 경험이 있습니다.
14. 회사와 함께 발전할 준비가 되었습니다.

그래서 :

• 1부터 6까지 - 시스템 관리자
• 7 - 시스템 관리자에게도 적합한 약간의 네트워크 관리, 중간 수준
• 8 - 중간 수준의 시스템 관리자에게 필수적인 약간의 보안
• 9-11 – 중간 시스템 관리자
• 12 — 할당된 작업에 따라 중간 시스템 관리자 또는 빌드 엔지니어
• 13 - 가상화 - 자금을 효율적으로 사용하고 유지 관리에 대한 부하를 줄이기 위해 중간 시스템 관리자 또는 소위 CloudOps, 특정 호스팅 사이트의 서비스에 대한 고급 지식

이 공석을 요약하면 중간/고위 시스템 관리자가 남자들에게 충분하다고 말할 수 있습니다.

그런데 Linux/Windows에서는 관리자를 강력하게 나누면 안 됩니다. 물론, 나는 이 두 세계의 서비스와 시스템이 다르다는 것을 이해하지만 모든 것의 기본은 동일하며 자존심이 강한 관리자라면 둘 다에 익숙하며 익숙하지 않더라도 유능한 관리자가 익숙해지는 것은 어렵지 않습니다.

또 다른 공석을 고려해 봅시다:

1. 고부하 시스템 구축 경험
2. Linux OS, 일반 시스템 소프트웨어 및 웹 스택(Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK)에 대한 탁월한 지식
3. 가상화 시스템(KVM, VMWare, LXC/Docker) 사용 경험
4. 스크립팅 언어에 대한 능숙도
5. 네트워크 프로토콜 네트워크의 작동 원리에 대한 이해
6. 내결함성 시스템 구축 원칙에 대한 이해
7. 독립성과 주도성;

다음을 살펴보자:

• 1 – 수석 시스템 관리자
• 2 - 이 스택에 담긴 의미에 따라 - 중간/고위 시스템 관리자
• 3 - 업무 경험은 다음을 의미할 수 있습니다. - "클러스터가 생성되지 않았지만 가상 머신을 생성 및 관리했으며 Docker 호스트가 하나 있었고 컨테이너에 대한 액세스를 사용할 수 없었습니다." - 중간 시스템 관리자
• 4 - 주니어 시스템 관리자 - 예, 관리자가 아닌 언어에 관계없이 기본 자동화 스크립트를 작성하는 방법을 모르는 관리자 - enikey입니다.
• 5 - 중간 시스템 관리자
• 6 – 수석 시스템 관리자

요약 - 중간/고위 시스템 관리자

하나 더:

1. 데브옵스 경험;
2. 하나 이상의 제품을 사용하여 CI/CD 프로세스를 생성한 경험. Gitlab CI가 유리할 것입니다.
3. 컨테이너 및 가상화 작업 docker를 사용했다면 좋지만 k8s를 사용했다면 좋습니다!
4. 민첩한 팀에서 일한 경험
5. 모든 프로그래밍 언어에 대한 지식

보자 :

• 1 - 흠... 그 사람들은 무슨 뜻인가요? =) 아마도 그들 자신은 그 뒤에 무엇이 숨겨져 있는지 알지 못할 것입니다.
• 2 - 빌드 엔지니어
• 3 - 중간 시스템 관리자
• 4 - 소프트 스킬, Agile은 편리한 방식으로 해석되는 또 다른 것이지만 지금은 고려하지 않습니다.
• 5 - 너무 장황합니다. 스크립팅 언어일 수도 있고 컴파일된 언어일 수도 있습니다. 학교에서 Pascal과 Basic으로 글을 쓰는 것이 그들에게 적합한지 궁금합니다. =)

또한 시스템 관리자가 이 항목을 다루는 이유에 대한 이해를 돕기 위해 항목 3에 대한 메모를 남기고 싶습니다. Kubernetes는 네트워크 드라이버 및 가상화/격리 호스트에 대한 직접 명령을 몇 가지 명령으로 래핑하고 추상적인 통신을 가능하게 하는 도구인 오케스트레이션일 뿐입니다. 그게 전부입니다. 예를 들어 '빌드 프레임워크' Make를 생각해 봅시다. 그런데 저는 프레임워크를 고려하지 않습니다. 예, 저는 필요하거나 필요하지 않은 곳 어디에서나 Make를 밀어넣는 방식을 알고 있습니다. 예를 들어 Maven을 Make에 래핑하는 것이 진지하게요?
본질적으로 Make는 k8s와 마찬가지로 셸에 대한 래퍼일 뿐이며 컴파일, 링크 및 컴파일 환경 명령을 단순화합니다.

한번은 OpenStack 위에서 k8s를 작업에 사용하는 한 사람을 인터뷰하여 그가 어떻게 서비스를 배포했는지에 대해 이야기했습니다. 그러나 OpenStack에 대해 물었을 때 시스템에 의해 관리될 뿐만 아니라 제기되는 것으로 나타났습니다. 관리자. 정말 OpenStack을 설치한 사람은 뒤에 어떤 플랫폼을 사용하든 k8s를 사용할 수 없다고 생각하시나요? =)
이 지원자는 실제로 DevOps가 아니라 시스템 관리자, 더 정확하게 말하면 Kubernetes 관리자입니다.

다시 한 번 요약하자면 중간/고위 시스템 관리자이면 충분합니다.

그램 단위로 무게를 측정하는 방법

표시된 공석에 대해 제안된 급여 범위는 90k-200k입니다.
이제 저는 시스템 관리자와 DevOps 엔지니어의 금전적 보상 사이에 유사점을 그려보고 싶습니다.

원칙적으로 일을 단순화하기 위해 업무 경험에 따라 성적을 흩뿌릴 수 있습니다. 비록 이것이 정확하지는 않지만 기사의 목적으로는 충분할 것입니다.

경험 :

1. 최대 3세 – 주니어
2. 6세 이하 – 중년
3. 6세 이상 – 시니어

직원 검색 사이트는 다음을 제공합니다.
시스템 관리자:

1. 주니어 – 2세 – 50 문지름
2. 중간 - 5년 - 70 문지름.
3. 시니어 - 11세 - 100만 문지름.

DevOps 엔지니어:

1. 주니어 – 2세 – 100 문지름
2. 중간 - 3년 - 160 문지름.
3. 시니어 - 6세 - 220만 문지름.

"DevOps"의 경험에 따르면 적어도 SDLC에 영향을 미친 경험이 사용되었습니다.

위에서부터 실제로 기업에는 DevOps가 필요하지 않으며, 관리자를 고용하면 초기 계획 비용의 50% 이상을 절약할 수 있으며, 또한 찾고 있는 사람의 책임을 보다 명확하게 정의할 수 있습니다. 그리고 필요를 더 빨리 채우십시오. 또한 명확한 책임 분담을 통해 인력에 대한 요구 사항을 줄일 수 있을 뿐만 아니라 중복이 없기 때문에 팀 내에서 보다 유리한 분위기를 조성할 수 있다는 사실도 잊어서는 안 됩니다. 대다수의 공석은 유틸리티 및 DevOps 레이블로 가득 차 있지만 DevOps 엔지니어에 대한 실제 요구 사항을 기반으로 한 것이 아니라 도구 관리자에 대한 요청만 기반으로 합니다.

DevOps 엔지니어 교육 프로세스도 특정 작업, 유틸리티 집합으로만 제한되며 프로세스 및 해당 종속성에 대한 일반적인 이해를 제공하지 않습니다. 콘솔에서 단 하나의 명령만 사용하여 이 클러스터의 Fluentd 사이드카 및 로깅 시스템용 AWS ELK 스택과 함께 Terraform을 사용하여 AWS EKS를 10분 안에 배포할 수 있다면 확실히 좋습니다. 로그 자체를 처리하는 원칙과 로그에 필요한 사항에 대한 메트릭을 수집하고 서비스 저하를 추적하는 방법을 모르는 경우 일부 유틸리티를 사용하는 방법을 아는 사람은 여전히 ​​​​동일한 enikey입니다.

그러나 수요는 공급을 창출하며 DevOps 위치에 대한 시장은 극도로 과열되어 요구 사항이 실제 역할과 일치하지 않고 시스템 관리자에게만 더 많은 수익을 허용합니다.

그럼 그들은 누구입니까? DevOps 또는 탐욕스러운 시스템 관리자입니까? =)

어떻게 살 것인가?

고용주는 요구 사항을보다 정확하게 공식화하고 필요한 사람을 정확히 찾아야하며 라벨을 버리지 않아야합니다. DevOps가 무엇을 하는지 알지 못합니다. 이 경우 DevOps가 필요하지 않습니다.

노동자 - 배우십시오. 지속적으로 지식을 향상시키고, 프로세스의 전반적인 그림을 살펴보고, 목표를 향한 경로를 추적하세요. 당신은 당신이 원하는 사람이 될 수 있습니다. 노력하기 만하면됩니다.

출처 : habr.com