На момент написання цієї статті пошук на популярному робітному сайті за словосполученням «Мережевий інженер» видавав близько трьохсот вакансій по всій Росії. Для порівняння, пошук за фразою "системний адміністратор" видає майже 2.5 тисяч вакансій, а "DevOps інженер" - майже 800.
Чи означає це, що мережевики більше не потрібні в часи хмар, що перемогли, докера, кубернетису і всюдисущого публічного вайфая?
Давайте розбиратися (с)
Давайте знайомитися. Мене звуть Олексій, і я сітавік.
Я більше 10 років займаюся мережами і більше 15 років працюю з різними *nix системами (довелося колупати і Linux, і FreeBSD). Працював в операторах зв'язку, великих компаніях, які прийнято вважати «ентерпрайзом», а останнім часом працюю «молодим і зухвалим» фінтехом, де хмари, девопси, кубернетеси та інші страшні слова, які обов'язково зроблять мене та моїх колег непотрібними. Колись. Може бути.
disclaimer: "У нашому житті не все, завжди і скрізь, а дещо, іноді і місцями" (с) Максим Дорофєєв.
Все нижченаписане можна і слід вважати особистим думкою автора, не претендуючим на істину в останній інстанції, і навіть повноцінне дослідження. Усі персонажі вигадані, всі збіги випадкові.
Ласкаво просимо в мій світ.
Де можна взагалі зустріти мережевиків?
1. Оператори зв'язку, сервісні компанії та інші інтегратори. Тут все просто: мережа для них – це бізнес. Вони безпосередньо продають зв'язність (оператори), або надають послуги із запуску/обслуговування мереж своїх замовників.
Досвіду тут багато, грошей не дуже (якщо ви не директор чи успішний менеджер-продажник). І тим не менше, якщо вам подобаються мережі, і ви тільки на початку шляху, кар'єра в саппорті якогось не дуже великого оператора буде, навіть зараз, ідеальною точкою для старту (у федеральних все дуже скриптовано, і простору для творчості мало). Та й історії про те, що можна з чергового інженера дорости за кілька років до C-level manager теж цілком реальні, хоча й рідкісні, зрозумілі причини. Потреба в кадрах є завжди, тому що плинність таки має місце бути. Це і добре, і погано одночасно — завжди є вакансії, з іншого боку — найчастіше, найактивніші/розумніші досить швидко йдуть або на підвищення, або в інші, тепліші» місця.
2. Умовний «ентерпрайз». Не важливо, пов'язана чи його основна діяльність з ІТ, чи ні. Головне, що в ньому є свій IT відділ, який займається забезпеченням роботи внутрішніх систем компанії, у тому числі мережі в офісах, каналів зв'язку у філії тощо. Функції мережного інженера в таких компаніях може «за сумісництвом» виконувати системний адміністратор (якщо мережева інфраструктура невелика, або їй займається зовнішній підрядник), а мережевик, якщо він все-таки є, може наглядати за телефоном і SAN (ненуачо). Платять по-різному — залежить від маржинальності бізнесу, розмірів компанії та структури. Я працював і з компаніями, де циски регулярно «вантажили бочками», і з компаніями, де мережу будували з фекалій, палиць та синьої ізоленти, а сервери не оновлювали приблизно ніколи (чи треба говорити, що ніяких резервів теж передбачено не було). . Досвіду тут значно менше, і він, майже напевно, буде в області жорсткого vendor-lock, або «як з нічого зробити дещо». Особисто мені там здалося дико нудно, хоча багатьом подобається - все досить розмірено і передбачувано (якщо ми говоримо про великі компанії), "дораха-бахато" і т.д. Не рідше одного разу на рік якийсь великий вендор каже, що придумав чергову мега-супер-пупер-систему, яка ось взагалі все зараз автоматизує і всіх сісадмінів та мережевиків можна буде розігнати, залишивши парочку для натискання на кнопки в гарному інтерфейсі. Реальність така, що, навіть якщо абстрагуватися від вартості рішення, нікуди мережевики звідти не подінуться. Так, можливо, замість консолі знову буде веб-інтерфейс (але вже не конкретної залізки, а великої системи, яка керує десятками і сотнями таких залізок), але знання «як усе влаштовано всередині» все одно знадобляться.
3. Продуктові компанії, Прибуток якої приносить розробка (і, часто, експлуатація) якого-небудь софту або платформи - того самого продукту. Зазвичай вони невеликі та спритні, їм ще далеко до масштабів ентерпрайзів та їхньої бюрократизованості. Саме тут масово водяться ті самі девопси, кубери, докери та інші страшні слова, які обов'язково зроблять мережу та мережевих інженерів непотрібним рудиментом.
Чим мережевик відрізняється від сисадміну?
У розумінні людей не з ІТ – нічим. І той, і другий дивляться в чорний екран і пише якісь заклинання, часом тихенько матюкаючись.
У розумінні програмістів — хіба предметною областю. Сисадміни адмінять сервери, мережевики адмінять комутатори та маршрутизатори. Іноді адмінять погано, і в усіх падає. Ну у разі будь-якого дивного винні теж сетевики. Just because fuck you, that's why.
Насправді ж, головна відмінність — це підхід до роботи. Мабуть, саме серед мережевиків найбільше зустрічається прихильників підходу «Працює – не чіпай!». Зробити якусь річ (в рамках одного вендора) можна, як правило, лише одним способом, вся конфігурація коробки – ось вона на долоні. Ціна помилки — висока, а іноді й дуже висока (наприклад, доведеться їхати за кілька сотень кілометрів, щоб перезавантажити роутер, а в цей час без зв'язку сидітимуть кілька тисяч людей — цілком звичайна ситуація для оператора зв'язку).
На мій погляд, саме тому саме мережеві інженери, з одного боку, дуже мотивовані на стабільність мережі (а зміни — головний ворог стабільності), а по-друге, їх знання йдуть більше вглиб, ніж ушир (не потрібно вміти конфігурувати десятки різних демонів). , потрібно знати технології та їх реалізацію у конкретного виробника обладнання). Саме тому сисадмін, який нагуглив, як на циску прописати влан - це ще не сітовик. І навряд чи він зможе ефективно підтримувати (а також траблшутить) більш-менш складну мережу.
Але навіщо потрібна мережевик, якщо у вас є хостер?
За додатковий гріш (а якщо ви дуже великий і улюблений клієнт - може навіть і безкоштовно, «по дружбі») інженери датацентру налаштують ваші комутатори під ваші потреби, і, можливо, навіть допоможуть підняти BGP-стик з провайдерами (якщо у вас є своя) підсіти ip-адрес для анонсу).
Основна проблема в тому, що датацентр - це не ваш IT-відділ, це окрема компанія, метою якої є отримання прибутку. Навіть за рахунок вас, як клієнта. Датацентр надає стійки, забезпечує їх електрикою та холодом, а також дає деяку «дефолтну» зв'язність з інтернетом. На основі цієї інфраструктури датацентр може розмістити ваше обладнання (colocation), здати в оренду сервер (dedicated server), або надати managed service (наприклад, OpenStack або K8s). Але бізнесом датацентру (зазвичай) не є адміністрування інфраструктури клієнтів, тому що цей процес досить трудомісткий, погано автоматизується (а в нормальному датацентрі автоматизовано все, що тільки можливо), ще гірше уніфікується (кожен клієнт індивідуальний) і взагалі загрожує претензіями («ви мені сервер налаштували, а він тепер упав, це ви у всьому винні!!!111»). Тому якщо хостер і вам буде в чомусь допомагати, то постарається зробити це максимально просто і «кондово». Бо робити складно — невигідно, як мінімум з погляду трудовитрат інженерів цього хостера (але ситуації бувають різні, див. дисклеймер). Не означає, що хостер обов'язково все зробить погано. Але зовсім не факт, що він зробить саме те, що було вам потрібне насправді.
Здавалося б, річ досить очевидна, але я кілька разів стикався у своїй практиці з тим, що компанії починали покладатися на свого хостинг-провайдера трохи більше, ніж слід, і нічого хорошого це не призводило. Доводилося довго і докладно пояснювати, що жоден SLA не покриє збитків від простою (є винятки, але зазвичай це дуже, дуже дорого для клієнта) і що хостер взагалі не обізнаний про те, що відбувається в інфраструктурі замовників (крім дуже загальних показників). І бекапів хостер теж за вас не робить. Ще гірша справа, якщо хостерів у вас більше одного. У разі якихось проблем між ними, вони точно не з'ясовуватимуть за вас, що ж все-таки пішло не так.
Власне, мотиви тут такі самі, як при виборі «своя команда адмінів vs аутсорс». Якщо ризики пораховані, якість влаштовує, а бізнес не проти, чому б і не спробувати. З іншого боку, мережа — це один із самих базових верств інфраструктури, і навряд чи варто віддавати його на відкуп хлопцям з боку, якщо все інше ви підтримуєте самі.
У яких випадках потрібна сітавік?
Далі йтиметься саме про сучасні продуктові компанії. З операторами та ентерпрайзом все плюс-мінус ясно — там мало що змінилося за останні роки, і мережевики там були потрібні раніше, потрібні й зараз. А ось з тими «молодими і зухвалими» все не так однозначно. Часто вони розміщують свою інфраструктуру цілком у хмарах, так що навіть і адміни їм особливо не потрібні — крім адмінів тих самих хмар, звичайно ж. Інфраструктура, з одного боку, досить проста за своїм пристроєм, з іншого боку — добре автоматизована (ansible/puppet, terraform, ci/cd… ну, ви знаєте). Але навіть тут є ситуації, коли без мережевого інженера не обійтись.
Приклад 1, класичний
Припустимо, компанія починає з одного сервера з публічною ip-адресою, яка стоїть у датацентрі. Потім серверів стає два. Потім більше… Рано чи пізно, виникає потреба в приватній мережі між серверами. Тому що «зовнішній» трафік лімітується як по смузі (не більше 100Мбіт/с наприклад), так і за обсягом завантаженого/відданого на місяць (у різних хостерів різні тарифи, але смуга у зовнішній світ, як правило, сильно дорожча за приватну мережу).
Хостер додає до серверів додаткові мережеві карти і включає їх у свої комутатори в окремий vlan. Між серверами з'являється "плоска" локалка. Зручно!
Кількість серверів зростає, трафік у приватній мережі теж – бекапи, реплікації тощо. Хостер пропонує відселити вас в окремі комутатори, щоб ви не заважали іншим клієнтам, а вони не заважали вам. Хостер ставить якісь комутатори і якось їх налаштовує — швидше за все, залишивши між усіма серверами одну плоску мережу. Все працює добре, але в певний момент починаються проблеми: періодично виростають затримки між хостами, в логах лайка на занадто велику кількість arp-пакетів в секунду, а пентестер при аудиті отримав всю вашу локалку, зламавши лише один сервер.
Що потрібно зробити?
Розділити мережу на сегменти – vlan'и. Налаштувати в кожній лані свою адресацію, виділити шлюз, який перекидатиме трафік між мережами. На шлюзі налаштувати acl для обмеження доступу між сегментами або взагалі поставити поруч окремий фаєрвол.
Приклад 1, продовження
Сервери підключені до локалки одним шнурком. Комутатори в стійках якось між собою з'єднані, але при аварії в одній стійці відвалюються ще три сусідні. Схеми існують, але в їхній актуальності є сумніви. Кожен сервер має свою публічну адресу, яка видається хостером і прив'язана до стійки. Тобто. при переміщенні сервера адресу доводиться змінювати.
Що потрібно зробити?
Підключити сервери за допомогою LAG (Link Aggregation Group) двома шнурками до комутаторів у стійці (їх також потрібно резервувати). З'єднання між стійками зарезервувати, переробити на «зірку» (або модний нині CLOS), щоб випадання однієї стійки не впливало на інші. Виділити «центральні» стійки, в яких розташовуватиметься мережеве ядро, і куди включатимуться інші стійки. Заодно упорядкувати публічну адресацію, взяти у хостера (або у RIR, якщо є можливість) підсіти, яку самостійно (або через хостера) анонсувати у світ.
Чи може все це зробити «звичайний» сисадмін, який не має глибоких знань у мережах? Не впевнений. Чи робитиме це хостер? Може й буде, але від вас буде потрібно досить детальне ТЗ, яке теж потрібно буде комусь скласти. а потім проконтролювати, що все зроблено правильно.
Приклад 2. Хмарний
Припустимо, у вас є VPC в якійсь публічній хмарі. Щоб отримати доступ з офісу або on-prem частини інфраструктури до локальної мережі всередині VPC, вам потрібно налаштувати з'єднання через IPSec або виділений канал. З одного боку, IPSec дешевше, т.к. не треба купувати додаткове залізо, можна налаштувати тунель між вашим сервером з публічною адресою та хмарою. Але - затримки, обмежена продуктивність (т.к. канал потрібно шифрувати), плюс негарантована зв'язність (т.к. доступ йде через звичайний інтернет).
Що потрібно зробити?
Підняти підключення через виділений канал (наприклад, AWS це називається Direct Connect). Для цього знайти оператора-партнера, який вас підключить, визначитися з найближчою до вас точкою включення (як у оператора, так і оператора в хмару), і, нарешті, все налаштувати. Чи можна це зробити без мережевого інженера? Напевно, так. А ось як це без нього блукати у разі проблем — уже не так зрозуміло.
А ще можуть виникнути проблеми з доступністю між хмарами (якщо у вас є мультиклауд) або проблеми із затримками між різними регіонами і т.д. Безумовно, зараз з'явилося багато інструментів, які підвищують прозорість того, що відбувається в хмарі (той самий Thousand Eyes), але це інструменти мережевого інженера, а не його заміна.
Я міг би ще десяток таких прикладів зі своєї практики накидати, але, гадаю, зрозуміло, що в команді, починаючи з певного рівня розвитку інфраструктури, має бути людина (а краще більше одного), яка знає, як працює мережа, зможе налаштувати мережне обладнання та розібратися в проблемах, якщо вони виникнуть. Повірте, йому буде чим зайнятися
Що повинен знати сітовик?
Зовсім не обов'язково (і навіть іноді шкідливо), мережному інженеру займатися тільки мережею і більше нічим. Навіть якщо не розглядати варіант з інфраструктурою, яка майже повністю живе в публічній хмарі (а вона, як не крути, стає все популярнішою та популярнішою), і взяти, наприклад, on premise або приватні хмари, де на одних лише «знаннях на рівні CCNP » не виїдеш.
Крім, власне, мереж — хоча тут просто безмежне поле для вивчення, навіть якщо концентруватися лише на якомусь одному напрямку (провайдерські мережі, ентерпрайз, датацентри, вайфай…)
Зрозуміло, багато хто з вас зараз згадає про Python та іншу «network automation», але це лише необхідна, але не достатня умова. Щоб мережевий інженер «успішно влився у колектив», він має вміти розмовляти однією мовою і з розробниками, і з колегами адмінами/девопсами. Що це означає?
- вміти не тільки працювати в Linux як користувач, але і адмініструвати його, хоча б на рівні сисадміна-джуна: поставити потрібний софт, перезапустити сервіс, що впав, написати простенький systemd-unit.
- Розуміти (хоча б загалом), як працює мережевий стек у Linux, як влаштована мережа в гіпервізорах та контейнерах (lxc/docker/kubernetes).
- Зрозуміло, вміти працювати з ansible/chef/puppet чи іншою SCM системою.
- Окремим рядком потрібно написати про SDN та мережі для приватних хмар (наприклад, TungstenFabric або OpenvSwitch). Це ще один величезний пласт знань.
Якщо стисло, то я описав типового T-shape спеціаліста (як зараз модно говорити). Начебто нічого нового, проте з досвіду співбесід далеко не всі мережеві інженери можуть похвалитися знаннями хоча б на дві теми зі списку вище. На практиці, відсутність знань «у суміжних областях» дуже ускладнює не лише комунікацію з колегами, а й розуміння вимог, які бізнес висуває до мережі, як до найнижчої рівня інфраструктури проекту. А без цього розуміння стає складніше аргументовано відстоювати свою точку зору та «продавати» її бізнесу.
З іншого боку, та сама звичка «розбиратися в тому, як працює система» дає мережевим дуже хорошу перевагу перед різними «фахівцями широкого профілю», які знають про технології за статтями на Хабре/медіумі та чатикам у телеграмі, але зовсім не уявляють, яких принципах працює той чи інший софт. А знання деяких закономірностей, як відомо, успішно замінює знання багатьох фактів.
Висновки, або просто TL; DR
- Мережевий адміністратор (як і DBA або VoIP-інженер) - це спеціаліст досить вузького профілю (на відміну від сісадмінів/девопсів/SRE), потреба в якому виникає далеко не відразу (і може не виникати довго, насправді). Але якщо виникає, то його навряд чи вдасться замінити експертизою з боку (аутсорс або звичайні адміни широкого профілю, «які ще й за мережею доглядають»). Що трохи сумніше - потреба в таких фахівця мала, і, умовно, у компанії на 800 програмістів і 30 девопсов / адмінів може бути всього два мережевики, які чудово справляються зі своїми обов'язками. Тобто. ринок був і є дуже і дуже невеликий, а так, щоб з гарною зарплатою — і менше.
- З іншого боку, хороша мережевика в сучасному світі повинна знати не тільки, власне, мережі (і як автоматизувати їх налаштування), але і як з ними взаємодіють операційні системи та софт, які поверх цих мереж бігають. Без цього буде дуже складно зрозуміти, що просять від тебе колеги та донести (обґрунтовано) свої побажання/вимоги до них.
- There is no cloud, it's just someone else's computer. Потрібно розуміти, що використання публічних/приватних хмар або послуг хостинг-провайдерів «який вам все робить під ключ» не скасовує того, що ваш додаток все ще використовує мережу, і проблеми з нею будуть впливати на роботу вашої програми. Ваш вибір — де розташовуватиметься центр компетенції, який відповідатиме за мережу вашого проекту.
Джерело: habr.com