헤이 하브르! 나는 기사의 번역을 당신의 관심에 제시합니다 "DevOps의 기원: 이름에는 무엇이 있나요?" 스티브 메작 지음.

관점에 따라 DevOps는 올해로 2016주년 또는 70주년을 맞이하게 됩니다. XNUMX년 RightScales의 클라우드 현황 보고서에서는 SMB의 XNUMX%가 DevOps 방식을 채택하고 있다고 밝혔습니다. 이 점수를 구성하는 모든 지표는 그 이후로 증가했습니다. DevOps가 두 번째 XNUMX년을 맞이할 준비를 하면서 과거를 되돌아보고 DevOps의 기원은 물론 이름 자체의 기원까지 돌아가는 것이 좋을 것입니다.

2007년 이전: 완벽한 일련의 사건

2007년 이전에는 일련의 상황이 결국 오늘날 DevOps로 알려진 것을 탄생시켰습니다.

기대다 이미 모범 사례임이 입증되었습니다. 또한 ~으로 알려진 토요타 생산 시스템, 린 제조(Lean Manufacturing)는 제조 현장의 프로세스를 최적화하기 위해 노력합니다. (그런데 Toyota 경영진은 처음에 Ford Motor Company가 도입한 원래의 조립 라인 방법에서 영감을 받았습니다.) 지속적인 개선 린 제조(Lean Manufacturing)를 위한 주문입니다. 실제로 다음 경로가 지속적으로 평가됩니다.

1. 원자재 및 완제품의 재고 수준을 최소한으로 유지합니다.. 린 제조란 상품을 생산하기 위한 원자재 재고의 최소량과 주문 또는 배송을 기다리는 완제품의 최소량을 의미합니다.
2. 주문 대기열 최소화. 이상적으로는 접수된 주문이 즉시 완료 상태로 전환됩니다. 린 제조의 핵심 지표는 항상 주문 접수부터 배송까지의 시간입니다.
3. 생산 공정의 효율성 극대화. 프로세스 리엔지니어링과 향상된 자동화가 결합되어 가능한 한 빨리 제품을 생산합니다. 전체 경로(절단, 용접, 조립, 테스트 등)에 따른 모든 생산 영역의 비효율성을 평가합니다.

IT 세계에서는 소프트웨어 개발의 폭포수 모델이라는 전통적인 방법이 이미 다음과 같은 빠른 반복 방법으로 대체되었습니다. 기민한. 빠른 개발과 배포를 추구하다 품질이 저하되는 경우도 있었지만 속도는 집결의 외침이었습니다. 거의 같은 방식으로 클라우드 컴퓨팅, 특히 서비스로서의 인프라 (IaaS) 및 Service-as-a-Service (PaaS)는 IT 프로세스 및 인프라에서 성숙한 솔루션으로 입증되었습니다.

마지막으로 최근 툴킷이 등장하기 시작했습니다. 지속적인 통합 (CI). CI 도구의 아이디어는 1991년 Gradi Booch의 Booch Method에서 탄생하고 제시되었습니다.

2007-2008: 실망한 벨기에인

벨기에 컨설턴트이자 Agile 프로젝트 및 실무 관리자인 Patrick Debois는 데이터 센터 마이그레이션을 돕기 위해 벨기에 정부 부처로부터 임명을 수락했습니다. 특히 그는 인증 및 준비 테스트에 참여했습니다. 그는 소프트웨어 개발 팀과 서버, 데이터베이스 및 네트워크 운영 팀 간의 관계를 조정하고 구축하는 책임을 맡았습니다. 결속력 부족, 개발과 운영 방식의 벽에 대한 좌절감은 그를 씁쓸하게 만들었다. 개선하려는 Desbois의 열망은 곧 그를 행동으로 이끌었습니다.
2008년 토론토에서 열린 Agile 컨퍼런스에서 Andrew Schaefer는 ""라는 주제를 논의하기 위해 특별히 준비된 비공식 회의를 주최할 것을 제안했습니다.민첩한 인프라"그리고 주제를 논의하기 위해 단 한 사람만 왔습니다. Patrick DeBois입니다. 그들의 토론과 아이디어 교환은 Agile 시스템 관리의 개념을 발전시켰습니다. 같은 해 DeBois와 Schaefer는 Google에서 어느 정도 성공적인 Agile Systems Administrator 그룹을 만들었습니다.

2009년: Dev와 Ops의 협력 사례

O'Reilly Velocity 컨퍼런스에서 두 명의 Flickr 직원, 기술 운영 담당 수석 부사장 John Allspaw와 CTO Paul Hammond가 현재 유명한 프레젠테이션을 진행했습니다. "하루 10건의 배포: Flickr의 개발 및 운영 협업".

프레젠테이션은 드라마 같았습니다. Allspaw와 Hammond는 소프트웨어 배포 과정에서 개발과 운영 담당자 사이의 복잡한 상호 작용을 재연하면서 “이건 내 코드가 아니고 모두 당신의 컴퓨터입니다!”라는 문구에 따라 손가락질하고 비난했습니다. 그들의 프레젠테이션을 통해 유일한 합리적인 옵션은 소프트웨어 개발 및 배포 활동이 원활하고 투명하며 완전히 통합되는 것임을 확인했습니다. 시간이 지남에 따라 이 프레젠테이션은 전설이 되었으며, 이제는 IT 업계가 오늘날 DevOps로 알려진 방법론을 요구하기 시작한 역사적 이정표로 간주됩니다.

2010년: 미국의 DevOps

추종자가 늘어나면서 DevOpsDays 컨퍼런스는 연례 Velocity 컨퍼런스 직후 미국 캘리포니아주 마운틴뷰에서 처음으로 개최되었습니다. 2018년에는 미국에서 열리는 수십 건을 포함해 30개 이상의 DevOpsDays 컨퍼런스가 예정되어 있습니다.

2013: 프로젝트 "피닉스"

우리 중 많은 사람들에게 DevOps 역사상 또 다른 주목할만한 순간은 Gene Kim, Kevin Behr 및 George Safford가 쓴 "The Phoenix Project"라는 책의 출판이었습니다. 이 소설은 절박한 상황에 처한 IT 관리자의 이야기를 담고 있습니다. 그는 잘못된 중요한 전자 상거래 프로젝트를 구출하는 임무를 맡게 되었습니다. 린 제조 방식에 열정을 갖고 있는 이사회 멤버인 관리자의 신비한 멘토는 DevOps의 개념을 예상하며 IT 및 애플리케이션 개발에 대해 생각할 수 있는 새로운 방법을 주인공에게 제안합니다. 그런데 "The Phoenix Project"는 새로운 주요 아웃소싱 제품을 개발하는 동안 소프트웨어 부사장이 DevOps를 사용하는 유사한 비즈니스 스토리에 대해 "Outsource or else..."라는 책을 쓰도록 영감을 주었습니다.

미래를 위한 DevOps

DevOps를 최종 목적지라기보다는 하나의 여정 또는 열망으로 설명하는 것이 좋습니다. DevOps는 린 제조와 마찬가지로 지속적인 개선, 생산성 및 효율성 향상, 지속적인 배포를 위해 노력합니다. DevOps를 지원하는 자동화된 도구는 계속 발전하고 있습니다.

지난 2018년 동안 DevOps가 시작된 이후 많은 성과를 거두었으며 XNUMX년과 그 이후에는 더 많은 성과를 거두게 될 것으로 예상됩니다.

출처 : habr.com