{"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\/hr\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Mre\u017eni stru\u010dnjaci (ne) su potrebni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

U trenutku pisanja ovog \u010dlanka, pretraga na popularnoj web stranici za poslove za izraz \"Mre\u017eni in\u017eenjer\" davala je oko tri stotine oglasa za posao \u0161irom Rusije. U usporedbi, pretraga za izraz \"sistemski administrator\" daje gotovo 2.5 tisu\u0107a oglasa, dok \"DevOps in\u017eenjer\" ima gotovo 800.<\/p>\n

Zna\u010di li to da mre\u017eni in\u017eenjeri vi\u0161e nisu potrebni u eri osvojene obrade u oblaku, Dockera, Kubernetesa i svuda prisutnog javnog Wi-Fi-ja?
\nHajde da to istra\u017eimo (c)<\/p>\n

\"Mre\u017eni
\n<\/a><\/noindex>
\nHajde da se upoznamo. Zovem se Aleksej i ja sam mre\u017eni in\u017eenjer. <\/p>\n

Vi\u0161e od 10 godina se bavim mre\u017eama i vi\u0161e od 15 godina radim s razli\u010ditim *nix sustavima (imao sam priliku raditi i s Linuxom i s FreeBSD-om). Radio sam za telekomunikacijske operatere, velike kompanije koje se smatraju \"enterprize\", a posljednjih godina radim u \"mladom i odva\u017enom\" fintechu gdje su oblak, devops, kubernetesi i drugi zastra\u0161uju\u0107i termini koji \u0107e me i moje kolege u\u010diniti suvi\u0161nima. Jednog dana. Mo\u017eda.<\/p>\n

disclaimer: \"U na\u0161em \u017eivotu nije sve, uvijek i svugdje, a ponekad i na mjestima\" (c) Maksim Dorofejev.<\/p>\n

Sve \u0161to je napisano u nastavku mo\u017ee i treba se smatrati osobnim mi\u0161ljenjem autora, koje ne pretendira na istinu u posljednjoj instanci, pa \u010dak ni na potpunu studiju. Svi likovi su izmi\u0161ljeni, sve podudarnosti su slu\u010dajne.<\/p><\/blockquote>\n

Dobrodo\u0161li u moj svijet.<\/p>\n

Gdje se uop\u0107e mogu susresti mre\u017eni in\u017eenjeri?<\/h3>\n

\n1. Telefonski operateri, servisne tvrtke i drugi integratori.<\/b>. Ovdje je sve jednostavno: mre\u017ea za njih je posao. Ili direktno prodaju vezu (operateri), ili pru\u017eaju usluge pokretanja\/odr\u017eavanja mre\u017ea svojih klijenata. <\/p>\n

Ovdje ima puno iskustva, ali novca \u2014 ne ba\u0161 mnogo (ako niste direktor ili uspje\u0161ni menad\u017eer prodaje). Ipak, ako volite mre\u017ee i tek ste na po\u010detku, karijera u podr\u0161ci nekog manje poznatog operatera bit \u0107e, \u010dak i sada, idealna to\u010dka za po\u010detak (u velikim kompanijama sve je prili\u010dno isplanirano, a prostora za kreativnost je malo). Tako\u0111er postoje pri\u010de o tome kako se od de\u017eurnog in\u017eenjera mo\u017ee napredovati do C-level menad\u017eera za nekoliko godina, iako su one rijetke, iz razumljivih razloga. Potra\u017enja za radnicima uvijek postoji, jer fluktuacija kadrova itekako postoji. To je i dobro i lo\u0161e u isto vrijeme \u2014 uvijek ima slobodnih radnih mjesta, s druge strane \u2014 najaktivniji\/najsposobniji obi\u010dno brzo odlaze ili na napredovanje ili u neka, prijatnija, radna okru\u017eenja.<\/p>\n

2. Uvjetni \"enterprise\"<\/b>. Neva\u017eno je je li njegova osnovna djelatnost vezana uz IT ili nije. Va\u017eno je da ima svoj IT odjel koji se bavi radom internih sustava tvrtke, uklju\u010duju\u0107i mre\u017eu u uredima, komunikacijske kanale u podru\u017enicama itd. Funkcije mre\u017enog in\u017eenjera u takvim tvrtkama mo\u017ee \"u zamjeni\" obavljati sistemski administrator (ako je mre\u017ena infrastruktura mala ili njome upravlja vanjski izvo\u0111a\u010d), a mre\u017eni in\u017eenjer, ako ga ima, mo\u017ee istovremeno nadgledati telefoniju i SAN (malo nezgodno). Pla\u0107e su razli\u010dite \u2014 jako ovise o mar\u017ei poslovanja, veli\u010dini tvrtke i strukturi. Radio sam s tvrtkama gdje su ciskici redovito bili \"optere\u0107eni\", i s tvrtkama gdje je mre\u017ea gra\u0111ena od sme\u0107a, \u0161tapova i plave izolir trake, a serveri nikada nisu a\u017eurirani (trebam li re\u0107i da nisu postojale nikakve rezervne opcije). Iskustva ovdje ima znatno manje, a gotovo \u0107e sigurno biti u podru\u010dju tvrdog vendor-locka ili \"kako iz ni\u010dega napraviti ne\u0161to\". Osobno mi se \u010dinilo jako dosadno, iako mnogima to odgovara \u2014 sve je dovoljno mirno i predvidljivo (ako govorimo o velikim tvrtkama), \"dora-ha-bahato\" itd. Ne rje\u0111e nego jednom godi\u0161nje, neki veliki dobavlja\u010d izjavi da je izmislio novu mega-super-puper-sustav koji \u0107e sada automatski sve obaviti, i sve sistemske administratore i mre\u017ene in\u017eenjere \u0107e mo\u0107i otpustiti, ostavljaju\u0107i nekoliko njih za klikove u lijepom su\u010delju. No stvarnost je takva da se, \u010dak i ako apstrahiramo cijenu rje\u0161enja, mre\u017eni in\u017eenjeri odande ne\u0107e maknuti. Da, mo\u017eda \u0107e umjesto konzole opet biti web su\u010delje (ali ne vi\u0161e za konkretnu opremu, ve\u0107 za veliki sustav koji upravlja desecima i stotinama takvih ure\u0111aja), no znanje \"kako sve unutra funkcionira\" i dalje \u0107e biti potrebno.<\/p>\n

3. Proizvodne tvrtke<\/b>, \u010diji je profit rezultat razvoja (i \u010desto, eksploatacije) nekog softvera ili platforme \u2014 tog istog proizvoda. Obi\u010dno su to male i brze tvrtke, jo\u0161 daleko od razmjera korporacija i njihove birokratizacije. Upravo ovdje se masovno nalaze oni dejopsi, kuberi, dokers i druge stra\u0161ne rije\u010di, koje \u0107e sigurno u\u010diniti mre\u017eu i mre\u017ene in\u017eenjere suvi\u0161nim reliktom. <\/p>\n

\u010cime se mre\u017eni in\u017eenjer razlikuje od sistemskog administratora?<\/h3>\n

\nU shvatanju ljudi koji nisu iz IT-a \u2014 ni\u0161ta. I jedan i drugi gledaju u crni ekran i kucaju neka \u010darobna slova, ponekad se tiho psuju\u0107i. <\/p>\n

U o\u010dima programera - to je samo predmetna oblast. Administratori upravljaju serverima, mre\u017eni in\u017eenjeri upravljaju preklopnicima i usmjeriva\u010dima. Ponekad upravljaju lo\u0161e, i svi padnu. Pa u slu\u010daju \u010dudnih problema krivi su opet mre\u017eni in\u017eenjeri. \u010cisto zato, da, to je razlog.<\/p>\n

U stvarnosti, glavna razlika \u2014 pristup radu. Vjerojatno se me\u0111u mre\u017enim administratorima najvi\u0161e mo\u017ee na\u0107i onih koji stoje iza pristupa \u2018Radi \u2014 ne diraj!\u2019. Neki zadatak (unutar jednog dobavlja\u010da) obi\u010dno se mo\u017ee u\u010diniti samo jednim na\u010dinom, a cijela konfiguracija ure\u0111aja \u2014 tu je, na dlanu. Cijena gre\u0161ke je visoka, a ponekad \u010dak i vrlo visoka (na primjer, morat \u0107ete putovati nekoliko stotina kilometara da restartate ruter, dok \u0107e nekoliko tisu\u0107a ljudi biti bez veze \u2014 sasvim uobi\u010dajena situacija za operatere telekomunikacija).<\/p>\n

Po mom mi\u0161ljenju, upravo zato su mre\u017eni in\u017eenjeri, s jedne strane, izuzetno motivirani na stabilnost mre\u017ee (a promjene su najve\u0107i neprijatelj stabilnosti), a s druge strane, njihovo znanje ide vi\u0161e u dubinu nego u \u0161irinu (nije potrebno znati konfigurirati desetine razli\u010ditih demona, potrebno je poznavati tehnologije i njihovu realizaciju kod konkretne opreme). Upravo zbog toga, sistemac koji je na internetu na\u0161ao kako se na Cisco ure\u0111aju postavlja VLAN \u2014 to jo\u0161 uvijek nije mre\u017eni in\u017eenjer. I te\u0161ko da \u0107e mo\u0107i u\u010dinkovito podr\u017eavati (a tako\u0111er i rje\u0161avati probleme) ne\u0161to slo\u017eeniju mre\u017eu. <\/p>\n

Ali za\u0161to je potreban mre\u017eni in\u017eenjer, ako imate hosting<\/a>?<\/b><\/p>\n

Uz dodatnu naknadu (a ako ste jako veliki i omiljeni klijent \u2014 mo\u017eda \u010dak i besplatno, 'iz prijateljstva') in\u017eenjeri data centra \u0107e prilagoditi va\u0161e switcheve prema va\u0161im potrebama, i, mo\u017eda, \u010dak pomo\u0107i podi\u0107i BGP vezu s davateljima usluga (ako imate svoju podmre\u017eu ip-adresa<\/a> za najavu).<\/p>\n

Glavni problem je u tome \u0161to je datacentar \u2013 to nije va\u0161 IT odjel, to je posebna kompanija \u010diji je cilj ostvarivanje profita. Uklju\u010duju\u0107i vas kao klijenta. Datacentar pru\u017ea rackove, osigurava im struju i hladno\u0107u, a tako\u0111er daje neku \"default\" povezanost s internetom. Na temelju te infrastrukture, datacentar mo\u017ee smjestiti va\u0161u opremu (colocation), iznajmiti vam server (dedicated server), ili pru\u017eiti uslugu upravljanja (primjerice, OpenStack ili K8s). No, posao datacentra (obi\u010dno) nije administracija infrastrukture klijenata jer je taj proces prili\u010dno radno intenzivan, slabo se automatizira (dok je u normalnom datacentru automatizirano sve \u0161to je mogu\u0107e), jo\u0161 te\u017ee se standardizira (svaki klijent je jedinstven) i uop\u0107e nosi rizike od pritu\u017ebi (\"ti si mi podesio server, a sad je pao, ti si kriv!!!111\"). Stoga, ako \u0107e vam hoster bilo kako pomo\u0107i, poku\u0161a\u0107e to u\u010diniti \u0161to jednostavnije i \"desetkasto\". Jer raditi slo\u017eeno - nije isplativo, najmanje s gledi\u0161ta tro\u0161kova rada in\u017eenjera tog istog hostera (ali situacije su razli\u010dite, vidi odricanje). To ne zna\u010di da \u0107e hoster sve obaviti lo\u0161e. No, nije uop\u0107e sigurno da \u0107e u\u010diniti ba\u0161 ono \u0161to vam je zapravo bilo potrebno.<\/p>\n

Naizgled, stvar je prili\u010dno o\u010dita, ali nekoliko puta sam se u svojoj praksi sukobio s tim da su kompanije po\u010dele previ\u0161e se oslanjati na svog hosting provajdera, vi\u0161e nego \u0161to bi trebalo, i to nije vodilo do ni\u010dega dobrog. Moralo se dugo i detaljno obja\u0161njavati da nijedan SLA ne pokriva gubitke zbog zastoja (ima iznimaka, ali obi\u010dno je to jako, JAKO skupo za klijenta) i da hoster uop\u0107e nije informiran o tome \u0161to se doga\u0111a u infrastrukturi naru\u010ditelja (osim vrlo op\u0107ih podataka). I backupe hoster tako\u0111er ne radi za vas. Jo\u0161 je gore ukoliko imate vi\u0161e od jednog hostera. U slu\u010daju bilo kakvih problema me\u0111u njima, sigurno se ne\u0107e truditi da otkriju za vas \u0161to je zapravo po\u0161lo po zlu.<\/p>\n

Motivi su ovdje potpuno isti kao i kada se odlu\u010dujete izme\u0111u 'vlastitog tima administratora vs outsourcinga'. Ako su rizici procijenjeni, kvaliteta odgovara, a biznis se sla\u017ee \u2014 za\u0161to ne probati? S druge strane, mre\u017ea je jedan od najosnovnijih slojeva infrastrukture, i te\u0161ko da bi trebalo prepustiti je vanjskim timovima, ako ve\u0107 sve ostalo podr\u017eavate sami.<\/p>\n

Kada vam treba mre\u017eni in\u017eenjer?<\/b><\/p>\n

U nastavku \u0107e se govoriti o modernim proizvodnim kompanijama. O operaterima i enterprise rje\u0161enjima sve je manje vi\u0161e jasno \u2014 tu se nije mnogo promijenilo u posljednjih nekoliko godina, a mre\u017eni in\u017eenjeri su bili potrebni prije, potrebni su i sada. Me\u0111utim, s onim 'mladim i hrabrim' stvar nije tako jednostavna. \u010cesto svoju infrastrukturu koriste u potpunosti u oblaku, tako da im \u010dak i administratori nisu posebno potrebni \u2014 osim za administratore tih istih oblaka, naravno. Infrastruktura je, s jedne strane, prili\u010dno jednostavna za implementaciju, dok je s druge strane dobro automatizirana (ansible\/puppet, terraform, ci\/cd\u2026 znate ve\u0107). No, \u010dak i ovdje postoje situacije kada ne mo\u017eete bez mre\u017enog in\u017eenjera.<\/p>\n

Primjer 1, klasi\u010dni<\/b><\/p>\n

Pretpostavimo da kompanija zapo\u010dinje s jednim serverom s javnom IP adresom koji se nalazi u data centru. Kasnije postaju dva servera. Zatim vi\u0161e\u2026 Rano ili kasno, javlja se potreba za privatnom mre\u017eom izme\u0111u servera. Jer 'spolja\u0161nji' promet je ograni\u010den kako po propusnosti (ne vi\u0161e od 100 Mbit\/s, na primjer), tako i po koli\u010dini preuzimanja\/otpreme mjese\u010dno (razli\u010diti hosteri imaju razli\u010dite tarife, ali vanjska propusnost je obi\u010dno mnogo skuplja od privatne mre\u017ee).<\/p>\n

Hoster dodaje dodatne mre\u017ene kartice u servere i priklju\u010duje ih u svoje switcheve u odvojenom vlan-u. Izme\u0111u servera se pojavljuje 'ravna' lokalna mre\u017ea. Prakti\u010dno!<\/p>\n

Broj servera raste, a promet u privatnoj mre\u017ei tako\u0111er - backupi, replikacije i sli\u010dno. Hosting provider nudi preseljenje u odvojene switcheve kako ne biste ometali druge klijente, a ni oni vas. Hosting provider postavlja odre\u0111ene switcheve i nekako ih konfigurira - najvjerojatnije ostavljaju\u0107i jednu ravnu mre\u017eu izme\u0111u svih va\u0161ih servera. Sve funkcionira dobro, ali u odre\u0111enom trenutku po\u010dinju problemi: povremeno se pove\u0107avaju latencije izme\u0111u hostova, u logovima su pritu\u017ebe na prevelik broj arp paketa u sekundi, a pentester tijekom audita je dobio pristup va\u0161oj lokalnoj mre\u017ei, sru\u0161iv\u0161i samo jedan server.<\/p>\n

\u0160to treba u\u010diniti?<\/i><\/p>\n

Podijeliti mre\u017eu na segmente - VLAN-ove. Postaviti vlastitu adresaciju za svaki VLAN, definirati pristupna ure\u0111aje koji \u0107e preusmjeravati promet izme\u0111u mre\u017ea. Na pristupnom ure\u0111aju postaviti ACL za ograni\u010davanje pristupa izme\u0111u segmenata, ili jednostavno postaviti zasebni vatrozid.<\/p>\n

Primjer 1, nastavak<\/b><\/p>\n

Serveri su povezani s lokalnom mre\u017eom jednim kabelom. Switchevi u ormaru su nekako povezani, ali ako do\u0111e do kvara u jednom ormaru, ispadaju jo\u0161 tri susjedna. Postoje sheme, ali postoji sumnja u njihovu aktualnost. Svakom serveru dodijeljen je javni IP koji dodjeljuje hosting provider i vezan je za ormar. Dakle, prilikom premje\u0161tanja servera, IP adresa se mora mijenjati.<\/p>\n

\u0160to treba u\u010diniti?<\/i><\/p>\n

Povezati servere putem LAG (Link Aggregation Group) s dva kabla na switcheve u ormaru (njih tako\u0111er treba rezervirati). Povezivanja izme\u0111u ormara rezervirati, preoblikovati u \"zvijezdu\" (ili moderni CLOS), kako bi ispad jednog ormara ne utjecao na druge. Izdvojiti \"centralne\" ormare u kojima \u0107e se nalaziti mre\u017eno jezgro i u koje \u0107e se priklju\u010divati drugi ormari. Uz to, urediti javnu adresaciju, dobiti od hosting providera (ili od RIR-a, ako je mogu\u0107e) podmre\u017eu koju \u0107e se samostalno (ili putem hosting providera) najaviti u svijet.<\/p>\n

Mo\u017ee li sve ovo u\u010diniti \"obi\u010dni\" sistem administrator, koji nema duboko znanje o mre\u017eama? Nisam siguran. Ho\u0107e li to u\u010diniti hosting provider? Mo\u017eda ho\u0107e, ali od vas \u0107e biti potrebna prili\u010dno detaljna tehni\u010dka specifikacija, koju tako\u0111er netko treba sastaviti, a zatim provjeriti da li je sve to\u010dno napravljeno.<\/p>\n

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

Pretpostavimo da imate VPC u nekoj javnoj oblaku. Da biste dobili pristup iz ureda ili on-prem dijela infrastrukture do lokalne mre\u017ee unutar VPC-a, potrebno je postaviti vezu putem IPSec-a ili namjenskog kanala. S jedne strane, IPSec je jeftiniji, budu\u0107i da ne morate kupovati dodatni hardver, mo\u017eete postaviti tunel izme\u0111u va\u0161eg poslu\u017eitelja s javnom adresom i oblaka. Me\u0111utim, tu su i ka\u0161njenja, ograni\u010dena propusnost (jer je potrebno \u0161ifrirati vezu), kao i ne garantirana povezanost (jer se pristup odvija putem obi\u010dnog interneta). <\/p>\n

\u0160to treba u\u010diniti?<\/i><\/p>\n

Postaviti vezu putem namjenskog kanala (na primjer, kod AWS-a to se zove Direct Connect). Za to prona\u0107i partnera-operatora koji \u0107e vas povezati, odrediti najbli\u017eu to\u010dku ulaska (bilo vas do operatora, bilo operatora do oblaka) i kona\u010dno sve postaviti. Mo\u017ee li se to u\u010diniti bez mre\u017enog in\u017eenjera? Zasigurno, da. A kako se sve to rje\u0161ava u slu\u010daju problema, to ve\u0107 nije tako jasno. <\/p>\n

Osim toga, mogu se javiti problemi s dostupno\u0161\u0107u izme\u0111u oblaka (ako imate multi-cloud) ili problemi s ka\u0161njenjem izme\u0111u razli\u010ditih regija itd. Bez sumnje, sada postoji mnogo alata koji pove\u0107avaju transparentnost onoga \u0161to se doga\u0111a u oblaku (poput Thousand Eyes), ali to su alati mre\u017enog in\u017eenjera, a ne njegovo zamjena.<\/p>\n

Mogao bih jo\u0161 desetak takvih primjera iz svoje prakse navesti, ali mislim da je jasno da u timu, po\u010dev\u0161i od odre\u0111enog nivoa razvoja infrastrukture, mora postojati osoba (a najbolje vi\u0161e njih) koja zna kako mre\u017ea funkcionira, mo\u017ee postaviti mre\u017enu opremu i rije\u0161iti probleme ako se oni jave. Vjerujte, imat \u0107e \u010dime da se bavi. <\/p>\n

\u0160to bi mre\u017eni in\u017eenjer trebao znati?<\/b><\/p>\n

Nije nu\u017eno (i ponekad \u010dak i \u0161tetno) da se mre\u017eni in\u017eenjer bavi isklju\u010divo mre\u017eom i ni \u010dim drugim. \u010cak i ne uzimaju\u0107i u obzir infrastrukturu koja skoro potpuno \u017eivi u javnom oblaku (koja postaje sve popularnija), ako uzmemo, na primjer, on-premise ili privatne oblake, s \u201eznanjem na razini CCNP-a\u201c ne\u0107ete daleko dogurati. <\/p>\n

Pored samih mre\u017ea - iako ovdje postoji neizmjerno polje za istra\u017eivanje, \u010dak i ako se koncentrirate samo na jedan smjer (mre\u017ee pru\u017eatelja usluga, enterprise, podatkovni centri, Wi-Fi...)<\/p>\n

Naravno, mnogi od vas \u0107e se sada sjetiti Pythona i ostale \u201emre\u017ene automatizacije\u201c, ali to je samo nu\u017ena, ali ne i dovoljna pretpostavka. Da bi se mre\u017eni in\u017eenjer \u201euspje\u0161no uklopio u tim\u201c, mora znati razgovarati istim jezikom s programerima, kolegama administratorima\/devops in\u017eenjerima. \u0160to to zna\u010di?<\/p>\n