회사 내 관리자, DevOps, 끝없는 혼란 및 DevOps 혁신에 대한 정보

2019년에 IT 기업이 성공하려면 무엇이 필요합니까? 컨퍼런스나 모임에서 강사들은 보통 사람들이 항상 이해할 수 없는 시끄러운 말을 많이 합니다. 배포 시간, 마이크로서비스, 단일체 포기, DevOps 혁신 등을 위한 투쟁입니다. 우리가 말의 아름다움을 버리고 직접 러시아어로 말한다면 모든 것은 간단한 논제로 귀결됩니다. 즉, 고품질의 제품을 만들고 팀을 위해 편안하게 수행하는 것입니다.

후자는 매우 중요해졌습니다. 기업은 마침내 편안한 개발 프로세스가 생산성을 높이고, 모든 것이 디버깅되어 시계처럼 작동한다면 중요한 상황에서 어느 정도 기동할 여지도 제공한다는 결론에 도달했습니다. 옛날 옛적에 이 책략을 위해 어떤 똑똑한 사람이 백업을 생각해 냈지만 업계는 발전하고 있으며 우리는 개발과 외부 인프라 간의 상호 작용 프로세스를 적절하고 적절한 것으로 바꾸는 사람들인 DevOps 엔지니어에게 왔습니다. 샤머니즘과 관련 없음.

이 전체 "모듈식" 이야기는 훌륭하지만... 일부 관리자가 갑자기 DevOps라고 불렸고 DevOps 엔지니어 자신도 최소한 텔레파시와 투시 능력이 요구되기 시작했습니다.

인프라 제공과 관련된 현대적인 문제에 대해 이야기하기 전에 이 용어의 의미를 정의해 보겠습니다. 현재 상황은 이 개념의 이중성에 도달하는 방식으로 발전했습니다. 인프라는 조건부로 외부일 수도 있고 조건부 내부일 수도 있습니다.

외부 인프라란 팀이 개발 중인 서비스나 제품의 기능을 보장하는 모든 것을 의미합니다. 이는 제품의 기능을 보장하는 애플리케이션 또는 웹 사이트 서버, 호스팅 및 기타 서비스입니다.

내부 인프라에는 개발 팀 자체와 일반적으로 많은 다른 직원이 사용하는 서비스와 장비가 포함됩니다. 이는 코드 저장 시스템의 내부 서버, 로컬로 배포된 작업 관리자 및 기업 인트라넷 내에 존재하는 모든 것입니다.

회사에서 시스템 관리자는 어떤 일을 하나요? 이러한 기업 인트라넷을 관리하는 업무 외에도 사무 장비의 운용성을 보장하기 위한 경제적 문제를 안고 있는 경우가 많습니다. 관리자는 다용도실에서 사용할 준비가 된 새 시스템 장치나 예비 노트북을 재빨리 끌고 새 키보드를 나눠주고 이더넷 케이블을 쭉 뻗으며 네 발로 사무실을 기어다니는 바로 그 사람입니다. 관리자는 내부 및 외부 서버뿐만 아니라 비즈니스 임원의 로컬 소유자이자 통치자입니다. 예, 일부 관리자는 하드웨어 없이 시스템 영역에서만 작업할 수 있습니다. 이들은 "인프라 시스템 관리자"라는 별도의 하위 클래스로 분리되어야 합니다. 그리고 일부는 사무용 장비 서비스만을 전문으로 하고 있지만 다행스럽게도 회사에 XNUMX명 이상의 직원이 있으면 작업이 끝나지 않습니다. 하지만 둘 다 데브옵스는 아니다.

DevOps는 누구입니까? Devops는 소프트웨어 개발과 외부 인프라의 상호 작용에 대해 이야기하는 사람들입니다. 더 정확하게 말하면, 최신 데브옵스는 단순히 FTP에 업데이트를 업로드한 관리자보다 훨씬 더 깊은 개발 및 배포 프로세스에 관여합니다. 이제 DevOps 엔지니어의 주요 임무 중 하나는 개발 팀과 제품 인프라 간의 편안하고 효과적으로 구조화된 상호 작용 프로세스를 보장하는 것입니다. 롤백 및 배포 시스템 배포를 담당하는 사람들이 바로 이러한 사람들이며, 개발자의 부담을 덜어주고 매우 중요한 작업에 최대한 집중하는 사람들입니다. 동시에, 데브옵스는 결코 새로운 케이블을 사용하거나 뒷방에서 새로운 노트북을 발급하지 않을 것입니다. (c) KO

