2021.11.17

데브옵스에 애자일과 ITSM 도구가 통합되어야 하는 3가지 이유

Isaac Sacolick | InfoWorld
데브옵스 원칙을 따르고 데브옵스 문화로 전환하려는 조직이 점차 늘어나고 있다. 데브옵스의 주 실행법에는 버전 제어, 지속적 통합 및 배포(CI/CD), 코드형 인프라(IaC), 머신러닝을 운영에 적용하기(AI옵스), 지속적 테스트 등이 포함된다.

더 발전 팀은 지속적 계획, 클라우드 네이티브 애플리케이션 설계, 마이크로서비스 개발, 기능 플래그를 사용한 코드 제어, 보안의 시프트 레프트 촉진, 서비스 수준 목표 설정, 오류 예산 관리, 데이터 지향성 강화 등에도 초점을 둔다.
 
위의 각 실행방법은 데브옵스 조직의 두 가지 주요 IT 기능인 개발(새 애플리케이션 구축하기, 품질 향상 자주 릴리스하기)과 운영(비즈니스 시스템, 데이터베이스, 애플리케이션의 안정성과 성능 보장하기)을 바꾸는 데 도움이 된다.
 
ⓒ Getty Images Bank

데브옵스를 데브섹옵스(DevSecOps)로까지 확장하고, 보안을 다른 요소와 동등한 지위에 올려두는 조직도 늘고 있다. 데브섹옵스의 주요 IT 실행방법에 필요한 요소로는 경쟁에 필요한 속도와 민첩성, 비즈니스 운영에 필요한 혁신, 안정성, 보안, 성능간의 균형을 들 수 있을 것이다.
 

데브옵스 협업에는 애자일 및 ITSM 도구 통합이 필요하다

데브섹옵스 실행방법 하나만 가지고는 개발과 운영, 보안 기능을 결합해 목표 달성에 필요한 협업을 완성할 수 없다. 각 기능을 포괄하는 워크플로우를 구현, 추적하고 측정해야 한다.
 
많은 조직에서 이런 워크플로우는 스크럼, 칸반 등 개발 팀에 사용되는 애자일 방법론과 요청 관리, 사고 관리, 문제 관리, 변경 관리, 구성 관리 데이터베이스(CMDB) 유지보수, 그리고 운영 팀이 관리하는 IT 서비스 관리(ITSM) 실행방법을 결합해 실행된다.
 
그러나 애자일과 ITSM 도구를 통합하는 조직은 많지 않다.
 
개발 팀은 애저 데브옵스, Digital.ai, 지라 소프트웨어, 기타 애자일 도구로 개발 프로세스에서 사용자 스토리, 스프린트, 릴리스의 백로그를 관리할 수 있다. 운영 팀은 독립적으로 BMC, 셔웰(Cherwell), 이반티(Ivanti), 지라 서비스 매니지먼트(Jira Service Management), 마이크로 포커스(Micro Focus), 서비스나우(ServiceNow), 기타 ITSM 도구를 사용해서 티켓 관리, 시스템 추적, 변경 관리 등을 처리할 수 있다.
 
자동화와 통합할 경우 애자일이나 ITSM 도구에서 지원되는 워크플로우를 연결할 수 있지만, 안타깝게도 현실은 이런 기능과 종단간 워크플로우를 연결하는 이메일, 회의, 슬랙(Slack), 줌(Zoom) 및 기타 수동 프로세스의 조합에 불과한 경우가 많다.
 
즉, 데브섹옵스 모범 사례와는 거리가 먼 것이다.
 
ITSM 도구와 워크플로우 연결이 왜 중요한지 궁금하다면, 빠른 배포, 보안, 안정적인 운영이라는 3가지 목표를 달성하기 위해 데브섹옵스에 필요한 통합 요점 3개를 자세히 살펴보자. 
 

위험성이 낮은 변경을 신속하게 배포할 것

대규모 IT 조직, 또는 규제 대상 업종에 속한 IT 조직은 프로덕션 환경으로 변경 사항을 배포할 때 규정 준수와 위험성 측면을 검토하기 위해 변경 자문 위원회를 두는 경우가 많다. 변경 자문 위원회는 보통 프로덕션 배포를 계획하고 실행하기 전에 데브옵스 팀에 문서를 제출하고 규정 준수 테스트를 시연하고 보안 위험을 검토하고 종속성을 공유할 것을 요구한다.
 
