소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다.
소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것이 목적
빠른 변화 대응의 측정 4요소
- 배포 빈도(Deployment Frequency)
- 장애복구시간(MTTR-Mean Time to Recover)
- 변경 실패율(Change Failure Rate)
- 리드타임(Lead Time)
기존의 SDLC(Software Development Life Cycle)에서 주로 사용하던 폭포수(Waterfall) 모델 방법론은 단계별로 명확한 구현을 원칙으로 진행되는데 실제적으로는 각 단계를 완벽히 마무리한 후 다음 단계로 넘어가는 것은 많은 어려움이 있다고 합니다.
따라서 일정 주기 단위로 필요한 요소를 그때그때 진행하는 방법론이 대두되며 변하는 비즈니스 환경과 사용자의 요구 사항에 빠르게 대처가 가능한 것에서 출발하였습니다.
기존의 방법론에서는 시스템 운영에 있어 SDLC의 일부로만 생각하는 경향이 있었다면 지속되는 새로운 프로세스 도입에 있어 기존의 소프트웨어 개발 생명 주기에 정착시킬 수 없기 때문에 운영(Operation)에 대한 고민도 이루지게 되었습니다.
아마존 웹 서비스(AWS)로 시작하는 데브옵스(AWS DevOps Discovery Book) - 권영환
- 제품 관리자, QA, IT 개발자, IT 운영자 그리고 정보보안 담당자가 유기적인 협력을 통해 조직의 공동 목표를 위해 노력하여 높으 ㄴ안정성과 신뢰성을 가질 수 있으며, 가용성과 보안성 높은 시스템의 구축을 통해 높은 경잴력으로 경쟁사들보다 높은 수준의 Market Share와 매출을 거둘 수 있다.
- 기업 내 교차기능팀(Corss-Functional Teams)의 구성을 통해 고객에게 어떤 서비스가 필요하며, 조직의 목표 달성을 위해 어떤 서비스와 시스템이 필요한지 보다 빠르게 파알하고 지원할 수 있스비낟. 이와 동시에 QA 및 IT 운영팀과 정보보안 담닫자는 팀의 마찰을 중이면서 개발자의 생산성을 높이고, 자체적으로 구성된 자동화된 운영/배포 모니터링 도구를 활용하여 다른 팀에 의존하지 않고도 업무와 관련된 기술을 활용할 수 있습니다.
- 조직은 이를 통해 소규모의 팀이 코드를 신속하고 독립적으로 개발, 테스트, 배포할 수 있는 프로세스를 구축할 수 있으며, 고객에게 빠르고 안전하며, 신뢰할 수 있는 가치를 제공할 수 있습니다. 그리고 조직은 개발자의 생산성을 극대화하며, 지속적인 학습을 통해 시장에서 승리할 수 있습니다.
위와 같은 이상적인 상황은 DevOps를 통해 얻을 수 있는 효과이다.
작은 규모의 개발자로 구성된 팀에서 IT 서비스의 기능을 독립적으로 구현하고, 운영 환경과 동일한 환경에서 실제와 같은 테스트를 수행하며, 코드를 운영 환경에 빠르게 배포하는 환경을 구성하는 것
빠르고 정확하게 운영 환경에 코드를 배포할 수 있다.
배포 프로세스 단계별로 빠른 피드백 루프를 생성하여 빠르게 피드백을 받을 수 있다.
자동화를 통해 보다 빠르고 효과적으로 업무 진행이 가능하다.
원하는 기능과 고객의 요구사항을 독립적으로 전달하고 배포할 수 있다.
신규 제품이나 기능의 출시와 이에 대한 피드백을 보다 효과적으로 진행할 수 있다.
조직과 문화의 변화 없이, 단지 툴만 도입하여 반쪽짜리 DevOps 프로젝트가 되면 안된다.
DevOps 문화는 한 단어로는 '협업', 두 단어로는 '다기능 협업'이라고 요약할 수 있습니다. 이 세상의 모든 도구와 자동화 시스템은 개발 팀원과 IT/Ops 전문가가 진심으로 협력하고자 하는 마음이 없다면 쓸모가 없다고 할 수 있는데요. DevOps는 도구의 문제를 해결하는 것이 아니라, 사람 간의 문제를 해결하기 때문입니다.
성공한 회사 대부분은 모든 부서와 모든 조직 체계에 DevOps 문화를 적용하고 있습니다. 이러한 회사에서는 열린 커뮤니케이션 채널을 갖추고 정기적으로 대화를 진행하며, 모든 사람이 목표를 지정하고 필요에 따라 조정하고, 고객 만족은 제품관리팀과 개발팀 모두의 책임이라고 생각합니다. 즉, DevOps는 한 팀이 하는 일이 아니라 모든 팀이 함께하는 일이라는 것을 알고 있습니다.
자동화는 개발, 테스트 및 지속적 배포의 핵심요소 입니다. 개발 사이클에 높은 수준의 자동화를 도입하 막대한 이점을 얻을 수 있는데요. 자동화를 처음 접하는 팀은 보통 지속적 배포로 시작합니다. 지속적 배포란 대부분 클라우드 기반 인프라로 촉진된 자동화 테스트를 통해 각 코드 변경 사항을 실행한 다음, 빌드를 패키징하고, 자동화 배포를 사용하여 생산을 추진하는 과정입니다. 지속적 배포는 쉽고 빠르게 만들어낼 수는 없지만, ROI는 충분한 가치가 있습니다.
시스템은 언제나 변화하지만 우리는 프로비저닝 코드를 사용하여 겉으로 보기에 시스템이 변하지 않는 것처럼 보이게 만들 수 있습니다. 이로써 손상된 서버를 수리하는 것보다 다시 프로비저닝하는 것이 더 빨라지며, 이는 더 안정적일 뿐만 아니라 위험도 줄어들게 됩니다.
개발팀 및 운영팀은 모두 프로비저닝 코드를 통해 새 언어 또는 기술을 통합하고, 서로 업데이트한 내용을 공유할 수 있는데요. 호환성 이슈는 릴리스 도중에 나타나는 것이 아니라 즉각적으로 분명하게 나타납니다.
소프트웨어의 맥락에서 'Lean'이란 보통 가치가 낮은 활동을 없애고 빠르고 적극적이며 Agile하게 움직인다는 의미입니다. DevOps와 가장 관련 있는 개념은 지속적인 개선과 실패 인정입니다.
DevOps는 여러 가지를 측정하고, 측정결과를 사이클 정비 데이터로 사용합니다. 실제적으로 데이터가 없으면 지속적인 개선을 위한 노력이 실제 개선으로 이어진다고 증명하기가 어려운데요. 성공적인 측정은 피드백 프로세스의 중요한 부분입니다.
기초가 탄탄하면 기능의 사용, 고객 경험 및 SLA(서비스 수준 계약)와 관련된 더 복잡한 메트릭을 포착할 수 있습니다. 이렇게 얻게 되는 정보는 로드맵을 작성하고 다음 계획을 세부적으로 수립할 때 도움이 되며, 다른 팀, 특히 다른 부서의 팀과 공유될 때 더 강력한 힘을 발휘합니다.
‘낭비를 제거하여 어떻게 하면 고객에게 가치를 빠르게 제공할 수 있을까?’를 고민하는 사고방식이며, 그 핵심은 끊임없이 문제를 해결하고 개선하는 것입니다. Lean Principle을 사용하면 지속적인 사이클을 가능하게 합니다.
성공 여부와 상관없이 DevOps는 다른 사람들이 배울 수 있도록 경험을 공유합니다. 개발팀과 운영팀 간의 오랜 마찰은 주로 공유의 부족으로 인해 발생하는데요. DevOps는 애플리케이션을 빌드한 사람들이 애플리케이션의 출시와 실행에도 참여해야 한다는 아이디어를 중심으로 합니다.
이는 개발자 및 운영자가 애플리케이션 라이프사이클의 모든 단계를 함께한다는 것을 의미하는데요. 아이디어의 공동 작업 및 최적화, 문제 및 성공사례 이야기는 필수적이며, 아이디어 공유는 피드백 채널을 열어 개선에 이르게 합니다.
altassian - What is DevOps?
lgcns - 비즈니스 변화를 빠르고 안정적으로 적용하는 기술과 문화
아마존 웹 서비스(AWS)로 시작하는 데브옵스(AWS DevOps Discovery Book) - 권영환