ProHoster > Blogs > Administrācija > Tīklotāji (nav) nepiecieŔami

Tīklotāji (nav) nepiecieŔami

Raksta rakstÄ«Å”anas laikā populārā darba vietnē, meklējot frāzi ā€œTÄ«kla inženierisā€, tika atrasti aptuveni trÄ«s simti vakanču visā Krievijā. SalÄ«dzinājumam, meklējot frāzi ā€œsistēmas administratorsā€, tiek iegÅ«ti gandrÄ«z 2.5 tÅ«kstoÅ”i vakanču, bet ā€œDevOps inženierisā€ - gandrÄ«z 800.

Vai tas nozÄ«mē, ka tÄ«klu veidotāji vairs nav vajadzÄ«gi uzvaroÅ”u mākoņu, Docker, Kubernetes un visuresoÅ”a publiskā Wi-Fi laikā?
Izdomāsim (c)

Tīklotāji (nav) nepiecieŔami

Iepazīsimies. Mani sauc Aleksejs, un es esmu tīkla speciālists.

Esmu bijis iesaistÄ«ts tÄ«klos vairāk nekā 10 gadus un vairāk nekā 15 gadus strādāju ar dažādām *nix sistēmām (man bija iespēja lāpÄ«t gan Linux, gan FreeBSD). Strādāju telekomunikāciju operatoros, lielos uzņēmumos, kas tiek uzskatÄ«ti par ā€œuzņēmumiemā€, un pēdējā laikā strādāju ā€œjaunā un drosmÄ«gāā€ fintech, kur mākoņi, devops, kubernetes un citi biedējoÅ”i vārdi, kas noteikti padarÄ«s mani un manus kolēģus nevajadzÄ«gus. . Kādu dienu. Var bÅ«t.

atruna: ā€œMÅ«su dzÄ«vē ne viss ir vienmēr un visur, bet kaut kas, dažreiz vietāmā€ (c) Maksims Dorofejevs.

Visu zemāk rakstÄ«to var un vajag uzskatÄ«t par autora personÄ«go viedokli, kas nepretendē uz galÄ«go patiesÄ«bu vai pat pilnvērtÄ«gu pētÄ«jumu. Visi varoņi ir izdomāti, visas sakritÄ«bas ir nejauÅ”as.

Laipni lūdzam manā pasaulē.

Kur jūs pat varat satikt tīkla darbiniekus?

1. Telekomunikāciju 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 (operatorus), vai sniedz pakalpojumus savu klientu tÄ«klu palaiÅ”anai/uzturÄ“Å”anai.

Å eit ir liela pieredze, bet nav daudz naudas (ja vien neesat direktors vai veiksmÄ«gs pārdoÅ”anas vadÄ«tājs). Un tomēr, ja jums patÄ«k tÄ«kli un jÅ«s esat tikai sava ceļojuma sākumā, karjera kāda ne pārāk liela operatora atbalstam pat tagad bÅ«s ideāls sākumpunkts (federālajā tÄ«klā viss ir ļoti skripts, un tur ir maz vietas radoÅ”umam). Nu, stāsti par to, kā no dežurējoÅ”a inženiera dažu gadu laikā var izaugt par C lÄ«meņa vadÄ«tāju, arÄ« ir diezgan reāli, kaut arÄ« reti, acÄ«mredzamu iemeslu dēļ. Vienmēr ir vajadzÄ«gi kadri, jo mainÄ«ba notiek. Tas ir gan labi, gan slikti reizē - vienmēr ir brÄ«vas vietas, no otras puses - nereti aktÄ«vākie/gudrākie ātri aizbrauc vai nu uz paaugstinājumu, vai uz citām, ā€œsiltākāmā€ vietām.

