Sysadmin과 DevOps Engineer의 차이점은 무엇입니까?

작업을 신청할 때 일반적으로 Sysadmin Engineer 및 DevOps Engineer 두 가지 유형의 유사한 작업을 찾을 수 있습니다 .

둘 다 서버 구성을 처리하고 컴퓨터 시스템의 안정적인 작동을 보장합니다. 둘 사이의 차이점을 말하기는 어려울 수 있습니다. 그들 사이의 주요 차이점은 무엇입니까?

주로 DevOps는 역할이 아닙니다 (이와 같이 사용하면 실제 역할보다 더 전문적인 용어 임).

DevOps는 대략 개발자와 sysadmin 사이의 사일로를 깨는 것을 목표로하는 조직 패턴입니다.
주요 목표는 정의, 아키텍처 결정에서이 제품을 실행하는 유지 관리에 이르기까지 제품 (응용 프로그램)을 담당하는 개발자 및 sysadmin (일반적으로 테스터와 함께)으로 팀을 구성하는 것입니다.
팀의 각 구성원은 제품의 전체 수명주기에 대한 결정에 참여하고, 개발자는 프로덕션에서 일부 sysadmin 작업을 수행하고, sysadmin은 인프라 관점에서 경고를 피하기 위해 제품의 디자인 단계에 참여합니다. 예를 들어.

이상적으로는 sysadmin은 제품 개발 팀의 일원이 될 수 있습니다. 실제 sysadmin 코드는 제품 주변의 구성 및 모니터링 솔루션에 대한 자세한 내용이지만 팀의 다른 구성원에게 우려를 표할 수 있으므로 많은 오해를 피할 수 있습니다. 배포 프로세스에서.

짧은 버전

DevOps는 조직 문화, 애자일 / 린 작업 방식 및 소프트웨어 자동화의 조합으로 시스템 관리 및 운영에 적용될 때 이러한 기능이 애자일 또는 린 개발 팀과 동일한 수준의 민첩성으로 작동 할 수 있도록합니다.

긴 버전

DevOps의 아이디어는 시스템 관리, 운영 및 애자일 커뮤니티에서 나온 것입니다. 특히 Patrick Debois 는 Agile2008 에서 'Agile Infrastructure'라는 제목 으로 프레젠테이션을 진행했습니다 .

1. 애자일 개발 팀 -코드를 작성하는 애자일 팀.
2. 시스템 관리 팀 -소프트웨어를 실행하기위한 인프라 구축
3. 운영 팀 -프로덕션 / 라이브에서 애플리케이션 및 인프라 지원

Debois의 제안은 세 가지 협업 방식, 특히 시스템 관리 팀과 운영 팀을 워터 폴 모델 에서 애자일 모델로 옮기는 세 가지 방법을 통합하는 것이 었습니다 . 이를 위해 Debois 는 벨기에 겐트에서 DevOpsDays 2009를 설정 하여 실수로 DevOps 라는 문구를 만들었습니다 .

DevOps의 아이디어는 VisibleOps 시리즈의 저자들과 함께 공감했습니다 : Gene Kim, George Spafford 및 Kevin Behr; 계속해서 The Phoenix Project 와 The DevOps Handbook을 작성했습니다 . 두 책 모두 Agile과 Lean이 시스템 관리 및 운영 팀에 긍정적 인 영향을 줄 수있는 방법을 살펴 봅니다.

A와 개발 운영의 운영 배경에서 오는 엔지니어, 당신이 구축하고 서버와 소프트웨어를 배포에서 이동 한 것입니다 수동 으로 스크립팅 잠시 후 등 BASH, PowerShell을, 파이썬의 좋아하여 서버에 소프트웨어의 설치를 어떻게 실현할 것 멋진 스크립팅은 배포 를 자동화 하는보다 정교한 방법을 모색하기 시작했습니다 .