많은 팀과 시스템 종속성, 비즈니스 운영 위험이 수반되는 매우 복잡한 배포를 조율할 때에는 이 접근 방법이 필요하다. 이런 문제를 최소화하는 데 목표를 두는 데브옵스 실행방법은 이미 많다. 예를 들어 견고한 지속적 테스트 및 CI/CD와 마이크로서비스를 함께 구축하면, 데브옵스 팀이 작고 위험성이 낮은 변경을 배포할 수 있다. 위험성이 낮은 변경의 예를 들면 서버리스 아키텍처에 배포되는 UX 구성요소, 내장된 분석 대시보드 변경, 로우코드 앱 개선, 소규모 데이터옵스 구성 변경 등이 있다.
 
위험성이 확실히 낮은 작은 변경이 있다면, IT는 애자일 도구에서 트리거되는 CI/CD 변경을 ITSM 도구에서 관리되는 변경 관리 워크플로우와 연결해서 승인을 자동화할 수 있을까?
 
물론 먼저 비즈니스, 개발, 보안, 운영 부서가 “낮은 위험”과 “작은”이라는 용어의 정의에 합의해야 한다. 또한 CI/CD 파이프라인이 롤백을 지원해야 하고, 이상적으로는 변경이 예기치 못한 문제를 일으킬 경우 사고 관리자가 트리거할 수 있어야 한다.
 
소프트웨어 구성요소의 크기와 규모와 종속성을 줄이면서 자주 배포하는 방향을 추구하는 데브옵스 팀이 늘어나는 만큼, 변경 승인 자동화는 애자일과 ITSM 도구 간의 주요 통합 요소가 되어야 한다.
 

프로덕션 결함 우선 순위화 및 해결할 것

사용 중인 테스트 자동화와 지속적 테스트 실행방법이 충분히 견고해서 결함이 없는 꾸준한 프로덕션 릴리스를 보장할 수 있는가?
 
운영 또는 사이트 안정성 엔지니어가 프로덕션 문제에 대한 근본 원인 분석을 수행하거나 사용자가 서비스 데스크에 애플리케이션 문제를 보고할 때, 온보드된 문제는 애자일 개발 팀의 백로그에 결함으로 나타나야 한다. 애자일 개발 팀이 이와 같은 결함의 검토, 그리고 이상적으로는 해결에 높은 우선 순위를 둔다면 ITSM 도구에서 캡처된 사고나 기타 티켓 유형은 현재 상태를 반영해야 한다.
 
이 매핑은 구현하기가 쉽지 않다. 애자일 도구와 ITSM 도구의 결함 간에 워크플로우 상태를 매핑해야 하기 때문이다. 또한 티켓이 여러 결함으로 이어지거나, 여러 티켓이 하나의 결함으로 연결될 수도 있다. 이런 워크플로우에는 다른 예외도 발생할 가능성이 높다. 예를 들어 서비스 데스크는 요청 티켓을 결함에 매핑하지만, 개발 팀은 사용자가 사실상 새로운 기능을 요청하는 것으로 보는 경우가 여기에 해당된다.
 
그러나 사용자 요청 및 서비스 데스크를 통해 보고되는 사고와 애자일 개발 팀의 백로그를 서로 완전히 분리할 경우 상당한 문제가 될 수도 있다. 애자일 개발 팀이 운영 문제와 사용자 요구를 검토하거나 우선처리하지 않을 수도 있음을 의미하기 때문이다.
 
고객 및 운영 문제에 민감해야 하는 팀 관점에서 볼 때 최선의 애자일 실행방법은 아니다. 최선의 방법은 결함 우선 순위화를 위해 두 워크플로우와 개발 정책을 연결하는 것이다.
 

배포와 모니터링과 AI옵스 플랫폼을 연결하기

프로덕션 사고가 발생할 때 서비스 데스크의 주요 성과 지표는 최대한 신속하고 효율적으로 사고를 해결하는 것이다. 프로덕션 사고의 평균 해결 시간(MTTR)을 추적하고 빠르게 문제를 파악하기 위해 모니터와 경보의 수를 늘리는 ITSM 팀이 많다.
 
멀티클라우드 아키텍처 또는 여러 모니터링 도구를 사용하는 IT 조직은 AI옵스 플랫폼으로 모니터링과 관찰 가능성 데이터를 중앙화할 수 있다. 데이터가 중앙에 모이면 AI옵스 플랫폼이 머신러닝을 적용해 여러 시스템 경보를 하나의 관리 가능한 사고로 연계할 수 있게 해준다. 그러나 간과되는 경우가 많은 한 가지는 개발 변경을 모니터링 및 AI옵스 도구와 통합하는 것이다.
 
