-
엔터프라이즈 DevOps(데브옵스)> IT Trend/개발환경 2020. 7. 25. 22:59
DevOps는 Dev(개발)과 Ops(운영)이 긴밀하게 협력/연계하여 비즈니스의 가치를 높이기 위해 일하는 방식과 문화다.
이 책에서는 실제 DevOps를 조직에 도입하기 위해 미크로 헤링이 컨설팅했던 경험이 담겨있는데, 현대적인 IT 조직을 운영하기 위한 솔루션들을 제시한다.
미처 생각지 못했던 부분은 조직과 인력관점에 대한 부분이 상당량을 차지하고 있다.
DevOps로 가기 위한 트랜스포메이션 로드맵
1. IT 프로세스를 가시화 한다.
- IT 프로세스를 처리량(throughput), 주기(cycletime), 품질(qualtity) 측면에서 측정
2. 로드맵 생성하기
- 프로세스의 병목 지점을 식별하기 위해서 IT 전달 프로세스의 가치 흐름 맵을 기반으로 한다.
> 가치 흐름 맵 : 공급업체에서 고객에 이르기까지 자재와 정보의 흐름을 아이콘을 사용하여 시각적으로 나타낸 경로 계획 기법.
> IT 전달을 평가하는 기준 설정 : 속도, 비용, 품질
* 속도를 고려할 때 주의해야 하는 사항 1) 실제로는 그렇게 나쁘지 않다 2) 사람들이 지름길을 찾게되면 위험이 증가하거나 품질이 감소함
- 많은 기능 및 변화를 구현하는 데에는 많은 시간이 필요하므로, 트랜스포메이션은 변경관리 활동의 일부여야 한다.
3. 트랜스포메이션 관리하기
- 데브옵스와 애자일은 목표가 아니다.
- 개선의 증거가 부족해 투자가 중단되는 것을 예방하기 위해 트랜스포메이션 시작시점에 기준을 정할 필요가 있다.
> Jenkins를 이용해 지속적인 통합을 도입하면, 빌드와 관련된 개발환경이 중단되는 사태를 30%까지 줄일수 있다는 구체적인 예시
> 출시 주기 - 작업패키지를 승인/출시하는 데 걸리는 평균 시간이 줄어드는 것
> 출시 비용 - 새로운 기능을 출시하는데 들어가는 모든 노력
> 회귀 지속시간 - 변경사항이 퇴행의 원인이 되지 않았다는 유효성 검사에 걸리는 시간
> 제품 가용성 - 제품이 기능적으로 이용할 수 있는 시간의 비율이나, 성공한 트랜잭션의 비율
> 평균 복구시간
> 팀의 수명 - 새로운 프로젝트를 위해 팀이 해체되고 재구성되기까지의 시간
4. IT 전달을 가시적으로 만들기
- 배포 파이프라인을 통해 개발에서 출시까지 소프트웨어가 따르는 모든 단계를 시각적으로 표현한 것을 이용하는 것
- 실시간 대시보드 생성해서 전체 소프트웨어 수명 주기동안 생성된 데이터를 활용
> 출시 품질이 얼마나 좋은지
> 배포 후 출시 패키지에 관련된 문제가 얼마나 있는지
> 소프트웨어 수명주기 후반기에서 테스트자동화 결합비율을 얼마나 개선했는지
5. IT 전달 관리하기(거버넌스)
- 동작하는 기능의 개수, 사고 시 복구시간, 기능들이 전달되어야 하는 주기, 이터레이션 마다 승인된 건과 같은 객관적인 측정치 활용
- 모든 단계에서 사용된 데이터를 가지고 있을 수 없어, 대시보드를 활용하는 것이 좋다. 그렇지 않다면 로깅 덤프를 하거나, 직접 개발한 도구를 사용하거나 추후에 너무 많은 데이터에 압도될 수 있기 때문이다.
6. IT 전달의 린 처리방식
- IT 전달 거버넌스 : 진행 전에 누군가 승인해야하는 모든 단계
> 테스트 환경 배포승인, 변경통제 등 승인과 리뷰 등이 포함되어 있는데, 시간이 지남에 따
> 실제 배포보다 승인프로세스에 더 많은 시간이 걸리는 경우가 있다.
어플리케이션 특성에 따라 그룹화하고 개선/변화 대상으로 선정하는 것
1. 거의 비용이 쓰이지 않는 어플리케이션으로 변화 필요성이나 중요 비즈니스를 하지 않는 대상
2. 비즈니스에 사용되지만 업데이트에 많은 비용이 드는 어플리케이션 - ERP 등..
3. 혁신 엔진 애플리케이션
진정한 레거시를 다루는 방법
- 교살자 패턴 : 새로운 애플리케이션으로 조금씩 이동시켜 레거시 애플리케이션을 제거하는 방법
- 레거시 애플리케이션의 실제 비용을 가시화
> 레거시 애플리케이션때문에 다른 애플리케이션에서 발생하는 지연, 원인이 되는 결함, 유지보수 비용
> 레거시 애플리케이션 때문에 사용할 수 없는 애플리케이션의 기회비용
올바른 거버넌스를 확보하는 방법은 공동의 목표를 달성하기 위해 이해당사자들(경영진)의 자원지원을 활용하는 것이다.
아키텍처 성숙도를 평가하기 위한 4가지 관점
- 자동 확장 : 애플리케이션이 과부하상태에 있는 기능을 유연하게 확장시킬 수 있는지
- 자가 치유 : 문제를 식별하고 대응책을 실행하기 위해 서버/애플리케이션을 재시작하거나, 메시지 큐의 정리, 애플리케이션/서버의 새로운 버전 설치
- 모니터링 : 애플리케이션의 어떤 부분이 비즈니스에 가치를 추가하는지, 데이터를 외부에서 가져올수 있는지
- 변경 역량 : 시스템 전체를 교체하지 않아도 컴포넌트를 변경하거나 업그레이드 할 수 있도록 모듈화되어야 하며, 상위/하위 호환성도 중요함
엔지니어링 원칙
- 소스코드 관리 : 형상관리 시스템에 저장할 수 있는 경우
- API를 이용한 자동화 : 코드품질검사, 단위테스팅, 컴파일, 패키징을 포함해서 자동화 hook 제공을 염두에 두고 만들어야 함
- 애플리케이션의 모듈성 : 빌드/배포시간 감소, 변경에 대한 처리비용을 감소시키도록 더 작은 규모의 프로덕션 배포와 더 작은 크기의 배치작업을 가능하게 함
- 클라우드 지원
기존 레거시 애플리케이션을 교체하는 데 비용과 시간을 투자할 수 없는 경우
- 시스템 통합업체 활용
- 사용자 그룹 환경
- 애플리케이션 교살자 패턴
- 공급업체가 제품을 개선하도록 장려
리소스가 아닌 사람 관리하기
- 일대일 미팅
- 피드백
- 위임
p31~32
IT부서는 비용을 줄이기 위해 더 나은 도구에 투자해 자동화할 수 있었고, 사용하는 소프트웨어의 조류를 바꿀 수도 있다. 또한 다른 기능을 작업자의 보수가 적은 어딘가로 이동시킬 수도 있었다.
IT를 공장에 비유하자면, 한 사람이 요구사항을 설계로 변환하면, 코드를 작성하는 다른 사람에게 이관한다. 그리고 코드를 테스트하는 다음 사람에게 이관한다. 이런 경우 모두 서로에게 아무런 얘기를 하지 않는다. 모든 이관작업은 조립라인에 있는 사람들처럼 기계적으로 처리된다.
p36
데브옵스는 IT분야를 효율적으로 만드는 것에 관련된 내용이 아니라, IT를 이용해 비즈니스를 효율적으로 만드는 것에 관련된 내용이다.
DevOps 정의 - blog.naver.com/ydot/221538123397
728x90반응형