시스템 관리자가 DevOps 엔지니어가 되어야 하는 이유

인생에서 오늘보다 배우기 더 좋은 시간은 없습니다.

2019년은 DevOps가 그 어느 때보다 관련성이 높습니다. 메인프레임 시대와 마찬가지로 시스템 관리자의 시대도 끝났다고 합니다. 하지만 이것이 정말 그렇습니까?
IT에서 흔히 발생하는 것처럼 상황이 바뀌었습니다. DevOps 방법론이 등장했지만 시스템 관리자 기술을 갖춘 사람, 즉 Ops가 없으면 존재할 수 없습니다.

DevOps 접근 방식이 현대적인 형태를 취하기 전에 저는 저를 Ops로 분류했습니다. 그리고 나는 시스템 관리자가 자신이 아직 할 수 없는 일이 얼마나 많은지, 그것을 배울 시간이 얼마나 적은지 깨달았을 때 어떤 경험을 하는지 잘 알고 있습니다.

그런데 정말 그렇게 무서운가요? 지식 부족을 큰 문제로 인식해서는 안된다고 말하고 싶습니다. 그것은 직업적인 도전에 가깝습니다.

웹스케일 제품은 Linux 또는 기타 오픈 소스 소프트웨어를 기반으로 하며, 이를 유지 관리할 수 있는 인력이 시장에서 점점 줄어들고 있습니다. 이 분야의 수요는 이미 전문가 수를 초과했습니다. 시스템 관리자는 더 이상 기술 수준을 향상시키지 않고는 단순히 작업을 계속할 수 없습니다. 그는 여러 서버/노드를 관리하는 자동화 기술을 보유하고 있어야 하며 발생하는 문제를 해결하기 위해 어떻게 작동하는지 잘 이해하고 있어야 합니다.

DevOps 팀의 구성원이 되기 전에 DevOps 표준에 따라 시스템을 유지 관리하는 데 필요한 새로운 기술과 다양한 도구를 배우면서 꽤 길지만 흥미로운 여정을 거쳐야 합니다.

그렇다면 시스템 관리자는 어떻게 일반적인 작업 접근 방식에서 새로운 개념의 DevOps로 이동할 수 있습니까? 모든 것이 평소와 같습니다. 먼저 생각을 바꿔야 합니다. 지난 XNUMX년, XNUMX년 동안 따라온 접근 방식을 포기하고 일을 다르게 시작하는 것은 쉽지 않지만 필요한 일입니다.

우선, DevOps는 회사의 특정 직위가 아니라 일련의 특정 관행이라는 점을 이해하는 것이 중요합니다. 이러한 관행은 격리된 시스템의 배포, 버그 및 오류로 인한 피해 감소, 빈번하고 시기적절한 소프트웨어 업데이트, 개발자(Dev)와 관리자(Ops) 간의 잘 확립된 상호 작용, 코드뿐만 아니라 또한 프로세스 내의 전체 구조 지속적 통합 및 전달(CI/CD).

사고 방식을 바꾸는 것과 함께 인프라를 유지 관리하고 애플리케이션, 서비스 및 소프트웨어의 지속적인 통합과 제공을 위한 안정적인 운영, 안정성 및 가용성을 보장하는 방법을 배워야 합니다.

Ops 전문가로서 당신이 놓칠 수 있는 것은 프로그래밍 기술입니다. 이제 시스템 관리자가 자동으로 서버에 패치를 설치하고, 파일과 계정을 관리하고, 문제를 해결하고, 문서를 컴파일하는 데 사용하는 스크립트(스크립트) 작성은 이미 쓸모없는 것으로 간주됩니다. 스크립팅은 비교적 단순한 경우에 여전히 적용되지만 DevOps는 구현, 테스트, 빌드 또는 배포 등 대규모 문제를 해결하는 것입니다.

따라서 자동화를 배우고 싶다면 개발자가 아니더라도 최소한 약간의 프로그래밍을 마스터해야 합니다. 인프라 자동화 DevOps에서는 이 기술이 필요합니다.

무엇을 해야 할까요? 전문가로서 수요를 유지하려면 관련 기술을 습득해야 합니다. 예를 들어 Python과 같은 프로그래밍 언어를 하나 이상 마스터해야 합니다. 전문적으로 관리에 관여하는 사람에게는 개발자만 프로그래밍한다고 생각하는 데 익숙하기 때문에 이는 어려워 보일 수 있습니다. 전문가가 될 필요는 없지만 프로그래밍 언어 중 하나에 대한 지식(Python, Bash 또는 심지어 파워 쉘), 분명히 장점이 될 것입니다.

