{"id":97373,"date":"2020-10-17T14:42:32","date_gmt":"2020-10-17T12:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/seteviki-ne-nuzhny"},"modified":"2020-10-17T14:42:32","modified_gmt":"2020-10-17T12:42:32","slug":"seteviki-ne-nuzhny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Omre\u017eni in\u017eenirji (ne) potrebni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ob trenutku pisanja tehle \u010dlanka je iskanje na priljubljeni spletni strani za zaposlovanje z izrazom \"Omre\u017eni in\u017eenir\" prikazovalo okoli tristo prostih delovnih mest po vsej Rusiji. Za primerjavo, iskanje z izrazom \"sistemski administrator\" prika\u017ee skoraj 2,5 tiso\u010do prostih delovnih mest, medtem ko \"DevOps in\u017eenir\" prika\u017ee skoraj 800.<\/p>\n

Ali to pomeni, da omre\u017eni in\u017eenirji niso ve\u010d potrebni v \u010dasu zmagovalnih oblakov, Dockra, Kubernetesa in vseprisotnega javnega WiFi-ja?
\nPoglejmo bli\u017eje (c)<\/p>\n

\"Omre\u017eni
\n<\/a><\/noindex>
\nNaj se predstavim. Moje ime je Aleksej in sem omre\u017eni in\u017eenir. <\/p>\n

Ve\u010d kot 10 let se ukvarjam z omre\u017eji in ve\u010d kot 15 let delam z razli\u010dnimi *nix sistemi (imel sem prilo\u017enost delati tako z Linuxom kot z FreeBSD). Dela sem v telekomunikacijah, velikih podjetjih, ki veljajo za \"enterprize\", v zadnjem \u010dasu pa delam v \"mladih in drznih\" fintech podjetjih, kjer oblak, DevOps, Kubernetes in druge stra\u0161ne besede, ki nas bodo zagotovo naredile z mene in mojih kolegov nepotrebne. Enkrat. Mogo\u010de.<\/p>\n

opomba: \"V na\u0161em \u017eivljenju ni vse, vedno in povsod, ampak nekaj, ob\u010dasno in na mestih\" (c) Maksim Dorofejev.<\/p>\n

Vse, kar je napisano spodaj, se lahko in mora obravnavati kot osebno mnenje avtorja, ki ne zahteva kon\u010dne resnice, niti ne celovite raziskave. Vsi liki so izmi\u0161ljeni, vsa sovpada so naklju\u010dna.<\/p><\/blockquote>\n

Dobrodo\u0161li v moj svet.<\/p>\n

Kje sploh lahko sre\u010damo omre\u017ene in\u017eenirje?<\/h3>\n

\n1. Telekomunikacijski operaterji, storitvene podjetja in drugi integratorji<\/b>. Tu je vse preprosto: omre\u017eje je zanje poslovanje. Bodisi neposredno prodajajo povezljivost (operaterji), bodisi nudijo storitve pri zagonu\/ vzdr\u017eevanju omre\u017eij svojih strank. <\/p>\n

Izku\u0161enj je tukaj veliko, denarja pa ne prav dosti (razen \u010de niste direktor ali uspe\u0161en prodajni mened\u017eer). Kljub temu, \u010de imate radi omre\u017eja in ste \u0161ele na za\u010detku poti, je kariera v podpori pri kak\u0161nem ne preve\u010d velikem ponudniku \u0161e vedno idealna izhodi\u0161\u010dna to\u010dka (v dr\u017eavnih podjetjih je vse zelo natan\u010dno dolo\u010deno in prostora za ustvarjalnost je malo). Zgodbe o tem, da lahko iz de\u017eurnega in\u017eenirja v nekaj letih napredujete do C-level mened\u017eerja, so tudi povsem realne, \u010deprav redke iz understood razlogov. Potreba po kadrih je vedno prisotna, saj obratna zasedenost res obstaja. To je hkrati dobro in slabo - vedno so prosta delovna mesta, po drugi strani pa pogosto najbolj aktivni\/delovni kmalu odidejo bodisi na vi\u0161je polo\u017eaje bodisi v druge, bolj 'prijetne' oblike zaposlitve.<\/p>\n

