Github를 수용하는 NetOps, vimdiff에 매달린 한 사람 제외

NetworkToCode 커뮤니티가 실시한 NetDevOps 2016년 가을 설문 조사 의 기타 통찰력

NetworkToCode 커뮤니티는 네트워킹과 코딩에 대한 열정이 넘치는 사람들로 가득합니다. 진부하게 들릴지 모르지만, 이들은 네트워킹을 자동화하는 것이 멋진 일(그리고 임원의 필수 사항)이 되기 전부터 이미 이를 해왔습니다.

2016년 가을, 커뮤니티에서는 네트워킹과 코드에 초점을 맞춰 다양한 질문에 대한 설문 조사를 실시했습니다. 원시 결과(위 링크)는 공개적으로 제공됩니다. 온라인 설문 조사 도구의 특성상, 데이터를 정규화하지 않는 한(정규화에는 노력이 필요함) 생성된 데이터 세트를 분석하기 어려울 수 있습니다. 다행히도 친애하는 독자 여러분, 저는 여러분을 위해 그 작업을 했고 더욱 그래픽하고 다채로운 방식으로 통찰력을 제공할 수 있습니다.

눈치 빠른 독자라면 제가 오랫동안 네트워크에 "DevOps" 원칙 이라고 하는 것을 적용하는 것을 옹호해 왔고, 놀랍지 않게도 이 데이터를 파헤치면서 제가 많은 노력을 기울인 부분이 바로 거기에 있다는 것을 알아차릴 것입니다.

코드와 네트워킹에 중점을 둔 그룹에서 DevOps에 대한 견해가 적어도 대체로 긍정적인 면에 치우쳐 있다는 것은 놀라운 일이 아닙니다. DevOps에 "관심 없음"이라고 답한 사람은 6.75%에 불과했고, 25.74%는 이미 생산 중이라고 답했습니다. 나머지 대부분은 평가하지는 않았더라도(28.27%) 적어도 생각(39.24%)하고 있었습니다.

이 설문조사를 실시한 훌륭한 조사원들은 Infrastructure as Code에 대한 NetOps 관점을 포함하여 이 주제에 대해 꽤 세부적인 질문을 했습니다. 이에 대해 관심이 약간 더 줄어들었고, 거의 10%가 "관심 없음"이라고 답했습니다. 흥미로운 점은 인프라를 코드로 사용하는 것이 "이미 프로덕션에 있다"고 응답한 사람이 19.35%에 불과했지만, 응답자의 무려 54%가 구성 배포에 자동화를 사용했으며, 66%가 구성 보관을 자동화한다고 답했다는 점입니다. 정확히 하나의 NetOps가 구성 관리를 자동화하고 있습니다(그리고 구성 변경을 관리하기 위해 vimdiff를 자랑스럽게 사용하는 NetOps가 그 중 하나가 아닐 것이라고 확신합니다).

일반적으로 가장 먼저 떠오르는 질문은 "코드로서의 인프라란 무엇인가?"입니다. 이것이 아마도 훨씬 더 많은 사람들이 그것에 대해 대부분 "평가"하거나 "생각"한다고 밝히면서도 실제로 "실천"하는 이유일 것입니다. 피로의 정의는 사실입니다. 요즘은 명확한 정의가 제공되지 않기 때문에 일시적인 용어에 대한 결론을 내리기 어렵습니다(그래도 우리는 그렇게 하겠죠. 그게 우리가 하는 일이니까요, 맞죠?).

그렇다면 NetOps는 무엇을 자동화하는 것일까 요? 우리는 디지털 혁신을 지연 없이 계속 진행하려면 그렇게 해야 한다고 계속 말합니다. 하지만 특히 기업 네트워크는 자동화를 실험하기에 적합한 환경이 아니라는 것도 알고 있습니다. 이는 오늘날 전체 기업이 의존하고 있는 심각한 네트워크입니다. NetOps는 상당히 많은 부분을 자동화하고 있는 것으로 나타났습니다.

구성 생성, 보관, 배포는 오늘날 자동화되고 있는 상위 3가지 작업입니다. 데이터 수집 및 보고 역시 점차 활성화되고 있는 것으로 보입니다.

실제로 구성 관리(그리고 모험적인 NetOps)를 제외한 모든 운영은 상당수의 응답자 조직에서 자동화된 것으로 나타났습니다.

물론 구성 관련 작업을 자동화하려면 얼마나 자주 자동화가 수행되는지, 그리고 자동화가 필요한지라는 의문이 제기됩니다. 저는 (이 주제에 대한 현재 생각에 반대할 가능성이 높지만) 프로덕션에 변경 사항을 덜 자주 배포할수록 자동화의 실제 가치가 더 높다고 주장하고 싶습니다. 물론, 자전거 타는 법을 "잊는" 일은 없습니다. 하지만 몇 달 또는 몇 년이 지난 뒤 처음으로 안장에 다시 앉는 것은 고통스러운(실수로 가득한) 경험이 될 수 있습니다. 배포도 마찬가지입니다. 하지만 그건 다음에 이야기하자.