2. nosacÄ«ts ā€œuzņēmumsā€. Nav svarÄ«gi, vai viņa pamatdarbÄ«ba ir saistÄ«ta ar IT vai nē. Galvenais, ka tai ir sava IT nodaļa, kas nodroÅ”ina uzņēmuma iekŔējo sistēmu darbÄ«bu, tai skaitā tÄ«klu birojos, sakaru kanālus uz filiālēm u.c. TÄ«kla inženiera funkcijas Ŕādos uzņēmumos ā€œnepilnu slodziā€ var veikt sistēmas administrators (ja tÄ«kla infrastruktÅ«ra ir maza vai to pārvalda ārējs darbuzņēmējs), savukārt tÄ«kla speciālists, ja tāds ir, tajā paŔā laikā rÅ«pēties par telefoniju un SAN (nav labi). Viņi maksā atŔķirÄ«gi ā€“ tas lielā mērā ir atkarÄ«gs no biznesa rentabilitātes, uzņēmuma lieluma un struktÅ«ras. Es strādāju ar uzņēmumiem, kur Cisco sistēmas tika regulāri ā€œielādētas mucāsā€, un ar uzņēmumiem, kur tÄ«kls tika veidots no fekālijām, kociņiem un zilās lentes, un serveri nekad netika atjaunināti (lieki piebilst, ka arÄ« rezerves netika nodroÅ”inātas). Å eit ir daudz mazāk pieredzes, un tā gandrÄ«z noteikti bÅ«s saistÄ«ta ar stingru pārdevēju bloÄ·Ä“Å”anu jeb ā€œkā no nekā kaut ko izgatavotā€. PersonÄ«gi man tas likās mežonÄ«gi garlaicÄ«gi, lai gan daudziem patÄ«k - viss ir diezgan izmērÄ«ts un paredzams (ja mēs runājam par lieliem uzņēmumiem), ā€œdorakha-bahatoā€ utt. Vismaz reizi gadā kāds nozÄ«mÄ«gs pārdevējs saka, ka ir izdomājis vēl vienu mega-super-duper sistēmu, kas tagad visu automatizēs, un visus sistēmas administratorus un tÄ«klu veidotājus var izklÄ«dināt, atstājot pāris pogas, kas jānospiež skaistā interfeisā. Realitāte ir tāda, ka, pat ja mēs ignorēsim risinājuma izmaksas, tÄ«klu veidotāji no turienes nekur nezudÄ«s. Jā, iespējams, konsoles vietā atkal bÅ«s tÄ«mekļa saskarne (bet ne konkrēta aparatÅ«ra, bet liela sistēma, kas pārvalda desmitiem un simtiem Ŕādu aparatÅ«ras vienÄ«bu), taču zināŔanas par to "kā viss darbojas iekŔā" joprojām bÅ«s bÅ«t vajadzÄ«gs.

3. Produktu uzņēmumi, kuras peļņa nāk no kādas programmatÅ«ras vai platformas ā€” tā paÅ”a produkta ā€” izstrādes (un bieži vien arÄ« darbÄ«bas). Parasti tie ir mazi un veikli, viņi joprojām ir tālu no uzņēmumu mēroga un to birokratizācijas. TieÅ”i Å”eit masveidā tiek atrasti tie paÅ”i devopi, kuberi, dokeri un citi briesmÄ«gi vārdi, kas noteikti padarÄ«s tÄ«klu un tÄ«kla inženierus par nevajadzÄ«gu rudimentu.

Kā tÄ«kla lietotājs atŔķiras no sistēmas administratora?

Cilvēku izpratnē ne no IT - nekā. Abi skatās uz melno ekrānu un raksta dažas burvestības, dažreiz klusi lamājas.

Programmētāju izpratnē ā€“ varbÅ«t pēc priekÅ”metu jomas. Sistēmas administratori administrē serverus, tÄ«kla operatori ā€“ slēdžus un marÅ”rutētājus. Dažreiz administrācija ir slikta, un visiem viss sabrÅ«k. Nu, ja kas dÄ«vains, vainÄ«gi arÄ« tÄ«klnieki. Tikai tāpēc, ka izdrāž tevi, tāpēc.

