NetOps에는 반대자가 아닌 옹호자가 필요합니다.

하루종일 기대하며 먹던 음식을 먹으려고 했는데 음식이 덜 익었다는 걸 알아차리는 경우가 많습니다. 좌절한 당신은 웨이터에게 거칠게 말을 걸고 심지어 팁을 깎아주기까지 할 수도 있습니다. 그게 자기들의 잘못이 아니더라도 그들은 미소 지으며 받아들인다. 결국, 그들은 당신의 식사를 준비하지 않았어요. 하지만 그들은 여러분을 주방으로 연결해주는 인터페이스이며, 궁극적으로 눈에 보이지 않는 곳에서 발생하는 실패에 대한 대가를 치르는 사람도 바로 그들입니다.

레스토랑의 웨이터든 <여기에 서비스 이름 삽입>의 고객 서비스 담당자든, 무언가 문제가 생겼을 때 가장 큰 고민, 좌절, 분노를 느끼는 사람은 대개 당신과 상호작용하는 사람입니다.

이는 데이터 센터에서도 마찬가지입니다.

IT가 더 높은 최적화와 속도를 목표로 디지털 방식으로 전환함에 따라, 내부 "고객"과 상호 작용할 가능성이 가장 높은 팀은 NetOps 팀이며, 프로세스가 원하는 만큼 빠르게 진행되지 않을 때 불만을 품은 사용자의 타격을 가장 많이 입게 됩니다.

항상 "NetOps"가 최신 사물/앱/서비스를 배포하는 데 방해가 되는 것은 아니라는 점을 인식하는 것이 중요합니다. 조직이 IT 운영을 혁신하고자 할 때 DevOps의 모든 전제 조건을 도입하지 못하면 속도에 방해가 되는 경우가 많습니다. 

DevOps를 하고 계신가요, 아니면 자동화만 하고 계신가요? 

CAMS는 DevOps의 핵심 원칙을 전파하는 데 가장 일반적으로 사용되는 수단입니다. CAMS는 문화 , 자동화 , 측정 , 공유 를 의미합니다.

이 네 가지 가운데 자동화가 가장 큰 열광을 받을 가능성이 높습니다. IT 내에서 서비스 속도를 개선하려는 노력에서 뒤처지거나 완전히 무시되는 경향이 있는 것은 나머지 세 가지입니다.

특히 주목할 점은 흔히 무시되는 세 가지 개념이 서로 얽혀 있다는 것입니다. 팀이 여전히 기능별로 분리되어 있고 다른 팀에는 중요하지 않은 지표에 집중하고 있다면 문화를 바꾸는 것은 어렵습니다. 우리는 우리가 측정받는 것을 향해 일합니다. 네트워크 가동 시간으로 측정한다면, 운영 담당자가 애플리케이션 가동 시간을 개선하려고 노력하더라도 그에 집중할 것입니다.

즉, 여러분은 Red Hat과 힘을 합쳐 DevOps, NetOps와 자동화의 모호한 세계를 탐구했던 State of Network Automation 연구를 기억하실 겁니다. 이 보고서에서 우리는 NetOps가 추구하는 지표(측정)와 개발 및 운영에 참여하는 사람들이 추구하는 지표(측정) 사이에 광범위한 차이가 있음을 발견했습니다.

NetOps의 거의 4분의 3(73%)이 '네트워크 가동 시간'을 주요 지표로 꼽았습니다. 반면에 개발자와 운영 담당자의 59%는 "애플리케이션 가동 시간"이 주요 지표라고 답했습니다. 반대로, 배포 빈도를 기준으로 측정된 개발자와 운영(30%)은 NetOps(16%)와 보안(17%)보다 거의 두 배나 많습니다.

왜 이런 불균형이 중요한가? 네트워크를 계속 사용할 수 있게 하는 게 주된 목표라면, 네트워크에 집중해서 시간을 보낼 겁니다. 계측 및 모니터링(후자는 DevOps의 공유 구성 요소에 중요함)은 먼저 네트워크에 초점을 맞추고, 그다음에 애플리케이션에 초점을 맞출 것입니다. 시간이 있다면 말이죠. 아무도 보안에 시간을 할애할 수 없고, 어차피 보안에 대한 평가도 받지 않습니다. 실제로 보안과 관련해 가장 중요하게 언급된 측정 항목은 <드럼을 치세요> "네트워크 가동 시간"이었는데, 보안 전문가 중 59%가 이 항목을 꼽았습니다.

여전히 IT의 핵심이며 자동화와 오케스트레이션을 구현해야 하는 팀을 구성하는 사람들은 반드시 동일한 목표에 맞춰 있지는 않습니다. 이런 불일치의 한 요인은 운영 도메인의 지속적인 고립입니다. NetOps 및 보안 그룹은 '단일 기능' 팀 구성으로 작업할 가능성이 더 높습니다. NetOps는 네트워크에 대해 걱정합니다. 보안? 보안. 운영? 시스템 운영