네트워크 운영 센터 또는 보안 운영 센터가 모든 관찰 가능성 데이터, 배포, 기능 플래그 변경 또는 기타 구성 변경을 완전히 파악하고 있는가? 필자가 만일 네트워크 운영 센터에서 일한다면 데이터베이스에서 경보가 발생할 때 애자일, ITSM, 버전 제어, 기능 플래그 및 기타 도구에서 누가 언제 무엇을 했는지 일일이 추적하고 싶지는 않을 것이다.
 
또한 개발 팀이 SRE 실행법과 오류 예산 측정을 중시한다면 앱과 서비스, 데이터베이스, 기반 인프라의 성능과 안정성에 대한 통합적인 프로덕션 분석 데이터를 받을 수 있어야 한다.
 
이런 형태의 통합은 종단간 데브옵스 실행법 지원에 결정적인 요소겠지만, 달성을 위해서는 다음과 같은 여러 시스템 간에 데이터를 연결해야 한다. 
 
  • 개발 팀이 사용하는 애자일 개발, 버전 제어, 기능 플래그, 테스트 자동화, CI/CD 도구
  • 서비스 데스크에서 관리하는 사고, 요청 및 변경을 캡처하기 위한 ITSM 도구
  • 인프라의 정확한 상태를 캡처하는 CMDB와 종속성 및 검색 매핑 도구
  • 네트워크 운영 센터와 보안 운영 센터에서 사용하는 모니터링 및 AI옵스 도구
  • 비즈니스 리더에게 투명성과 통제 수단을 제공하기 위한 가치 흐름 매핑 및 기타 제품 관리 도구
 
AI옵스, 관찰가능성, 서비스 수준 목표를 위한 관리 도구에는 빅판다(BigPanda), 브로드컴(Broadcom), 데이터도그(DataDog), 데보(Devo), 디지테이트(Digitate), 다이나트레이스(Dynatrace), 일래스틱(Elastic), 마이크로 포커스(Micro Focus), 무그소프트(Moogsoft), 뉴 렐릭(New Relic), 노블9(Nobl9), 옵스램프(OpsRamp), 리졸브(Resolve), 사이언스로직(ScienceLogic), 스플렁크(Splunk) 등이 있다.
 
IT 팀이 데브옵스에 초점을 맞출 때 가장 중요한 것은 개발, 운영, 보안 워크플로우의 통합과 현대화의 필요성을 인지하는 것이다. editor@itworld.co.kr 


2021.11.17

데브옵스에 애자일과 ITSM 도구가 통합되어야 하는 3가지 이유

Isaac Sacolick | InfoWorld
데브옵스 원칙을 따르고 데브옵스 문화로 전환하려는 조직이 점차 늘어나고 있다. 데브옵스의 주 실행법에는 버전 제어, 지속적 통합 및 배포(CI/CD), 코드형 인프라(IaC), 머신러닝을 운영에 적용하기(AI옵스), 지속적 테스트 등이 포함된다.

더 발전 팀은 지속적 계획, 클라우드 네이티브 애플리케이션 설계, 마이크로서비스 개발, 기능 플래그를 사용한 코드 제어, 보안의 시프트 레프트 촉진, 서비스 수준 목표 설정, 오류 예산 관리, 데이터 지향성 강화 등에도 초점을 둔다.
 
위의 각 실행방법은 데브옵스 조직의 두 가지 주요 IT 기능인 개발(새 애플리케이션 구축하기, 품질 향상 자주 릴리스하기)과 운영(비즈니스 시스템, 데이터베이스, 애플리케이션의 안정성과 성능 보장하기)을 바꾸는 데 도움이 된다.
 
ⓒ Getty Images Bank

데브옵스를 데브섹옵스(DevSecOps)로까지 확장하고, 보안을 다른 요소와 동등한 지위에 올려두는 조직도 늘고 있다. 데브섹옵스의 주요 IT 실행방법에 필요한 요소로는 경쟁에 필요한 속도와 민첩성, 비즈니스 운영에 필요한 혁신, 안정성, 보안, 성능간의 균형을 들 수 있을 것이다.
 

데브옵스 협업에는 애자일 및 ITSM 도구 통합이 필요하다

데브섹옵스 실행방법 하나만 가지고는 개발과 운영, 보안 기능을 결합해 목표 달성에 필요한 협업을 완성할 수 없다. 각 기능을 포괄하는 워크플로우를 구현, 추적하고 측정해야 한다.
 
많은 조직에서 이런 워크플로우는 스크럼, 칸반 등 개발 팀에 사용되는 애자일 방법론과 요청 관리, 사고 관리, 문제 관리, 변경 관리, 구성 관리 데이터베이스(CMDB) 유지보수, 그리고 운영 팀이 관리하는 IT 서비스 관리(ITSM) 실행방법을 결합해 실행된다.
 