결국 Chef, Puppet, Ansible 또는 기타 구성 관리 도구를 사용하여 시스템 집합을 관리 하는 데 도움이 될 것입니다. 도구와 함께 응용 프로그램 배포 및 시스템 관리 자동화 기술이 향상됨에 따라 최근에는 ' 코드로 인프라 '영역으로 이동하여 소프트웨어 배포뿐만 아니라 필요한 인프라 및 환경을 자동화하는 데 사용했습니다. 비즈니스가 클라우드로 전환하는 동안 소프트웨어를 구동합니다.

이제 가스로 요리하고 있습니다. 시간이 지남에 따라 소스 제어 와 같은 개발자 중심 도구를 사용하여 배포 및 관리 도구를 구성하는 모듈, 레시피 및 템플릿을 관리 하는 이점을 소개했습니다 .

DevOps 팀 으로 전환 하면 소프트웨어 개발 수명주기와 지속적인 통합 개념에 노출되었습니다 . 그 개발자들이 신속하게 변경 사항을 발표하고 계속 유지하기 위해 개발자와 더 밀접하게 일하는 것을 발견했습니다! 당신은 개발팀이 "일이 정해지지 않았다면 그것을 고치지 마라 "라는 오래된 운영 패러다임에 반하는 모든 것을 변화시키기 위해 개발 팀에 긴급한 것을 경험했다 . 더 이상 시스템 가동 시간에 대해 자랑하지 않아도되므로 일회용 인프라를 사용하게됩니다.

당신은에 이동 것으로 나타났습니다 개발 운영 팀이 더 많은 작업을보다했다 DEVS , 또는 사용하는 새로운 도구 와 기술을 하지만, 뚜렷한 있었다 문화 대규모의 조직을 통해 침투 팀의 변화, 한. 당신은 공유 된 책임 , 툴링 및 목표 공유를 가진 긴밀한 팀으로 일하고있었습니다 .

자동화 된 배치 기술을 사용하여 Jenkins , Bamboo 또는 Code Pipeline 과 같은 " 연속 통합 서버 " 를 통해 " CICD "파이프 라인 으로 통합했습니다 . 이제 개발자가 새 코드를 푸시하면 스크립트, 도구 및 템플릿이 필요에 따라 새로운 환경을 세우고 테스트 프레임 워크를 트리거하여 작업을 수행하고 릴리스에서 녹색 표시등이 켜진 후 사전 프로덕션 환경을 분해합니다. " 지속적인 배달 "의 아이디어 .

새 코드가 CICD 단계를 거치면서 개발자와 비즈니스는 프로덕션으로 출시 될 때 업데이트가 중단되지 않을 것이라는 확신을 갖게됩니다. 팀이 " 지속적인 배포 "에 도달하기 전에 갈 수있는 방법이 있지만 , 여전히 블루 / 그린 배포 기능 을 자동화하는 더 나은 지점을 결정해야하며 결정은 대부분 비즈니스입니다. 당분간은 오전 3시에 전화가 가라 앉았고 sev-1과 sev-2가 줄어들 었다는 내용입니다.

sev-1을 사용하더라도 관리자가 등을 숨쉬면서 더 이상 밤새도록 당기지 않습니다. CICD 파이프 라인을 통해 이전 버전을 쉽게 해제하고 짧은 시간 내에 시스템을 다시 온라인으로 전환 할 수 있습니다. 비즈니스는 변화 속도 에도 불구하고 IT 시스템 의 안정성 이 향상 되었음을 알게 되었습니다 .

비즈니스에서 소프트웨어를 구동하는 데 필요한 리소스를 관리하는 방식, 특히 데이터 센터의 레일에 남은 혈액량과 과거의 혈액량을 다시 생각할 때 놀라 울 것입니다.

Sysadmin과 DevOps (개인보기)

일부 회사는 개발, 운영 및 테스트에 대해 이야기합니다. 무언가를 테스트해야한다면 "테스트를해야한다"고 말합니다. 무언가를 개발해야 할 경우 Dev가 그렇게하고 소프트웨어를 배포해야 할 경우 Ops가 그렇게합니다.