PatiesÄ«bā galvenā atŔķirÄ«ba ir pieeja darbam. Iespējams, tieÅ”i tÄ«kla veidotāju vidÅ« ir visvairāk pieejas ā€œJa tas darbojas, neaiztiec!ā€ atbalstÄ«tāju. Parasti kaut ko var izdarÄ«t (viena pārdevēja ietvaros) tikai vienā veidā; visa kastes konfigurācija ir turpat plaukstā. Kļūdas izmaksas ir augstas un dažreiz ļoti augstas (piemēram, jums bÅ«s jābrauc vairāki simti kilometru, lai pārstartētu marÅ”rutētāju, un Å”ajā laikā vairāki tÅ«kstoÅ”i cilvēku bÅ«s bez saziņas - telekomunikāciju operatoram diezgan izplatÄ«ta situācija) .

Manuprāt, tāpēc tÄ«kla inženieri, no vienas puses, ir ārkārtÄ«gi motivēti tÄ«kla stabilitātei (un pārmaiņas ir galvenais stabilitātes ienaidnieks), un, otrkārt, viņu zināŔanas ir vairāk dziļākas nekā plaÅ”as (jÅ«s to nedarat). jāspēj konfigurēt desmitiem dažādu dēmonu, jāzina tehnoloÄ£ijas un to ievieÅ”ana no konkrēta iekārtu ražotāja). Tāpēc sistēmas administrators, kurÅ” Google meklēja, kā reÄ£istrēt VLAN Cisco sistēmā, vēl nav tÄ«kla lietotājs. Un maz ticams, ka viņŔ spēs efektÄ«vi atbalstÄ«t (kā arÄ« novērst problēmas) vairāk vai mazāk sarežģītā tÄ«klā.

Bet kāpēc jums ir nepiecieÅ”ams tÄ«kla veidotājs, ja jums ir mitinātājs?

Par papildu naudu (un, ja esat ļoti liels un iemīļots klients, varbÅ«t pat bez maksas, ā€œkā draugsā€), datu centra inženieri konfigurēs jÅ«su slēdžus atbilstoÅ”i jÅ«su vajadzÄ«bām un, iespējams, pat palÄ«dzēs izveidot BGP saskarni ar pakalpojumu sniedzējiem. (ja jums ir savs IP adreÅ”u apakÅ”tÄ«kls paziņojumam).

Galvenā problēma ir tā, ka datu centrs nav jÅ«su IT nodaļa, tas ir atseviŔķs uzņēmums, kura mērÄ·is ir gÅ«t peļņu. Tai skaitā uz jÅ«su kā klienta rēķina. Datu centrs nodroÅ”ina plauktus, nodroÅ”ina tos ar elektrÄ«bu un aukstumu, kā arÄ« nodroÅ”ina zināmu "noklusējuma" savienojumu ar internetu. Pamatojoties uz Å”o infrastruktÅ«ru, datu centrs var mitināt jÅ«su aprÄ«kojumu (izvietoÅ”ana), iznomāt jums serveri (speciālais serveris) vai nodroÅ”ināt pārvaldÄ«tu pakalpojumu (piemēram, OpenStack vai K8s). Bet datu centra bizness (parasti) nav klientu infrastruktÅ«ras administrÄ“Å”ana, jo Å”is process ir diezgan darbietilpÄ«gs, vāji automatizēts (un parastā datu centrā viss iespējamais ir automatizēts), vienots vēl sliktāk (katrs klients ir individuāla) un kopumā pilns ar sÅ«dzÄ«bām (ā€œJÅ«s sakāt, ka serveris ir iestatÄ«ts, bet tagad tas ir avarējis, tā ir jÅ«su vaina!!!111ā€). Tāpēc, ja saimnieks jums kaut ko palÄ«dz, viņŔ centÄ«sies to padarÄ«t pēc iespējas vienkārŔāku un ērtāku. Jo darÄ«t to grÅ«ti ir neizdevÄ«gi, vismaz no Ŕī paÅ”a hostera inženieru darbaspēka izmaksu viedokļa (bet situācijas ir dažādas, skat. atruna). Tas nenozÄ«mē, ka saimnieks noteikti visu izdarÄ«s slikti. Bet tas nepavisam nav fakts, ka viņŔ darÄ«s tieÅ”i to, kas jums patieŔām bija vajadzÄ«gs.

