Raksta sagatavošanas brīdī populārā darba vietnē meklējot pēc frāzes "Tīklošanas inženieris" tika atrastas apmēram trīs simti vakances visā Krievijā. Salīdzinājumam, meklējot pēc frāzes "sistēmu administrators", tiek atrastas gandrīz 2.5 tūkstoši vakances, bet "DevOps inženieris" – gandrīz 800.
Vai tas nozīmē, ka tīklošanas speciālisti vairs nav nepieciešami laikos, kad uzvarējuši mākoņi, Docker, Kubernetes un visur esošais publiskais Wi-Fi?
Apskatīsim šo tēmu (c)
Pazīsimies. Mani sauc Aleksejs, un es esmu tīklošanas speciālists.
Es vairāk nekā 10 gadus nodarbojos ar tīkliem un vairāk nekā 15 gadus strādāju ar dažādām *nix sistēmām (man ir bijusi iespēja pētīt gan Linux, gan FreeBSD). Esmu strādājis sakaru operatoriem, lielās kompānijās, kuras parasti tiek uzskatītas par "uzņēmējdarbību", bet pēdējā laikā strādāju "jaunajā un radikālajā" fintehā, kur mākoņi, devops, kubernetes un citas biedējošas frāzes noteikti padarīs mani un manus kolēģus nevajadzīgus. Kādu dienu. Varbūt.
atzīme: "Mūsu dzīvē nav viss, vienmēr un visur, bet dažas lietas, dažreiz un vietām" (c) Maksims Dorofejevs.
Visu, kas uzrakstīts turpmāk, var un vajag uzskatīt par autora personisko viedokli, kas nepretendē uz patiesību pēdējā instancē, un pat ne uz pilnvērtīgu pētījumu. Visi varoņi ir izdomāti, visas sakritības ir nejaušas.
Laipni lūdzam manā pasaulē.
Kur vispār var sastapt tīklošanas speciālistus?
1. Sakaru operatori, pakalpojumu uzņēmumi un citi integratori. Šeit viss ir vienkārši: tīkls viņiem ir bizness. Viņi vai nu tieši pārdod savienojamību (operatori), vai sniedz pakalpojumus savu klientu tīklu uzsākšanai/apsaimniekošanai.
Šeit ir daudz pieredzes, bet naudas - ne tik daudz (ja vien neesi direktors vai veiksmīgs pārdošanas menedžeris). Un tomēr, ja tev patīk tīkli un esi tikai ceļa sākumā, karjera kāda mazākā operatora atbalsta komandā būs, pat tagad, ideāla vieta, kur uzsākt (federālajās struktūrās viss ir ļoti standartizēts, un radošumam ir maz iespēju). Un stāsti par to, ka no dežūras inženiera var izaugt līdz C-līmeņa vadītājam pāris gadu laikā, arī ir pilnīgi reāli, lai gan tie ir reti, saprotamu iemeslu dēļ. Nepieciešamība pēc darbiniekiem vienmēr ir, jo mainība tomēr notiek. Tas ir gan labi, gan slikti vienlaicīgi - vienmēr ir brīvas darba vietas, bet no otras puses - visaktīvākie/gudrākie diezgan ātri aiziet, vai nu paaugstinājumam, vai uz citiem, siltākiem amatiem.
2. Nosacītais «uzņēmums». Neatkarīgi no tā, vai viņa pamatdarbība saistīta ar IT vai nē. Svarīgākais ir tas, ka viņam ir savs IT nodaļa, kas nodarbojas ar iekšējo sistēmu darbības nodrošināšanu uzņēmumā, tai skaitā biroju tīkla, sakaru kanālu nodrošināšanu filiālēm utt. Tīkla inženiera funkcijas šādās uzņēmumos var pildīt sistēmu administrators (ja tīkla infrastruktūra ir neliela, vai to pārvalda ārējais piegādātājs), bet tīkla speciālists, ja viņš vispār ir, var pieskatīt arī telefoniju un SAN (nu jā, nekas). Algas atšķiras — tas stipri atkarīgs no biznesa maržām, uzņēmuma izmēriem un struktūras. Es esmu strādājis gan ar uzņēmumiem, kur Cisco regulāri “slodzēja bļodas”, gan ar uzņēmumiem, kas tīklu būvēja no ekskrementiem, nūjām un zilās izolācijas lentes, un serverus atjaunināja, apmēram, nekad (jāteic, ka rezerves arī nebija paredzētas). Pieredze šeit ir ievērojami mazāka, un gandrīz noteikti tā būs stingri ierobežota ar vendor-lock, vai “kā no nekas izveidot kaut ko”. Personīgi man tur šķita ļoti garlaicīgi, lai gan daudziem tas patīk — viss ir diezgan mērens un paredzams (ja runājam par lieliem uzņēmumiem), “daraha-bahato” utt. Ne retāk kā reizi gadā kāds lielais piegādātājs paziņo, ka ir izdomājis kārtējo mega-super-duper sistēmu, kas tagad automātizē visu un visus sistēmu administratorus un tīkla speciālistus varēs izsist, atstājot dažus, lai piespiestu pogas skaistā saskarnē. Tomēr reālajā dzīvē pat ja abstraktizējamies no risinājuma izmaksām, tīkla speciālisti no turienes nekur neizbēgs. Jā, iespējams, vietā, lai atkal būtu konzole, būs tīmekļa saskarne (bet vairs ne konkrētas iekārtas, bet lielas sistēmas, kas pārvalda desmitus un simtus šādu iekārtu), tomēr zināšanas “kā viss iekšā iekārtots” tomēr būs nepieciešamas.
3. Produktu uzņēmumi, kuru peļņu gūst, izstrādājot (un bieži arī izmantojot) kādu programmatūru vai platformu — to pašu produktu. Parasti tie ir mazi un aktīvi, tiem vēl tālu līdz uzņēmumu attiecību apjomam un birokrātijai. Tieši šeit masveidā dzīvo tie paši devops, kuberi, dokeri un citi biedējošie vārdi, kas noteikti padarīs tīklu un tīklu inženierus nevajadzīgu rudenī.
Kā tīkla speciālists atšķiras no sistēmu administratora?
Cilvēku izpratnē, kuri nav saistīti ar IT, tas nav nekas. Abi skatās melnajā ekrānā un raksta kaut kādus burvju vārdus, reizēm klusi lādzami.
Programmētāju izpratnē tas ir, iespējams, tikai zināšanas par konkrēto jomu. Sistēmu administratori administrē serverus, tīkla speciālisti administrē slēdžus un maršrutētājus. Dažreiz administrēšana notiek slikti, un visiem viss sabrūk. Nu, ja kaut kas dīvains notiek, tad vainīgi arī tīkla speciālisti. Tāpēc, ka – ja nē, tad kāpēc.
Patiesībā lielākais atšķirības faktors ir pieeja darbam. Iespējams, tieši starp tīkla speciālistiem visvairāk ir piekritēju pieejai "Ja darbojas, netraucē!". Izveidot kaut ko (vienā piegādātājā) parasti var tikai vienā veidā, visa iekārtu konfigurācija ir „uz plaukstas”. Kļūdas cena ir augsta, dažreiz pat ļoti augsta (piemēram, būs jābrauc simtiem kilometrus, lai restartētu maršrutētāju, un šajā laikā bez saziņas būs vairākas tūkstoši cilvēku – pilnīgi parasta situācija sakaru operatoram).
Manuprāt, tieši tāpēc tīkla inženieri no vienas puses ir ārkārtīgi motivēti uz tīkla stabilitāti (bet izmaiņas ir galvenais ienaidnieks stabilitātei), un, no otras puses, viņu zināšanas ir vairāk orientētas uz dziļumu, nevis platumu (nav nepieciešams zināt, kā konfigurēt desmitiem dažādu demonu, bet jāzina tehnoloģijas un to ieviešana konkrētā ražotāja aprīkojumā). Tieši tāpēc sistēmu administrators, kurš gūglē, kā Cisco ierīcē izveidot VLAN, vēl nav tīkla speciālists. Un, visticamāk, viņš nevarēs efektīvi atbalstīt (un arī risināt problēmas) diezgan sarežģītu tīklu.
Bet kāds labums no tīkla speciālista, ja jums ir mitinātājs?
Par papildu naudu (ja jūs esat ļoti liels un mīļš klients – varbūt pat bez maksas, "darbību dēļ") datu centra inženieri pielāgos jūsu slēdžus atbilstoši jūsu vajadzībām, un varbūt pat palīdzēs izveidot BGP savienojumu ar pakalpojumu sniedzējiem (ja jums ir sava apakśtīkla IP adreses paziņojumam).
Galvenā problēma ir tā, ka datu centrs nav jūsu IT nodaļa, tas ir atsevišķa kompānija, kuras mērķis ir gūt peļņu. Arī jūsu, kā klienta, rēķina. Datu centrs nodrošina skapīšus, piegādā tiem elektrību un dzesēšanu, kā arī nodrošina kādu "standarta" savienojamību ar internetu. Pamatojoties uz šo infrastruktūru, datu centrs var izvietot jūsu aprīkojumu (kolokācija), iznomāt jums serveri (dedicated server) vai nodrošināt pārvaldītu pakalpojumu (piemēram, OpenStack vai K8s). Taču datu centra bizness (parasti) nav klientu infrastruktūras administrēšana, jo šis process ir diezgan darbietilpīgs, grūti automatizējams (bet normālā datu centrā ir automatizēts viss, ko vien iespējams), pat vēl grūtāk standartizējams (katrs klients ir individuāls) un vispār ir riskants attiecībā uz sūdzībām ("jūs man serveri noregulējāt, bet tagad tas ir izslēdzies, jūs esat vainīgi!!!111"). Tāpēc, ja hostings jums kaut kur palīdzēs, tad centīsies to darīt pēc iespējas vienkāršāk un "sagatavotāk". Jo grūti darīt — tas nav izdevīgi, vismaz no inženieru darba kostīšanās viedokļa (bet situācijas var būt dažādas, skatiet atrunu). Tas nenozīmē, ka hostings obligāti visu izdarīs slikti. Bet nav garantijas, ka viņš tieši izdarīs to, ko jums patiesībā vajadzēja.
Neraugoties uz to, ka šķiet acīmredzams, es savā praksē vairākkārt esmu saskāries ar to, ka uzņēmumi sāka paļauties uz savu hosting pakalpojumu sniedzēju nedaudz vairāk, nekā vajadzētu, un tas neradīja neko labu. Bija jāpaskaidro, ka neviens SLA segs zaudējumus no dīkstāves (ir izņēmumi, bet parasti tas ir ļoti, ĻOTI dārgi klientam) un ka hostings vispār nav informēts par to, kas notiek pasūtītāju infrastruktūrā (izņemot ļoti vispārējus rādītājus). Un hostings arī neizdara back-upus par jums. Pat sliktāk ir tad, ja jums ir vairāk nekā viens hostings. Kādu problēmu gadījumā starp viņiem, viņi noteikti neizskaidros jūsu vietā, kas tad īsti noticis.
Motīvi šeit ir tādi paši kā izvēloties "savu adminu komandu pret ārpakalpojumu". Ja riski ir aprēķināti, kvalitāte apmierina un uzņēmums ir gatavs — kāpēc gan neizmēģināt. No otras puses, tīkls ir viens no pamata infrastruktūras slāņiem, un retu reizi to derētu uzticēt kādam ārpusē, ja visu pārējo atbalsta paši.
Kad ir nepieciešams tīkla inženieris?
Nākamajā daļā tiks runāts par mūsdienu produktu uzņēmumiem. Ar operatoriem un uzņēmumiem viss ir samērā skaidrs — tur daudz kas nav mainījies pēdējos gados, un tīkla inženieri tur ir bijuši vajadzīgi agrāk, ir vajadzīgi arī tagad. Savukārt ar tādiem "jauniem un uzdrošinātiem" tas nav tik viennozīmīgi. Bieži viņi izvieto visu savu infrastruktūru mākoņos, tādēļ pat īsti admini viņiem nav vajadzīgi — izņemot mākonī esošos administratorus. Infrastruktūra, no vienas puses, ir samērā vienkārša, taču, no otras puses, labi automatizēta (ansible/puppet, terraform, ci/cd… nu, jūs zināt). Pat šeit ir situācijas, kad bez tīkla inženiera neiztikt.
Piemērs 1, klasika
Pieņemsim, ka uzņēmums sāk ar vienu serveri ar publisku IP adresi, kas atrodas datu centrā. Pēc tam serveru kļūst divi. Pēc tam vairāk… Agrāk vai vēlāk rodas nepieciešamība pēc privātā tīkla starp serveriem. Jo "ārējais" trafiks ir ierobežots gan pēc joslas platuma (ne vairāk kā 100 Mbit/s, piemēram), gan pēc mēneša laikā lejupielādētā/augšupielādētā apjoma (dažādām hostinga firmām ir atšķirīgi tarifi, bet joslas platums ārējā pasaulē parasti ir daudz dārgāks nekā privātā tīkla joslas platums).
Hostings pievieno serveriem papildu tīkla kartes un ieslēdz tās savos slēdžos atsevišķā VLAN. Starp serveriem veidojas "plakans" lokālais tīkls. Ērti!
Serveru skaits pieaug, kā arī satiksme privātajā tīklā — rezerves kopijas, replikācijas utml. Hostings piedāvā jūs novietot atsevišķos slēdžos, lai jūs netraucētu citiem klientiem, un viņi netraucētu jums. Hostings uzstāda kādus slēdžus un kaut kā tos konfigurē — visticamāk, atstājot starp visiem jūsu serveriem vienkāršu tīklu. Viss strādā labi, taču noteiktā brīdī sākas problēmas: periodiski pieaug aiztures starp hostiem, žurnālos ir sūdzības par pārmērīgu arp-paketu skaitu sekundē, un pentesters jūsu tīkla audita laikā ir ieguvis piekļuvi jūsu lokālajam tīklam, sabojājot tikai vienu serveri.
Ko darīt?
Sadalīt tīklu segmentos — vlan’os. Konfigurēt katrā vlanā savu adresāciju, norādīt vārteju, kas pārsūtīs satiksmi starp tīkliem. Vārtejā konfigurēt ACL piekļuves ierobežošanai starp segmentiem vai vispār blakus uzstādīt atsevišķu ugunsmūri.
Piemērs 1, turpinājums
Serveri ir pievienoti lokālajam tīklam ar vienu kabeli. Slēdži stendā ir kaut kā savienoti, taču avārijas gadījumā vienā stendā atslēdzas vēl trīs blakus esošie. Shēmas pastāv, bet to aktualitātē ir šaubas. Katram serverim ir sava publiskā adrese, ko piešķir hostings un kas ir piesaistīta stendam. T.i., pārvietojot serveri, adresi jāmaina.
Ko darīt?
Pievienot serverus, izmantojot LAG (Link Aggregation Group), divus kabeļus pie slēdžiem stendā (tos arī nepieciešams rezervēt). Savienojumus starp stendiem rezervēt, pārveidot uz "zvaigzni" (vai mūsdienīgu CLOS), lai viena stenda izslēgšanās neietekmētu citus. Izdalīt "centrālos" stendus, kuros atradīsies tīkla kodols, un kuros tiks pievienoti citi stendi. Pārējais ir ierakstīt publisko adresāciju, ņemt no hostinga (vai no RIR, ja iespējams) apakšnetu, ko paši (vai caur hostingu) anonsēt pasaulē.
Vai visu to var izdarīt „parastais” sistēmu administrators, kuram nav dziļu zināšanu par tīkliem? Neesmu pārliecināts. Vai to darīs hostings? Varbūt, taču jums būs nepieciešama diezgan detalizēta tehniskā specifikācija, kas arī būs jāizstrādā. un pēc tam jāpārbauda, vai viss ir izdarīts pareizi.
Piemērs 2. Mākonis
Pieņemsim, ka jums ir VPC kādā publiskā mākoņdienestā. Lai iegūtu piekļuvi no biroja vai on-prem daļas infrastruktūras vietējai tīklam iekš VPC, jums ir jāizveido savienojums caur IPSec vai veltītu kanālu. No vienas puses — IPSec ir lētāk, jo nav nepieciešams iegādāties papildu aparatūru, var izveidot tuneli starp jūsu serveri ar publisko adresi un mākoņu. Bet — kavēšanās, ierobežota veiktspēja (jo kanāls ir jāšifrē), plus negarantēta savienojamība (jo piekļuve notiek caur parasto internetu).
Ko darīt?
Uzstādīt savienojumu caur veltītu kanālu (piemēram, AWS to sauc par Direct Connect). Lai to izdarītu, jāatrod partneroperators, kurš jūs pieslēgs, jānosaka tuvākā jums pieslēgšanās vieta (gan jums pie operators, gan operatora pie mākoņa), un visbeidzot, viss jānokārto. Vai visu to var izdarīt bez tīkla inženiera? Noteikti, jā. Taču kā to visu novērst problēmu gadījumā jau nav tik skaidrs.
Var rasties arī pieejamības problēmas starp mākoņiem (ja jums ir daudzmākonis) vai kavēšanās problēmas starp dažādiem reģioniem utt. Protams, tagad ir daudz rīku, kas uzlabo redzamību par to, kas notiek mākoņos (piemēram, Thousand Eyes), bet tie visi ir tīkla inženiera rīki, nevis viņa aizstājēji.
Es varētu piedāvāt vēl desmit tādu piemēru no savas prakses, bet domāju, ka ir skaidrs, ka komandā, sasniedzot noteiktu infrastruktūras attīstības līmeni, jābūt cilvēkam (vēlams, vairāk nekā vienam), kuram ir zināšanas par to, kā darbojas tīkls, kas spēj iestatīt tīkla aparatūru un risināt problēmas, ja tās rastos. Ticiet man, viņam būs ko darīt.
Ko būtu jānokārto tīkla inženierim?
Nav nemaz obligāti (un pat dažreiz, kaitīgi), lai tīkla inženieris nodarbotos tikai ar tīklu un neko citu. Pat neņemot vērā variantu ar infrastruktūru, kas gandrīz pilnībā dzīvo publiskā mākoņa vidē (un tas, neraugoties uz visu, kļūst arvien populārāks), ņemsim piemēram on-prem vai privātos mākoņus, kur tikai „zināšanas CCNP līmenī” nav pietiekamas.
Papildus pašiem tīkliem — šeit ir bezgalīgs lauks izpētei, pat ja koncentrējas tikai uz kādu vienu virzienu (piedāvātāju tīkli, uzņēmumu līmenis, datu centri, WiFi…)
Protams, daudzi no jums tagad atcerēsies par Python un citu "tīklu automatizāciju", taču tas ir tikai nepieciešams, bet ne pietiekams nosacījums. Lai tīklošanas inženieris "veiksmīgi iekļautos kolektīvā", viņam jāsprot runāt vienā valodā gan ar izstrādātājiem, gan ar kolēģiem administratoriem/devops. Ko tas nozīmē?
- spēt ne tikai strādāt Linux kā lietotājam, bet arī pārvaldīt to, vismaz līmenī kā junior sistēmas administrators: uzstādīt vajadzīgo programmatūru, restartēt avārijā nonākušo servisu, uzrakstīt vienkāršu systemd-unit.
- Saprast (vismaz vispārīgi), kā darbojas tīkla steks Linux, kā ir izveidota tīkls hipervizoros un konteineros (lxc / docker / kubernetes).
- Protams, jāspēj strādāt ar ansible/chef/puppet vai citu SCM sistēmu.
- Atsevišķi jāpievērš uzmanība SDN un tīkliem privātajām mākoņiem (piemēram, TungstenFabric vai OpenvSwitch). Tas ir vēl viens milzīgs zināšanu slānis.
Ja īsi, esmu aprakstījis tipisku T-shape speciālistu (kā šobrīd ir modē teikt). It kā nekas jauns, tomēr pēc interviju pieredzes tālu ne visi tīklu inženieri var lepoties ar zināšanām vismaz divās no iepriekš minētajām tēmām. Praksē, zināšanu trūkums "blakus jomās" ļoti apgrūtina ne tikai komunikāciju ar kolēģiem, bet arī izpratni par prasībām, kuras bizness uzliek tīklam kā pašai zemākajai infrastruktūrai projektā. Bez šīs izpratnes kļūst grūtāk pamatoti pamatot savu viedokli un "pārdot" to biznesam.
No otras puses, šī tieksme "izprast, kā darbojas sistēma" sniedz tīkla speciālistiem ļoti labu priekšrocību pār dažādiem "plaša profila speciālistiem", kuri zina par tehnoloģijām pēc rakstiem Habrē/Medium un čatiem Telegramā, bet pilnīgi nesaprot, uz kādiem principiem darbojas tas vai cits softs. Un zināšanas par dažām likumsakarībām, kā zināms, veiksmīgi aizvieto daudzu faktu zināšanas.
Secinājumi, vai vienkārši TL;DR
- Tīkla administrators (tāpat kā DBA vai VoIP inženieris) ir diezgan šaura profila speciālists (atsevišķi no sistēmu administratoriem/devops/mākoņinženieriem), kura nepieciešamība rodas nevis uzreiz (un patiesībā to var ilgi nejust), taču, kad tā rodas, to ir grūti aizstāt ar ārēju ekspertīzi (outsourcing vai parastajiem plaša profila adminiem, «kuri arī uzlūko tīklu»). Vēl jo skumjāk ir tas, ka šādu speciālistu nepieciešamība ir maza, un, piemēram, uzņēmumā ar 800 programmētājiem un 30 devops/adminiem var būt tikai divi tīkla speciālisti, kuri labi tiek galā ar saviem pienākumiem. Tas nozīmē, ka tirgus ir bijis un paliek ļoti neliels, bet vēl jo mazāk ir iespējas ar labu algu.
- No otras puses, labam tīkla speciālistam mūsdienu pasaulē ir jāzina ne tikai paši tīkli (kā automatizēt to iestatīšanu), bet arī tas, kā ar tiem sadarbojas operētājsistēmas un programmatūra, kas skraida pa šiem tīkliem. Bez šī būs ekstremāli grūti saprast, ko kolēģi no tevis prasa, un pamatoti nodot savas vēlmes/prasības viņiem.
- Nav mākoņa, tas ir tikai kāda cita dators. Jāizprot, ka publisko/privāto mākoņu izmantošana vai hosting pakalpojumu sniedzēju, «kurš visu izdara jūsu vietā», pakalpojumi nenozīmē, ka jūsu lietotne joprojām neizmanto tīklu, un problēmas ar to ietekmēs jūsu lietotnes darbību. Jūsu izvēle ir, kur tiks organizēts kompetenču centrs, kas būs atbildīgs par jūsu projekta tīklu.
Avots: habr.com