제 생각에는 여러 회사에서 경험 한 바에 따르면 사람들과 팀 사이에 마찰을 일으키는 "벽에 던져"사고 방식이 생깁니다. 개인적으로, 나는 사람들이 개별적으로 일한다고 생각하고 이것이 내가 한 일이라고 말하며 팀으로 일하는 대신 할 일이 없습니다.

저에 따르면 DevOps는 팀의 모든 사람이 개발, 테스트 및 운영에 책임감 있고 바쁘다는 것을 의미합니다. 팀에는 별도의 부서가 없습니다. 모두 풀어 주어야합니다. 물론 전문 분야가 있지만 모든 사람들이 모든 분야에서 최소한 25 %의 작업을 수행 할 수 있어야한다고 생각합니다. 예를 들어 누군가가 당시 개발자였던 경우, 일부 구성 관리 코드 (예 : 요리사 및 배포 소프트웨어)를 변경할 수 있어야합니다.

참고 문헌

Sysadmin

Wikipedia 에 따르면 :

시스템 관리자 또는 sysadmin은 컴퓨터 시스템의 유지 관리, 구성 및 안정적인 작동을 담당하는 사람입니다. 특히 서버와 같은 다중 사용자 컴퓨터.

시스템 관리자는 자신이 관리하는 컴퓨터의 가동 시간, 성능, 리소스 및 보안이 예산을 초과하지 않고도 사용자의 요구를 충족 시키도록 노력합니다.

이러한 요구를 충족시키기 위해 시스템 관리자는 컴퓨터 구성 요소 및 소프트웨어를 구입, 설치 또는 업그레이드 할 수 있습니다. 일상적인 자동화 제공 보안 정책 유지 문제 해결; 직원 훈련 또는 감독; 또는 프로젝트에 대한 기술 지원을 제공합니다.

데브 옵스

Wikipedia 에 따르면 :

DevOps ( "개발"및 "운영"의 잘린 조합)는 제품 관리, 소프트웨어 개발 및 운영 전문가 간의 커뮤니케이션 및 협업을 강조하는 소프트웨어 개발 및 전달 프로세스입니다. 소프트웨어 구축, 테스트 및 릴리스가 신속하고 빈번하고보다 안정적으로 발생할 수있는 문화와 환경을 구축함으로써 소프트웨어 통합, 테스트, 배포 및 인프라 변경 프로세스를 자동화하고 모니터링함으로써이를 지원합니다.

데브 옵스

DevOps 툴체인

시스템 관리자는 서버를 유지 관리하고 구성 할 책임이 있으며 사용자가 원하는 성능, 가동 시간 및 보안을 보장해야합니다. 공식적인 경력 경로가없고 DevOps 자체가 여러 형태를 가질 수 있기 때문에 DevOps 엔지니어의 역할을 정의하는 것은 조금 더 어렵습니다.

예를 들어 DevOps 엔지니어는 네트워크 및 배포 작업에 관심이있는 개발자이거나 코딩 및 스크립팅에 대한 열정이있는 시스템 관리자 일 수 있습니다. 시스템 관리자에서 DevOps 엔지니어로 전환하는 것은 그리 어렵지 않습니다. 실제로이 기사 는 프로세스를 설명하는 데 매우 효과적입니다.

많은 사람들은 시스템 관리자의 위치가 향후 폐기 될 것이기 때문에 시스템 관리자에서 DevOps 엔지니어로의 전환이 필수적이라고 주장 할 것입니다. 유지 관리가 필요한 레거시 서버는 많지만 시스템 관리자는 "부족 적 지식"을 많이 보유하고 있지만 향후 sysadmin 위치는 더 부족할 것입니다.