캐치는 무엇입니까?

"DevOps는 누구입니까?"라는 질문에 현장 작업자 중 절반이 "음, 간단히 말해서 이 사람은 관리자입니다..."와 같은 내용으로 대답하기 시작합니다. 예, 옛날 옛적에 DevOps 엔지니어라는 직업이 서비스 유지 관리 측면에서 가장 재능 있는 관리자에게서 막 등장했을 때 이들 간의 차이점은 모든 사람에게 분명하지 않았습니다. 그러나 이제 팀 내 데브옵스와 관리자의 기능이 근본적으로 달라졌기 때문에 이들을 혼동하거나 동일시하는 것조차 용납할 수 없습니다.

그러나 이것이 비즈니스에 무엇을 의미합니까?

채용, 그게 전부입니다.

"시스템 관리자" 공석을 개설하고 거기에 나열된 요구 사항에는 "개발 및 고객과의 상호 작용", "CI/CD 전달 시스템", "회사 서버 및 장비 유지 관리", "내부 시스템 관리" 등이 있습니다. 에; 고용주가 말도 안되는 말을하고 있다는 것을 이해합니다. 중요한 점은 공석 직함은 "시스템 관리자" 대신 "DevOps 엔지니어"여야 하며, 이 직위가 변경되면 모든 것이 제자리에 있다는 것입니다.

그런데 그런 공석을 읽으면 어떤 인상을 받나요? 회사는 버전 제어와 모니터링 시스템을 모두 배포하고 이를 악물고 트위스터를 쥐어짜줄 다중 기계 운영자를 찾고 있습니다...

그러나 노동 시장에서 약물 중독의 정도를 높이지 않으려면 공석을 고유 이름으로 부르고 DevOps 엔지니어와 시스템 관리자가 서로 다른 두 개체라는 점을 명확하게 이해하는 것으로 충분합니다. 그러나 후보자에게 가능한 가장 광범위한 요구 사항 목록을 제시하려는 일부 고용주의 억제할 수 없는 욕구는 "고전적인" 시스템 관리자가 주변에서 일어나는 일을 더 이상 이해하지 못하게 한다는 사실로 이어집니다. 뭐, 직업이 변하고 있고 시대에 뒤떨어져 있나요?

아니요, 아니요, 한 번 더 아니요. 회사 내부 서버를 관리하거나 L2/L3 지원 직책을 맡아 다른 직원을 도와줄 인프라 관리자는 사라지지 않았고 앞으로도 사라지지 않을 것입니다.

이러한 전문가가 DevOps 엔지니어가 될 수 있나요? 물론 그럴 수 있습니다. 실제로 이는 시스템 관리 기술이 필요한 관련 환경이지만, 이 외에도 모니터링, 전달 시스템 작업, 일반적으로 개발 및 테스트 팀과의 긴밀한 상호 작용이 추가됩니다.

또 다른 DevOps 문제

실제로 모든 것이 채용과 관리자와 DevOps 간의 지속적인 혼란에만 국한되지 않습니다. 어느 시점에서 비즈니스는 업데이트를 제공하고 개발 팀과 최종 인프라 간의 상호 작용 문제에 직면했습니다.

아마도 어느 컨퍼런스에서 눈을 반짝반짝 빛나게 하는 삼촌이 무대에 올라 “우리는 이것을 DevOps라고 부릅니다. 이 사람들이 당신의 모든 문제를 해결할 것입니다.” - 그리고 DevOps 관행을 구현한 후 회사의 삶이 얼마나 좋은지 말하기 시작했습니다.

그러나 모든 것이 제대로 작동하도록 하려면 DevOps 엔지니어를 고용하는 것만으로는 충분하지 않습니다. 회사는 완전한 DevOps 혁신을 거쳐야 합니다. 즉, 제품 개발 및 테스트 팀 측에서도 DevOps의 역할과 기능을 명확하게 이해해야 합니다. 우리는 이 주제에 관해 몇몇 장소에서 일어나고 있는 모든 잔인함을 완전히 보여주는 “놀라운” 이야기를 가지고 있습니다.

