네트워커(아님) 필요

이 기사를 작성할 당시 인기 있는 채용 사이트에서 "네트워크 엔지니어"라는 문구를 검색하면 러시아 전역에서 약 2.5개의 공석이 검색되었습니다. 비교를 위해 "시스템 관리자"라는 문구를 검색하면 거의 800개의 공석이 반환되고 "DevOps 엔지니어"는 거의 XNUMX개가 반환됩니다.

이는 클라우드, Docker, Kubernetes 및 유비쿼터스 공용 Wi-Fi가 승리하는 시대에 네트워크 담당자가 더 이상 필요하지 않다는 것을 의미합니까?
알아 봅시다 (c)

알아 봅시다. 제 이름은 Alexey이고 네트워크 담당자입니다.

저는 10년 이상 네트워크 분야에 종사해 왔으며 15년 이상 다양한 *nix 시스템을 다루었습니다(Linux와 FreeBSD를 모두 다룰 기회가 있었습니다). 저는 통신 사업자, "기업"으로 간주되는 대기업에서 근무했으며 최근에는 클라우드, 데브옵스, 쿠버네티스 및 나와 동료를 불필요하게 만드는 다른 무서운 단어가 있는 "젊고 대담한" 핀테크에서 일하고 있습니다. . 타일. 아마도.

면책 조항: "우리 삶에서 모든 것이 항상 어디에나 있는 것은 아니지만 때로는 장소에 있는 것"(c) Maxim Dorofeev.

아래에 쓰여진 모든 내용은 저자의 개인적인 의견으로 간주될 수 있으며, 이는 궁극적인 진실이나 본격적인 연구라고 주장하지 않습니다. 모든 등장인물은 허구이며, 우연의 일치는 모두 무작위입니다.

내 세계에 오신 것을 환영합니다.

네트워크 담당자를 어디에서 만날 수 있나요?

1. 통신 사업자, 서비스 회사 및 기타 통합업체. 여기에서는 모든 것이 간단합니다. 이들의 네트워크는 비즈니스입니다. 그들은 연결성(운영자)을 직접 판매하거나 고객의 네트워크를 시작/유지하기 위한 서비스를 제공합니다.

여기에는 많은 경험이 있지만 돈은 많지 않습니다(이사 또는 성공적인 영업 관리자가 아닌 이상). 그럼에도 불구하고 네트워크를 좋아하고 여정의 시작 단계에 있다면 그리 크지 않은 일부 운영자를 지원하는 경력이 지금도 이상적인 출발점이 될 것입니다(연방 네트워크에서는 모든 것이 매우 스크립트로 작성되어 있으며 창의력을 발휘할 여지가 거의 없습니다.) 글쎄요, 몇 년 안에 근무하는 엔지니어에서 C급 관리자로 성장할 수 있는 방법에 대한 이야기도 비록 드물기는 하지만 분명한 이유로 꽤 현실적입니다. 이직이 발생하기 때문에 항상 인력이 필요합니다. 이것은 좋은 동시에 나쁜 것입니다. 반면에 항상 공석이 있습니다. 종종 가장 활동적이고 똑똑한 사람들은 승진을 위해 빨리 떠나거나 다른 "따뜻한" 장소로 떠납니다.

