왜 'DevOps 엔지니어'를 고용하려고하지 않아야합니까?

최근 DevOps 엔지니어를 보유 하고 있다는 아이디어가 인기를 얻었 으며 Puppet 블로그에 설명 된 것처럼 DevOps의 많은 이점을 제공하고 제공 할 수있는 사람을 확보하는 것이 매력적입니다 .

DevOps 사례를 사용하는 조직은 압도적으로 높은 기능을 수행합니다 .2015 DevOps State 보고서에 따르면, 경쟁 업체보다 최대 30 배 더 자주 코드를 배포하고 배포의 50 %가 실패합니다.

그러나 DevOps 엔지니어가 이러한 개선을 시도하려는 아이디어에 대해 많은 반대 의견이있었습니다.

핵심 DevOps 속성에 대한 광범위한 동의에도 불구하고 논쟁은 "DevOps 엔지니어"라는 용어를 둘러 쌉니다. 일부 용어는 용어 자체가 DevOps 값과 모순된다고 말합니다. Continuous Delivery의 공동 저자 인 Jez Humble은 누군가 DevOps 엔지니어에게 전화하면 dev 및 ops 외에도 세 번째 사일로를 만들 수 있다고 지적합니다. "

비즈니스에서 DevOps 엔지니어를 고용하여 이와 같은 블로그가 주장하는 조직 변화와 달리 DevOps를 구현하고 시도하는 것이 그렇게 좋은 아이디어가 아닌 이유는 무엇 입니까? 격리 된 DevOps 역할만으로 혜택이 무효화됩니까?

TL; DR : DevOps 팀 을 고용 해서는 안됩니다

기본적으로 세 가지 가장 일반적인 역할이 있습니다.

1. DevOps 아키텍트 / 전도자
2. DevOps 엔지니어
3. CI / CD 엔지니어

이러한 역할은 전통적으로 소프트웨어 엔지니어링 조직을 구성하는 6 가지 필수 소프트웨어 개발 역할과 다릅니다.

1. 제품 관리
2. 소프트웨어 개발
3. 도구 개발
4. 보안 및 규정 준수
5. 품질 및 테스트
6. 시스템 운영 (SRE)

세 가지 역할을 하나씩 살펴보고 각각의 역할을 살펴 보겠습니다.

DevOps 아키텍트 또는 전도자

• 이유 : 당신이 길을 잃고, 느리고, 깨졌으며 무엇을해야할지 모른다면.
• 시기 : 계획 단계에서 프로세스 시작시.
• 내용 : 전체 소프트웨어 엔지니어링 조직의 모든 관리자 및 리드를 안내하는 관리 수준의 역할 이 사람은 엔지니어링 조직의 전체 전환을 고기능 상태로 계획 할 것입니다.
• 누가 : 컨설팅 엔지니어는 소프트웨어 엔지니어링 부사장에게 직접보고하는 이론, 관리 관행, 문화 주제 및 운영에 정통합니다.

경우에 따라 중소 기업의 경우 DORA와 같은 컨설팅 조직을 고용하는 대신 프로세스를 시작할 수 있습니다.

DevOps 엔지니어

• 왜 :
  1. 상호 기능 수준의 협력을 보장하기 위해 위에서 언급 한 기능적 역할을 따라 조직 된 팀 간의 격차를 해소합니다.
  2. 팀에 포함 된 6 개의 기존 역할을 각각 갖춘 제품 지향 팀을 포함하여 지식 격차를 해소하고 새로운 관행과 도구의 구현 및 채택을 돕습니다.
• 시기 : 계획을 세우고 조직 전환을 시작하면 전체 관리 팀이 참여합니다.
• 내용 : 교차 기능 협력을 가능하게하고, 팀 경계가 허물어 지도록하고, 팀 내부의 로컬 최적화로 인해 고객의 희망에서 고객 배송까지 모든 가치 사슬에 걸쳐 높은 작업 처리량을 가로막는 장애물이되지 않도록합니다.
• 누가 : 소프트웨어 개발과 시스템 운영에 숙련 된 엔지니어. 그는 DevOps 변환과 관련된 모범 사례, 프로세스 및 문화 변경에 능숙해야합니다.

CI / CD 엔지니어

• 이유 : CI / CD 파이프 라인을 구현하려면 툴 체인을 통합하고 회사의 업무 효율을 높일 수있는 툴을 도입하십시오.
• 시기 : 대규모 조직으로 전환하는 동안 위의 역할이 이미 채워져 있습니다.
• 내용 : 엔지니어 : CI / CD 파이프 라인을 설정하고 작업 처리량에서 마찰을 제거 할 수있는 방식으로 내부 시스템 통합을 시작할 수있는 도구 팀의 일원 인 엔지니어.
• Who : 엔지니어는 도구, 통합 프로세스, 릴리스 관리 및 DevOps 실무 경험이 있습니다. 릴리스 프로세스에서 자동화를 통해 휴먼 게이팅을 대체하고 있음을 이해하는 사람.