그러나 애자일과 ITSM 도구를 통합하는 조직은 많지 않다.
 
개발 팀은 애저 데브옵스, Digital.ai, 지라 소프트웨어, 기타 애자일 도구로 개발 프로세스에서 사용자 스토리, 스프린트, 릴리스의 백로그를 관리할 수 있다. 운영 팀은 독립적으로 BMC, 셔웰(Cherwell), 이반티(Ivanti), 지라 서비스 매니지먼트(Jira Service Management), 마이크로 포커스(Micro Focus), 서비스나우(ServiceNow), 기타 ITSM 도구를 사용해서 티켓 관리, 시스템 추적, 변경 관리 등을 처리할 수 있다.
 
자동화와 통합할 경우 애자일이나 ITSM 도구에서 지원되는 워크플로우를 연결할 수 있지만, 안타깝게도 현실은 이런 기능과 종단간 워크플로우를 연결하는 이메일, 회의, 슬랙(Slack), 줌(Zoom) 및 기타 수동 프로세스의 조합에 불과한 경우가 많다.
 
즉, 데브섹옵스 모범 사례와는 거리가 먼 것이다.
 
ITSM 도구와 워크플로우 연결이 왜 중요한지 궁금하다면, 빠른 배포, 보안, 안정적인 운영이라는 3가지 목표를 달성하기 위해 데브섹옵스에 필요한 통합 요점 3개를 자세히 살펴보자. 
 

위험성이 낮은 변경을 신속하게 배포할 것

대규모 IT 조직, 또는 규제 대상 업종에 속한 IT 조직은 프로덕션 환경으로 변경 사항을 배포할 때 규정 준수와 위험성 측면을 검토하기 위해 변경 자문 위원회를 두는 경우가 많다. 변경 자문 위원회는 보통 프로덕션 배포를 계획하고 실행하기 전에 데브옵스 팀에 문서를 제출하고 규정 준수 테스트를 시연하고 보안 위험을 검토하고 종속성을 공유할 것을 요구한다.
 
많은 팀과 시스템 종속성, 비즈니스 운영 위험이 수반되는 매우 복잡한 배포를 조율할 때에는 이 접근 방법이 필요하다. 이런 문제를 최소화하는 데 목표를 두는 데브옵스 실행방법은 이미 많다. 예를 들어 견고한 지속적 테스트 및 CI/CD와 마이크로서비스를 함께 구축하면, 데브옵스 팀이 작고 위험성이 낮은 변경을 배포할 수 있다. 위험성이 낮은 변경의 예를 들면 서버리스 아키텍처에 배포되는 UX 구성요소, 내장된 분석 대시보드 변경, 로우코드 앱 개선, 소규모 데이터옵스 구성 변경 등이 있다.
 
위험성이 확실히 낮은 작은 변경이 있다면, IT는 애자일 도구에서 트리거되는 CI/CD 변경을 ITSM 도구에서 관리되는 변경 관리 워크플로우와 연결해서 승인을 자동화할 수 있을까?
 
물론 먼저 비즈니스, 개발, 보안, 운영 부서가 “낮은 위험”과 “작은”이라는 용어의 정의에 합의해야 한다. 또한 CI/CD 파이프라인이 롤백을 지원해야 하고, 이상적으로는 변경이 예기치 못한 문제를 일으킬 경우 사고 관리자가 트리거할 수 있어야 한다.
 
소프트웨어 구성요소의 크기와 규모와 종속성을 줄이면서 자주 배포하는 방향을 추구하는 데브옵스 팀이 늘어나는 만큼, 변경 승인 자동화는 애자일과 ITSM 도구 간의 주요 통합 요소가 되어야 한다.
 

프로덕션 결함 우선 순위화 및 해결할 것

사용 중인 테스트 자동화와 지속적 테스트 실행방법이 충분히 견고해서 결함이 없는 꾸준한 프로덕션 릴리스를 보장할 수 있는가?
 
운영 또는 사이트 안정성 엔지니어가 프로덕션 문제에 대한 근본 원인 분석을 수행하거나 사용자가 서비스 데스크에 애플리케이션 문제를 보고할 때, 온보드된 문제는 애자일 개발 팀의 백로그에 결함으로 나타나야 한다. 애자일 개발 팀이 이와 같은 결함의 검토, 그리고 이상적으로는 해결에 높은 우선 순위를 둔다면 ITSM 도구에서 캡처된 사고나 기타 티켓 유형은 현재 상태를 반영해야 한다.
 