2. 조건부 "기업". 그의 주요 활동이 IT와 관련되어 있는지 여부는 중요하지 않습니다. 가장 중요한 것은 사무실 네트워크, 지점 통신 채널 등을 포함하여 회사 내부 시스템의 운영을 보장하는 자체 IT 부서가 있다는 것입니다. 이러한 회사에서 네트워크 엔지니어의 기능은 시스템 관리자가 "파트타임"으로 수행할 수 있으며(네트워크 인프라가 작거나 외부 계약자가 처리하는 경우) 네트워크 전문가가 있는 경우 동시에 전화 통신과 SAN을 관리합니다(좋지 않음). 그들은 다르게 지불합니다. 이는 비즈니스 수익성, 회사 규모 및 구조에 따라 크게 달라집니다. 나는 Cisco 시스템이 정기적으로 "통에 적재"되는 회사와 배설물, 막대기 및 파란색 테이프로 네트워크가 구축되고 서버가 업데이트되지 않는 회사와 일했습니다 (물론 예비도 제공되지 않았습니다). 여기에는 경험이 훨씬 적고 엄격한 벤더 잠금 영역, 즉 "무에서 유를 만드는 방법" 영역에 있을 것이 거의 확실합니다. 개인적으로 많은 사람들이 좋아하지만 매우 지루하다고 생각했습니다. 모든 것이 상당히 측정되고 예측 가능합니다 (대기업에 대해 이야기하는 경우), "dorakha-bahato"등. 적어도 XNUMX년에 한 번, 일부 주요 공급업체는 이제 모든 것을 자동화하고 모든 시스템 관리자와 네트워크 담당자를 분산시켜 아름다운 인터페이스에서 몇 명만 버튼을 누를 수 있도록 하는 또 다른 초강력 시스템을 내놓았다고 말합니다. 현실은 솔루션 비용을 무시하더라도 네트워크 담당자는 거기서 아무데도 가지 않을 것입니다. 예, 아마도 콘솔 대신 웹 인터페이스가 다시 있을 것입니다(그러나 특정 하드웨어는 아니지만 수십, 수백 개의 하드웨어를 관리하는 대규모 시스템). 그러나 "모든 것이 내부에서 어떻게 작동하는지"에 대한 지식은 여전히 ​​​​있습니다. 필요합니다.

3. 제품 회사, 그 이익은 일부 소프트웨어나 플랫폼, 즉 동일한 제품의 개발(및 종종 운영)에서 발생합니다. 일반적으로 그들은 작고 민첩하며 여전히 기업 규모 및 관료화와는 거리가 멀습니다. 동일한 데브옵스, 큐버, 도커 및 기타 끔찍한 단어가 한꺼번에 발견되는 곳이 바로 여기이며, 이는 확실히 네트워크 및 네트워크 엔지니어를 불필요한 초보로 만들 것입니다.

네트워크 담당자는 시스템 관리자와 어떻게 다릅니까?

IT가 아닌 사람들을 이해하는 데에는 아무것도 없습니다. 두 사람 모두 검은 화면을 바라보며 주문을 쓰거나, 때로는 조용히 욕을 하기도 한다.

프로그래머에 대한 이해 - 아마도 주제 영역별로. 시스템 관리자는 서버를 관리하고, 네트워크 담당자는 스위치와 라우터를 관리합니다. 때로는 행정이 나쁘고 모든 사람이 모든 것을 무너지게 됩니다. 글쎄요, 이상한 일이 발생하면 네트워크 담당자도 책임이 있습니다. 그냥 엿먹이기 때문에, 그게 이유야.

실제로 가장 큰 차이점은 작업에 대한 접근 방식입니다. 아마도 "효과가 있다면 건드리지 마세요!"라는 접근 방식을 가장 많이 지지하는 사람은 네트워크 담당자들일 것입니다. 일반적으로 한 가지 방법으로만 작업을 수행할 수 있습니다(한 공급업체 내에서). 상자의 전체 구성이 바로 손바닥 안에 있습니다. 오류 비용은 높으며 때로는 매우 높습니다. 예를 들어 라우터를 재부팅하려면 수백 킬로미터를 이동해야 하며 이때 수천 명의 사람들이 통신을 할 수 없게 됩니다. 이는 통신 사업자에게 매우 일반적인 상황입니다. .

제 생각에는 이것이 네트워크 엔지니어가 한편으로는 네트워크 안정성에 대해 매우 높은 동기를 부여하고(그리고 변화는 안정성의 주요 적입니다) 두 번째로 그들의 지식이 폭보다 더 깊이 있는 이유입니다(당신은 그렇지 않습니다). 수십 개의 서로 다른 데몬을 구성할 수 있어야 하며 특정 장비 제조업체의 기술과 구현을 알아야 합니다. 그렇기 때문에 Cisco 시스템에 VLAN을 등록하는 방법을 검색한 시스템 관리자는 아직 네트워크 담당자가 아닙니다. 그리고 그가 다소 복잡한 네트워크를 효과적으로 지원(문제 해결)할 수 있을 것 같지 않습니다.

