자동화의 도입으로 NetOps Ops가 필요하게 됨

자동화는 미래입니다. DevOps는 오랫동안 모든 것을 자동화한다는 아이디어를 받아들였지만, NetOps는 프로덕션 프로세스에서 자동화와 오케스트레이션을 광범위하게 사용하여 두 가지 간의 격차를 빠르게 줄이고 있습니다.

2018년 애플리케이션 제공 상태 설문 조사에 참여한 응답자의 거의 절반(46%)이 프로덕션에서 자동화를 '부분적으로' 사용하고 있다고 밝혔습니다. 여기에는 주요 생산 변경(25%), 사소한 생산 변경(26%), 심지어 사고 대응(22%)에도 항상 자동화를 사용하는 것이 포함됩니다. 세 가지 경우 모두 절반 이상이 '때때로' 자동화를 사용합니다.

자동화는 다양한 방법으로 구현됩니다. Cisco, VMware, OpenStack 등의 네트워크 자동화가 인기를 끌고 있으며, Puppet, Chef 등의 프레임워크와 도구, 그리고 오래된 Python 스크립트도 인기가 많습니다.

자동화가 실제로 일어나고 있다고 말하는 것은 과소평가가 아닙니다. NetOps가 도래했습니다. 이것은 훈련이 아닙니다.

표면적으로는 흥미로운 일이지만, 그것이 무슨 뜻인지 깊이 파고들면 아직 표면에 드러나지 않은 과제들이 있다는 것을 알게 됩니다.

예를 들어 방화벽이나 라우터의 변경을 자동화하는 것이 한 가지 방법입니다. 이를 포괄적인 배포 프로세스에 포함시키는 것은 또 다른 문제입니다(궁금하시다면 이에 대한 적절한 용어는 오케스트레이션입니다).

시스템과 스크립트를 체이닝(통합)하기 시작하면 '애플리케이션'과 동등한 것을 구축한 것입니다. 배포, 관리, 유지 관리, 업그레이드, 패치 및 라이선스가 필요한 움직이는 부분이 많습니다.

이는 시시포스의 작업은 아니지만 NetOps가 고려하지 않은 작업 중 하나일 가능성이 있습니다.

개발자가 ServiceNow에 티켓을 입력하면 원하는 리소스를 자동으로 프로비저닝하고 구성하고 청구하는 IT 워크플로가 시작되는 것은 정말 좋습니다. 하지만 ServiceNow가 작동을 멈추면 어떻게 될까요? 아니면 그 연약한 사슬의 구성 요소 중 하나가 갑자기 무너지는 경우. 아니면 구성 요소 중 하나를 업그레이드하면 통합이 끊어지는 경우는 어떨까요?

눈을 감으면 개발자들이 그 생각에 샤덴프로이데에 휩싸여 깔깔대며 웃는 소리가 들릴 겁니다.

IT 자동화의 예상치 못한 결과 중 하나는 IT 부서가 유지 관리해야 할 소프트웨어와 시스템이 더 많아진다는 것입니다. 일부 증상은 심각할 수 있으며, 다른 증상에 비해 더 많은 관리와 영양 공급이 필요합니다.

기업 조직 내에 단순히 소프트웨어 시스템을 실행하는 것만을 담당하는 수많은 '유지관리' 또는 '지원' 개발자가 있는 것처럼, IT 내에서도 NetOps 운영의 일상 업무를 처리하는 유사한 역할이 필요할 것입니다.

넷옵스옵스. 네, 끔찍한 합성어지만 자동화가 점점 더 많은 NetOps 배포 작업을 소모함에 따라 무엇이 필요한지 설명하는 정확한 방법입니다.

해당 업무 중 일부는 기존 운영 직원이 처리할 수 있는 성격(통합, 소프트웨어 시스템 등)의 업무입니다. 하지만 일부는 네트워크에만 국한되며, 이는 스크립트와 시스템 , 관련 네트워킹 구성 요소를 모두 이해하는 사람이 필요하다는 것을 의미합니다.

코드/스크립트/템플릿이 무엇을 하는지 모르면 문제를 해결하거나 업데이트하거나 수정할 수 없습니다.

내 스노모빌에 무슨 문제가 있냐고 묻는다면, 나는 전혀 모른다고 말할 것입니다. 나는 보닛을 여는 방법과 배터리를 충전하는 방법을 알고 있지만, 자동차를 움직이는 부품을 직접 만지작거리라고는 하지 마세요. 이는 JavaScript에 능숙한 개발 인턴에게 COBOL 사본을 업데이트하라고 요청하는 것과 같습니다. 그건 바로 재앙을 불러올 요인이에요.

궁극적으로 NetOps에는 네트워크와 이를 자동화하는 데 사용되는 시스템에 대한 지식이 있는 사람들(NetOps Ops)이 필요할 것입니다. 자동화가 많이 사용될수록 엔지니어가 차세대 혁신 기술을 개발하는 동안 자동화를 유지할 담당자를 배치하는 것이 더욱 중요해질 것입니다.