Å Ä·iet, ka lieta ir diezgan paÅ”saprotama, taču vairākas reizes savā praksē esmu saskāries ar faktu, ka uzņēmumi sāka paļauties uz savu hostinga pakalpojumu sniedzēju nedaudz vairāk nekā vajadzētu, un tas ne pie kā laba nenoveda. Man nācās gari un detalizēti skaidrot, ka ne viens vien SLA nesegs zaudējumus no dÄ«kstāves (ir izņēmumi, bet parasti tas klientam izmaksā ļoti, Ä»OTI dārgi) un ka hosters nemaz nav informēts par notiekoÅ”o klientu infrastruktÅ«ra (izņemot ļoti vispārÄ«gus rādÄ«tājus). Un mitinātājs arÄ« neveido dublējumus jÅ«su vietā. Situācija ir vēl sliktāka, ja jums ir vairāk nekā viens saimnieks. Ja starp viņiem rodas kādas problēmas, viņi noteikti neuzzinās jÅ«su vietā, kas nogāja greizi.

Faktiski motÄ«vi Å”eit ir tieÅ”i tādi paÅ”i kā izvēloties ā€œiekŔēja administratora komanda pret ārpakalpojumuā€. Ja riski ir aprēķināti, kvalitāte ir apmierinoÅ”a un bizness neiebilst, kāpēc gan nepamēģināt. No otras puses, tÄ«kls ir viens no visvienkārŔākajiem infrastruktÅ«ras slāņiem, un diez vai ir vērts to atstāt sveÅ”iniekiem, ja visu pārējo jau atbalstāt pats.

Kādos gadījumos ir nepiecieŔams tīkla operators?

Tālāk mēs runāsim tieÅ”i par mÅ«sdienu pārtikas uzņēmumiem. Ar operatoriem un uzņēmumu viss ir skaidrs pluss vai mÄ«nuss - pēdējos gados tur maz kas ir mainÄ«jies, un tÄ«klu veidotāji bija vajadzÄ«gi arÄ« agrāk, un tie ir vajadzÄ«gi arÄ« tagad. Bet ar tiem paÅ”iem ā€œjaunajiem un drosmÄ«gajiemā€ lietas nav tik skaidras. Bieži vien viņi visu savu infrastruktÅ«ru izvieto mākoņos, tāpēc viņiem pat Ä«sti nav vajadzÄ«gi administratori ā€” protams, izņemot to paÅ”u mākoņu administratorus. InfrastruktÅ«ra, no vienas puses, ir diezgan vienkārÅ”a savā dizainā, no otras puses, tā ir labi automatizēta (ansible/lelle, terraform, ci/cd... nu, ziniet). Bet pat Å”eit ir situācijas, kad jÅ«s nevarat iztikt bez tÄ«kla inženiera.

1. piemērs, klasika

Pieņemsim, ka uzņēmums sāk ar vienu serveri ar publisku IP adresi, kas atrodas datu centrā. Tad ir divi serveri. Tad vēl... Agri vai vēlu radÄ«sies nepiecieÅ”amÄ«ba pēc privātā tÄ«kla starp serveriem. Tā kā ā€œÄrējoā€ trafiku ierobežo gan joslas platums (piemēram, ne vairāk kā 100 Mbit/s), gan lejupielādēto/augÅ”upielādēto datu apjoms mēnesÄ« (dažādiem mitinātājiem ir atŔķirÄ«gi tarifi, bet joslas platums uz ārpasauli parasti ir daudz dārgāks nekā privātais tÄ«kls).

Hosteris pievieno serveriem papildu tÄ«kla kartes un iekļauj tās savos slēdžos atseviŔķā vlanā. Starp serveriem parādās ā€œplakansā€ lokālais apgabals. Ērti!