2. Pogojski 'enterprise'<\/b>. Ni pomembno je, ali je njegova glavna dejavnost povezana z IT ali ne. Klju\u010dno je, da ima svoj IT oddelek, ki skrbi za delovanje notranjih sistemov podjetja, vklju\u010dno z omre\u017ejem v pisarnah, komunikacijskimi kanali do podru\u017enic itd. Funkcije mre\u017enega in\u017eenirja v tak\u0161nih podjetjih lahko 'povezovalno' opravlja sistemski administrator (\u010de je omre\u017ena infrastruktura majhna ali jo upravlja zunanje podjetje), medtem ko lahko mre\u017eni in\u017eenir, \u010de sploh obstaja, hkrati skrbi tudi za telefonijo in SAN (ne da bi \u0161li preve\u010d v podrobnosti). Pla\u010dila so razli\u010dna \u2014 mo\u010dno so odvisna od mar\u017enosti poslovanja, velikosti podjetja in strukture. Delal sem s podjetji, kjer so redno 'nalo\u017eili vse', in s tistimi, kjer so omre\u017eje gradili iz odpadkov, palic in modre izolirne trake, ter kjer stre\u017eniki nikoli niso bili posodobljeni (morda ni potrebno omenjati, da tudi rezerve niso bile zagotovljene). Izku\u0161enj je tukaj bistveno manj in skoraj zagotovo so v obliki strogega vendor-locka ali 'kako iz ni\u010d narediti nekaj'. Osebno se mi je zdelo tam izjemno dolgo\u010dasno, \u010deprav mnogim ustreza \u2014 vse je dovolj umirjeno in predvidljivo (\u010de govorimo o velikih podjetjih), 'zelo veliko' itd. Vsaj enkrat letno kateri koli veliki dobavitelj trdi, da je izumil novo mega-super-vrhunsko sistem, ki bo popolnoma avtomatiziral vse in vse sistemske administratorje in mre\u017ene in\u017eenirje bomo lahko odpustili, pri \u010demer bo ostalo le nekaj za pritiskanje na gumbe v lepem vmesniku. Realnost pa je tak\u0161na, da se mre\u017eni in\u017eenirji nikamor ne bodo odpravili, tudi \u010de se abstrahiramo od stro\u0161kov re\u0161itve. Da, morda bo namesto konzole ponovno spletni vmesnik (a ne konkretne strojne opreme, temve\u010d velikega sistema, ki upravlja z desetinami in stotinami tak\u0161nih naprav), vendar bodo znanja 'kako je vse notranje urejeno' \u0161e vedno potrebna.<\/p>\n

3. Izdelovalna podjetja<\/b>, katerih dobi\u010dek prina\u0161a razvoj (in pogosto tudi obratovanje) nekega programske opreme ali platforme \u2014 prav tega proizvoda. Obi\u010dajno so majhna in hitra, do podjetij z obse\u017eno birokracijo so \u0161e dale\u010d. Prav tu se masovno pojavljajo tisti devops, kubermetniki, dokerski in druge stra\u0161ne besede, ki bodo nujno naredile omre\u017eje in mre\u017ene in\u017eenirje za nepotreben relikt. <\/p>\n

Kaj razlikuje mre\u017enega in\u017eenirja od sistemskega administratorja?<\/h3>\n

\nV razume ljudi, ki niso iz IT, ni ni\u010d posebnega. Oba, tako programer kot sistemski administrator, gledata v \u010drn ekran in pi\u0161eta nekak\u0161na zaklinjanja, ob\u010dasno tiho prekletujeta. <\/p>\n

\u0412 \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u0432 \u2014 \u0440\u0430\u0437\u0432\u0435 \u0447\u0442\u043e \u043f\u0440\u0435\u0434\u043c\u0435\u0442\u043d\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u044c\u044e. \u0421\u0438\u0441\u0430\u0434\u043c\u0438\u043d\u044b \u0430\u0434\u043c\u0438\u043d\u044f\u0442 \u0441\u0435\u0440\u0432\u0435\u0440\u044b, \u0441\u0435\u0442\u0435\u0432\u0438\u043a\u0438 \u0430\u0434\u043c\u0438\u043d\u044f\u0442 \u043a\u043e\u043c\u043c\u0443\u0442\u0430\u0442\u043e\u0440\u044b \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u044b. \u0418\u043d\u043e\u0433\u0434\u0430 \u0430\u0434\u043c\u0438\u043d\u044f\u0442 \u043f\u043b\u043e\u0445\u043e, \u0438 \u0443 \u0432\u0441\u0435\u0445 \u0432\u0441\u0451 \u043f\u0430\u0434\u0430\u0435\u0442. \u041d\u0443 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0441\u044f\u043a\u043e\u0433\u043e \u0441\u0442\u0440\u0430\u043d\u043d\u043e\u0433\u043e \u0432\u0438\u043d\u043e\u0432\u0430\u0442\u044b \u0442\u043e\u0436\u0435 \u0441\u0435\u0442\u0435\u0432\u0438\u043a\u0438. Just because fuck you, that’s why.<\/p>\n

