NetOps를 위한 DevOps는 규모에 관한 것입니다

그리고 규모는 속도로 이어진다. 그리고 속도는 성공으로 이어진다.

한 엔지니어가 변경 요청을 2시간 안에 처리할 수 있다고 가정해 보겠습니다. 다른 엔지니어가 해당 변경 요청을 1.5시간 안에 처리할 수 있다고 가정해 보겠습니다. 만약 그들이 함께 일한다면, 200개의 변경 요청을 처리하는 데 얼마나 걸릴까요?

네, 답은 당연히 맥주입니다.  

수학 수업에서 분수 관계에 대해 가르쳐주기 위해 고안된 악명 높은 "기차"나 "그림" 문제를 누구나 (적지 않은 두려움과 혐오감과 함께) 기억할 것입니다. 사실, 그것이 그들의 의도였습니다. 비록 우리 중 많은 사람이 그들로부터 그림과 기차 여행에 대한 혐오감을 얻었지만요. 그리고 많은 밈(meme)들이요. 밈도 잊지 마세요.

요점은 이러한 유형의 공식적인 측정이 데이터 센터, 특히 네트워크에서 필수가 되고 있다는 것입니다. 예산이 제한적이기 때문이죠.(맞죠? 얼마나 미친 짓인가요?) X명의 엔지니어를 Y개의 작업에만 고용할 수 있습니다. 빠르고 빈번한 릴리스 주기가 게임의 이름인 애플리케이션 세계에서 적시에 릴리스를 달성하기 위해 고용할 수 있는 "X"의 수는 제한되어 있습니다.

이것이 네트워크에서 "devops" 또는 "netops"의 주요 동인인 이유입니다. DevOps의 운영 원칙을 네트워크에 적용하면 넷옵스는 "X" 엔지니어가 예산 제약 내에서 정해진 시간 내에 "Y" 작업을 수행할 수 있도록 하는 데 필요한 운영 규모를 달성할 수 있다고 믿어집니다. 이는 X와 Y 간의 관계가 기하급수적(평범한 번역: 정말 불균형적)일 때에도 마찬가지입니다.

변경 요청 문제는 실제적인 문제입니다. 점점 더 많은 변경 요청(애플리케이션에 대한 부하 분산 엔드포인트를 만들고 DNS에 추가한 다음 액세스를 허용하는 방화벽 규칙을 만드는 작업)에 직면한 네트워크 엔지니어가 제기한 문제입니다. 이러한 변경 요청은 궁극적으로 사용 가능한 직원에게 과부하를 초래하고 동시에 완료까지 걸리는 시간을 늘리는 결과를 가져왔습니다.

물론, 답은 자동화에서 찾을 수 있었고, DevOps의 원칙을 적용하여 다른 엔지니어가 요청을 하면 티켓팅 시스템에 문서화되고 다양한 네트워킹 및 애플리케이션 서비스 API를 통해 수행될 수 있는 셀프 서비스 인터페이스를 제공하는 데 있었습니다.

자동화(그리고 오케스트레이션, 전체 프로세스가 실제로 자동화됨)를 도입함으로써 기존 엔지니어가 운영을 확장할 수 있을 뿐만 아니라 프로세스도 더 빨라 졌습니다. 변경 요청을 처리하는 데 더 이상 최대 2시간이 걸리지 않으며, 이제는 단 5분 만에 처리됩니다.

네, 맞게 읽으신 겁니다. 최대 2시간이 아니라 5분이에요.

자동화와 오케스트레이션을 통해 확장 할 수 있는 능력 덕분에 속도가 크게 향상되었습니다. 야심찬 "데이터 센터 전체" 프로젝트는 아니지만 엔지니어와 애플리케이션 소유자가 자주 경험했던 특정한 문제점을 해결합니다. 이 경우에는 일주일에 최대 200번까지 가능하다고 합니다.

이는 바로 넷옵스가 프로덕션 네트워크 내에서 자동화와 오케스트레이션에 접근해야 하는 방식입니다. 변경 검토 위원회에서 반복 가능하고 사소한 것으로 간주되는 작업(즉, 중단이 발생하지 않고 대부분 엔지니어가 잠을 자면서도 할 수 있는 작업)을 찾으면 비즈니스와 애플리케이션 소유자가 네트워크에서 달성해야 한다고 말하는 속도를 구현할 수 있는 상당한 확장 기회가 생길 수 있습니다.

가능한 한 중단 위험이 적은 자동화가 가능한 핵심 요소를 찾아내면 엔지니어는 자동화에 적합하지 않은 것으로 간주되는 작업에 집중할 수 있습니다. 이러한 집중은 또한 더 간단하고 반복 가능한 작업에 지나치게 많은 시간을 소비하지 않아도 되므로 다른 서비스 구현에 걸리는 시간도 단축됩니다.

네트워크 자동화에 CPR 접근 방식을 취하는 것이 얼마나 중요한지 충분히 강조할 수 없습니다. 일관되고 예측 가능하며 반복 가능한 자동화를 통해 규모를 보다 효율적으로 확장하고 제공 시간을 단축할 수 있으며 오류로 인한 중단 위험을 줄일 수 있습니다. 이는 신뢰성과 안정성이 우선이지만 민첩성도 여전히 바람직한 소위 "모드 1"과 "모드 2" 운영 모델의 결합입니다. 네트워크에서 자동화 및 오케스트레이션에 CPR 방식을 적용함으로써 조직은 약 200개 정도의 다른 애플리케이션을 제공해야 하는 네트워크의 안정성을 방해할 위험을 훨씬 낮추면서 민첩성을 향상시킬 수 있습니다.

데이터 센터 네트워크는 기존 기술과 새로운 기술로 구성되어 있으며, 종종 풍선껌과 낚싯줄이 필요한 맥가이버와 같은 기술로 결합됩니다. 이러한 네트워크는 50년 전부터 생산되고 있는 애플리케이션(메인프레임은 아직 존재함)과 갓 나온 기술을 기반으로 만들어진 새로운 애플리케이션(컨테이너 등)을 동시에 지원해야 합니다. 모든 애플리케이션을 안정적이고 안전하게 제공해야 합니다. 이러한 표준은 최신의 더 반짝이는 응용 프로그램에 필요한 속도와 주파수를 고려하여 무시될 수 없습니다.

하지만 넷옵스는 변경 제어 및 기타 승인자가 체크박스 작업으로 간주하고 방해가 되지 않는 작업과 서비스 제공 옵션을 식별하여 이를 철저히 자동화할 수 있다면 두 가지가 공존하는 균형을 이룰 수 있습니다.

결국, 집을 칠하는 데 걸리는 시간을 결정하는 우리가 가장 좋아하는 방정식은 페인트 작업자에게 수동 브러시 대신 자동 페인트 롤러가 제공되면 극적으로 달라집니다.

네트워크를 변경하는 것에 대해 너무 걱정하지 말고 대신 방정식만 변경하세요.