팀 구조에 영향을 받는 애플리케이션 서비스 배포 계획

개발자들은 정말 다릅니다. 개발자는 역할과 책임, 조직 구조 내에서의 위치 등을 고려했을 때 종종 "이상한 집단"에 속합니다. 개발팀은 IT의 일부와 비즈니스의 일부 사이에서 왔다 갔다 하기 때문에 "IT"라는 용어에 포함할 수도 없습니다.

DevOps가 문화적 변화로 자리 잡기 시작했음에도 불구하고 대부분의 조직은 기능적으로 IT 사일로라는 별로 좋게 불리지 않는 방식으로 여전히 조직되어 있습니다. 2019년 애플리케이션 서비스 현황 조사에서 모든 응답자의 거의 절반(46%)이 여전히 "네트워크", "서버", "스토리지", "보안"과 같은 "단일 기능 팀"으로 구성되어 있는 것으로 나타났습니다. 3분의 1 이상(37%)이 애플리케이션 제공 및 배포에 DevOps 원칙과 접근 방식을 도입하고 적용하는 데 더 적합한 결합된 운영 팀에서 일하고 있었습니다. 사업부나 회사 제품을 기반으로 하는 소규모의 기능 간 팀에서 일하는 사람은 15%에 불과했습니다.

구조는 목적과 우선순위를 정의하기 때문에 중요합니다. 그러면 성공을 측정하는 기준이 결정됩니다. 조직이 분산되면 지표도 분산됩니다. 이는 지난 여름의 NetOps와 DevOps 설문조사 에서 확인할 수 있습니다. 우리는 팀의 구조에 따라 팀을 측정하는 방법에 상당한 차이가 있음을 보았습니다. 예를 들어, 모든 팀 유형과 역할에서 가장 일반적인 지표는 다음과 같습니다.

1. 네트워크 가동 시간(60%)
2. 애플리케이션 가동 시간(56%)
3. 프로세스 최적화(40%)
4. 평균 해결 시간(39%)

하지만 이를 분석하여 팀 유형에 따른 지표를 살펴보면, 보다 협력적인 팀일수록, DevOps와 유사 - 팀 구조이므로 우선순위가 바뀝니다. 

그러면 측정 기준은 애플리케이션 서비스와 어떤 관련이 있을까요? 실제로는 꽤 많습니다.

네트워크 가동 시간이 주된 관심사라면 그에 맞춰 노력하고 해당 목표를 달성하는 서비스를 배포해야 합니다. 애플리케이션 가동 시간에도 마찬가지입니다. 그것이 여러분의 우선순위라면 배포 빈도로 측정되는 사람들보다 가용성 서비스를 훨씬 더 중요하게 생각할 것입니다.

우리 연구에서는 애플리케이션 서비스 배포 계획에서 대부분 "단일 기능 팀" 응답자 기반의 영향을 확인할 수 있습니다. 보안, 성능, ID/액세스, 가용성 및 이동성과 같이 애플리케이션에 제공하는 기능을 기준으로 애플리케이션 서비스를 분류하면 이는 더욱 분명해집니다. 

이러한 결과는 단일 기능 팀 지표의 영향을 반영합니다. 개발자는 주로 가용성(종종 구체적인 성능 목표 포함)에 관심을 갖고 있으며 가용성과 성능을 모두 지원하는 애플리케이션 서비스를 배포할 계획을 세웁니다. 마찬가지로 NetOps는 네트워크 프로토콜을 최적화, 확장 및 보호하여 네트워크 가동 시간을 지원하는 애플리케이션 서비스에 중점을 둡니다. 

팀 구조가 중요합니다. 보다 협력적인 문화를 장려해야 할 필요성 때문일 뿐만 아니라, 그것이 기술 선택을 포함한 의사 결정에 영향을 미치는 방식 때문입니다. 다양한 목표는 갈등과 좌절로 이어진다. 이는 기존에 NetOps에서 배포 및 운영하던 로드 밸런싱과 같은 애플리케이션 서비스가 DevOps로 인해 대체되어 애플리케이션의 일부로 배포되는 이유 중 하나입니다. 단일 기능 팀 구조를 갖춘 조직에서는 애플리케이션 가동 시간이 개발자에게는 우선순위이지만 NetOps에게는 그렇지 않습니다.

DevOps를 실제로 활용하려면 팀 구조와 이를 측정하는 지표가 기존의 단일 기능 팀에서 벗어나 더욱 협력적인 모델로 전환되어야 합니다.

사일로는 IT가 아닌 농장에 속하기 때문입니다.