기업용 애플리케이션을 개발, 테스트, 배포, 운영 및 유지 관리하는 것과 관련된 결정이 개별적으로 이루어지지 않습니다. 과거에는 네트워크 운영 인력이 상황을 통제하고, 중요한 일이 일어나기 전에 마지막으로 조치를 취하는 사람들이었을 수 있습니다. 솔직히 말해서, 그들 대부분은 아마 그런 방식을 좋아했을 겁니다.
하지만 상황이 바뀌었습니다. 이제 NetOps는 엄격한 통제를 행사하기보다는 스스로 일을 처리하는 것을 선호하는 사람들(솔직히 말해서 DevOps 사람들)에게 폭격을 당하고 있습니다. NetOps에서 하지 않았으면 하는 일(예: 새 앱의 보안 프로토콜을 우회하거나 해당 앱 업데이트를 위해 부하 분산 설정을 변경하는 것)
이제 DevOps를 하는 사람들은 단지 상황을 개선하려고 노력하고 있다고 주장할 수도 있습니다. 더욱 적응력이 뛰어납니다. 자기 관리가 더 철저하고 세부 관리가 덜 철저합니다. 더욱 민첩하게(대문자 A로 시작).
문제는 오늘날의 기업 환경에서 DevOps가 Agile 작업 스타일을 유지하려면 NetOps가 필요하다는 것입니다. DevOps만으로는 이를 실현할 수 없습니다. 결국 모든 애플리케이션은 기반 인프라에서 실행됩니다. 그리고 그들은 NetOps가 뒤로 물러나서 전통적인 책임을 모두 포기할 것이라고 기대할 수 없습니다. 당신도 그들이 그러기를 바라지 않을 것이다. NetOps는 DevOps가 생성하는 모든 앱의 보안과 성능을 유지하는 데 중요한 역할을 하며, CI/CD 워크플로에 중요한 기술과 역량을 제공합니다.
DevOps에 종사하고 있고 NetOps 동료를 CI/CD 워크플로에 더 깊이 참여시키려는 경우 먼저 그들이 참여하고 싶어하고 현상 유지를 바꾸는 것의 가치를 알아차리도록 해야 합니다. 사실, 자동화를 통해 쉽게 해결할 수 있는 쉬운 문제는 반복적으로 수행해야 하는 지루하고 시간이 많이 걸리는 일상적인 작업뿐이므로, 이 작업을 수행하는 것은 매우 쉽습니다. 제정신인 사람이라면 누구나 봇에게 기꺼이 맡길 만한 작업입니다.
변경 주문이 좋은 예입니다. 쌓인 주문을 하나하나 살펴보고, 모든 변경 사항을 수동으로 입력한 다음, 모든 작업이 올바르게 수행되었는지 다시 한 번 확인합니다. 결국 오늘 아침에야 9번째 주문을 받았고, 모두 함께 실행되기 시작했는데, 처음에 이 분야에 뛰어든 이유가 무엇이었습니까? 하루 종일, 매일 변경 주문을 처리하시나요? 나는 그렇게 생각하지 않는다.
더 나은 방법이 있습니다. 즉, 그렇지 않으면 흥미롭고 생산적인 하루를 망치는 모든 중복적이고 자주 반복되는 작업을 완전히 자동화하는 것입니다.
기업에서 일하는 사람들은 우리가 이걸 먼저 이야기하길 원했어요. 왜냐하면 이건 전부 제품에 관한 거잖아요, 맞죠? 그 일을 하는 남자나 여자들이 자기 직업을 사랑하는지 누가 신경 쓰겠는가? (잘못된!)
그럼에도 불구하고 앱의 강력한 성능과 보안은 실제로 작업이 지루할 정도로 덜 중복적이 되어 매우 기분 좋은 부수 효과입니다.
애플리케이션을 안정적이고 안전하게 만드는 서비스를 자동화하면 보다 흥미롭고 반복적이지 않은 프로젝트에 시간을 투자할 수 있을 뿐만 아니라 해당 서비스의 품질도 향상됩니다. 그 이유는 잘 만들어진 자동화된 워크플로가 저절로 생겨나는 것이 아니기 때문입니다. NetOps 엔지니어의 역할은 각 자동화된 워크플로가 작동하는 최적의 모델을 만들고 이를 통해 반복적으로 최적의 결과를 생성하는 것입니다.
자동화의 장점은 처음에 제대로 하면 그 이후에도 계속해서 제대로 수행된다는 것입니다.
자동화된 워크플로우에서 NetOps는 전문 분야에 대한 제어권을 유지할 수 있을 뿐만 아니라(이를 통해 앱이 더 빠르고, 더 안정적이며, 더 안전해짐) 사용하기 매우 간단한 자동화된 프로세스를 생성할 수 있으므로 DevOps는 다시는 잘못된 방향으로 나아가는 것을 고려하지 않을 것입니다(이를 통해 앱이 더 빠르고, 더 안정적이며, 더 안전해짐).
DevOps 팀이나 NetOps 팀 모두 조직의 중요한 앱과 데이터를 유지 관리하는 데 필요한 모든 솔루션을 스스로 파악할 수 없는 경우가 거의 대부분입니다. 두 팀이 협력하는 것이 필요하다는 것은 항상 있어 왔습니다. 그리고 오늘날의 자동화 기능은 이런 상호작용에서 발생하는 마찰을 줄이는 데 큰 역할을 하고 있습니다.
DevOps, NetOps, SecOps… Ops는 고립된 섬이 아닙니다. 최신 CI/CD 워크플로에서 성공은 복잡한 시스템 전체에 빠르고 쉽게(즉, 자동으로) 복제할 수 있는 명확하게 정의되고 검증된 방법론을 개발함으로써 실현됩니다. 이러한 자동화된 워크플로를 위한 견고한 기반을 구축하려면 DevOps, NetOps, SecOps 간의 견고한 파트너십이 필요하며, 각 부서는 서로를 지원하기 위해 자신의 전문 지식을 제공해야 합니다.
어떤 환경(클라우드, 컨테이너 등)이든 앱은 기본 애플리케이션 서비스, 네트워크 서비스, 보안 서비스에 의존합니다. NetOps는 네트워크를 통해 데이터 흐름을 유지하고, 앱의 확장성과 반응성을 보장하며, 필요할 때 데이터를 사용하고 항상 안전하게 보호하는 역할을 합니다. 그리고 모든 운영팀은 위험을 줄이기 위해 각자의 역할을 해야 합니다. 앱이 의도한 대로 작동하지 않을 위험, 네트워크가 과부하될 위험, 외부 위협이 자산을 공격할 위험 등이 있습니다. 그리고 소프트웨어 개발에서 좋은 성과를 이끌어내는 DevOps 원칙(문화, 자동화, 측정 및 공유) 이 Puppet의 2019년 DevOps 현황 보고서 에 따르면, 좋은 보안 성과를 이끌어내는 원칙과 동일하다는 점이 흥미롭습니다.
다양한 운영팀 간의 상호작용은 끊임없이 이루어집니다. 이는 인터넷 시대 전반에 걸쳐 IT가 운영되는 방식입니다. 하지만 Agile 소프트웨어 개발 프로세스가 등장하면서 앱을 개발하고 배포하는 속도의 경계가 넓어지는 등 항상 개선의 여지가 있었습니다. 그 당시 DevOps는 개발에 대한 보다 Agile한 접근 방식으로 큰 변화를 가져오기 시작했으며, "코드에서 고객까지" 더 빠르게 도달하는 방법을 채택했습니다.
이러한 속도의 증가는 현재 DevOps가 목격하고 있는 엄청난 변화를 주도하고 있습니다. DevOps는 더 빠르게 움직이고 보다 사전 예방적일 수 있다는 점에서 장점이 있지만, 다른 부서의 프로세스가 동일한 방식으로 작동하도록 설정되지 않은 경우 마찰을 일으킬 수 있다는 점에서 단점이 있습니다.
다른 부서나 새로운 업무 방식을 아직 따라잡지 못한 동료를 무시하는 것은 나쁜 생각입니다. DevOps가 모든 것을 스스로 하려고 하면 비효율적이고 부적절합니다. 그렇게 해서 프로세스가 중단되는 겁니다(실수로든 아니든). 그리고 중단된 프로세스는 온갖 일이 잘못되는 결과를 초래할 수 있습니다. DevOps에만 국한되는 것이 아니라 고객을 포함한 모든 사람을 위해서도 필요합니다. 고객은 가장 부정적인 영향을 받아서는 안 될 사람들입니다.
DevOps가 제대로 된 역할을 하려면 NetOps를 적이 아닌 파트너로 삼아야 합니다. 그리고 견고한 파트너십의 핵심은 의사소통입니다. DevOps는 앱을 지원하는 데 필요한 서비스를 얻는 방법에 대해 네트워크 팀과 소통해야 합니다.
종종 DevOps 팀은 자동화, 전반적인 프레임워크 및 코드로서의 인프라와 같은 분야의 전문가가 됩니다. 하지만 네트워크 팀은 프로비저닝이 필요한 실제 아키텍처 리소스와 해당 프로비저닝에 사용할 수 있는 도구를 이해하는 전문가입니다. DevOps와 NetOps는 대화와 상호 존중을 통해 자동화가 필요한 부분을 파악하고 이를 가장 잘 구현하는 방법을 파악할 수 있습니다.
DevOps는 잃을 것이 없고 CI/CD 워크플로 전체에서 자동화의 역할을 확장하도록 NetOps 담당자를 돕는 데서 많은 것을 얻을 수 있습니다. 핵심은 여러분이 코드 개발의 전문가인 것처럼, 여러분의 동료 중 한 명 이상이 해당 코드를 지원하기 위한 네트워크 및 보안 서비스 프로비저닝의 전문가라는 점을 인식하는 것입니다. 그들이 최고의 전문가가 될 수 있도록 돕는 기회를 놓치지 마세요.