데이터 센터에서 실행되는 소리가 들리지 않는 서버가 있습니다. 모든 것이 소프트웨어가 될 것입니다. 스토리지, 네트워크, 시스템, 보안, 데이터 센터; SDN, 방화벽, NFV, 스토리지, 서버 등 소프트웨어 개발 배경이없는 Sysadmin, SDLC 경험 (Perl, Powershell 등 스크립팅을 의미하지는 않습니다)은 사라질 것입니다. 대부분 클라우드 인 분산되고 확장 가능하며 가상화 된 환경은 수직이 아닌 수평으로 성장합니다.

나는 Sysadmins가 수직으로 성장하고 DevOps (또는 OpsDev)가 수평으로 성장한다고 감히 말합니다. 마이크로 서비스가 모놀리스에서 진화 한 것과 동일한 패턴을 볼 수 있습니다. 오히려 운영 / 시스템 팀이 아닌 소프트웨어 팀의 DevOps 엔지니어를 선택하고 싶습니다.

운영 / 시스템 팀은 소프트웨어 팀이 구축 한 것을 실행하기 때문입니다.

• Sysadmin은 소프트웨어 엔지니어가 응용 프로그램을 빌드 / 컴파일하는 것처럼 Linux / FreeBSD / windows 커널 등을 빌드 / 컴파일하지 않습니다.
• Sysadmin은 SDLC (Software Development Life Cycle)를 거치지 않습니다.
• Sysadmin은 프로덕션 파이프 라인 (CI / CD 프로세스)의 일부가 아닙니다.

• CI / Continuous Delivery / Deployment가 종료 된 후 Sysadmin이 작업을 시작합니다.

  배포 / 배달을 중단하고 할당하면 파이프 라인
  이 끊어 질 수 있습니다. 소프트웨어 팀은 제작자 시스템 / 운영 팀이 주로 주자 / 관리자입니다.

관리 할 서버 / 시스템이없고 sysadmin이 필요없는 것 같습니다.

서버리스 컴퓨팅은 클라우드 제공 업체가 서버 역할을 수행하여 머신 리소스 할당을 동적으로 관리하는 클라우드 컴퓨팅 실행 모델입니다. 가격은 다소 용량의 미리 구입 단위보다는, 애플리케이션에 의해 소비되는 자원의 실제 양에 기반 서버를 사용 컴퓨팅

소프트웨어 팀의 누군가는 이미 코딩 방법 (SRE vs DevOps / OpsDev)을 구축하고 유지하는 방법을 이미 알고 있습니다.

왜 DevOps라고 불리는 지 OpsDev가 아닌지 궁금합니다. 둘 사이의 방향과 관련이 있습니까?

* 어딘가 중간에 소프트웨어 정의 스토리지에 대한 글을 작성하지 않았습니다. 이것은 그것에 대해 삭제 된 의견에 대한 반응입니다 *

소프트웨어 정의 스토리지 정보

• 소프트웨어 정의 스토리지 (SDS)는 기본 하드웨어와 무관하게 데이터 스토리지의 정책 기반 프로비저닝 및 관리를위한 컴퓨터 데이터 스토리지 소프트웨어의 마케팅 용어입니다. 소프트웨어 정의 스토리지

• EMC는 최초의 오픈 소스 제품인 Project CoprHD를 발표했습니다. CoprHD는 소프트웨어 정의 스토리지 자동화 및 관리 컨트롤러이며, EMC의 최근 오픈 소스 결정은 성장과 극심한 변화의 영역에 진입함에 따라 글로벌 비즈니스에 더 큰 가치를 제공하려는 전략의 핵심입니다. 스토리지 및 정보 관리 분야의 세계적 선두 기업인 EMC는 SDS (Software Defined Storage)를 주도 할 것을 요구합니다 .

• CoprHD는 오픈 소스 소프트웨어 정의 스토리지 컨트롤러 및 API 플랫폼입니다. 블록, 오브젝트 및 파일 스토리지 제공자 CoprHD를 위한 스토리지 자원의 정책 기반 관리 및 클라우드 자동화