그런데 호스팅 업체가 있는데 왜 네트워킹 담당자가 필요한가요?

추가 비용을 지불하면(또한 귀하가 매우 크고 사랑받는 고객인 경우 "친구로서" 무료로) 데이터 센터 엔지니어가 귀하의 요구에 맞게 스위치를 구성하고 공급자와 BGP 인터페이스를 설정하는 데 도움을 줄 수도 있습니다. (공지사항을 위한 자체 IP 주소 서브넷이 있는 경우)

가장 큰 문제는 데이터 센터가 IT 부서가 아니라 이익 창출을 목표로 하는 별도의 회사라는 것입니다. 고객으로서 귀하를 희생하는 것을 포함합니다. 데이터 센터는 랙을 제공하고, 전기와 냉방을 제공하며, 인터넷에 대한 일부 "기본" 연결도 제공합니다. 이러한 인프라를 기반으로 데이터 센터는 귀하의 장비를 호스팅(코로케이션)하거나, 서버를 귀하에게 임대(전용 서버)하거나, 관리형 서비스(예: OpenStack 또는 K8s)를 제공할 수 있습니다. 그러나 데이터 센터의 비즈니스(일반적으로)는 클라이언트 인프라 관리가 아닙니다. 이 프로세스는 노동 집약적이고 자동화 수준이 낮으며(일반적인 데이터 센터에서는 가능한 모든 것이 자동화됨) 통합이 더욱 나쁘기 때문입니다(각 클라이언트 개별적임) 일반적으로 불만 사항이 많습니다("서버가 설정되었다고 말했지만 이제 충돌이 발생했습니다. 모두 귀하의 잘못입니다!!!111"). 따라서 호스팅 업체가 귀하에게 도움을 주면 가능한 한 간단하고 편리하게 만들려고 노력할 것입니다. 어려운 작업은 적어도 동일한 호스팅 업체의 엔지니어의 인건비 측면에서 볼 때 수익성이 없기 때문입니다(그러나 상황은 다릅니다. 고지 사항 참조). 그렇다고 호스팅 업체가 반드시 모든 일을 잘못한다는 의미는 아닙니다. 그러나 그가 당신에게 정말로 필요한 일을 정확히 할 것이라는 것은 전혀 사실이 아닙니다.

문제는 매우 분명한 것처럼 보이지만 실제로 여러 번 회사가 호스팅 공급자에 필요한 것보다 조금 더 의존하기 시작했으며 이것이 좋은 결과로 이어지지 않았다는 사실을 여러 번 접했습니다. 단 하나의 SLA도 가동 중지 시간으로 인한 손실을 보상할 수 없으며(예외가 있지만 일반적으로 클라이언트에게는 매우 많은 비용이 듭니다) 호스팅 업체가 서버에서 무슨 일이 일어나고 있는지 전혀 인식하지 못한다는 점을 길고 자세하게 설명해야 했습니다. 고객의 인프라(매우 일반적인 지표 제외) 그리고 호스팅 업체도 귀하를 위해 백업을 만들지 않습니다. 호스팅 업체가 두 명 이상인 경우 상황은 더욱 악화됩니다. 그들 사이에 문제가 있는 경우, 그들은 확실히 무엇이 잘못되었는지 알아내지 못할 것입니다.

실제로 여기서의 동기는 "사내 관리 팀 대 아웃소싱"을 선택할 때와 정확히 동일합니다. 리스크를 계산해 보면 품질이 만족스럽고 업체도 개의치 않는 것이라면 시도해 보는 것은 어떨까요? 반면, 네트워크는 인프라의 가장 기본적인 계층 중 하나이며, 이미 다른 모든 것을 직접 지원하고 있다면 외부인에게 맡길 가치가 거의 없습니다.

어떤 경우에 네트워커가 필요합니까?