V resnici je glavna razlika v pristopu k delu. Morda je prav med omre\u017enimi in\u017eenirji najve\u010d simpatizerjev pristopa '\u010ce deluje, ga ne dotikaj!'. Nekaj narediti (v okviru enega ponudnika) obi\u010dajno pomeni, da to lahko stori\u0161 le na en na\u010din, celotna konfiguracija naprave je tu, na dlani. Cena napake je visoka, v\u010dasih pa tudi zelo visoka (na primer, treba bo iti ve\u010d sto kilometrov, da ponovno za\u017eene\u0161 usmerjevalnik, medtem ko bo brez povezave sedelo nekaj tiso\u010d ljudi \u2014 povsem obi\u010dajna situacija za ponudnika telekomunikacij).<\/p>\n

Zato menim, da so omre\u017eni in\u017eenirji z ene strani izjemno motivirani za stabilnost omre\u017eja (spremembe so glavni sovra\u017enik stabilnosti), z druge strani pa so njihova znanja bolj poglobljena kot \u0161iroka (ni potrebno znati konfigurirati desetine razli\u010dnih demonov, potrebno je poznati tehnologije in njihovo izvedbo pri dolo\u010denem proizvajalcu opreme). Zato sistemski administrator, ki je na\u0161el, kako na Ciscu nastaviti VLAN, \u0161e ni omre\u017eni in\u017eenir. In verjetno ne bo mogel u\u010dinkovito podpirati (in tako tudi re\u0161evati te\u017eave) bolj ali manj zapletenega omre\u017eja. <\/p>\n

Ampak zakaj sploh potrebujete omre\u017enega in\u017eenirja, \u010de imate ponudnik gostovanja<\/a>?<\/b><\/p>\n

Za dodatno denar (ali \u010de ste zelo veliki in priljubljen kupec, morda celo brezpla\u010dno, 'po prijateljsko') in\u017eenirji podatkovnega centra nastavijo va\u0161a stikala po va\u0161ih potrebah in morda celo pomagajo vzpostaviti BGP-peering s ponudniki (\u010de imate svojo podmre\u017eo IP naslovov<\/a> za oglas).<\/p>\n

Osnovni problem je to \u0161to je data centar \u2013 to nije va\u0161a IT slu\u017eba, to je zasebna kompanija \u010diji je cilj ostvarivanje profita. Uklju\u010duju\u0107i i putem vas, kao klijenta. Data centar pru\u017ea rackove, obezbe\u0111uje im struju i hladno\u0107u, kao i neku \u201epodrazumevanu\u201c povezanost sa internetom. Na osnovu ove infrastrukture, data centar mo\u017ee smestiti va\u0161u opremu (kolokacija), iznajmljivati vam server (iznajmljeni server), ili pru\u017eiti upravljanu uslugu (na primer, OpenStack ili K8s). Me\u0111utim, poslovanje data centra (obi\u010dno) nije administracija infrastrukture klijenata, jer je taj proces prili\u010dno te\u017eak, slabo se automatizuje (a u normalnom data centru automatizovano je sve \u0161to je mogu\u0107e), jo\u0161 gore se standardizuje (svaki klijent je jedinstven) i uop\u0161te nosi rizike od pritu\u017ebi (\u201enaterali ste me da server konfiguri\u0161em i sada je pao, vi ste krivi!!!111\u201c). Zato, ako vam ponu\u0111a\u010d usluga bude pomagao u ne\u010demu, trudi\u0107e se da to bude \u0161to jednostavnije i \u201euvuljivo\u201c. Jer raditi te\u0161ko \u2013 nije isplativo, barem sa stanovi\u0161ta tro\u0161kova rada in\u017eenjera tog istog ponu\u0111a\u010da usluga (ali situacije su razli\u010dite, vidi odricanje). To ne zna\u010di da ponu\u0111a\u010d usluga obavezno sve radi lo\u0161e. Ali nije ni izvesno da \u0107e uraditi upravo ono \u0161to vam je stvarno potrebno.<\/p>\n