프로그래밍을 배우는 데는 시간이 좀 걸립니다. 주의 깊게 인내심을 가지면 DevOps 팀 구성원 및 고객과 소통할 때 상황을 파악하는 데 도움이 됩니다. 하루에 XNUMX분, 한 시간 이상 프로그래밍 언어를 배우는 것이 주요 목표가 되어야 합니다.

시스템 관리자와 DevOps 전문가는 비슷한 문제를 해결하지만 상당한 차이가 있습니다. DevOps 엔지니어가 할 수 있는 모든 것을 시스템 관리자가 할 수는 없다고 생각됩니다. 시스템 관리자는 서버 시스템의 구성, 유지 및 성능 보장에 더 중점을 두지만 DevOps 엔지니어는 이 카트와 또 다른 작은 카트를 모두 가져옵니다.

하지만 이 말이 얼마나 사실일까요?

시스템 관리자: 현장 전사 XNUMX명

이 기사에 언급된 차이점과 유사점에도 불구하고 저는 여전히 시스템 관리와 ​​DevOps 사이에 큰 차이가 없다고 믿습니다. 시스템 관리자는 항상 DevOps 전문가와 동일한 기능을 수행해 왔지만 이전에는 누구도 DevOps라고 부르지 않았습니다. 특히 어떤 작업과도 관련이 없는 경우 차이점을 구체적으로 찾는 것은 의미가 없다고 생각합니다. DevOps는 시스템 관리자와 달리 직위가 아니라 개념이라는 점을 잊지 마세요.

한 가지 더 중요한 사항에 주목해야 합니다. 이것이 없으면 관리와 DevOps에 대한 대화가 불완전해집니다. 일반적인 의미의 시스템 관리는 전문가가 특정 기술을 보유하고 있으며 다양한 유형의 인프라 서비스에 중점을 두고 있다는 것을 전제로 합니다. 이것이 보편적 직원이라는 의미가 아니라 모든 관리자가 수행하는 많은 작업이 있다는 의미입니다.

예를 들어, 때때로 그들은 일종의 기술 잡역부 역할을 해야 합니다. 즉 말 그대로 모든 일을 해야 합니다. 그리고 전체 조직에 그러한 관리자가 한 명뿐이라면 그는 일반적으로 모든 기술 작업을 수행합니다. 이는 프린터 및 복사기 유지 관리부터 라우터 및 스위치 설정 및 관리, 방화벽 구성과 같은 네트워크 관련 작업 수행에 이르기까지 다양합니다.

또한 일반적으로 PowerShell, Python 또는 Bash 스크립트를 통해 하드웨어 업그레이드, 로그 검사 및 분석, 보안 감사, 서버 패치, 문제 해결, 근본 원인 분석 및 자동화를 담당합니다. 사용 예 시나리오 사용자 및 그룹 계정을 관리하는 것입니다. 사용자 계정을 생성하고 권한을 할당하는 것은 사용자가 거의 매일 나타나고 사라지기 때문에 매우 지루한 작업입니다. 스크립트를 통한 자동화를 통해 스위치 및 서버 업그레이드, 관리자가 근무하는 회사의 수익성에 영향을 미치는 기타 프로젝트 등 더 중요한 인프라 작업에 시간을 확보할 수 있습니다(일반적으로 IT 부서가 직접 수입을 창출하지 않는다는 것은 인정되지만).

시스템 관리자의 임무는 가능한 한 시간을 낭비하지 않고 회사 비용을 절약하는 것입니다. 때때로 시스템 관리자는 Linux, Windows, 데이터베이스, 스토리지 등의 관리자를 통합하여 대규모 팀의 구성원으로 작업합니다. 근무 일정도 다양합니다. 예를 들어, 하루가 끝날 때 한 시간대의 교대 근무는 프로세스가 중단되지 않도록 케이스를 다른 시간대의 다음 교대 근무로 이전합니다(순종). 또는 직원은 오전 9시부터 오후 5시까지 정규 근무일을 갖습니다. 또는 연중무휴 데이터 센터에서 작동합니다.

시간이 지남에 따라 시스템 관리자는 전략적으로 생각하고 중요한 문제를 일상적인 작업과 결합하는 방법을 배웠습니다. 그들이 일하는 팀과 부서는 일반적으로 자원이 부족하지만 동시에 모든 사람은 일상 업무를 최대한 완료하려고 노력하고 있습니다.

DevOps: 하나의 개발 및 유지 관리

개발자 개발 및 유지 관리 프로세스에 대한 일종의 철학입니다. IT 세계에서 이러한 접근 방식은 정말 혁신적이었습니다.

DevOps의 산하에는 한쪽에는 소프트웨어 개발 팀이 있고 다른 쪽에는 유지 관리 팀이 있습니다. 여기에는 제품 관리 전문가, 테스터, 사용자 인터페이스 디자이너가 합류하는 경우가 많습니다. 이들 전문가들은 함께 운영을 간소화하여 새로운 애플리케이션과 코드 업데이트를 신속하게 출시하여 회사 전체의 효율성을 지원하고 향상시킵니다.

