DevOps는 배달로 끝나지 않습니다

배포로 인해 릴리스가 지연되면 아무리 빨리 제공하더라도 소용이 없습니다. NetOps가 자동화와 오케스트레이션을 도입하고 있지만 배포 속도를 높이기 위한 노력에는 상당한 과제가 있습니다. DevOps는 이를 도울 수 있는 가장 적합한 위치에 있습니다.

디지털 전환은 DEVOPS를 의미합니다.

디지털 혁신과 DevOps 사이에는 분명히 연관성이 있습니다. DX로 인해 조직의 48%가 앱을 프로덕션에 더 자주 제공하고 있습니다. 62%는 IT 시스템과 프로세스를 자동화하고 조정하고 있습니다. 52%는 앱 개발 방식을 바꾸고 있습니다(Agile을 생각해 보세요). 그리고 42%는 컨테이너와 마이크로서비스를 탐색하고 있습니다. 애플리케이션의 구성 요소부터 이를 시장에 출시하기 위한 방법까지 디지털 변환은 DevOps가 "지속적인 전달"을 "지속적인 배포"로 확장할 수 있는 방법이 있다는 것을 의미합니다. "배달"이란 마케팅을 의미하는 것이 아니라 프로덕션을 의미합니다. 프로덕션은 배포 프로세스가 시작되어 애플리케이션을 소비에 적합한 상태로 만드는 것을 의미합니다.

"사용에 적합하다"는 것은 단순히 "앱이 제대로 작동한다"는 것을 의미하지 않기 때문입니다. 여기에는 애플리케이션 서비스 형태로 구현하고 배포해야 하는 일련의 요구사항이 포함됩니다. 규모, 보안, 성능, 모니터링이 모두 갖춰져야 애플리케이션이 "소비에 적합하다"고 간주될 수 있습니다. 이것이 오늘날의 "배포 파이프라인"을 구성하는 것입니다.

자동화 및 오케스트레이션의 약속을 실현하려면 배포에 DEVOPS가 필요합니다. 

안타깝게도 납품 및 배포 분야의 자동화 현황을 너무나 정확하게 묘사한 것은 조지 제트슨과 프레드 플린트스톤과 함께 하는 스키 여행입니다. 전자는 미래에서 왔기 때문에 제트 추진 스키를 타고, 후자는 여전히 과거에 살고 있기 때문에 수동 추진 스키를 탄다. 로켓 추진 스키를 탄 조지 제트슨이 지속적인 배포를 수행하는 DevOps라고 추측했다면 정답입니다. NetOps가 대부분 수동 방법으로 지속적인 배포를 시도하고 있다고 추측했다면 정답입니다. 

NetOps는 오늘날 기업에서 사용하는 평균 14개의 애플리케이션 서비스를 프로비저닝, 배포 및 운영하는 업무를 담당하는 사람들입니다. 여기에는 확장성(로드 밸런싱 및 유입 제어)부터 보안(웹 애플리케이션 방화벽 및 봇 방어)은 물론, 애플리케이션을 지원하는 전체 스택의 성능을 개선하는 덜 알려진 서비스까지 모든 것이 포함됩니다.

이제 그들은 더 빠르게 움직일 수 있는 스키를 가지고 있지만 DevOps 대응자가 사용하는 로켓 지원 스키는 여전히 부족합니다.

파이프라인 자동화의 불일치로 인해 좌절스러운 지연이 발생할 수 있습니다. 

"지속적인 배포"를 달성하는 데 필요한 다양한 애플리케이션 서비스 구성 요소의 자동화 속도 간의 차이는 대다수의 조직에서 여전히 수동 방식을 사용하게 하는 "불균형한 힘"을 제거해야 할 필요성을 나타냅니다. 이는 자동화된 배포 구성 요소가 전혀 없는 조직에 특히 해당됩니다. 이것이 로켓 보조 스키와 기존 스키의 차이입니다. 파이프라인의 일부를 자동화하는 데 성공한 기업조차도 일관성 있게 자동화를 달성하지는 못했습니다. 4가지 핵심 구성 요소를 모두 자동화한 기업은 단 21%에 불과했습니다. 11%는 단 하나의 영역만 자동화하는 데 성공했고, 25%는 두 영역을 자동화하는 데 성공했습니다.

비행 중인데 갑자기 스키에 장착된 로켓이 사라진다고 상상해보세요.

우리는 더 이상 배포 속도를 높이기 위한 전통적인 "더 많은 인력을 문제에 투입"하는 것에 의존할 수 없습니다. 이는 생산 단계에서 소비자에게 전달되는 과정 사이에 더 많은 커뮤니케이션 계층과 프로세스의 함정을 추가하여 지연을 더욱 심화시킬 뿐입니다. 

