Devops는 개발/운용 부문이 긴밀히 연계하고 다양한 방법과 문화를 도입하여 서비스 개선에 걸리는 시간을 단축하며, 신속하게 비즈니스 요구에 대응한다.
- 지속적인 통합 (CI)
: 코드의 Build 및 정적/동적 테스트를 빈번하게 계속적으로 실시하는 것[장점]
1. Code로 인해 발생하는 문제를 조기 발견
2. Build, Test에 관계된 작업 비용 감소
3. 테스트 상황 가시화
4. Delivery Time 대폭 단축
하지만, 지속적인 통합은 운영보다는 개발에 초점이 맞추어져 있다 보니 빌드 이후 만 들어진 실행 파일에 대한 형상관리, 그리고 QA 프로세스를 진행하여 릴리즈를 만들고 해 당 릴리즈를 배포하는 과정에 대해서 소홀한 부분이 있다.
→ 이 때문에 서두에서 기술 했듯이 IT 조직에게 수시로 변경사항을 애플리케이션에 반영하고, 운영 서버에 배포할 수 있는 역량을 갖추도록 요구하는 현 상황에서 지속적인 통합 이후의 과정에 대한 보완이 필요하게 되었다.
→ 지속적인 통합의 부족한 부분을 보완하기 위해 DevOps 는 이러한 지속적인 통합을 확장한 지속적인 딜리버리(Continuous Deliver)를 제시
[지속적인 딜리버리]
: 구축부터 테스트까지의 작업이 성공하면, 운영 환경으로 Release 준비까지를 완료하는 과정
[출처: 정보통신기술진흥센터]
- 모니터링
: 모니터링은 PDCA 사이클에서 Check 단계를 하기 위한 기반이 된다.모니터링은 단순 감시 용도가 아닌 Resource의 상태를 계속적으로 취득하고 가시화할 경우 서버의 부하 상황과 서비스 사용자의 접속 수 등을 수치화하여 정량적 분석을 실시
모니터링이 없다면 서비스를 계속적으로 개선하지 못하고 성능 튜닝을 할 수 없기때문에 Devops에서 매우 중요한 요소이다.
(Zabbix, Munin, JP1, Hinemos)
PDCA: Plan -> Do -> Check -> Act 사이클을 돌면서 계속적으로 개선을 실시
- 속인성 작업?
: 어떤 특정한 사람에게 크게 의존하는 작업
- 운용 관점에서 봤을 때, 속인성 있는 작업을 배제하지 못한다면 치명적으로 작용한다.
- 해결방법
: 인프라 자원을 구축하는 절차를 가시화 (대표적으로 Ansible이 있음)
- 팀간의 오버헤드가 크다며, 불필요한 기간이나 작업이 대량으로 요구된다.
- 개발과 운용 팀 사이의 관계에서는 오버헤드를 제거하고 함께 요건을 받아 의논하고 크로스 체크를 하며 서보의 작업을 인지한 상태에서 서비스 개선을 진행시키는 관계가 필요하다.
- 해결방법
: 공통의 이슈 트래킹 시스템 또는 채팅 도구 도입
: 시스템을 설계하는 조직은 그 조직의 의사소통 구조를 그대로 복사한 설계를 하게 된다.
→ 한 개의 조직에 여러 팀으로 구성하게 되면, 시스템도 각 파타마다 전문성이 높게 기능이 분리된다.
→ 전문성이 높은 팀은 다른 팀과의 오버헤드가 커진다.
→ 이 때, Devops 도구와 사고방식을 도입하면 시스템 구성과 조직의 위상을 변화시킬 수 있는 긍정적인 영향을 준다.