F5 DevOps 및 NetOps 설문 조사 보고서: 자동화는 디지털 격차를 해소하는 데 핵심입니다.
DevOps와 NetOps 간의 전형적인 관계에 대해 많은 이야기가 나옵니다. 우리는 서로를 대립시키는 "우리 대 그들"이라는 수사적 표현에 끊임없이 폭격을 당하고 있으며, 그들을 나누는 벽 너머로 신청과 비난이 앞뒤로 오갑니다. 앱을 더 빠르고 더 자주 제공해야 한다는 압력이 커지면서, 이러한 벽은 앱 경제의 승자와 그렇지 않은 사람을 구분하는 디지털 격차로 작용할 수 있습니다.
다행히도 IT 자동화 및 오케스트레이션 덕분에 이런 디지털 격차가 줄어들고 있습니다. 각 그룹을 별도로 조사하여 기술 사용, 서로에 대한 인식 및 제공하는 애플리케이션을 심층적으로 조사한 결과, NetOps와 DevOps 모두가 이러한 디지털 격차를 메우기 위해 협업하고 싶다는 욕구를 발견했습니다. 이는 자동화와 오케스트레이션만이 효과적으로 달성할 수 있는 규모와 속도가 필요한 디지털 혁신 노력에 착수하는 기업들에게 점점 더 좋은 소식이 되고 있습니다. 이는 이미 과부하 상태인 직원으로부터 더 많은 관심이 필요한 멀티 클라우드 환경으로 어려움을 겪고 있는 조직에게도 좋은 소식입니다. 자동화를 통해 온프레미스의 부담을 덜어내면 클라우드 관련 프로젝트에 리소스를 투자할 수 있습니다.
884명의 NetOps 및 DevOps 전문가가 2017년 여름에 실시한 온라인 설문조사에 응답했습니다. 우리는 일반적인 애플리케이션과 NetOps 또는 DevOps의 대응 애플리케이션에 대한 인식 관련 질문을 몇 가지 물었고, 배포 빈도와 성공률에 대한 인식에 초점을 맞춘 질문도 했습니다.
결과에 따르면, 그들 사이의 벽은 여전히 존재하지만, 그 벽은 지역 사회 내의 대화나 다른 업계 보고서에서 말하는 것만큼 높거나 불투명하지는 않습니다. 우리는 규모와 업종에 관계없이 모든 조직에서 생산 파이프라인 자동화의 중요성과 열망에 대해 많은 공통점을 발견했으며, 두 그룹이 개발하고 구축하려는 애플리케이션의 보안, 성능, 안정성에 대한 공동의 확신을 발견했습니다.
자동화는 NetOps와 DevOps를 통합하는 힘으로 보입니다. 원칙적으로는 그렇지 않더라도 구체적인 구현 세부 사항은 그렇습니다.
DevOps와 NetOps는 셀프 서비스 및 자동화를 통해 얼마나 많은 파이프라인에 접근할 수 있어야 하는지에 대해 여전히 의견이 일치하지 않지만, 대부분 그룹은 상대방이 올바른 길을 가고 있다고 보고 있습니다. DevOps의 82%와 NetOps의 76%는 서로가 "올바른 것"을 우선시한다는 데 동의합니다. 분명히 디지털 격차에도 불구하고 조직도에는 항상 그런 것은 아니지만 적어도 목표와 초점에 있어서는 공통점이 있습니다.
NetOps 측의 반대 의견 중 DevOps가 우선시하지 않는 부분에 대한 가장 일반적인 응답에는 보안이 포함되었습니다. DevOps를 사용하는 NetOps 담당자가 겪는 좌절의 원인으로 신뢰성이 자주 거론되었습니다.
신뢰성과 보안은 배송 속도만큼 중요합니다. 보안은 여전히 사후 고려 사항입니다. 성능, 보안, 안정성.
놀랍지 않게도 NetOps의 우선 순위와 관련하여 DevOps에서 가장 흔히 반복되는 말 중 하나는 자동화를 중심으로 합니다. 아니, 오히려 그런 것이 부족하다는 뜻이다.
자동화 자동화 자동화. 저는 그들이 클라우드 공간에서 자동화되고 클라우드에 독립적인 리소스 생성을 우선시하는 것을 보고 싶습니다. 자동화, DevOps, 클라우드, 보안.
이러한 의견 차이는 자동화 및 셀프 서비스를 통한 개발자와 DevOps의 프로덕션 파이프라인 액세스 부족이 IT 외부의 클라우드 및 솔루션 도입에 미치는 영향을 폭로한 다음 주요 발견의 근원일 가능성이 높습니다.
자동화는 클라우드 도입에 영향을 미칩니다
이제 그들은 당신의 말을 들을 수 있습니다. 오랫동안 기업 및 DevOps 이해 관계자 모두 클라우드 도입을 촉진하는 요인 중 하나는 프로덕션 배포 파이프라인에 대한 셀프 서비스 액세스가 부족하여 배포 주기가 길어지는 것이라고 믿어 왔습니다. 그다지 좋지 않은 소식은 설문 조사에서 이러한 믿음이 확인되었다는 것입니다. DevOps의 27%가 클라우드 기반 솔루션을 선택하기로 결정하는 데 영향을 "많이" 미친다고 답했고 38%가 "어느 정도" 영향을 미쳤다고 답했습니다. 좋은 소식은 NetOps가 그 영향을 모르는 것은 아니라는 것입니다. NetOps의 65% 이상은 프로덕션 파이프라인에 대한 자동화 및 셀프 서비스 액세스를 제공하려는 욕구가 DevOps가 클라우드를 수용하기로 한 결정에 "어느 정도" 또는 "많이" 영향을 받았다고 말합니다.
주요 결과
- 자동화를 위한 견고한 지원. DevOps의 경우 5점 만점에 평균 4.0, NetOps의 경우 3.5의 중요도 평가를 받아, 전달 및 배포 파이프라인을 자동화하는 것의 중요성에 대해서는 확실한 의견 일치가 있습니다. 전반적으로 응답자들은 프로덕션 파이프라인이 50% 이상 자동화되면 애플리케이션의 안정성, 성능 및 보안에 대한 확신이 더 크다고 보고했습니다. 두 그룹은 또한 상대방이 "올바른 일을 우선시하고 있다"는 데 압도적으로 동의했습니다.
- 자동화는 클라우드 도입에 영향을 미치며 그 반대의 경우도 마찬가지입니다. 그러한 합의에도 불구하고 두 집단 간의 의견 차이는 현실적이며 그에 따른 결과가 따릅니다. 그 중 하나는 프로덕션 파이프라인 액세스에 대한 다양한 견해인데, 이것이 멀티 클라우드의 증가에 영향을 미치는 것으로 보입니다. DevOps 측면에서는 응답자의 65%가 프로덕션 파이프라인에 대한 접근성이 부족하여 클라우드 및 외부 솔루션을 모색하기로 결정하는 데 영향을 미쳤다고 답했습니다. 반대로, NetOps의 거의 대부분(44%)은 DevOps가 클라우드로 전환하기로 한 결정이 파이프라인 액세스를 제공하려는 욕구에 "어느 정도" 영향을 미쳤다고 말했고, 21%는 "많이" 영향을 미쳤다고 인정했습니다.
- 파이프라인 접근을 둘러싼 불협화음. 내부 효율성과 외부 참여를 개선하는 애플리케이션을 제공하는 데 중점을 둔 디지털 혁신 노력은 개발과 프로덕션 간의 경계를 넘어야 합니다. 개발자와 DevOps에 얼마나 많은 프로덕션 파이프라인에 대한 접근 권한을 제공해야 하는지에 대한 의견이 엇갈리면서 두 분야 간의 벽은 여전히 존재합니다. DevOps 응답자 중 가장 큰 비중을 차지하는 것은 프로덕션 파이프라인의 75% 이상이 셀프 서비스 및 자동화를 통해 제공되어야 한다고 믿는 것입니다. NetOps는 덜 관대한 편이지만 대중적인 인식이 우리를 믿게 하는 것만큼은 그렇지 않습니다.
- 현재 배포 빈도는 양호합니다. DevOps와 NetOps 모두 현재 배포 빈도가 "충분히 좋다"는 데 전적으로 동의했습니다. 두 그룹 간의 단절에 대한 현재의 인식을 유지하면서, NetOps는 DevOps 대응자보다 배포 빈도가 "너무 빈번하다"고 생각할 가능성이 두 배나 높습니다. DevOps 측에서는 소수(4%)만이 "너무 빈번한" 릴리스가 있다고 믿는다고 밝혔습니다.
자동화를 위한 견고한 지원
비난 게임은 끝났습니다. 사고가 발생한 후 NetOps와 DevOps가 끝없이 서로를 비난하는 인기 있는 스토리라인과는 달리, 우리는 각 그룹이 서로를 훨씬 더 긍정적인 시각으로 본다는 증거를 발견했습니다.
파이프라인 접근성 부족으로 인해 좌절한 사람들이 클라우드에 손을 뻗는 것은 멀티 클라우드의 증가와 보안 및 성능과 관련된 과제에 크게 기여합니다. 이는 종종 이로 인해 발생하는 "불량 IT"로 어려움을 겪는 사람들이 지적합니다. NetOps가 프라이빗 클라우드나 클라우드형 시스템을 사용하여 자동화/셀프 서비스를 통한 액세스를 제공하려는 노력을 계속하고 있지만, 무시할 수 없을 정도로 외부 클라우드 솔루션에 대한 상당한 기존 투자가 여전히 남아 있습니다. 이로 인해 조직은 관리, 모니터링 및 보안해야 할 여러 클라우드 솔루션과 환경을 갖게 되며, 이는 디지털 경제에서 운영의 복잡성을 증가시킵니다.
이제 질문은 "우리가 프로덕션 파이프라인에 셀프 서비스 액세스를 제공할까?"가 아니라 "얼마나 노출할까?"입니다.
파이프라인 접근 주변의 불협화음
얼마면 충분할까요? 자동화/셀프 서비스 기능을 통해 개발자와 DevOps에 적절한 양의 파이프라인에 접근할 수 있게 되자 의견 차이가 뚜렷하게 드러났습니다. DevOps는 NetOps가 제공하는 것보다 프로덕션 파이프라인에 대한 접근성을 더 원합니다.
NetOps가 DevOps에 더 많은 파이프라인 액세스를 제공하는 것을 꺼리는 이유에 대한 통찰력을 요청하지는 않았지만 그렇게 하는 데 사용할 수 있는 기술에서 답을 찾을 수 있을 것입니다. NetOps 응답자들은 일반적으로 업무를 수행하는 데 필요한 기술과 현재 보유하고 있는 교육/지식 사이에 격차가 있다고 생각합니다.
실제로 "개발자"라고 자기 자신을 규정하는 NetOps와 DevOps는 비슷한 책임과 기술 세트를 감안할 때 5년 후에도 자신의 직업이 관련성이 있을 것이라고 믿을 가능성이 더 높았습니다. 가장 자신감이 없는 사람은 벽 양쪽에 있는 네트워크 운영자로 확인된 사람들이었습니다.
NetOps 측의 현재 생산 파이프라인 자동화 상태는 그러한 기술 격차의 영향을 반영하는 것으로 보입니다. DevOps 제공 파이프라인보다 상당히 뒤처져 있다는 사실은 놀라운 일이 아니었습니다. NetOps의 11%는 프로덕션 파이프라인을 자동화하지 않는다고 인정한 반면, DevOps의 경우 애플리케이션 제공 파이프라인을 자동화하지 않는다고 답한 사람은 5%에 불과했습니다.
파이프라인 자동화와 성공적인 배포 빈도 사이에 긍정적인 상관관계가 있다는 사실을 감안할 때 파이프라인 자동화의 현황을 주목하는 것이 중요합니다. 86%의 NetOps는 파이프라인 자동화 비율이 더 높았고(75% 이상) 매우 성공적인 배포(90% 이상) 빈도도 더 높았습니다.
하지만 이것이 유일한 요소는 아니며, 애플리케이션 변경 빈도도 성공적인 배포 빈도에 영향을 미치는 것으로 나타났습니다.
현재 배포 빈도는 양호합니다.
괜찮습니다. 고맙습니다. 아마도 가장 큰 문화적 격차는 배치 빈도의 영역에서 존재할 것입니다. 일부 DevOps는 엄청난 속도로 앱을 프로덕션에 제공하는 반면(12%는 하루에 두 번 이상 프로덕션에 변경 사항을 제공함), NetOps는 더 느리지만 꾸준한 속도로 변경 사항을 배포하는 데 훨씬 더 편안함을 느끼는 것으로 보입니다.
전반적으로 다수의 응답자에게서 월별 및 주별 빈도에 대한 어느 정도의 의견 일치가 있는 것으로 보입니다. 놀랍지 않게도 DevOps는 NetOps보다 더 자주 제공하는 것을 선호합니다. 즉, 더 자주 제공하기를 원하는 DevOps 담당자 26% 중 28%는 일주일에 한 번 제공하고, 26%는 이미 하루에 두 번 이상 제공하고 있습니다.
변화가 전달되는 속도의 적절성에 대한 인식은 그룹마다 다릅니다. 그러나 두 분야 모두의 대부분(DevOps의 70%, NetOps의 74%)이 변경 빈도를 "우리에게 충분히 좋다"고 설명했다는 점이 주목할 만합니다.
공통점은 거기서 끝납니다. DevOps 측에서 현재 일정이 "너무 빈번하다"고 주장한 사람은 불과 4%에 불과한 반면, NetOps 측에서 제공 빈도가 "너무 빈번하다"고 설명한 사람의 수는 두 배로 늘었습니다. DevOps의 4명 중 1명 이상(26%)이 더 빠르게 진행하기를 원하는 반면, NetOps의 경우 속도를 높이고 싶어하는 사람은 5명 중 1명 미만(18%)입니다.
그러나 욕구를 무시하고 결과를 검토하면 속도 와 성공률의 균형을 맞추는 데 "이상적인" 배포 빈도가 무엇인지 알 수 있습니다. 성공적인 배포를 90% 이상의 시간 동안 경험한 65%의 NetOps와 57%의 DevOps 중 변경 사항은 "일주일에 한 번" 프로덕션에 푸시됩니다.
결론
디지털 격차는 애플리케이션이 전달에서 배포까지 이르는 데 여전히 존재합니다. 배포 파이프라인의 상당 부분은 여전히 수동으로 구동되고 있으며, 이를 통해 애플리케이션이 앞으로도 클라우드로 이동하게 될 것입니다. 그러면 DevOps가 클라우드로 전환하기로 결정하면 NetOps가 여정을 가속화하는 데 필요한 셀프 서비스 액세스를 더 많이 제공하게 됩니다.
자동화는 NetOps와 DevOps가 더 열심히가 아니라 더 스마트하게 일하고, 함께 비즈니스 요구 사항을 충족하도록 운영을 확장할 수 있게 해주므로 디지털 격차를 해소하는 데 중요한 열쇠입니다.
방법론
이 보고서의 데이터는 2017년 7월에 실시한 두 차례의 별도 온라인 설문 조사를 통해 수집되었습니다. 두 프로젝트 모두 개발에서 배포까지 애플리케이션 수명 주기에서 자동화 활용을 조사하고, 관련된 두 주요 그룹의 인식을 파악하기 위해 설계되었습니다. 두 그룹의 응답자 모두 참여에 대한 인센티브를 받았습니다.
부록: 설문조사 발췌문
아래에는 NetOps와 DevOps 응답자 모두로부터 수집한 설문조사 질문에 대한 추가 선택 응답이 포함되어 있습니다. 이는 포괄적인 목록은 아니지만, 여기에서는 받은 피드백 유형의 샘플로 제시합니다. 제품 이름은 정확성을 위해 편집되었습니다. 그 외에는 수신된 의견을 편집하지 않고 그대로 게시하는 것이 목적입니다.
넷옵스
"개발팀이 모든 것의 우선순위를 제대로 정하고 있나요?"라는 질문에 "아니요"라고 답했다면, 어떤 우선순위를 다르게 정하기를 원하시나요?
- 안정성, 품질, 비전. 사람들은 종종 데이트를 위해 서둘러 가는데, 이로 인해 가장 큰 손해를 보는 것은 품질입니다. 또한 현재 작업 너머를 보지 않으면 결국 엄청난 재작업과 최적이 아닌 솔루션이 나오게 됩니다(쓸모없는 것을 엉터리로 짜깁기해서 작동할 수는 있지만 어떤 면에서든 최적이거나 이상적이지는 않습니다).
- 개발팀과 시스템 관리팀 사이에 더 많은 협업이 필요합니다. 우리는 수동 관리에서 벗어나는 데 충분히 빠른 속도를 보이고 있지 않습니다.
- 개발팀이 운영 안정성, 아키텍처 일관성 및 다양한 개발팀 간의 협력에 대해 더 많은 관심을 갖는 모습을 보고 싶습니다.
- 앱 개발자들은 네트워크나 보안에 대해 생각하지 않습니다. 보안은 개발에 대해서만 간략하게 알고 있고, 네트워킹은 개발이 완료된 후에야 운영상의 변화를 알게 됩니다.
이상적인 상황이라면 개발팀과 운영팀 간의 상호작용, 의사소통, 협업 등을 어떻게 개선할 수 있을까요?
- 성과를 양측 모두가 알 수 있도록 지표, 모니터링 및 가시성을 개선합니다. 파이프라인을 자동화하여 서비스 제공 속도를 높입니다. 배송 시간이 길어지는 것을 방지하기 위해 적절한 용량을 확보하세요.
- 더 똑똑한 사람들로 교체하세요
- 서로를 장애물로 보는 것을 그만두고 모든 팀이 가장 가치를 더할 수 있는 부분에 기여하도록 하세요. 자동화는 훌륭하지만, 감독 없이는 효과가 있을 수 있는 솔루션이 구현될 수 있지만, 더 좋고 최적의 방법이 있을 수도 있는 경우가 많습니다.
- 개발팀과 운영팀 간의 경계가 더욱 모호해졌습니다. 최소한의 오버헤드로 사용 가능한 인프라에서 확장 가능하고 우수한 성능을 발휘하는 방식으로 애플리케이션을 제공한다는 공동의 목표를 가진 "하나의 팀"으로 간주되어야 합니다.
- 넥타이를 매고 있는 사람과 대화한다면 의사소통은 중요하지 않습니다.
- DEV 주기의 프로세스 초기에 F5 팀을 참여시킵니다.
- 개발 주기 초기에 Ops를 도입하세요
- 파이프라인의 공유 코드 및 가시성. 코드로 관리할 수 있는 도구가 많을수록 좋습니다(예: F5 BIG-IP를 코드로 관리하는 것은 쉽지 않은데, 이것이 우리 프로세스의 약점입니다).
데브옵스
"운영팀이 모든 것의 우선순위를 적절하게 정하고 있나요?"라는 질문에 "아니요"라고 답했다면, 어떤 우선순위를 다르게 정하기를 원하시나요?
- 클라우드 공간에서 자동화되고 클라우드에 독립적인 리소스 생성을 우선시하는 모습을 보고 싶습니다. 개발자, QA, 운영 측면에서 확실히 달성 가능하고 유용한 푸시 버튼 인프라입니다.
- 그들은 자신이 만지는 모든 것을 자동화하는 데 적응해야 하며 일자리 상실을 두려워하지 않아야 합니다.
- 수동 작업이 너무 많고, 자동화가 없으며, 핵심적인 기술적 문제에 대한 이해 부족. 개발자에게 권한을 부여합니다.
- 그들은 돈을 던져서 문제를 해결하려는 경향이 있습니다. 더 (비싼) 장비. 자동화보다는 더 많은 인력을 투입해 크랭크를 돌리는 게 낫다.
이상적인 상황이라면 개발팀과 운영팀 간의 상호작용, 의사소통, 협업 등을 어떻게 개선할 수 있을까요?
- 운영팀에서 운영 환경의 세부 정보를 추상화하기 위한 더 많은 도구를 제공하기를 바랍니다.
- 저는 개발자이고 인프라를 배포하고 자동화해야 합니다. 운영진은 자동화와 몇 가지 도구 사용법을 배워야 합니다.
- 운영 팀을 인프라 관리를 자동화하는 인프라 지원 부서로 변경합니다. 이를 통해 개발자는 업그레이드, 서버 관리 등을 수행하기 위해 운영에 의존하는 대신, 인프라를 일종의 서비스로 활용할 수 있습니다. 또한 애플리케이션을 보다 쉽게 관리할 수 있도록 돕기 위해 운영팀 구성원을 다른 그룹에 연락 담당자로 파견할 것입니다.
- 운영팀을 확대하고 개발 및 테스트에 직접 참여해야 합니다. 요청을 접수할 곳이라기보다는 최전선에서 통합된 파트너 역할을 더 강화해야 합니다.