하지만 그보다 더 깊은 의미가 있습니다. 큰 사일로 안에는 더욱 작은 사일로가 있기 때문입니다. 마트료시카 (러시아 마트료시카 인형)처럼, NetOps 내에는 그 겉보기에 간단해 보이는 "새로운 사이트" 요청이 완료되기 전에 반드시 흘러들어오는 여러 팀이 있습니다. 이러한 요청을 완료하려면 많은 인프라와 애플리케이션 서비스를 프로비저닝하고 구축해야 합니다. 새로운 사이트를 만들려면 이를 호스팅하는 데 필요한 컴퓨팅 및 네트워크 리소스뿐만 아니라, 다른 많은 요구 사항도 필요합니다. 웹 서버와 저장소. 접근 제어. 인증서 및 키 관리. 부하 분산. 방화벽 규칙. 이 "간단한" 요청이 거쳐야 하는 IT 내부 사일로 목록은 끝이 없습니다.

그리고 NetOps 사일로 내의 사일로 중 하나라도 자동화되지 않으면 그 프로세스는 갑자기 중단됩니다. 이런 요청을 처리하는 데는 며칠이 아니라면 몇 주가 걸릴 수도 있습니다.

외부에서, 요청자에게는 NetOps가 일을 제대로 하지 못하는 것처럼 보입니다. 간단한 요청을 처리하는 데 왜 이렇게 오랜 시간이 걸리는지 묻는 사람들의 고뇌를 감내해야 하는 것은 바로 "상대방", "연락 담당자", "IT 파트너"입니다. 우리가 NetOps를 비난하는 것은 마치 기술 초보자가 인터넷 문제에 대해 지역 서비스 제공자를 비난하는 것과 같지만, 실제로는 다른 서비스 제공자가 관리하는 백본 깊숙한 곳에 있는 라우터에 문제가 있는 것입니다. 

반대자가 아닌 옹호자가 되십시오

보다 협력적이고 투명한 IT로의 전환은 아직도 많은 기업에게는 일순간의 희망에 불과합니다. 일부 IT 그룹은 변화의 필요성을 보고 필요한 변화를 수용하지만, 모두가 그런 것은 아니다. 우리가 애플리케이션 서비스에 대한 연구를 수행한 5년 동안 "DevOps"가 비즈니스가 원하고 필요로 하는 속도를 달성하는 데 필요한 문화적, 조직적 변화를 실제로 시작하는 데 필요한 전략적 중요성 수준에 도달한 적은 없었습니다. 그 대신 기업들은 자동화를 도입했고, DevOps에 필수적인 다른 세 가지 구성 요소는 잊고 말았습니다.

IT 분야에서 DevOps의 움직임을 자동화 그 이상으로 인식하지 못하는 것은 문제가 있습니다. 속도를 얻으려면 파이프라인을 자동화해야 하며, 그 파이프라인은 IT 내의 모든 운영 도메인과 사일로를 가로지른다는 사실을 인식하지 못하는 것입니다. 즉, 영향을 받는 모든 사람이 자동화로 전환해야 함을 의미하며, 그렇지 않으면 원하는 배포 속도와 빈도를 실현하는 데 실패하게 됩니다. 자동화를 도입한다고 해서 성공할 것이라고 기대할 수는 없습니다. 자동화가 여러 그룹 간의 경계를 넘어야 할 때, 의미 있는 문화적 변화 없이는 실패할 것입니다.

필요한 변화는 위에서부터 시작되어야 합니다. 특히 조직 변화. 우리는 우리 자신을 제대로 재조직할 수 없죠? 우리가 목표의 우선순위를 재조정하고 완전히 다른 지표를 사용할 수는 없지 않나요?

우리는 그렇게 할 수 없습니다. 필요한 변화를 만들 수 있는 사람들을 교육하고 설득하지 않는 한, 우리는 자동화된 파이프라인 한가운데서 수동 프로세스에 갇히게 될 것입니다.

따라서 NetOps를 희생양으로 삼는 것을 중단하고 NetOps 역시 좌절감을 느끼고 있다는 사실을 인정해야 합니다. 대신, 의사결정권자들에게 조직 구조를 재평가하고 측정의 우선순위를 재조정하여 비즈니스와 나머지 지속적인 파이프라인에 더 잘 부합하도록 해야 한다는 점을 상기시킵니다. 

최전선에 있는 NetOps 직원에게 소리를 지르는 것은 만족스러운 일 이겠지만, 처음에 분노를 불러일으킨 상황을 실제로 바꿀 수는 없습니다. 그리고 변화가 없다면 파이프라인은 더 빨라지지 않을 것입니다.

NetOps의 적이 아닌 옹호자가 되세요. 그들에게는 가능한 모든 도움이 필요합니다.