Pieaug serveru skaits, pieaug arÄ« trafiks privātajā tÄ«klā - dublējumkopijas, replikācijas utt. Hosters piedāvā jÅ«s pārvietot atseviŔķos slēdžos, lai jÅ«s netraucētu citiem klientiem, un viņi netraucē jums. Hosteris instalē dažus slēdžus un kaut kā tos konfigurē - visticamāk, atstājot vienu plakanu tÄ«klu starp visiem jÅ«su serveriem. Viss darbojas labi, bet noteiktā brÄ«dÄ« sākas problēmas: periodiski palielinās kavÄ“Å”anās starp saimniekiem, žurnāli sÅ«dzas par pārāk daudz arp pakeÅ”u sekundē, un audita laikā pentester izdrāza visu jÅ«su lokālo tÄ«klu, izjaucot tikai vienu serveri.

Ko man darīt?

Sadaliet tÄ«klu segmentos - vlans. Konfigurējiet savu adresi katrā vlan, atlasiet vārteju, kas pārsÅ«tÄ«s trafiku starp tÄ«kliem. Konfigurējiet vārtejā acl, lai ierobežotu piekļuvi starp segmentiem vai pat tuvumā instalējiet atseviŔķu ugunsmÅ«ri.

1. piemērs, turpinājums

Serveri ir savienoti ar LAN ar vienu vadu. Slēdži statÄ«vos ir kaut kā savienoti viens ar otru, bet, ja vienā plauktā notiek avārija, nokrÄ«t vēl trÄ«s blakus esoÅ”ie. Shēmas pastāv, taču pastāv Å”aubas par to atbilstÄ«bu. Katram serverim ir sava publiskā adrese, kuru izsniedz resursdators un kas ir piesaistÄ«ta statÄ«vam. Tie. Pārvietojot serveri, ir jāmaina adrese.

Ko man darīt?

Savienojiet serverus, izmantojot LAG (Link Aggregation Group), ar diviem vadiem ar slēdžiem statÄ«vā (tiem arÄ« jābÅ«t liekiem). Rezervējiet savienojumus starp statÄ«viem un pārveidojiet tos par "zvaigznÄ«ti" (vai tagad modē esoÅ”o CLOS), lai viena statÄ«va zaudÄ“Å”ana neietekmētu pārējos. Atlasiet ā€œcentrālosā€ statÄ«vus, kuros atradÄ«sies tÄ«kla kodols un kur tiks pievienoti citi statÄ«vi. Tajā paŔā laikā sakārtojiet publisko adresāciju, paņemiet no hostera (vai no RIR, ja iespējams) apakÅ”tÄ«klu, kuru jÅ«s pats (vai ar hostera starpniecÄ«bu) paziņojat pasaulei.

Vai to visu var izdarÄ«t ā€œparastsā€ sistēmas administrators, kuram nav dziļu zināŔanu par tÄ«kliem? Neesmu pārliecināts. Vai saimnieks to darÄ«s? VarbÅ«t arÄ« bÅ«s, bet bÅ«s nepiecieÅ”ama diezgan detalizēta tehniskā specifikācija, kas kādam arÄ« bÅ«s jāsastāda. un pēc tam pārbaudiet, vai viss ir izdarÄ«ts pareizi.

2. piemērs: mākonis

Pieņemsim, ka jums ir VPC kādā publiskā mākonÄ«. Lai piekļūtu no biroja vai infrastruktÅ«ras lokālas daļas vietējam tÄ«klam VPC iekÅ”ienē, ir jākonfigurē savienojums, izmantojot IPSec vai speciālu kanālu. No vienas puses, IPSec ir lētāks, jo nav jāiegādājas papildu aparatÅ«ra; varat izveidot tuneli starp serveri ar publisko adresi un mākoni. Bet - kavÄ“Å”anās, ierobežota veiktspēja (jo kanālu vajag Å”ifrēt), plus negarantēta savienojamÄ«ba (jo piekļuve notiek caur parasto internetu).