DevOps는 전체 수명주기 동안 소프트웨어 개발 및 운영에 대한 제어를 기반으로 합니다. 유지 관리 담당자는 개발자를 지원해야 하며, 개발자는 시스템에 사용되는 API 그 이상을 이해해야 합니다. 그들은 버그를 더 잘 처리하고, 문제를 해결하고, 서비스 기술자와 상호 작용할 수 있도록 내부 내용(즉, 하드웨어 및 운영 체제가 작동하는 방식)을 이해해야 합니다.

시스템 관리자는 최신 기술을 배우고 혁신적인 아이디어와 솔루션에 열려 있는 경우 DevOps 팀으로 이동할 수 있습니다. 내가 말했듯이, 그들이 완전한 프로그래머가 될 필요는 없지만 Ruby, Python 또는 Go와 같은 프로그래밍 언어를 마스터하면 팀에서 매우 유용한 구성원이 되는 데 도움이 될 것입니다. 시스템 관리자는 전통적으로 모든 작업을 스스로 수행하고 종종 외톨이로 인식되지만 DevOps에서는 프로세스에 참여하는 모든 사람이 서로 상호 작용하는 완전히 반대되는 경험을 합니다.

자동화라는 주제가 점점 더 중요해지고 있습니다. 시스템 관리자와 DevOps 전문가 모두 신속한 확장, 오류 감소, 기존 오류의 신속한 발견 및 수정에 관심이 있습니다. 따라서 자동화는 두 영역이 수렴되는 개념입니다. 시스템 관리자는 AWS, Azure, Google Cloud Platform과 같은 클라우드 서비스를 담당합니다. 지속적인 통합 및 제공의 원칙과 다음과 같은 도구를 사용하는 방법을 이해해야 합니다. 젠킨스.

또한 시스템 관리자는 다음과 같은 구성 및 관리 도구를 사용해야 합니다. 책임감있는, XNUMX~XNUMX개의 서버를 병렬 배포하는 데 필요합니다.

주요 컨셉은 코드로서의 인프라. 소프트웨어가 전부입니다. 실제로 시스템 관리자라는 직업이 관련성을 잃지 않으려면 강조점을 조금만 바꾸면 됩니다. 시스템 관리자는 서비스 비즈니스에 종사하므로 개발자와 효과적으로 커뮤니케이션할 수 있어야 하며, 그 반대의 경우도 마찬가지입니다. 머리 하나는 좋지만 두 개는 더 좋다는 말이 있죠.

이 메커니즘의 마지막 세부 사항은 다음과 같습니다. 힘내. Git 작업은 시스템 관리자의 전통적인 일일 책임 중 하나입니다. 이 버전 제어 시스템은 개발자, DevOps 전문가, Agile 팀 및 기타 많은 사람들이 널리 사용합니다. 귀하의 작업이 소프트웨어 수명주기와 관련되어 있다면 반드시 Git으로 작업하게 될 것입니다.

Git에는 많은 기능이 있습니다. Git 명령을 모두 배우지는 못할 수도 있지만 이것이 소프트웨어 통신 및 협업의 필수 요소인 이유를 정확히 이해하게 될 것입니다. DevOps 팀에서 일하는 경우 Git에 대한 철저한 지식은 매우 중요합니다.

시스템 관리자라면 Git을 더 잘 연구하고 버전 제어가 어떻게 구축되는지 이해하고 일반적인 명령을 기억해야 합니다. git 상태, git commit -m, git add, git pull, git push, git rebase, git Branch, git diff 다른 사람. 이 주제를 처음부터 배우고 특정 기술을 갖춘 전문가가 되는 데 도움이 되는 많은 온라인 강좌와 서적이 있습니다. 멋진 것도 있습니다 Git 명령이 포함된 치트 시트, 따라서 모두 벼락치기를 할 필요는 없지만 Git을 더 많이 사용할수록 더 쉬워질 것입니다.

결론

궁극적으로 DevOps 전문가가 되어야 하는지 아니면 시스템 관리자로 남는 것이 더 나은지 결정하게 됩니다. 보시다시피 전환을 위해서는 학습 곡선이 있지만 빨리 시작할수록 좋습니다. 프로그래밍 언어를 선택하고 동시에 다음과 같은 도구를 배우십시오. 힘내 (버전 관리), 젠킨스 (CI/CD, 지속적 통합) 및 책임감있는 (구성 및 자동화). 어떤 선택을 하든, 끊임없이 배우고 기술을 향상시켜야 한다는 사실을 잊지 마세요.

출처 : habr.com