Naizgled, stvar je prili\u010dno o\u010digledna, ali vi\u0161e puta sam se suo\u010dio u praksi sa situacijama kada su kompanije po\u010dele da se oslanjaju na svog hosting provajdera malo vi\u0161e nego \u0161to bi trebalo, \u0161to nikako nije vodilo do dobrih rezultata. Dugo i detaljno sam morao obja\u0161njavati da nijedan SLA ne pokriva gubitke od zastoja (ima izuzetaka, ali obi\u010dno je to veoma, VEOMA skupo za klijenta) i da hosting provajder generalno nije obave\u0161ten o onome \u0161to se de\u0161ava u infrastrukturi naru\u010dioca (osim vrlo op\u0161tih pokazatelja). A backupove hostera oni tako\u0111er ne rade umesto vas. Jo\u0161 gore je kada imate vi\u0161e od jednog hostinga. U slu\u010daju nekih problema izme\u0111u njih, sigurno ne\u0107e razja\u0161njavati za vas \u0161ta je zapravo po\u0161lo po zlu.<\/p>\n

Motivi so v tem primeru pravzaprav enaki kot pri izbiri \"lastna ekipa skrbnikov vs. zunanje podjetje\". \u010ce so tveganja ocenjena, kakovost zadovoljiva in podjetje nima ni\u010d proti temu, zakaj ne bi poskusili. Po drugi strani pa je omre\u017eje eden osnovnih slojev infrastrukture, zato ga verjetno ni smiselno prepustiti zunanjim izvajalcem, \u010de \u017ee samostojno upravljate vse drugo.<\/p>\n

Kdaj potrebujemo omre\u017enega in\u017eenirja?<\/b><\/p>\n

Tukaj se bomo osredoto\u010dili na sodobna podjetja, ki ponujajo izdelke. Z operaterji in podjetji vseh velikosti je vse ve\u010dinoma jasno \u2014 tam se v zadnjih letih ni veliko spremenilo, omre\u017eni in\u017eenirji so bili potrebni v preteklosti, so potrebni tudi sedaj. Se pa s tistimi \"mladimi in drznimi\" zadeva ne zdi tako jasna. Pogosto celotno infrastrukturo postavljajo v oblake, zato sploh ne potrebujejo skrbnikov \u2014 razen skrbnikov teh oblakov, seveda. Infrastruktura je s svojega vidika precej preprosta, hkrati pa dobro avtomatizirana (ansible\/puppet, terraform, ci\/cd... no, verjetno \u017ee veste). Vendar pa obstajajo tudi situacije, ko je brez omre\u017enega in\u017eenirja te\u017eko.<\/p>\n

Primer 1, klasi\u010den<\/b><\/p>\n

Predpostavimo, da podjetje za\u010dne z enim stre\u017enikom s javnim ip naslovom, ki se nahaja v podatkovnem centru. Potem postaneta dva stre\u017enika. Pozneje \u0161e ve\u010d... Rano ali pozno se pojavi potreba po zasebnem omre\u017eju med stre\u017eniki. Ker je \"zunanji\" promet omejen tako po pasovni \u0161irini (na primer ne ve\u010d kot 100 Mbit\/s) kot po koli\u010dini prenesenih podatkov na mesec (razli\u010dni gostitelji imajo razli\u010dne cene, toda pasovna \u0161irina za zunanji promet je obi\u010dajno precej dra\u017eja od zasebnega omre\u017eja).<\/p>\n

Gostitelj dodaja dodatne omre\u017ene kartice v stre\u017enike in jih povezuje s svojimi stikali v lo\u010denem vlan-u. Med stre\u017eniki se ustvari \"plo\u0161\u010data\" lokalna mre\u017ea. Enostavno!<\/p>\n

