На момант напісання гэтага артыкула пошук на папулярным работным сайце па словазлучэнні "Сеткавы інжынер" выдаваў каля трохсот вакансій па ўсёй Расіі. Для параўнання, пошук па фразе "сістэмны адміністратар" выдае амаль 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 дэвапсаў/адмінаў можа быць усяго два сецявікі, якія выдатна спраўляюцца са сваімі абавязкамі. Г.зн. рынак быў і ёсць вельмі і вельмі невялікі, а так, каб з добрым заробкам - і таго менш.
- З іншага боку, добры сецявік у сучасным свеце павінен ведаць не толькі, уласна, сеткі (і як аўтаматызаваць іх наладу), але і як з імі ўзаемадзейнічаюць аперацыёнкі і софт, якія па-над гэтымі сеткамі бегаюць. Без гэтага будзе вельмі складана зразумець, што просяць ад цябе калегі і данесці (абгрунтавана) свае пажаданні/патрабаванні да іх.
- Там не ёсць cloud, гэта толькі некаторы адзін кампутар. Трэба разумець, што выкарыстанне публічных/прыватных аблокаў або паслуг хостынг-правайдэраў "які вам усё робіць пад ключ" не адмяняе таго, што ваша прыкладанне ўсё яшчэ выкарыстоўвае сетку, і праблемы з ёй будуць уплываць на працу вашага прыкладанне. Ваш выбар - дзе будзе размяшчацца цэнтр кампетэнцыі, які будзе адказваць за сетку вашага праекта.
Крыніца: habr.com