귀하의 질문 링크에 설명 된 Devops Engineer 가 주로 sysadmin 역할 이라고 주장합니다 . 이 답변의 배경 기술을 인용하십시오.

등산 장비.

• Puppet, Chef 또는 이와 동등한 것을 사용하는 자동화 / 구성 관리에 대한 Linux / Unix 관리 경험에 대한 강력한 배경 지식
• 다양한 오픈 소스 기술 및 클라우드 서비스를 사용할 수있는 기능 (AWS 사용 경험이 필요함)
• SQL 및 MySQL에 대한 강력한 경험 (Nois 경험도 Redis를 사용하기 때문에 플러스입니다)
• 코드 및 스크립트에 대한 실무 이해 (PHP, Python, Perl 및 / 또는 Ruby)
• 상시 가동 가능한 항상 사용 가능한 서비스의 모범 사례 및 IT 운영에 대한 지식

이 샘플 작업 설명에서 DevOps Engineer는 클라우드 기반 인프라, 자동화, 진단에 도움이되는 코드를 읽을 수 있고 고 가용성 사례 및 솔루션에 대해 잘 알고있는 sysadmin의 전문 용어입니다.

이것은이 질문에서 볼 수 있듯이 DevOps 사례 및 개발자와 운영 부서 간의 사일로 차단 문화와 밀접한 관련이 있습니다. Sysadmin과 DevOps Engineer의 차이점은 무엇입니까?

시스템 관리자가 실습과 문화에 얼마나 편한지 sysadmin이 회사 전환을 주도하는 올바른 사람이 아니기 때문에 좋은 생각이 아닙니다. 문화적 변화를 염두에두고 프로세스 구성에 도움이되지 않는 도구 구성보기를 사용하여이 사람을 고용하지는 않습니다. 이것은 동료들에게도 잘못 받아 들여질 수 있으며 사전에 문화 변화가 계획되어 있지 않으면 변화에 저항 할 것입니다.

@ Jiri Klouda 의 답변은 devops 의 성공을 향한 성공적인 패턴을 위해 수용 가능한 DevOps 엔지니어 역할에 대한 훌륭한 개요와 가치를 가져오고 성공에 도움이 될 변화의 단계를 제공합니다.

이 답변이 귀하에게 꼭 맞지 않을 수도 있다는 것을 알고 있습니다.

나는 매우 바쁜 전자 상거래 스타트 업에서 일하는 최초의 개발자였으며 ​​트래픽이 엄청나게 높았습니다. 나는 회사가 아직 젊다는 것을 알고 있으며, 잠시 동안 나는 유일한 사내 기술 자원이 될 것입니다.

이를 알면서 ZERO 시스템 관리를 수행 할 수 있도록 인프라를 구축하기로 결정했습니다.

시스템 유지 관리가 필요 없기 때문에 클라우드에서 호스팅하기로 결정했습니다. 꼭두각시 경험을 가진 AWS 엔지니어를 찾았습니다. 우리는 함께 클라우드 스케일링 코드로 작성된 자동 확장 가능한 인프라를 설계했습니다. 모든 구성 파일은 퍼펫 내에서 버전이 지정되었습니다.

이를 통해 개발자로서이 devops 역할을 맡을 수있었습니다. 파이썬으로 코드 릴리스 도구를 만들었습니다. 동일한 스크립트를 사용하여 응용 프로그램을 자동 확장되는 새 서버로 부트 스트랩했습니다.

이것은 매우 잘 작동했으며 3 년이 지난 지금도 여전히 시스템 유지 관리를 수행하지 않습니다. 우리는 한 달에 10 시간 동안 시스템 관리자 (동일한 AWS 엔지니어)를 보유하고 있으며, 자신을 괴롭히지 않는 방식으로 스프린트를 구성하려고합니다. 그런 식으로 나는 그의 시간을 존중하고 최선의 방법으로 스프린트를 관리합니다.

시스템 성능이 저하되면 시스템을 종료하고 다른 시스템이 대신 작동합니다.

이 답변이 어떻게 든 도움이 되길 바랍니다.

DevOps에는 한 사람이 이러한 분야의 모든 측면에서 전문가가 될 수없는 매우 다양한 분야가 포함되어 있으므로 DevOps 엔지니어를 고용해서는 안됩니다. 모든 거래의 잭을 고용함으로써, 당신은 없음의 주인을 고용 할 것입니다.

DevOps는 반드시 팀 기반의 노력 이므로 한 개인이 전체 팀의 기대를 지원할 수는 없습니다. DevOps의 범위를 고려하십시오. 한 사람은 다음을 수행 할 수 없습니다.

• [언어]의 록 스타 개발자가 되십시오
• 모든 필수 RFC를 알고 네트워킹 전문가가 되십시오
• 전문가 시스템 관리자가 되십시오
• 전문가 품질 보증 테스터
• 데이터베이스 관리자가 되십시오
• 스토리지 및 백업 전문
• 사이트 신뢰성 공학 지식
• 잠재적으로 다른 학문