이러한 지연으로 인해 기업은 기다려야 하기 때문에 불만을 품게 되고, 더 나쁜 경우 시간을 벌기 위해 보안 검사 등의 단계를 건너뛰는 경우가 많습니다. 이를 해결하려면 지속적인 배포를 늦추는 "불균형한 힘"을 찾아 해결해야 합니다.

이러한 "불균형한 힘"은 무엇이고 DEVOPS는 이를 재균형화하기 위해 무엇을 할 수 있습니까?

배포 과정에서 불균형을 이루는 힘은 NetOps가 언급한 과제에서 찾을 수 있습니다. 기술, 정책, 예산 및 통합은 지속적인 배포를 실현하는 데 있어 큰 걸림돌이 됩니다. 오해하지 마세요, NetOps는 스크립팅을 할 수 있고, 항상 그렇게 합니다. 하지만 스크립팅은 자동화가 아니며 잠재적으로 14가지의 서로 다른 장치, 시스템 및 서비스를 통합해야 할 필요성을 해결하지 못합니다. NetOps는 이러한 분산된 시스템 간의 통합을 가능하게 할 뿐만 아니라 일관되고 예측 가능하며 반복 가능한 방식으로 배포 프로세스를 추진하는 도구와 방법론을 식별하고 실행하는 데 도움이 필요합니다. 

바로 이 부분에서 DevOps는 NetOps가 성공적인 지속적 배포 관행을 구축하는 데 도움을 줄 수 있습니다.

협업은 IT와 DEV 간의 경계를 넘어야 합니다.

문화는 선택 사항이 아닙니다. 그것은 행동과 관행에 매우 실제적인 영향을 미칩니다. 팀 구조만으로도 파이프라인 자동화가 극적으로 변하며, 기존의 단일 기능 팀은 현대적이고 DevOps 중심의 팀보다 뒤처지게 됩니다. 더욱 협력적인 팀 구조를 추진하세요. 같은 맥락에서, 협력적인 팀은 주요 지표에 대해 일치된 의견을 가져야 합니다. 공유된 메트릭을 통해 NetOps와 보안 팀은 페널티 없이 지속적인 배포를 추진할 수 있습니다. 현재 NetOps의 약 4분의 3이 네트워크 가동 시간을 기준으로 측정됩니다. 배치 빈도는 그들에게 거의 영향을 미치지 않습니다. 그들은 네트워크 유지에 집중할 것입니다. 왜냐하면 그것이 그들이 집중해야 할 일이기 때문입니다. 공유된 메트릭을 통해 NetOps는 비즈니스에 필요한 것, 즉 더 빠르고 더 빈번한 배포에 집중할 수 있습니다. 

마지막으로 공감이 필요합니다. 여러분은 모두 같은 팀이고, 놀라실지도 모르지만, 같은 것을 소중히 여깁니다. NetOps는 DevOps만큼 파이프라인 자동화에 높은 중요성을 둘 가능성이 높습니다. DevOps는 통합, 도구, 기술 세트와 관련된 장애물을 탐색하고 극복하는 측면에서 NetOps보다 10년 앞서 있다는 점을 기억하세요. 협업 팀은 배포부터 배포에 이르는 모든 도구(예: Jenkins 및 GitHub/GitLab)에 대한 표준화를 촉진함으로써 도움을 줄 수 있습니다.

점심 식사를 하며 배움을 얻으세요. NetOps 담당자에게 멘토링을 제공하고 NetOps 담당자가 업계의 요령을 배울 수 있는 기회를 제공하는 튜토리얼과 커뮤니티에 대한 통찰력과 링크를 공유합니다. "자동화 우수 센터" 또는 커뮤니티를 시작하여 모범 사례를 확립하고, 솔루션을 공유하고, "불균형한 힘"을 해결하는 지식 공유를 장려합니다.

DevOps는 배포로 끝나서는 안 되며, 끝날 수도 없습니다. 어떤 애플리케이션이 의도한 소비자의 손에 전달되기 전까지는 실제로 "완성"된 것이 아닙니다. 즉, 배포와 이를 위해 필요한 복잡한 장치 및 애플리케이션 서비스 파이프라인을 자동화하여 배포에 걸리는 시간을 줄여야 합니다. DevOps는 NetOps 스키를 로켓에 장착하는 데 필요한 기술, 도구 및 경험을 보유하고 있어 기업에서 필요로 하는 만큼 빠르게 움직일 수 있습니다.