\u0160tevilo stre\u017enikov se pove\u010duje, prav tako tudi promet v zasebnem omre\u017eju \u2014 varnostne kopije, replikacije itd. Hoster vam ponuja, da se preselite na lo\u010dene stikala, da ne bi motili drugih strank, in da oni ne bi motili vas. Hoster namesti nekatera stikala in jih nekako konfigurira \u2014 verjetno z enim samim ravnim omre\u017ejem med vsemi va\u0161imi stre\u017eniki. Vse deluje dobro, vendar v dolo\u010denem trenutku za\u010dnejo nastajati te\u017eave: ob\u010dasno se pove\u010dajo zamude med gostitelji, v dnevnikih so opozorila o prevelikem \u0161tevilu arp-paketov na sekundo, in pentester vam je pri reviziji prevzel celotno lokalno omre\u017eje, ko je pokvaril le en stre\u017enik.<\/p>\n

Kaj je treba storiti?<\/i><\/p>\n

\u0420\u0430\u0437\u0434\u0435\u043b\u0438\u0442\u044c \u0441\u0435\u0442\u044c \u043d\u0430 \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u044b \u2014 vlan’\u044b. \u041d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0432 \u043a\u0430\u0436\u0434\u043e\u043c \u0432\u043b\u0430\u043d\u0435 \u0441\u0432\u043e\u044e \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u044e, \u0432\u044b\u0434\u0435\u043b\u0438\u0442\u044c \u0448\u043b\u044e\u0437, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u043f\u0435\u0440\u0435\u043a\u0438\u0434\u044b\u0432\u0430\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a \u043c\u0435\u0436\u0434\u0443 \u0441\u0435\u0442\u044f\u043c\u0438. \u041d\u0430 \u0448\u043b\u044e\u0437\u0435 \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c acl \u0434\u043b\u044f \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0430\u043c\u0438, \u043b\u0438\u0431\u043e \u0432\u043e\u043e\u0431\u0449\u0435 \u043f\u043e\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u044f\u0434\u043e\u043c \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0439 \u0444\u0430\u0435\u0440\u0432\u043e\u043b.<\/p>\n

Primer 1, nadaljevanje<\/b><\/p>\n

Stre\u017eniki so povezani v lokalno omre\u017eje z enim kablom. Stikala v omaricah so nekako povezana, vendar ob okvari v eni omarici padejo \u0161e tri sosednje. Diagrame obstajajo, vendar je njihova aktualnost vpra\u0161ljiva. Vsak stre\u017enik ima svojo javno naslov, ki ga dodeli hoster in je povezan z omarico. T.j. ob premiku stre\u017enika je treba naslov spremeniti.<\/p>\n

Kaj je treba storiti?<\/i><\/p>\n

Pove\u017eite stre\u017enike s pomo\u010djo LAG (Link Aggregation Group) z dvema kabloma do stikal v omarici (tudi ta je treba rezervirati). Povezave med omaricami rezervirajte, preoblikujte v 'zvezdo' (ali moderen CLOS), da izpad ene omarice ne vpliva na druge. Dodelite 'centralne' omarice, v katerih bo name\u0161\u010deno omre\u017eno jedro, in kamor se bodo vklju\u010dile druge omarice. Hkrati uredite javno naslovitev, pridobite od hosterja (ali od RIR, \u010de je mogo\u010de) podomre\u017eje, ki ga boste sami (ali preko hosterja) napovedali v svet.<\/p>\n

Ali lahko to stori 'navaden' sistemski administrator, ki nima globokega znanja o omre\u017ejih? Nisem prepri\u010dan. Ali bo to storil hoster? Morda, a od vas bo zahteval precej podrobne tehni\u010dne specifikacije, ki jih bo prav tako treba nekdo sestaviti in nato nadzorovati, da bo vse naredil pravilno.<\/p>\n

Primer 2. Oblak<\/b><\/p>\n

Recimo, da imate VPC v nekem javnem oblaku. Da bi dobili dostop iz pisarne ali on-prem dela infrastrukture do lokalnega omre\u017eja znotraj VPC, morate vzpostaviti povezavo prek IPSec ali namenskega kanala. Po eni strani je IPSec cenej\u0161i, saj ni treba kupovati dodatne opreme, lahko nastavite tunel med va\u0161im stre\u017enikom s javnim naslovom in oblakom. Vendar pa so tukaj zamude, omejena zmogljivost (ker je kanal potrebno \u0161ifrirati), poleg tega pa ni zagotovljene povezljivosti (ker dostop poteka prek obi\u010dajnega interneta). <\/p>\n