NetOps는 꽤 정기적으로 배포하고 있는 것으로 나타났으며, 약 절반(50.92%)만이 하루에 두 번 이상 프로덕션 환경에 사소한 변경 사항을 배포하고, 37.59%는 한 달에 1~5회 주요 변경 사항을 배포합니다. 이는 웹 네이티브, 주로 단일 앱을 지원하는 기술 공급업체(Netflix, PayPal 또는 Facebook 생각해보세요)가 선전하는 "하루 200회"라는 엄청난 수준에는 미치지 못하지만 평균적으로 200개가 넘는 애플리케이션을 지원하는 기업에 있어서는 여전히 꽤 좋은 속도로 앱을 옮기고 있습니다(당사의 애플리케이션 제공 상태 설문 조사에 따름).

마지막으로, 그들이 이 모든 변화를 어떻게 관리하는지 궁금해집니다. 제목에서 언급했듯이, 실제로 변경 사항을 관리하는 데 vimdiff만을 사용한다고 주장하는 자랑스러운 NetOps가 단 한 명 있었습니다. 데이터 구조를 고려하면 이를 프로덕션의 변경 빈도와 연관시키기 어렵지만, 외부 압력에 관계 없이 자신들에게 맞는 것을 자랑스럽게 고수하는 이 NetOps와 정말 이야기를 나누고 싶습니다.

나머지 NetOps는 무엇에 의존하나요? 그중 상당수가 Github을 사용하는 것으로 나타났습니다. 정확하게는 47%예요. 그리고 또 다른 대규모 그룹(39%)은 산패/산화를 사용하고 있습니다. 랜시드(1991년 캘리포니아주 버클리에서 결성된 미국의 펑크 록 밴드와 혼동하지 마세요)는 구성 백업을 관리하는 네트워크 도구입니다. Oxidized는 또한 구성 백업을 관리하기 위한 네트워크 도구로, 종종 RANCID를 대체하는 것으로 알려져 있습니다. 이에 대한 전담 서브레딧이 있으니, 이에 대해 더 알고 싶은 충동이 들면 찾아보세요.

무려 8%는 구성 변경 사항을 전혀 추적하지 않습니다. 저는 연구실에서 한 번 그렇게 해봤는데, 단방향으로는 100Mbps, 반대방향으로는 1.5Mbps인 끔찍하게 비대칭적인 네트워크 간 링크가 생겼습니다. 네, 저는 약 11년 전에 그린베이의 연구실에서 우연히 현대 광대역 케이블 모델을 재현했습니다. 아니요, 불행히도 저는 로열티를 받지 못합니다. 하지만 좋은 소식은 제가 증오 편지를 받지 않는다는 것입니다. 다시 말해, 조직의 규모에 따른 교차분석 능력 없이는 그 논리를 이해하기 어렵습니다. 흥미로운 점은 11.91%가 0~50개의 네트워크 장치를 관리한다는 것입니다. 따라서 이 8%는 관리할 수 있는 장치 수가 충분하고 문제없이 잘 수행하고 있다고 추측할 수 있습니다. 가장 큰 NetOps 그룹(38.63%)은 1,000개 이상의 장치를 관리하고, 다른 28.23%는 251~1,000개 사이를 관리하고 있습니다. 따라서 대부분의 NetOps가 많은 장치(거의 확실히 이기종)를 담당하고 있다고 말할 수 있으며, 따라서 구성 변경 사항을 추적하는 것은 네트워크의 지속적인 건강뿐만 아니라 운영자의 정신 건강에도 필요하게 됩니다.

일반적으로 말해서, 저는 NetDevOps의 세계에 대한 이런 탐구를 정말 즐겼습니다. 그들이 스스로를 부르는 방식과 그들이 사용하는 것, 그들이 중요하다고 생각하는 것, 그리고 그들이 운영하는 환경이 어떤 모습인지에 대한 견해를 5만 피트 높이에서 뼈대만 보고 본 것이기는 하지만요.

NetOps는 IT 조직의 중추이며 기업이 네트워크와 네트워크를 안전하게 운영하는 운영자의 부담을 증가시킬 것으로 예상되는 디지털 전환을 추진하는 동안 모든 것을 원활하게 운영할 책임을 점점 더 많이 맡고 있습니다.

저는 기존 모델에서 좀 더 민첩한 DevOps 유사 모델로 네트워크 운영을 대대적으로 개편하는 것은 불가능하다고 생각합니다. 기업의 디지털 혁신과 마찬가지로 IT의 디지털 혁신도 기존 프로세스를 방해하여 기업의 흐름을 방해 하지 않도록 단계적으로 진행됩니다. 이 설문 조사는 "DevOps"라고 분류되지 않았거나 그것이 수반하는 것에 대한 순수주의자의 개념을 완전히 충족시키지는 않았지만, 기업 네트워크를 자체 디지털 변환 여정에서 확실히 전진시키고 있는 분명히 변화가 발생하고 있음을 보여줍니다.