상황. DevOps는 실제로 작동 방식을 조사하지 않고 버전 롤백 시스템을 배포하는 데 필요합니다. 사용자 시스템 내에 이름, 성, 비밀번호에 대한 별도의 필드가 있다고 가정해 보겠습니다. 새 버전의 제품이 나오지만 개발자에게 "롤백"은 모든 것을 고칠 수 있는 마술 지팡이일 뿐이며 어떻게 작동하는지조차 모릅니다. 예를 들어, 다음 패치에서 개발자는 이름과 성 필드를 결합하여 프로덕션에 출시했지만 어떤 이유로 버전이 느립니다. 무슨 일이야? 경영진이 데브옵스에 와서 "스위치를 당겨라!"라고 말합니다. 즉, 이전 버전으로 롤백하라고 요청하는 것입니다. 데브옵스는 무슨 일을 하나요? 이전 버전으로 롤백하지만 개발자는 이 롤백이 어떻게 수행되었는지 알고 싶지 않았기 때문에 아무도 데브옵스 팀에 데이터베이스도 롤백해야 한다고 말하지 않았습니다. 결과적으로 모든 것이 충돌하고 느린 웹 사이트 대신 사용자에게 "500" 오류가 표시됩니다. 이전 버전이 새 데이터베이스의 필드와 작동하지 않기 때문입니다. Devops는 이에 대해 모릅니다. 개발자들은 침묵합니다. 경영진은 신경과 돈을 잃기 시작하고 백업을 기억하고 "적어도 뭔가 작동"할 수 있도록 백업을 롤백하겠다고 제안합니다. 결과적으로 사용자는 일정 기간 동안 모든 데이터를 잃게 됩니다.

물론 미친 짓은 "적절한 롤백 시스템을 만들지 않은" 데브옵스로 이동하고, 이 이야기에서 무스가 개발자라는 사실에 아무도 관심을 두지 않습니다.

결론은 간단합니다. DevOps에 대한 일반적인 접근 방식이 없으면 거의 쓸모가 없습니다.
기억해야 할 주요 사항: DevOps 엔지니어는 마술사가 아니며, 우수한 커뮤니케이션과 개발과의 양방향 상호 작용이 없으면 자신의 작업에 대처할 수 없습니다. 개발자는 자신의 "문제"를 혼자 방치하거나 "개발자에게 간섭하지 마세요. 개발자의 임무는 코딩하는 것입니다"라는 명령을 받은 다음 중요한 순간에 모든 것이 제대로 작동하기를 바랄 수 없습니다. 그것은 작동 방식이 아닙니다.

본질적으로 DevOps는 관리와 기술의 경계에 있는 역량입니다. 게다가 이 칵테일에는 관리보다 기술이 더 많이 포함되어야 한다는 것도 분명하지 않습니다. 더 빠르고 효율적인 개발 프로세스를 정말로 구축하려면 데브옵스 팀을 신뢰해야 합니다. 그는 올바른 도구를 알고 있고, 유사한 프로젝트를 구현했으며, 이를 수행하는 방법을 알고 있습니다. 그를 도와주고, 그의 조언을 듣고, 그를 일종의 자율적인 단위로 격리시키려고 하지 마십시오. 관리자가 스스로 작업할 수 있다면 이 경우 데브옵스는 쓸모가 없습니다. 귀하가 이 도움을 받아들이고 싶지 않으면 그들은 귀하가 더 나아지도록 도울 수 없습니다.

마지막으로, 인프라 관리자를 불쾌하게 만드는 일을 중단하십시오. 그들은 자신만의 매우 중요한 작업 영역을 가지고 있습니다. 예, 관리자는 DevOps 엔지니어가 될 수 있지만 이는 압력을 받아서가 아니라 개인의 요청에 따라 이루어져야 합니다. 그리고 시스템 관리자가 시스템 관리자로 남아 있기를 원한다는 사실에는 아무런 문제가 없습니다. 이것은 그의 별도 직업이자 권리입니다. 전문적인 변화를 겪고 싶다면 기술적 능력뿐만 아니라 관리 능력도 키워야 한다는 점을 결코 잊지 말아야 합니다. 아마도 이 모든 사람들을 모아서 동일한 언어로 의사소통하도록 가르치는 것은 리더로서 당신에게 달려 있을 것입니다.

출처 : habr.com