Kaj je treba storiti?<\/i><\/p>\n

Vzpostavite povezavo prek namenskega kanala (na primer, pri AWS se to imenuje Direct Connect). Za to najdite partnerskega operaterja, ki vas bo povezoval, dolo\u010dite najbli\u017ejo to\u010dko priklju\u010dka (tako za vas kot za operaterja v oblaku) in kon\u010dno vse nastavite. Ali je to mogo\u010de storiti brez mre\u017enega in\u017eenirja? Zelo verjetno, da. Vendar pa, kako to re\u0161iti brez njega v primeru te\u017eav \u2014 to ni tako jasno. <\/p>\n

Lahko se pojavijo tudi te\u017eave z dostopnostjo med oblakom (\u010de imate multicloud) ali te\u017eave z zamudami med razli\u010dnimi regijami itd. Nedvomno je sedaj na voljo veliko orodij, ki pove\u010dujejo preglednost dogajanja v oblaku (tisto, kar ponuja Thousand Eyes), vendar so to orodja mre\u017enega in\u017eenirja, ne pa njegova zamenjava.<\/p>\n

Lahko bi navedel \u0161e deset tak\u0161nih primerov iz svoje prakse, a mislim, da je jasno, da bi moral biti v ekipi, ko infrastrukturna raven dose\u017ee dolo\u010deno stopnjo razviti, \u010dlovek (\u0161e bolje ve\u010d kot en), ki ve, kako omre\u017eje deluje, lahko nastavi omre\u017eno opremo in re\u0161i te\u017eave, \u010de se pojavijo. Verjemite, da bo imel dovolj dela. <\/p>\n

Kaj mora znati mre\u017eni in\u017eenir?<\/b><\/p>\n

Nije nujno (in celo v\u010dasih \u0161kodljivo), da se mre\u017eni in\u017eenir ukvarja samo z omre\u017ejem in ni\u010d ve\u010d. Tudi \u010de ne upo\u0161tevamo mo\u017enosti infrastrukture, ki skoraj v celoti \u017eivi v javnem oblaku (kar postaja vse bolj priljubljeno), in se osredoto\u010dimo na primer na on-premise ali zasebne oblake, kjer s samimi 'znanji na ravni CCNP' ne bo \u0161lo. <\/p>\n

\u041f\u043e\u043c\u0438\u043c\u043e, \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u0441\u0435\u0442\u0435\u0439 \u2014 \u0445\u043e\u0442\u044f \u0442\u0443\u0442 \u043f\u0440\u043e\u0441\u0442\u043e \u0431\u0435\u0441\u043a\u0440\u0430\u0439\u043d\u0435\u0435 \u043f\u043e\u043b\u0435 \u0434\u043b\u044f \u0438\u0437\u0443\u0447\u0435\u043d\u0438\u044f, \u0434\u0430\u0436\u0435 \u0435\u0441\u043b\u0438 \u043a\u043e\u043d\u0446\u0435\u043d\u0442\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c\u0441\u044f \u0442\u043e\u043b\u044c\u043a\u043e \u043d\u0430 \u043a\u0430\u043a\u043e\u043c-\u0442\u043e \u043e\u0434\u043d\u043e\u043c \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0438 (\u043f\u0440\u043e\u0432\u0430\u0439\u0434\u0435\u0440\u0441\u043a\u0438\u0435 \u0441\u0435\u0442\u0438, \u044d\u043d\u0442\u0435\u0440\u043f\u0440\u0430\u0439\u0437, \u0434\u0430\u0442\u0430\u0446\u0435\u043d\u0442\u0440\u044b, \u0432\u0430\u0439\u0444\u0430\u0439…)<\/p>\n

Seveda, mnogi iz vas se zdaj spomnijo Pythona in druge \"avtomatizacije omre\u017eja\", vendar je to le potrebna, a ne zadostna pogoj. Da se omre\u017eni in\u017eenir \"uspe\u0161no vklopi v skupino\", mora znati komunicirati tako z razvijalci kot s sodelavci administratorji\/devops. Kaj to pomeni?<\/p>\n