다음으로 현대 식품 회사에 대해 구체적으로 이야기하겠습니다. 운영자와 기업의 경우 모든 것이 명확하고 플러스 마이너스입니다. 최근 몇 년 동안 거의 변경되지 않았으며 이전에는 네트워크가 필요했고 지금도 필요합니다. 그러나 똑같은 "젊고 대담한" 것들은 그렇게 명확하지 않습니다. 전체 인프라를 클라우드에 배치하는 경우가 많기 때문에 관리자가 실제로 필요하지도 않습니다. 물론 동일한 클라우드의 관리자를 제외하면 말이죠. 한편으로 인프라는 설계가 매우 단순하지만, 다른 한편으로는 잘 자동화되어 있습니다(ansible/puppet, terraform, ci/cd... 음, 아시다시피). 하지만 여기에도 네트워크 엔지니어 없이는 할 수 없는 상황이 있습니다.

예 1, 클래식

회사가 데이터 센터에 위치한 공용 IP 주소를 가진 하나의 서버로 시작한다고 가정합니다. 그러면 서버가 100개가 됩니다. 그러면 더... 조만간 서버 간 사설 네트워크가 필요하게 될 것입니다. "외부" 트래픽은 대역폭(예: XNUMXMbit/s 이하)과 월별 다운로드/업로드 볼륨(호스터마다 요금이 다르지만 외부 세계에 대한 대역폭은 일반적으로 대역폭보다 훨씬 비쌉니다. 개인 네트워크).

호스터는 서버에 추가 네트워크 카드를 추가하고 이를 별도 VLAN의 스위치에 포함시킵니다. 서버 사이에는 "평평한" 로컬 영역이 나타납니다. 편안한!

서버 수가 증가하고 있으며 백업, 복제 등 개인 네트워크의 트래픽도 증가하고 있습니다. 호스터는 귀하가 다른 클라이언트를 방해하지 않고 귀하를 방해하지 않도록 별도의 스위치로 이동할 것을 제안합니다. 호스터는 일부 스위치를 설치하고 어떻게든 구성합니다. 대부분의 경우 모든 서버 사이에 하나의 평면 네트워크를 남겨 둡니다. 모든 것이 잘 작동하지만 특정 순간에 문제가 시작됩니다. 호스트 간의 지연이 주기적으로 증가하고, 로그에서 초당 너무 많은 arp 패킷에 대해 불평하고, 감사 중에 침투 테스터가 전체 로컬 네트워크를 망쳐 서버 하나만 중단했습니다.

어떻게해야합니까?

네트워크를 세그먼트(Vlan)로 나눕니다. 각 VLAN에서 고유한 주소 지정을 구성하고 네트워크 간에 트래픽을 전송할 게이트웨이를 선택합니다. 세그먼트 간 액세스를 제한하려면 게이트웨이에 acl을 구성하거나 근처에 별도의 방화벽을 설치하세요.

예제 1, 계속

서버는 하나의 코드로 LAN에 연결됩니다. 랙에 있는 스위치는 어떻게든 서로 연결되어 있지만, 한 랙에서 사고가 발생하면 인접한 XNUMX개의 스위치가 더 떨어져 나갑니다. 계획이 존재하지만 관련성에 대한 의구심이 있습니다. 각 서버에는 호스팅 업체가 발행하고 랙에 연결된 자체 공개 주소가 있습니다. 저것들. 서버이전시 주소변경이 ​​필요합니다.

어떻게해야합니까?

두 개의 코드가 있는 LAG(Link Aggregation Group)를 사용하여 서버를 랙의 스위치에 연결합니다(또한 중복되어야 함). 한 랙의 손실이 다른 랙에 영향을 미치지 않도록 랙 사이의 연결을 예약하고 이를 "스타"(또는 현재 유행하는 CLOS)로 변환합니다. 네트워크 코어가 위치하고 다른 랙이 연결될 "중앙" 랙을 선택합니다. 동시에 공개 주소 지정을 순서대로 설정하고 호스트(또는 가능하면 RIR)에서 서브넷을 가져와서(또는 호스트를 통해) 전 세계에 알립니다.