Ko man darīt?

Izveidojiet savienojumu, izmantojot Ä«paÅ”u kanālu (piemēram, AWS to sauc par tieÅ”o savienojumu). Lai to izdarÄ«tu, atrodiet partnera operatoru, kas jÅ«s savienos, izlemiet par jums tuvāko savienojuma punktu (gan jÅ«s operatoram, gan operatoru ar mākoni) un, visbeidzot, iestatiet visu. Vai to visu var izdarÄ«t bez tÄ«kla inženiera? Noteikti jā. Bet kā problēmu gadÄ«jumā novērst problēmas bez viņa, vairs nav tik skaidrs.

Var bÅ«t arÄ« problēmas ar pieejamÄ«bu starp mākoņiem (ja jums ir multicloud) vai problēmas ar kavÄ“Å”anos starp dažādiem reÄ£ioniem utt. Protams, tagad ir parādÄ«juÅ”ies daudzi rÄ«ki, kas palielina mākonÄ« notiekoŔā caurspÄ«dÄ«gumu (tās paÅ”as Thousand Eyes), taču tie visi ir tÄ«kla inženiera rÄ«ki, nevis viņa aizstājējs.

Es varētu ieskicēt vēl duci Ŕādu piemēru no savas prakses, taču, manuprāt, ir skaidrs, ka komandā, sākot no noteikta infrastruktÅ«ras attÄ«stÄ«bas lÄ«meņa, ir jābÅ«t cilvēkam (vēlams vairāk nekā vienam), kurÅ” zina, kā tÄ«kls darbojas un prot konfigurēt tÄ«kla aprÄ«kojumu un novērst problēmas, ja tās rodas. Tici man, viņam bÅ«s ko darÄ«t

Kas būtu jāzina tīkla speciālistam?

TÄ«kla inženierim nemaz nav nepiecieÅ”ams (un dažreiz pat kaitÄ«gs) nodarboties tikai ar tÄ«klu un neko citu. Pat ja mēs neapsveram iespēju ar infrastruktÅ«ru, kas gandrÄ«z pilnÄ«bā dzÄ«vo publiskajā mākonÄ« (un, lai kā teiktu, tā kļūst arvien populārāka), un ņemam, piemēram, uz telpu vai privātiem mākoņiem, kur uz "CCNP lÄ«meņa zināŔanas vien" "JÅ«s nepametÄ«sit.

Faktiski papildus tÄ«kliem - lai gan ir vienkārÅ”i bezgalÄ«gs studiju lauks, pat ja koncentrējaties tikai uz vienu jomu (pakalpojumu sniedzēju tÄ«kli, uzņēmumi, datu centri, Wi-Fi ...)

Protams, daudzi no jums tagad atcerēsies Python un citu ā€œtÄ«kla automatizācijuā€, taču tas ir tikai nepiecieÅ”ams, bet ne pietiekams nosacÄ«jums. Lai tÄ«kla inženieris varētu ā€œsekmÄ«gi pievienoties komandaiā€, viņam jāspēj runāt vienā valodā gan ar izstrādātājiem, gan citiem administratoriem/izstrādātājiem. Ko tas nozÄ«mē?

  • jāprot ne tikai strādāt Linux kā lietotājs, bet arÄ« to administrēt, vismaz sysadmin-jun lÄ«menÄ«: instalējiet nepiecieÅ”amo programmatÅ«ru, restartējiet neveiksmÄ«gu servisu, uzrakstiet vienkārÅ”u systemd-unit.
  • Izprotiet (vismaz vispārÄ«gi), kā tÄ«kla steks darbojas operētājsistēmā Linux, kā tÄ«kls darbojas hipervizoros un konteineros (lxc / docker / kubernetes).
  • Protams, jāprot strādāt ar ansible/chef/lelle vai citu SCM sistēmu.
  • AtseviŔķa rinda jāraksta par SDN un tÄ«kliem privātajiem mākoņiem (piemēram, TungstenFabric vai OpenvSwitch). Tas ir vēl viens milzÄ«gs zināŔanu slānis.

