DevOps와 자동화의 차이점은 무엇입니까?

누군가 누군가 DevOps를 할 때마다 배포와 같은 것들을 자동화하는 것에 관한 것입니다.

그러나 자동화는 어디에서 끝나고 DevOps는 시작됩니까?

DevOps의 많은 부분은 매우 자주 릴리스 할 수있게합니다. 자동화 된 빌드, 자동화 된 테스트 등이 함께 제공됩니다. 목표를 달성하기 위해 DevOps는 자동화를 사용하여 효율적이어야합니다.

다음은 DevOps 및 자동화와 관련이 있습니다. DevOps는 자동화가 아니라 그 이상입니다. 반대로, 자동화는 "DevOps 사용자"가 독점적으로 사용하지 않습니다. DevOps가 등장하기 전에 IT에서 많은 자동화가 이루어졌습니다.

DevOps 또는 모든 자동화를 나타내는 위의 다이어그램을 고려하지 마십시오. 독자가 두 개념이 어떻게 관련되어 있는지 파악하는 데 도움이됩니다.

자동화는 DevOps의 핵심 속성이지만 전체 스토리는 아닙니다. 질문은 "시간 복싱과 스크럼의 차이점은 무엇입니까?"와 비슷합니다.

DevOps는 '문화', '운동', '방법론'및 설명이 정확하더라도 이해하기에 충분하지 않은 모든 종류의 것들을 듣게 될 것입니다. 간단히 말해 DevOps는 소프트웨어 프로젝트의 관리 / 제어 / 스티어링에서 새로운 피드백 루프를 가능하게하는 민첩한 방법론, 자동화 및 가상화의 합류에 관한 것입니다.

공격적인 자동화를 통해 오랜 시간이 걸리고 인적 오류가 발생할 수있는 작업은 이제 사고없이 신속하게 수행됩니다. 결과적으로 우리는 더 자주하는 경향이 있습니다. 이것의 기본 예는 '생산에 배치'입니다. 우리는 대량의 작업을 저장하고 '무언가 잘못'된 경우를 대비하여 근무 외 시간에 배치했습니다. 그러나 이제 우리는 하루에 여러 번 변경 사항을 배포하여 '무언가 잘못 될 가능성'을 크게 줄이고, 잘못되었을 때의 영향이 훨씬 적을 수 있습니다.

이 반복 가능한 프로세스가 완료되면 '파이프 라인'으로보기 시작합니다. 프로덕션 환경에 배포 된 코드가 필요합니다. 테스트, 문서화, 병합, 배포 및 기타 테스트 등 파이프 라인을 따라 모든 것을 자동화합니다. 사람들이 자동화에 중점을두기 때문에이를 주도한 '파이프 라인 사고 방식'을 보지 못합니다. 이것이 파이프 라인에서 주목받는 관리 방법론으로 DevOps를 자동화 이상의 가치로 만듭니다.

자동화가 완료되면 피드백 루프가 시작됩니다. 사이클 시간 과 같은 것을 측정하기 시작하여 이전에 추정으로 추측하려고 한 것을 파악할 수 있습니다. 자동화 / 연속 전달을 어렵게 만드는 아키텍처에 관한 사항은 자동화 / 연속 전달을보다 쉽게하는 대체 아키텍처 패턴으로 대체되는 경향이 있습니다 (여러 가지 훌륭한 예는 'Evolutionary Databases'책에 설명되어 있습니다. ).

공지 사항 Jenkins, Check, Puppet, Ansible, Vagrant, AWS 또는 기타 지원 도구에 대해 이야기하지 않고이 설명을 제공 할 수있었습니다. 이것이 우리가 '방법론'과 같은 더 큰 수준의 유행어에 의해 의미하는 바입니다. 결국 모든 도구 세트를 교체 할 수 있습니다. 우리가 남은 것은 자동화와 파이프 라인에 중점을 둔 핵심 관리 원칙입니다.

DevOps는 실제로 문화적 변화입니다. 운영과 개발 사이의 전통적 장벽을 무너 뜨리기위한 것입니다 (실제로 QA 및 나머지 비즈니스에서도). 아이디어는 부서별 '사일로'를 사용하지 않고 다른 팀과 직접 협력하여 작업을보다 빠르고 효율적으로 수행 할 수 있다는 것입니다.

제약 조건 제거 및 프로세스 간소화에 관한 모든 것입니다. 반복 가능한 프로세스를 사용하면 제약 조건을 제거하는 데 도움이되므로 자동화에 많은 도움이됩니다. 예를 들어, 운영 담당자가 환경에 코드를 가져 오기 위해 수동 릴리스 프로세스를 수행해야하는 경우 방해가 될 수있는 몇 가지 사항이 있습니다. 둘째, 수동 작업에 오류가 발생하기 때문에 릴리스 프로세스에 대한 확신이 부족합니다.

DevOps에는 자동화가 포함되어 있지만 그 일부일뿐입니다. DevOps는 조직의 여러 부분 사이의 사일로를 분해하여 완전한 가치 흐름을 제공하는 문화적 변화입니다. 비즈니스, 개발, 품질 보증, 인프라, 보안, 운영 등이 모두 협력하여 최종 사용자에게 가치를 제공하는 문화를 제공합니다. DevOps는 도구가 아니므로 구입할 수 없으며 문화를 바꿔야합니다.