네트워크에 대한 깊은 지식도 없는 "일반" 시스템 관리자가 이 모든 작업을 수행할 수 있습니까? 확실하지 않다. 호스트가 이것을 할 것인가? 그럴 수도 있겠지만, 누군가가 작성해야 하는 상당히 상세한 기술 사양이 필요할 것입니다. 그런 다음 모든 것이 올바르게 수행되었는지 확인하십시오.

예시 2: 클라우드

일부 퍼블릭 클라우드에 VPC가 있다고 가정해 보겠습니다. 사무실이나 인프라의 온프레미스 부분에서 VPC 내부 로컬 네트워크에 액세스하려면 IPSec 또는 전용 채널을 통해 연결을 구성해야 합니다. 한편으로는 IPSec이 더 저렴합니다. 추가 하드웨어를 구입할 필요가 없으며 공용 주소가 있는 서버와 클라우드 사이에 터널을 설정할 수 있습니다. 그러나 지연, 제한된 성능(채널을 암호화해야 하기 때문에) 및 보장되지 않는 연결(액세스가 일반 인터넷을 통해 이루어지기 때문에)이 있습니다.

어떻게해야합니까?

전용 채널을 통해 연결을 생성합니다(예: AWS에서는 이를 Direct Connect라고 함). 이렇게 하려면 귀하를 연결해 줄 파트너 운영자를 찾고, 귀하에게 가장 가까운 연결 지점(귀하와 운영자 및 운영자 모두 클라우드)을 결정한 후 마지막으로 모든 것을 설정하십시오. 네트워크 엔지니어 없이 이 모든 것이 가능합니까? 물론이죠. 그러나 문제가 발생한 경우 그 사람 없이 문제를 해결하는 방법은 더 이상 명확하지 않습니다.

클라우드 간 가용성 문제(멀티클라우드가 있는 경우)나 서로 다른 지역 간의 지연 문제 등이 있을 수도 있습니다. 물론 이제 클라우드에서 일어나는 일의 투명성을 높이는 많은 도구(동일한 Thousand Eyes)가 등장했지만 이는 모두 네트워크 엔지니어의 도구이지 그를 대체하는 도구는 아닙니다.

내 실무에서 그러한 예를 XNUMX개 더 스케치할 수 있지만 특정 수준의 인프라 개발부터 시작하는 팀에는 네트워크 작동 방식을 알고 구성할 수 있는 사람(가급적이면 한 명 이상)이 있어야 한다는 것이 분명하다고 생각합니다. 네트워크 장비를 관리하고 문제가 발생하면 이를 해결합니다. 내 말을 믿으세요. 그 사람은 할 일이 있을 거예요.

네트워크 담당자는 무엇을 알아야 합니까?

네트워크 엔지니어가 네트워크만 다루고 다른 작업을 수행하는 것은 전혀 필요하지 않습니다(때로는 해로울 때도 있음). 거의 전적으로 퍼블릭 클라우드에 존재하는 인프라에 대한 옵션을 고려하지 않고(그리고 누가 뭐라고 말하든 점점 더 대중화되고 있음) 온프레미스 또는 프라이빗 클라우드를 예로 들더라도 "CCNP 수준의 지식만으로" "당신은 떠나지 않을 것입니다.

실제로 네트워크에 더해 - 단순히 연구할 분야가 끝이 없지만 한 영역(공급자 네트워크, 기업, 데이터 센터, Wi-Fi ...)에만 집중하더라도

물론 이제 여러분 중 많은 분들이 Python과 기타 “네트워크 자동화”를 기억하실 것입니다. 그러나 이것은 단지 필요조건일 뿐 충분조건은 아닙니다. 네트워크 엔지니어가 "성공적으로 팀에 합류"하려면 개발자 및 동료 관리자/개발자 모두와 동일한 언어로 말할 수 있어야 합니다. 무슨 뜻이에요?