ÄŖsāk sakot, aprakstÄ«ju tipisku T formas speciālistu (kā tagad modē teikt). Å Ä·iet, ka tas nav nekas jauns, taču, pamatojoties uz interviju pieredzi, ne visi tÄ«kla inženieri var lepoties ar zināŔanām vismaz par divām tēmām no iepriekÅ” minētā saraksta. Praksē zināŔanu trÅ«kums ā€œsaistÄ«tās jomāsā€ ļoti apgrÅ«tina ne tikai komunicēt ar kolēģiem, bet arÄ« izprast prasÄ«bas, ko bizness izvirza tÄ«klam, kā projekta zemākā lÄ«meņa infrastruktÅ«rai. Un bez Ŕīs izpratnes kļūst grÅ«tāk aizstāvēt savu viedokli un ā€œpārdotā€ to biznesam.

No otras puses, tas pats ieradums ā€œsaprast, kā sistēma darbojasā€ sniedz tÄ«kla lietotājiem ļoti labas priekÅ”rocÄ«bas salÄ«dzinājumā ar dažādiem ā€œÄ£enerālistiemā€, kuri zina par tehnoloÄ£ijām no rakstiem par HabrĆ©/medium un tērzētavām vietnē Telegram, bet absolÅ«ti nezina, kā to darÄ«t. pēc kādiem principiem darbojas Ŕī vai cita programmatÅ«ra? Un zināŔanas par noteiktiem modeļiem, kā zināms, veiksmÄ«gi aizstāj zināŔanas par daudziem faktiem.

Secinājumi, vai vienkārŔi TL;DR

  1. TÄ«kla administrators (tāpat kā DBA vai VoIP inženieris) ir diezgan Å”aura profila speciālists (atŔķirÄ«bā no sistēmas administratoriem/devs/SRE), kura nepiecieÅ”amÄ«ba nerodas uzreiz (un patiesÄ«bā var arÄ« neradÄ«ties ilgi) . Bet, ja tas tomēr rodas, to diez vai aizstās ārēja ekspertÄ«ze (ārpakalpojumu sniedzēji vai parastie vispārējas nozÄ«mes administratori, ā€œkas arÄ« rÅ«pējas par tÄ«kluā€). Nedaudz skumjāk ir tas, ka nepiecieÅ”amÄ«ba pēc Ŕādiem speciālistiem ir maza, un nosacÄ«ti uzņēmumā ar 800 programmētājiem un 30 devopiem/administratoriem var bÅ«t tikai divi tÄ«klotāji, kas lieliski pilda savus pienākumus. Tie. tirgus bija un ir ļoti, ļoti mazs, un ar labu algu - vēl mazāk.
  2. No otras puses, labam tÄ«kla lietotājam mÅ«sdienu pasaulē ir jāzina ne tikai paÅ”i tÄ«kli (un to konfigurācijas automatizācija), bet arÄ« tas, kā operētājsistēmas un programmatÅ«ra, kas darbojas uz Å”iem tÄ«kliem, mijiedarbojas ar tiem. Bez tā bÅ«s ārkārtÄ«gi grÅ«ti saprast, ko no jums prasa jÅ«su kolēģi, un (pamatoti) izteikt viņiem savas vēlmes/prasÄ«bas.
  3. Mākoņa nav, tas ir tikai kāda cita dators. Jums ir jāsaprot, ka, izmantojot publiskos/privātos mākoņus vai mitināŔanas pakalpojumu sniedzēja pakalpojumus, "kas visu jÅ«su vietā dara pēc atslēgas principa", nemainās fakts, ka jÅ«su lietojumprogramma joprojām izmanto tÄ«klu, un problēmas ar to ietekmēs jÅ«su pieteikumu. JÅ«su izvēle ir vieta, kur atradÄ«sies kompetences centrs, kas bÅ«s atbildÄ«gs par jÅ«su projekta tÄ«klu.

Avots: www.habr.com

Pievieno komentāru