{"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\/sq\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Inxhinier\u00ebt e rrjetit (nuk) jan\u00eb t\u00eb nevojsh\u00ebm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

N\u00eb momentin e shkrimit t\u00eb k\u00ebtij artikulli, k\u00ebrkimi n\u00eb nj\u00eb nga faqet e pun\u00ebs m\u00eb t\u00eb njohura p\u00ebr shprehjen \"Inxhinier rrjeti\" jepte rreth treqind vende pune n\u00eb t\u00eb gjith\u00eb Rusin\u00eb. P\u00ebr krahasim, k\u00ebrkimi me fraz\u00ebn \"administrator sistemi\" jep gati 2.5 mij\u00eb vende pune, nd\u00ebrsa \"Inxhinier DevOps\" \u2014 gati 800.<\/p>\n

A do t\u00eb thot\u00eb kjo se inxhinier\u00ebt e rrjetit nuk jan\u00eb m\u00eb t\u00eb nevojsh\u00ebm n\u00eb epok\u00ebn e reve, docker-it, kubernetes-it dhe wifi-t publik q\u00eb \u00ebsht\u00eb kudo?
\nLe t\u00eb e zbulojm\u00eb (c)<\/p>\n

\"Inxhinier\u00ebt
\n<\/a><\/noindex>
\nLe ta njohim nj\u00ebri-tjetrin. Emri im \u00ebsht\u00eb Aleksei, dhe un\u00eb jam inxhinier rrjeti. <\/p>\n

Kam m\u00eb shum\u00eb se 10 vjet q\u00eb merrem me rrjetet dhe m\u00eb shum\u00eb se 15 vjet q\u00eb punoj me sisteme t\u00eb ndryshme *nix (kam ndjer\u00eb p\u00ebrvoj\u00ebn me Linux dhe FreeBSD). Kam punuar n\u00eb operator\u00ebt e komunikacionit, n\u00eb kompani t\u00eb m\u00ebdha q\u00eb zakonisht konsiderohen \"nd\u00ebrmarrje\", dhe koh\u00ebt e fundit punoj n\u00eb nj\u00eb fintech \"t\u00eb ri dhe t\u00eb guximsh\u00ebm\", ku re, DevOps, kubernetes dhe fjal\u00eb t\u00eb tjera frik\u00ebsuese q\u00eb do t\u00eb na b\u00ebjn\u00eb mua dhe koleg\u00ebt e mi t\u00eb panevojsh\u00ebm. Diku. Ndoshta.<\/p>\n

p\u00ebrjashtim: \"N\u00eb jet\u00ebn ton\u00eb nuk \u00ebsht\u00eb gjith\u00e7ka, gjithmon\u00eb dhe kudo, por ndonj\u00ebher\u00eb dhe n\u00eb disa vende\" (c) Maksim Dorofejev.<\/p>\n

E gjith\u00eb ajo q\u00eb \u00ebsht\u00eb shkruar m\u00eb sip\u00ebr mund dhe duhet t\u00eb konsiderohet si mendim personal i autorit, q\u00eb nuk pretendon p\u00ebr t\u00eb qen\u00eb e v\u00ebrteta absolute, dhe as p\u00ebr nj\u00eb k\u00ebrkim t\u00eb plot\u00eb. T\u00eb gjitha personazhet jan\u00eb imagjinare, t\u00eb gjitha ngjashm\u00ebrit\u00eb jan\u00eb rast\u00ebsore.<\/p><\/blockquote>\n

Mir\u00eb se vini n\u00eb bot\u00ebn time.<\/p>\n

Ku mund t\u00eb takosh rrjetist\u00eb n\u00eb p\u00ebrgjith\u00ebsi?<\/h3>\n

\n1. Operator\u00eb t\u00eb komunikimit, kompani sh\u00ebrbimi dhe integrator\u00eb t\u00eb tjer\u00eb<\/b>. K\u00ebtu gjith\u00e7ka \u00ebsht\u00eb e thjesht\u00eb: rrjeti p\u00ebr ta \u00ebsht\u00eb biznes. Ata ose e shesin drejtp\u00ebrdrejt lidhjen (operator\u00eb), ose ofrojn\u00eb sh\u00ebrbime p\u00ebr fillimin\/mbajtjen e rrjeteve t\u00eb klient\u00ebve t\u00eb tyre. <\/p>\n

Ka\u00e7 eksperienca k\u00ebtu ka, para \u2014 nuk ka shum\u00eb (n\u00ebse nuk jeni drejtor ose menaxher i suksessh\u00ebm shitjesh). Megjithat\u00eb, n\u00ebse ju p\u00eblqejn\u00eb rrjetet dhe sapo keni filluar, nj\u00eb karrier\u00eb n\u00eb mb\u00ebshtetje tek ndonj\u00eb operator jo shum\u00eb i madh do t\u00eb ishte, edhe tani, pika ideale p\u00ebr t\u00eb nisur (n\u00eb kompanit\u00eb federale gjith\u00e7ka \u00ebsht\u00eb shum\u00eb e standardizuar, dhe ka pak hap\u00ebsir\u00eb p\u00ebr krijimtari). Po ashtu, historit\u00eb p\u00ebr at\u00eb se si mund t\u00eb kalosh nga inxhinier dezhurni n\u00eb nj\u00eb menaxher C-level brenda disa vjet\u00ebsh jan\u00eb gjithashtu t\u00eb mundshme, ndon\u00ebse t\u00eb ralla, p\u00ebr arsye t\u00eb njohura. Ka gjithmon\u00eb nevoj\u00eb p\u00ebr personel, sepse turnoveri ndodh. Kjo \u00ebsht\u00eb e mir\u00eb dhe e keqe nj\u00ebkoh\u00ebsisht \u2014 gjithmon\u00eb ka vende t\u00eb lira, nga ana tjet\u00ebr \u2014 shpesh, ata m\u00eb aktiv\u00eb\/ inteligjent\u00eb ikin mjaft shpejt p\u00ebr p\u00ebrmir\u00ebsim, ose p\u00ebr vende m\u00eb 't\u00eb ngrohta'.<\/p>\n

2. Nj\u00eb 'nd\u00ebrmarrje' e kusht\u00ebzuar<\/b>. Nuk \u00ebsht\u00eb e r\u00ebnd\u00ebsishme n\u00ebse aktiviteti i tij kryesor \u00ebsht\u00eb i lidhur me IT-t\u00eb apo jo. E r\u00ebnd\u00ebsishme \u00ebsht\u00eb q\u00eb ka nj\u00eb departament IT i cili merret me funksionimin e sistemeve t\u00eb brendshme t\u00eb kompanis\u00eb, p\u00ebrfshir\u00eb rrjetet n\u00eb zyrat, kanalet e komunikimit n\u00eb deg\u00eb etj. Funksionet e inxhinierit t\u00eb rrjetit n\u00eb k\u00ebto kompani mund t\u00eb kryhen \u00abn\u00eb m\u00ebnyr\u00eb t\u00eb p\u00ebrbashk\u00ebt\u00bb nga nj\u00eb administrator sistemi (n\u00ebse infrastruktura e rrjetit \u00ebsht\u00eb e vog\u00ebl, ose menaxhohet nga nj\u00eb kontraktues i jasht\u00ebm), nd\u00ebrsa nj\u00eb rrjetar, n\u00ebse e ka, mund t\u00eb mbik\u00ebqyr\u00eb gjithashtu telefonin\u00eb dhe SAN-in (pa dyshim). Pagat ndryshojn\u00eb gjithashtu \u2014 shum\u00eb varen nga margjinaliteti i biznesit, madh\u00ebsia e kompanis\u00eb dhe struktura. Kam punuar me kompani ku Cisco-t ngarkoheshin rregullisht me tonelata dhe me kompani ku rrjeti nd\u00ebrtohej nga plehra, deg\u00eb dhe kashta blu, dhe server\u00ebt nuk refreshoheshin kurr\u00eb (nuk ka nevoj\u00eb t\u00eb thuhet se nuk ishin parashikuar as rezervat). Eksperienca k\u00ebtu \u00ebsht\u00eb shum\u00eb m\u00eb e vog\u00ebl, dhe pothuajse me siguri do t\u00eb jet\u00eb n\u00eb fush\u00ebn e bllokimit t\u00eb fort\u00eb nga shit\u00ebsit, ose \u00absi t\u00eb b\u00ebsh di\u00e7ka nga asgj\u00eb\u00bb. Personalish, m\u00eb dukej jasht\u00ebzakonisht e m\u00ebrzitshme, ndon\u00ebse shum\u00eb u p\u00eblqen \u2014 gjith\u00e7ka \u00ebsht\u00eb mjaft e qet\u00eb dhe e parashikueshme (n\u00ebse flasim p\u00ebr kompani t\u00eb m\u00ebdha), \u00abdoraha-bahato\u00bb etj. Jo m\u00eb pak se nj\u00eb her\u00eb n\u00eb vit ndonj\u00eb shit\u00ebs i madh thot\u00eb se ka krijuar nj\u00eb sistem mega-super-duper, i cili do t\u00eb automatizoj\u00eb gjith\u00e7ka dhe do t\u00eb jet\u00eb e mundur t\u00eb shuhen t\u00eb gjith\u00eb administrator\u00ebt e sistemeve dhe rrjeteve, duke l\u00ebn\u00eb nj\u00eb apo dy p\u00ebr t\u00eb shtypur butonat n\u00eb nj\u00eb nd\u00ebrfaqe t\u00eb bukur. Realiteti \u00ebsht\u00eb se, edhe n\u00ebse abstrahohemi nga kostoja e zgjidhjes, rrjetar\u00ebt nuk do t\u00eb zhduken nga aty. Po, ndoshta, n\u00eb vend t\u00eb konsol\u00ebs do t\u00eb jet\u00eb s\u00ebrish nj\u00eb nd\u00ebrfaqe web (por jo e nj\u00eb pajisjeje t\u00eb caktuar, por e nj\u00eb sistemi t\u00eb madh q\u00eb menaxhon dhjet\u00ebra dhe qindra t\u00eb till\u00eb), por njohurit\u00eb \u00absi \u00ebsht\u00eb gjith\u00e7ka brenda\u00bb do t\u00eb nevojiten gjithsesi.<\/p>\n

3. Kompanit\u00eb e produkteve<\/b>, fitimi i s\u00eb cil\u00ebs vjen nga zhvillimi (dhe, shpesh, operimi) i ndonj\u00eb programi ose platforme \u2014 aty ku gjendet ai produkt. Zakonisht jan\u00eb t\u00eb vogla dhe t\u00eb shpejta, ende larg shkall\u00ebve t\u00eb nd\u00ebrmarrjeve dhe burokracis\u00eb s\u00eb tyre. Pik\u00ebrisht k\u00ebtu \u00ebsht\u00eb vendi ku n\u00eb mas\u00eb t\u00eb madhe operojn\u00eb devops-\u00ebt, kubernetes-at, docker-at dhe fjal\u00ebt e tjera t\u00eb frikshme, q\u00eb patjet\u00ebr do t\u00eb b\u00ebjn\u00eb q\u00eb rrjetet dhe inxhinier\u00ebt e rrjetit t\u00eb duken si nj\u00eb relikt t\u00eb panevojsh\u00ebm. <\/p>\n

Si ndryshon nj\u00eb inxhinier rrjeti nga nj\u00eb administrator sistemi?<\/h3>\n

\nN\u00eb kuptimin e njer\u00ebzve jasht\u00eb IT-s\u00eb \u2014 asgj\u00eb. T\u00eb dy shikojn\u00eb nj\u00eb ekran t\u00eb zi dhe shkruajn\u00eb disa formula magjike, ndonj\u00ebher\u00eb duke shfryr\u00eb n\u00eb heshtje. <\/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

N\u00eb t\u00eb v\u00ebrtet\u00eb, ndryshimi kryesor \u00ebsht\u00eb qasja ndaj pun\u00ebs. Mendoj se pik\u00ebrisht midis inxhinier\u00ebve t\u00eb rrjetit ka m\u00eb shum\u00eb mb\u00ebshtet\u00ebs t\u00eb qasjes \"Funksionon - mos e prek!\". T\u00eb b\u00ebsh di\u00e7ka (brenda nj\u00eb ofruesi) zakonisht mund t\u00eb realizohet vet\u00ebm n\u00eb nj\u00eb m\u00ebnyr\u00eb, e gjith\u00eb konfigurimi i pajisjes \u00ebsht\u00eb k\u00ebtu, n\u00eb p\u00ebll\u00ebmb\u00eb. \u00c7mimi i gabimit \u00ebsht\u00eb i lart\u00eb, dhe ndonj\u00ebher\u00eb shum\u00eb i lart\u00eb (p\u00ebr shembull, mund t\u00eb ndodh\u00eb q\u00eb duhet t\u00eb udh\u00ebtosh disa qindra kilometra p\u00ebr t\u00eb rinisur router-in, nd\u00ebrsa n\u00eb k\u00ebt\u00eb koh\u00eb disa mij\u00ebra njer\u00ebz do t\u00eb mbesin pa lidhje - nj\u00eb situat\u00eb krejt normale p\u00ebr nj\u00eb operator t\u00eb sh\u00ebrbimit t\u00eb komunikimit).<\/p>\n

Mendimi im \u00ebsht\u00eb se pik\u00ebrisht p\u00ebr k\u00ebt\u00eb arsye inxhinier\u00ebt e rrjetit, nga nj\u00ebra an\u00eb, jan\u00eb shum\u00eb t\u00eb motivuar p\u00ebr stabilitetin e rrjetit (dhe ndryshimet jan\u00eb armiku kryesor i stabilitetit), dhe nga ana tjet\u00ebr, njohurit\u00eb e tyre shkojn\u00eb m\u00eb thell\u00eb se sa n\u00eb gjer\u00ebsi (nuk \u00ebsht\u00eb e nevojshme t\u00eb dish t\u00eb konfigurosh dhjet\u00ebra demon\u00eb t\u00eb ndrysh\u00ebm, por duhet t\u00eb njoh\u00ebsh teknologjit\u00eb dhe implementimin e tyre nga nj\u00eb prodhues specifik t\u00eb pajisjeve). Pik\u00ebrisht p\u00ebr k\u00ebt\u00eb arsye, nj\u00eb sistem administrator q\u00eb ka k\u00ebrkuar n\u00eb Google se si t\u00eb konfiguroj\u00eb VLAN-in n\u00eb Cisco - nuk \u00ebsht\u00eb ende nj\u00eb inxhinier i rrjetit. Dhe \u00ebsht\u00eb e v\u00ebshtir\u00eb q\u00eb ai t\u00eb mb\u00ebshtes\u00eb effektivisht (po ashtu si dhe t\u00eb zgjidh\u00eb problemet) nj\u00eb rrjet m\u00eb t\u00eb nd\u00ebrlikuar. <\/p>\n

Por \u00e7far\u00eb do t\u00eb ju nevojitet nj\u00eb rrjet, n\u00ebse keni hostin<\/a>?<\/b><\/p>\n

P\u00ebr nj\u00eb tarif\u00eb t\u00eb vog\u00ebl (dhe n\u00ebse jeni nj\u00eb klient shum\u00eb i madh dhe i dashur \u2014 ndoshta madje edhe falas, \"nga shoq\u00ebria\") inxhinier\u00ebt e qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave do t\u00eb konfiguruan switchet tuaj sipas nevojave tuaja dhe ndoshta do t'ju ndihmojn\u00eb t\u00eb ngrini BGP-n\u00eb me ofruesit (n\u00ebse keni subnetin tuaj adresat ip<\/a> p\u00ebr njoftim).<\/p>\n

Problemi kryesor \u00ebsht\u00eb se data center-i nuk \u00ebsht\u00eb departamenti juaj IT, por nj\u00eb kompani e ve\u00e7ant\u00eb, e cila ka si q\u00ebllim fitimin. Kjo p\u00ebrfshin edhe ju si klient. Data center-i ofron raftet, siguron energjin\u00eb elektrike dhe ftohjen, si dhe ofron nj\u00eb lidhje 'default' me internetin. Bazuar n\u00eb k\u00ebt\u00eb infrastruktur\u00eb, data center-i mund t\u00eb vendos\u00eb pajisjet tuaja (colocation), t\u00eb marr\u00eb me qira nj\u00eb server (dedicated server), ose t\u00eb ofroj\u00eb nj\u00eb sh\u00ebrbim t\u00eb menaxhuar (p.sh., OpenStack ose K8s). Por, biznesi i data center-it (zakonisht) nuk \u00ebsht\u00eb administrimi i infrastruktur\u00ebs s\u00eb klient\u00ebve, sepse ky proces \u00ebsht\u00eb mjaft i pun\u00ebsuar, i v\u00ebshtir\u00eb p\u00ebr t'u automatizuar (dhe n\u00eb nj\u00eb data center normal, gjith\u00e7ka q\u00eb \u00ebsht\u00eb e mundur \u00ebsht\u00eb automatizuar), akoma m\u00eb e v\u00ebshtir\u00eb p\u00ebr t'u standardizuar (\u00e7do klient \u00ebsht\u00eb i ve\u00e7ant\u00eb) dhe n\u00eb p\u00ebrgjith\u00ebsi i rreziksh\u00ebm p\u00ebr pretendime ('e konfiguruat serverin tim, dhe tani ra, ju jeni fajtor\u00ebt!!!111'). Prandaj, n\u00ebse host-i do t\u00eb ndihmoj\u00eb n\u00eb ndonj\u00eb \u00e7\u00ebshtje, ai do t\u00eb p\u00ebrpiqet ta b\u00ebj\u00eb sa m\u00eb t\u00eb leht\u00eb dhe 'standard'. Sepse b\u00ebja e gj\u00ebrave t\u00eb komplikuara \u00ebsht\u00eb e pafavorshme, t\u00eb pakt\u00ebn nga pik\u00ebpamja e kostove t\u00eb pun\u00ebs s\u00eb inxhinier\u00ebve t\u00eb k\u00ebtij host-i (por situatat mund t\u00eb ndryshojn\u00eb, shih p\u00ebrjashtimin). Kjo nuk do t\u00eb thot\u00eb se host-i do t\u00eb b\u00ebj\u00eb gjithmon\u00eb pun\u00eb t\u00eb keqe. Por, nuk \u00ebsht\u00eb aspak e garantuar q\u00eb do t\u00eb b\u00ebj\u00eb pik\u00ebrisht at\u00eb q\u00eb ju nevojitej n\u00eb t\u00eb v\u00ebrtet\u00eb.<\/p>\n

Duket se \u00ebsht\u00eb nj\u00eb gj\u00eb mjaft e dukshme, por un\u00eb kam p\u00ebrjetuar disa her\u00eb n\u00eb praktik\u00ebn time se kompanit\u00eb fillonin t\u00eb mb\u00ebshteteshin te ofruesi i tyre i hostimit pak m\u00eb shum\u00eb sesa duhet, dhe kjo nuk \u00e7onte n\u00eb asgj\u00eb t\u00eb mir\u00eb. Duhej t\u00eb shpjegoja p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb se asnj\u00eb SLA nuk do t\u00eb mbuloj\u00eb humbjet nga ndalja (ka p\u00ebrjashtime, por zakonisht \u00ebsht\u00eb shum\u00eb, SHUM\u00cb e shtrenjt\u00eb p\u00ebr klientin) dhe se ofruesi i hostimit nuk \u00ebsht\u00eb n\u00eb dijeni t\u00eb asaj q\u00eb ndodh n\u00eb infrastruktur\u00ebn e klient\u00ebve (p\u00ebrve\u00e7 t\u00eb dh\u00ebnave shum\u00eb t\u00eb p\u00ebrgjithshme). Dhe ofruesi gjithashtu nuk b\u00ebn backup p\u00ebr ju. M\u00eb keq \u00ebsht\u00eb n\u00ebse keni m\u00eb shum\u00eb se nj\u00eb ofrues hostimi. N\u00eb rast t\u00eb ndonj\u00eb problemi mes tyre, ata me siguri nuk do t\u00eb hetojn\u00eb p\u00ebr ju se \u00e7far\u00eb ka shkuar keq.<\/p>\n

Motivet k\u00ebtu jan\u00eb pik\u00ebrisht t\u00eb nj\u00ebjtat si n\u00eb zgjedhjen e \"ekipit t\u00eb brendsh\u00ebm t\u00eb admin\u00ebve vs outsourcing\". N\u00ebse rreziqet jan\u00eb llogaritur, cil\u00ebsia \u00ebsht\u00eb e pranueshme dhe biznesi nuk ka problem \u2014 pse t\u00eb mos provohet. Nga nj\u00ebra an\u00eb, rrjeti \u00ebsht\u00eb nj\u00eb nga shtresat bazike t\u00eb infrastruktur\u00ebs, dhe nuk ka shum\u00eb kuptim ta dor\u00ebzoni n\u00eb duar t\u00eb njer\u00ebzve t\u00eb jasht\u00ebm, n\u00ebse gjith\u00e7ka tjet\u00ebr e mbani vet\u00eb.<\/p>\n

N\u00eb cilat raste nevojitet nj\u00eb specialist i rrjetit?<\/b><\/p>\n

Tani do t\u00eb flasim p\u00ebr kompanit\u00eb moderne t\u00eb produkteve. Me operator\u00ebt dhe nd\u00ebrmarrjet, gjith\u00e7ka \u00ebsht\u00eb m\u00eb shum\u00eb-m\u00eb pak e qart\u00eb \u2014 aty shum\u00eb gj\u00ebra nuk kan\u00eb ndryshuar n\u00eb vitet e fundit, dhe specialist\u00ebt e rrjetit ishin t\u00eb nevojsh\u00ebm m\u00eb par\u00eb, jan\u00eb t\u00eb nevojsh\u00ebm edhe tani. Por me ato t\u00eb rinjt\u00eb dhe guximtar\u00ebt, gj\u00ebrat nuk jan\u00eb kaq t\u00eb qarta. Shum\u00eb her\u00eb ata vendosin infrastruktur\u00ebn e tyre t\u00ebr\u00ebsisht n\u00eb re, k\u00ebshtu q\u00eb madje as administrator\u00ebt e sistemit nuk i duhen shum\u00eb \u2014 p\u00ebrve\u00e7 administrator\u00ebve t\u00eb atyre vet\u00eb reve, sigurisht. Infrastruktura, nga nj\u00ebra an\u00eb, \u00ebsht\u00eb mjaft e thjesht\u00eb n\u00eb nd\u00ebrtimin e saj, nga ana tjet\u00ebr \u2014 mir\u00eb e automatizuar (ansible\/puppet, terraform, ci\/cd\u2026 e dini). Por madje edhe k\u00ebtu ka situata kur nuk mund t\u00eb shmangni nj\u00eb inxhinier rrjeti.<\/p>\n

Shembulli 1, klasik<\/b><\/p>\n

Supozoni se nj\u00eb kompani fillon me nj\u00eb server me adres\u00eb IP publike q\u00eb ndodhet n\u00eb nj\u00eb qend\u00ebr t\u00eb t\u00eb dh\u00ebnave. M\u00eb pas, server\u00ebt b\u00ebhen dy. Pastaj m\u00eb shum\u00eb... Her\u00ebt apo von\u00eb, shfaqet nevoja p\u00ebr nj\u00eb rrjet privat mes server\u00ebve. Sepse trafiku \"jasht\u00eb\" \u00ebsht\u00eb i kufizuar si p\u00ebr brez (jo m\u00eb shum\u00eb se 100Mbit\/s p\u00ebr shembull), ashtu edhe p\u00ebr sasin\u00eb e t\u00eb dh\u00ebnave t\u00eb shkarkuara\/ndar\u00eb n\u00eb muaj (t\u00eb ndryshme sipas ofruesve t\u00eb sh\u00ebrbimeve, por brezi n\u00eb bot\u00ebn e jashtme, zakonisht, \u00ebsht\u00eb shum\u00eb m\u00eb i shtrenjt\u00eb se nj\u00eb rrjet privat).<\/p>\n

Ofruesi i sh\u00ebrbimit shton karta t\u00eb tjera rrjeti n\u00eb server\u00eb dhe i lidh ato n\u00eb switch-at e tij n\u00eb nj\u00eb VLAN t\u00eb ve\u00e7ant\u00eb. Nd\u00ebrmjet server\u00ebve shfaqet nj\u00eb lokal i \"planizuar\". I p\u00ebrshtatsh\u00ebm!<\/p>\n

Numri i server\u00ebve po rritet, po ashtu edhe trafiku n\u00eb rrjetin privat \u2014 backup-et, replikimet etj. Ofruesi i sh\u00ebrbimit ofron mund\u00ebsin\u00eb p\u00ebr t'ju izoluara n\u00eb switch-e t\u00eb ve\u00e7ant\u00eb, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mos e shqet\u00ebsoni nj\u00ebri-tjetrin. Ofruesi i sh\u00ebrbimit instalon disa switch-e dhe i konfiguron ato \u2014 ndoshta duke l\u00ebn\u00eb nj\u00eb rrjet t\u00eb shesht\u00eb midis t\u00eb gjith\u00eb server\u00ebve tuaj. Gjith\u00e7ka funksionon mir\u00eb, por n\u00eb nj\u00eb moment fillojn\u00eb problemet: her\u00eb pas here ndodhin vonesa midis hosteve, n\u00eb log-e ka ankes\u00eb p\u00ebr nj\u00eb num\u00ebr shum\u00eb t\u00eb madh paketash ARP n\u00eb sekond\u00eb, dhe nj\u00eb p\u00ebntestues, gjat\u00eb auditimit, ka arritur t\u00eb hyj\u00eb n\u00eb t\u00eb gjith\u00eb rrjetin tuaj lokal, duke prishur vet\u00ebm nj\u00eb server.<\/p>\n

\u00c7far\u00eb duhet t\u00eb b\u00ebhet?<\/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

Shembulli 1, vazhdim<\/b><\/p>\n

Server\u00ebt jan\u00eb t\u00eb lidhur n\u00eb lokal me nj\u00eb kabllo t\u00eb vetme. Switch-\u00ebt n\u00eb raftet jan\u00eb t\u00eb lidhur ndryshe, por n\u00eb rast t\u00eb nj\u00eb \u0430\u0432\u0430\u0440ie n\u00eb nj\u00eb raft, tre t\u00eb tjer\u00ebt ndalojn\u00eb gjithashtu. Ekzistojn\u00eb skema, por ka dyshime p\u00ebr aktualitetin e tyre. \u00c7do server ka nj\u00eb adres\u00eb publike, e cila jepet nga hosteri dhe lidhja me raftin. N\u00ebnkupton q\u00eb, kur serveri t\u00eb zhvendoset, duhet t\u00eb ndryshohet adresa.<\/p>\n

\u00c7far\u00eb duhet t\u00eb b\u00ebhet?<\/i><\/p>\n

P\u00ebrdorni LAG (Link Aggregation Group) p\u00ebr t\u00eb lidhur server\u00ebt me dy kabllo n\u00eb switch-at n\u00eb raft (k\u00ebto gjithashtu duhet t\u00eb jen\u00eb t\u00eb rezervuara). Lidhjet mes raft\u00ebve duhet t\u00eb rezervohen dhe t\u00eb ri-rregullohen n\u00eb form\u00ebn e \"yjesh\" (ose CLOS, q\u00eb \u00ebsht\u00eb aktualisht n\u00eb mod\u00eb), q\u00eb humbja e nj\u00eb rafti t\u00eb mos ndikoj\u00eb n\u00eb t\u00eb tjer\u00ebt. Disa raft\u00eb \"qendror\u00eb\" duhet t\u00eb p\u00ebrzgjidhen, ku do t\u00eb vendoset b\u00ebrthama rrjet\u00ebrore dhe ku do t\u00eb lidhen raftet e tjera. Po ashtu, si\u00e7 duhet b\u00ebr\u00eb nj\u00eb renditje e adresave publike, duhet marr\u00eb nga hosteri (ose nga RIR, n\u00ebse \u00ebsht\u00eb e mundur) nj\u00eb subnetwork, e cila do t\u00eb shpallet n\u00eb bot\u00eb vet\u00eb (ose p\u00ebrmes hosterit).<\/p>\n

A mund t\u00eb b\u00ebj\u00eb gjith\u00e7ka nj\u00eb 'administrator i zakonsh\u00ebm' pa njohuri t\u00eb thella n\u00eb rrjet? Nuk jam i sigurt. A do ta b\u00ebj\u00eb kjo kompani hostingu? Mund ta b\u00ebj\u00eb, por do t'ju duhet nj\u00eb specifikim i detajuar, q\u00eb gjithashtu duhet t\u00eb krijohet nga dikush tjet\u00ebr. Pastaj duhet t\u00eb kontrolloni q\u00eb gjith\u00e7ka \u00ebsht\u00eb b\u00ebr\u00eb si\u00e7 duhet.<\/p>\n

Shembulli 2. Reja<\/b><\/p>\n

Supozoni se keni nj\u00eb VPC n\u00eb nj\u00eb nga rethet publike. P\u00ebr t\u00eb kaluar aksesin nga zyra ose nga pjesa on-prem e infrastruktur\u00ebs n\u00eb rrjetin lokal brenda VPC, duhet t\u00eb konfiguroni nj\u00eb lidhje p\u00ebrmes IPSec ose nj\u00eb kanali t\u00eb dedikuar. Nga nj\u00eb an\u00eb \u2014 IPSec \u00ebsht\u00eb m\u00eb i lir\u00eb, pasi nuk nevojitet blerja e pajisjeve t\u00eb tjera; mund t\u00eb krijoni nj\u00eb tunel mes serverit tuaj me adres\u00eb publike dhe re. Por \u2014 ka vonesa, performanc\u00eb t\u00eb kufizuar (pasi kanali duhet t\u00eb kriptohet), gjithashtu lidhshm\u00ebria nuk \u00ebsht\u00eb e garantuar (pasi aksesi b\u00ebhet p\u00ebrmes internetit t\u00eb zakonsh\u00ebm). <\/p>\n

\u00c7far\u00eb duhet t\u00eb b\u00ebhet?<\/i><\/p>\n

Ngrijeni lidhjen p\u00ebrmes nj\u00eb kanali t\u00eb dedikuar (p.sh., p\u00ebr AWS njihet si Direct Connect). P\u00ebr k\u00ebt\u00eb, gjeni nj\u00eb operator partner q\u00eb do t'ju lidhe, p\u00ebrcaktoni pik\u00ebn e lidhjes m\u00eb t\u00eb af\u00ebrt (si te operatori ashtu edhe te operatori n\u00eb cloud), dhe, p\u00ebr m\u00eb n\u00eb fund, konfigurojini t\u00eb gjitha. A \u00ebsht\u00eb e mundur t\u00eb b\u00ebhet kjo pa nj\u00eb inxhinier rrjeti? Sigurisht, po. Por, si do ta zgjidhni ndonj\u00eb problem q\u00eb paraqitet pa t\u00eb, nuk \u00ebsht\u00eb aq e qart\u00eb. <\/p>\n

Gjithashtu, mund t\u00eb ket\u00eb probleme me aksesin midis cloud-eve (n\u00ebse keni multicloud) ose probleme me vonesat midis rajoneve t\u00eb ndryshme etj. Sigurisht, tani ka shum\u00eb mjete q\u00eb rrisin transparenc\u00ebn e asaj q\u00eb po ndodh n\u00eb cloud (po ashtu si dhe Thousand Eyes), por k\u00ebto jan\u00eb mjete t\u00eb inxhinier\u00ebve rrjet, jo z\u00ebvend\u00ebsimi i tyre.<\/p>\n

Mund t\u00eb ofroja edhe dhjet\u00eb t\u00eb till\u00eb si shembuj nga praktika ime, por mendoj se \u00ebsht\u00eb e qart\u00eb se n\u00eb ekip, duke filluar nga nj\u00eb nivel t\u00eb caktuar i zhvillimit t\u00eb infrastruktur\u00ebs, duhet t\u00eb ket\u00eb nj\u00eb person (e preferueshme m\u00eb shum\u00eb se nj\u00eb), i cili di se si funksionon rrjeti, mund t\u00eb konfiguroj\u00eb pajisjet rrjet dhe t\u00eb merret me problemet n\u00ebse ato shfaqen. Besoni, atij do t'i ket\u00eb me \u00e7far\u00eb t\u00eb merret. <\/p>\n

\u00c7far\u00eb duhet t\u00eb dij\u00eb nj\u00eb inxhinier rrjeti?<\/b><\/p>\n

Nuk \u00ebsht\u00eb aspak e nevojshme (dhe madje ndonj\u00ebher\u00eb d\u00ebmton) q\u00eb nj\u00eb inxhinier rrjeti t\u00eb merret vet\u00ebm me rrjetin dhe asgj\u00eb tjet\u00ebr. Edhe n\u00ebse nuk e marrim parasysh opsionin e infrastruktur\u00ebs q\u00eb jeton pothuajse krejt\u00ebsisht n\u00eb re publike (dhe, si\u00e7 e dim\u00eb, po b\u00ebhet gjithnj\u00eb e m\u00eb e njohur), dhe marim, p\u00ebr shembull, re on-premise ose private, njohurit\u00eb vet\u00ebm n\u00eb nivelin CCNP nuk jan\u00eb t\u00eb mjaftueshme. <\/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

Natyrisht, shum\u00eb prej jush tani do t\u00eb kujtojn\u00eb p\u00ebr Python dhe automatik\u00ebn e rrjetit, por kjo \u00ebsht\u00eb vet\u00ebm nj\u00eb kusht i nevojsh\u00ebm, por jo i mjaftuesh\u00ebm. Q\u00eb nj\u00eb inxhinier rrjeti t\u00eb \"inkludhet me sukses n\u00eb ekip\", ai duhet t\u00eb dij\u00eb t\u00eb flas\u00eb n\u00eb t\u00eb nj\u00ebjt\u00ebn gjuh\u00eb me zhvilluesit dhe koleg\u00ebt administrator\u00eb\/devops. \u00c7far\u00eb do t\u00eb thot\u00eb kjo?<\/p>\n