이 매핑은 구현하기가 쉽지 않다. 애자일 도구와 ITSM 도구의 결함 간에 워크플로우 상태를 매핑해야 하기 때문이다. 또한 티켓이 여러 결함으로 이어지거나, 여러 티켓이 하나의 결함으로 연결될 수도 있다. 이런 워크플로우에는 다른 예외도 발생할 가능성이 높다. 예를 들어 서비스 데스크는 요청 티켓을 결함에 매핑하지만, 개발 팀은 사용자가 사실상 새로운 기능을 요청하는 것으로 보는 경우가 여기에 해당된다.
 
그러나 사용자 요청 및 서비스 데스크를 통해 보고되는 사고와 애자일 개발 팀의 백로그를 서로 완전히 분리할 경우 상당한 문제가 될 수도 있다. 애자일 개발 팀이 운영 문제와 사용자 요구를 검토하거나 우선처리하지 않을 수도 있음을 의미하기 때문이다.
 
고객 및 운영 문제에 민감해야 하는 팀 관점에서 볼 때 최선의 애자일 실행방법은 아니다. 최선의 방법은 결함 우선 순위화를 위해 두 워크플로우와 개발 정책을 연결하는 것이다.
 

배포와 모니터링과 AI옵스 플랫폼을 연결하기

프로덕션 사고가 발생할 때 서비스 데스크의 주요 성과 지표는 최대한 신속하고 효율적으로 사고를 해결하는 것이다. 프로덕션 사고의 평균 해결 시간(MTTR)을 추적하고 빠르게 문제를 파악하기 위해 모니터와 경보의 수를 늘리는 ITSM 팀이 많다.
 
멀티클라우드 아키텍처 또는 여러 모니터링 도구를 사용하는 IT 조직은 AI옵스 플랫폼으로 모니터링과 관찰 가능성 데이터를 중앙화할 수 있다. 데이터가 중앙에 모이면 AI옵스 플랫폼이 머신러닝을 적용해 여러 시스템 경보를 하나의 관리 가능한 사고로 연계할 수 있게 해준다. 그러나 간과되는 경우가 많은 한 가지는 개발 변경을 모니터링 및 AI옵스 도구와 통합하는 것이다.
 
네트워크 운영 센터 또는 보안 운영 센터가 모든 관찰 가능성 데이터, 배포, 기능 플래그 변경 또는 기타 구성 변경을 완전히 파악하고 있는가? 필자가 만일 네트워크 운영 센터에서 일한다면 데이터베이스에서 경보가 발생할 때 애자일, ITSM, 버전 제어, 기능 플래그 및 기타 도구에서 누가 언제 무엇을 했는지 일일이 추적하고 싶지는 않을 것이다.
 
또한 개발 팀이 SRE 실행법과 오류 예산 측정을 중시한다면 앱과 서비스, 데이터베이스, 기반 인프라의 성능과 안정성에 대한 통합적인 프로덕션 분석 데이터를 받을 수 있어야 한다.
 
이런 형태의 통합은 종단간 데브옵스 실행법 지원에 결정적인 요소겠지만, 달성을 위해서는 다음과 같은 여러 시스템 간에 데이터를 연결해야 한다. 
 
  • 개발 팀이 사용하는 애자일 개발, 버전 제어, 기능 플래그, 테스트 자동화, CI/CD 도구
  • 서비스 데스크에서 관리하는 사고, 요청 및 변경을 캡처하기 위한 ITSM 도구
  • 인프라의 정확한 상태를 캡처하는 CMDB와 종속성 및 검색 매핑 도구
  • 네트워크 운영 센터와 보안 운영 센터에서 사용하는 모니터링 및 AI옵스 도구
  • 비즈니스 리더에게 투명성과 통제 수단을 제공하기 위한 가치 흐름 매핑 및 기타 제품 관리 도구
 
AI옵스, 관찰가능성, 서비스 수준 목표를 위한 관리 도구에는 빅판다(BigPanda), 브로드컴(Broadcom), 데이터도그(DataDog), 데보(Devo), 디지테이트(Digitate), 다이나트레이스(Dynatrace), 일래스틱(Elastic), 마이크로 포커스(Micro Focus), 무그소프트(Moogsoft), 뉴 렐릭(New Relic), 노블9(Nobl9), 옵스램프(OpsRamp), 리졸브(Resolve), 사이언스로직(ScienceLogic), 스플렁크(Splunk) 등이 있다.
 
IT 팀이 데브옵스에 초점을 맞출 때 가장 중요한 것은 개발, 운영, 보안 워크플로우의 통합과 현대화의 필요성을 인지하는 것이다. editor@itworld.co.kr 


X