• 사용자로서 Linux에서 작업할 수 있을 뿐만 아니라 최소한 sysadmin-jun 수준에서 이를 관리할 수도 있습니다. 필요한 소프트웨어를 설치하고, 실패한 서비스를 다시 시작하고, 간단한 systemd-unit을 작성합니다.
• (적어도 일반적인 용어로) Linux에서 네트워크 스택이 작동하는 방식, 하이퍼바이저 및 컨테이너(lxc/docker/kubernetes)에서 네트워크가 작동하는 방식을 이해합니다.
• 물론, ansible/chef/puppet 또는 다른 SCM 시스템과 함께 작업할 수 있습니다.
• SDN 및 프라이빗 클라우드용 네트워크(예: TungstenFabric 또는 OpenvSwitch)에 대해서는 별도의 줄을 작성해야 합니다. 이것은 또 다른 거대한 지식 계층입니다.

간단히 말해서, 나는 전형적인 T자형 전문가를 묘사했습니다(지금 말하는 것이 유행입니다). 새로운 것은 없어 보이지만 인터뷰 경험에 따르면 모든 네트워크 엔지니어가 위 목록 중 최소 두 가지 주제에 대한 지식을 자랑할 수 있는 것은 아닙니다. 실제로 "관련 분야"에 대한 지식이 부족하면 동료와 의사소통하는 것뿐만 아니라 기업이 프로젝트의 최하위 인프라인 네트워크에 배치하는 요구 사항을 이해하는 것도 매우 어렵습니다. 그리고 이러한 이해가 없으면 귀하의 관점을 방어하고 이를 비즈니스에 "판매"하는 것이 더 어려워집니다.

반면에 "시스템 작동 방식을 이해"하는 동일한 습관은 Habré/medium의 기사와 Telegram의 채팅을 통해 기술에 대해 알고 있지만 어떻게 해야할지 전혀 모르는 다양한 "일반주의자"에 비해 네트워크 담당자에게 매우 좋은 이점을 제공합니다. 원칙적으로 이 소프트웨어 또는 저 소프트웨어가 작동합니까? 그리고 알려진 바와 같이 특정 패턴에 대한 지식은 많은 사실에 대한 지식을 성공적으로 대체합니다.

결론 또는 간단히 요약하자면

1. 네트워크 관리자(예: DBA 또는 VoIP 엔지니어)는 시스템 관리자/개발자/SRE와 달리 프로필이 다소 좁은 전문가로, 그 필요성이 즉시 발생하지 않으며 실제로 오랫동안 발생하지 않을 수도 있습니다. . 그러나 만약 발생하더라도 외부 전문가(아웃소싱 또는 "네트워크도 관리하는" 일반 범용 관리자)로 대체될 가능성은 거의 없습니다. 다소 슬픈 점은 그러한 전문가에 대한 필요성이 적다는 점이며, 조건적으로 800명의 프로그래머와 30명의 개발자/관리자가 있는 회사에서 자신의 책임을 훌륭하게 수행하는 네트워크 담당자는 단 두 명뿐일 수 있다는 것입니다. 저것들. 시장은 과거에도 그랬고 지금도 매우 작으며 급여도 좋습니다. 심지어 더 적습니다.
2. 반면에, 현대 세계의 훌륭한 네트워크 담당자는 네트워크 자체(및 구성을 자동화하는 방법)뿐만 아니라 이러한 네트워크 위에서 실행되는 운영 체제 및 소프트웨어가 네트워크와 상호 작용하는 방식도 알아야 합니다. 이것이 없으면 동료가 귀하에게 무엇을 요구하는지 이해하고 귀하의 바람/요구 사항을 동료에게 (합리적으로) 전달하는 것이 극히 어려울 것입니다.
3. 클라우드는 없고 단지 다른 사람의 컴퓨터일 뿐입니다. 퍼블릭/프라이빗 클라우드 또는 "턴키 방식으로 모든 작업을 수행하는" 호스팅 제공업체의 서비스를 사용해도 애플리케이션이 여전히 네트워크를 사용한다는 사실은 바뀌지 않으며 애플리케이션 문제가 애플리케이션 운영에 영향을 미칠 수 있다는 점을 이해해야 합니다. 너의 어플리케이션. 귀하의 선택은 귀하의 프로젝트 네트워크를 담당할 역량 센터의 위치입니다.

출처 : habr.com