위의 일부에는 Windows 시스템 관리자 대 Linux / Unix 시스템 관리자와 같은 하위 분야가 있거나 귀하의 코딩 언어를 두 개 이상 사용할 수도 있습니다.

이 모든 일에 전문가가 될 수있는 사람은 아무도 없습니다. 즉 DevOps 엔지니어에게 광고하는 경우 DevOps 팀의 가장 취약한 영역이 네트워킹 인 경우 네트워킹 전문가 에게 필요한 광고를 제대로 수행하지 못하고 있습니다. DevOps 팀을 위해 . DevOps 팀에서 특정 역할에 비둘기를 individual는 사람은 없지만 DevOps 범위 내에 전문가 또는 SME (Subject Matter Expert)가없는 것으로 가장하여 팀을 장애 상태로 만듭니다. DevOps 팀의 모든 역할이 동일 하듯이 사일 링에서 척하는 것까지 진자 스윙을 극단에서 다른 극단으로 스윙하면 많은 문제가 발생할 수 있습니다.

팀 구성원이 두 개 이상의 분야에서 교차 훈련을받는 동안, 특히 겹치는 영역에서 좋은 것은 아니지만, 이러한 광범위한 지식에 능숙 할 것으로 기대하는 것은 단순히 실천이 아닙니다.

즉, DevOps의 모든 측면을 알고 있다고 말하면 누구나 거짓말을 할 수 있습니다. "DevOps 엔지니어"가 아닌 DevOps 팀에서 일한 사람 중 가장 약한 분야의 전문가를 고용하십시오.

ASOS에서 구현할 때이 정확한 도전을 받았습니다. 우리의 목표는 자급 자족하고 헌신적 인 역할을하는 팀이 반 패턴이 될 수 있도록하는 것입니다. 그러나 우리는 현실 세계에 살고 있으며 많은 개발자들에게 좋은 DevOps 사례를 생각하는 것이 그들의 일차가 아니므로 도움이 필요합니다 거기에 도착.

우리가 한 일은 :

• DevOps 엔지니어의 용어를 잃어 버리면 DevOps는 직책이 아니라 우리 모두가해야 할 일이므로 다른 이름으로 불렀습니다.

• 팀에 배포했지만 3 명당 1 명으로, 이는 수행자가 될 수 없었지만 팀이 더 나은 결과를 얻고 자신의 문제를 해결할 수 있도록 역량으로 보여야했습니다 (지침 포함).

• 역량 센터 역할을 수행하고 모든 팀에 영향을 미치는 모든 것을 고려하여 엔터프라이즈 고려 사항을 처리하기위한 중앙 기능 유지

우리가 진화함에 따라 우리는이 모델을 검토하지만 지금까지 효과적으로 작동하고 있습니다

나는 당신이 이것에 대해 결정적인 대답을 얻을 수 있다고 생각하지 않습니다.

• 회사에서 DevOps 실습을 수행하는 방법
• 회사가 제공하는 응용 프로그램 또는 서비스의 종류
• 회사의 구조

방금 면접을 마치고 DevOps 엔지니어라는 제목으로 끝났지 만 Sys Admin 작업 중 일부가 있습니다. 그것은 회사의 규모와 응용 프로그램 현명한 관리의 특성으로 인해 필요하지 않습니다. 내가 인터뷰 한 일부 직책은 비슷한 직책을 가지고 있었으며, 개발 경험 측면에서 현명한 사람을 더 찾고있었습니다. 그들은 자동화를 수행하는 시스템 관리자가 아닌 더 많은 코드 작성을 기대했습니다. SRE는 인기를 얻고있는 타이틀 인 것 같습니다. 나는 시간의 일부와 요리사 스택을 작성했기 때문에 나는 마지막 직업으로 시스템 관리자 및 자동화 엔지니어로 자신을했다. 이 회사는 모든 사람들이 탑승하고 개발팀이 작전과 함께 일했던 꽤 좋은 devops 모델을 따르고 있었지만 그들의 미래는 그렇지 않았다고 생각합니다.

이제 나는이 위치에 있기 때문에 자동화에서 경적을 울리려고 노력하고 있으며 우리는 사람들에게 문제를 해결해야합니다. 사람들이오고 가고 워크 플로 중 일부는 사람들이 작업 방식에 맞지 않기 때문에 다른 방식으로 디자인했기 때문에 설계되었습니다.

그래서 기본적으로 나는 당신이 직업 설명을 알아 내고 제목에 대해 걱정하지 말고 어떤 식 으로든 지불하거나 다른 사람이 올바른 종류의 사람들을 끌어 들일 것이라고 생각하지 않는 한.

DevOps의 의미에 관심이 있고 "한 가지 진로"를 따르는 경우 DevOps 엔지니어를 고용해서는 안됩니다. 자동화 엔지니어, 배포 엔지니어 또는 플랫폼 설계자 또는 필요한 다른 역할을 수행해야합니다.

진정한 DevOps 실무자가 중요하지 않은 경우 원하는대로 호출 할 수 있습니다.