자동화는 품질과 함께 제공 속도가 빠르다는 점에서 DevOps의 핵심 부분입니다. 배포 프로세스의 자동화는 많은 사람들이 가장 먼저 초점을 맞추는 영역 중 하나입니다. 배포 시간을 단축 할뿐만 아니라 프로세스를 표준화하고 제거함으로써 빠른 가치를 얻고 최고의 투자 수익을 제공합니다. 오류.

나는 2 센트를 추가하고 싶습니다 :
1) 자동화 :
     오늘날 우리가 나아가 야 할 것. 바람직한 방법은 전체 공정이 아닌 경우 조각을 자동화하는 것이 더 필요하다. 이 접근 방식은 사용자 (개발자)가 필요에 따라 사용자 정의 할 수있는 고정 단계를 사용할 수있는 유연성을 제공합니다.
     이 접근 방식의 장점은 개발자가 개별 프로세스를 함께 묶을 수 있도록 원하는 부분을 자동화 할 수 있다는 것입니다. 자동화 단계를 세분화할수록 제어 수준이 향상됩니다.
     또한 로봇 자동화, SOP 자동화 (서비스 산업용), 보고서 자동화 (Splunk와 같은) 등의 공간에서 자동화를위한 많은 도구가 있습니다.
2) DevOps:
     현재 세계에서 예상되는 제공 품질 및 적시성 상태를 고려할 때 소프트웨어 제공 프로세스의 자동화를 확장해야합니다. 이를 가능하게하고 가능한 가장 빠른 방법으로 고객에게 가치를 제공하기 위해 DevOps는 자동화 도구에 광범위하게 의존합니다.
     이 방식의 장점은 개별 단계를 자동화하여 전사적으로 일관성을 유지하면서 전체 오케스트레이션을 해당 프로젝트에 필요한 프로세스에 맞게 수정할 수 있다는 것입니다.
     구축 용 Chef, Dockerfile을 통한 Docker, 빌드 용 Maven 등과 같은 개별 자동화 도구를 Jenkins를 통해 함께 묶어 필요한 솔루션을 제공하는 동시에 구현 또는 사용에 필요한 시간을 단축 할 수 있습니다. .
이것이 당신이 이미 가지고있을 수있는 사고 과정에 가치를 더하는 데 도움이되기를 바랍니다.

편집 : DevOps의 3 가지 측면 중 2 가지 프로세스 및 도구에 대해 이야기했다는 것을 잊었습니다. 다른 사람들이 언급했듯이 세 번째로 똑같이 중요한 측면은 사람들입니다. 내가 이것과 자동화 사이의 주요 차이점 중 하나는 사람들이 DevOps에 저항하는 것보다 자동화를 더 자주 흡수하기 쉽다는 것입니다. DevOps 자체의 특성 때문이라고 생각합니다. 자동화는 일반적으로 작업을보다 쉽게 ​​해주는 것과 관련이 있으며 DevOps는 익숙한 방식을 바꾸고 있다고 생각합니다.

DevOps 이동은 CAMS로 약칭 된 네 가지 주요 영역으로 구성됩니다 .

1. 문화
2. 오토메이션
3. 측정
4. 나누는

다음은 2010 년 의 원래 게시물 입니다.

각 영역에는 일반적으로 수용되는 몇 가지 도구, 프로세스 및 관행이 있지만, 주제는 모범 사례에 대해 잘 정의되어 있지 않지만 대부분의 경우 따라야 할 모범 사례가 있습니다.

자동화 자체는 좀 더 넓은 주제이지만 DevOps와 관련하여 다루고있는 것의 일부일뿐입니다. 현장을 처음 접하는 많은 DevOps 실무자가 종종 자신의 위험을 간과하고 자동화로 바로 넘어가지만, 우리는 문화를 선도한다는 점에 유의하십시오.

자동화와 DevOps는 관련이 없습니다. DevOps는 사이트 또는 서비스 개발자가 해당 사이트 또는 서비스의 운영자 인 복합 엔지니어링과 유사합니다. 이 소설은 왜? 내 경험상 네트워크 실수보다 더 흥미로운 일이있을 때 Ops 팀이 가장 먼저 한 일은 Dev 팀에 전화하는 것이 었습니다. 그들은 왜 그렇게 했습니까? 모든 Ops 팀이 전화를 걸어 개발 전화 번호 목록을 모니터링하고 유지했기 때문에.

자동화에 대해 아무 말도하지 않았습니다.

자동화는 성공을 반복하는 것입니다. 단계 a, b 및 c를 수행하고 프로세스 X가 항상 작동하면 단계 a, b 및 c가 자동화의 좋은 후보입니다. 그런 다음 돈을 벌 수있는 일을하기 위해 수동 프로세스였던 시간을 사용할 수 있습니다. 간단하면 자동화에 성공합니다. 새로운 릴리스 배포, 통합 테스트 실행, 볼트 너트 고정, 데이터 백업, 크레딧 대 차변 균형 조정 등은 모두 사람이나 로봇에 의해 단계가 반복되기 때문에 자동화의 훌륭한 후보입니다.

참고 : 새로운 기능은 개발자도 운영자입니다. 다른 그룹이 없습니다. 제 경우에는 협력이 드물었습니다. 문제점 해결 안내서 (일명 TSG)에 아무것도 없으면 전화가 걸렸습니다. 내 경험에 따르면 백호의 경우 Ops가 첫 번째 전화였습니다. 서비스 간 문제는 조타실에서 벗어났습니다.