PĂ«rshĂ«ndetje tĂ« gjithĂ«ve, quhem Sergej Emeljançik. Jam drejtues i kompanisĂ« Audit-Telecom, zhvilluesi kryesor dhe autori i sistemit Veliam. Vendosa tĂ« shkruaj njĂ« artikull pĂ«r mĂ«nyrĂ«n se si, sĂ« bashku me njĂ« mik, krijuam njĂ« kompani outsourcing, zhvilluam softuer pĂ«r nevojat tona dhe mĂ« pas nisĂ«m ta ofronim pĂ«r tĂ« gjithĂ« tĂ« interesuarit sipas modelit SaaS. Edhe pĂ«r faktin se pĂ«r njĂ« kohĂ« tĂ« gjatĂ« nuk besoja aspak se kjo ishte e mundur. NĂ« kĂ«tĂ« artikull nuk do tĂ« ketĂ« vetĂ«m rrĂ«fim, por edhe hollĂ«si teknike mbi mĂ«nyrĂ«n si u krijua produkti Veliam, pĂ«rfshirĂ« edhe disa pjesĂ« tĂ« kodit burimor. Do tĂ« tregoj çfarĂ« gabimesh bĂ«mĂ« dhe si i korrigjuam mĂ« pas. Kisha dyshime nĂ«se duhej ta publikoja njĂ« artikull tĂ« tillĂ«. Por mendova se Ă«shtĂ« mĂ« mirĂ« ta bĂ«j, tĂ« marr feedback dhe tĂ« pĂ«rmirĂ«sohem, sesa tĂ« mos e publikoj dhe tĂ« mendoj se çfarĂ« do tĂ« kishte ndodhur nĂ«seâŠ
Historia e mëparshme
Punoja në një kompani si specialist IT. Kompania ishte mjaft e madhe dhe kishte një infrastrukturë rrjeti të degëzuar. Nuk do të ndalem te detyrat e mia të punës; do të them vetëm se zhvillimi i çfarëdo zgjidhjeje nuk bënte aspak pjesë në to.
Ne kishim njĂ« sistem monitorimi, por thjesht nga interesi profesional doja tĂ« provoja tĂ« shkruaja njĂ« version timin sa mĂ« tĂ« thjeshtĂ«. Ideja ishte kjo: doja qĂ« gjithçka tĂ« ishte nĂ« web, nĂ« mĂ«nyrĂ« qĂ« tĂ« mund tĂ« hyje lehtĂ« pa instaluar asnjĂ« klient dhe tĂ« shihje se çfarĂ« po ndodhte me rrjetin nga çdo pajisje, pĂ«rfshirĂ« edhe njĂ« pajisje mobile pĂ«rmes Wi-Fi. Gjithashtu, doja shumĂ« qĂ« tĂ« kuptohej shpejt se nĂ« cilĂ«n dhomĂ« ndodhej pajisja qĂ« âkishte problemeâ, sepse kĂ«rkesat pĂ«r kohĂ«n e reagimit ndaj situatave tĂ« tilla ishin mjaft tĂ« rrepta. Si pĂ«rfundim, mĂ« lindi ideja tĂ« krijoja njĂ« faqe tĂ« thjeshtĂ« web, me njĂ« imazh jpeg tĂ« skemĂ«s sĂ« rrjetit si sfond, tĂ« veçoja nĂ« kĂ«tĂ« figurĂ« vetĂ« pajisjet me adresat e tyre IP dhe, mbi figurĂ«, nĂ« koordinatat e duhura, tĂ« shfaqja pĂ«rmbajtje dinamike nĂ« formĂ«n e njĂ« adrese IP tĂ« gjelbĂ«r ose tĂ« kuqe qĂ« pulsonte. Detyra u pĂ«rcaktua, le tĂ« fillojmĂ«.
Më parë jam marrë me programim në Delphi, PHP, JS dhe shumë sipërfaqësisht në C++. E njoh mjaft mirë funksionimin e rrjeteve: VLAN, Routing (OSPF, EIGRP, BGP), NAT. Kaq mjaftonte që të shkruaja vetë një prototip të një sistemi monitorimi primitiv.
E shkrova atë që kisha menduar në PHP. Serveri Apache dhe PHP ishin në Windows, sepse në atë moment Linux për mua ishte diçka e paqartë dhe shumë e ndërlikuar. Më vonë doli se isha gabuar rëndë: në shumë raste Linux është shumë më i thjeshtë se Windows, por kjo është temë më vete dhe të gjithë e dimë sa shumë debat ka rreth saj. Windows Task Scheduler, me një interval të shkurtër (nuk e mbaj mend saktësisht, por diçka si një herë në tre sekonda), thërriste një skript PHP që kontrollonte të gjitha objektet me një ping të thjeshtë dhe ruante gjendjen në një skedar.
system(âping -n 3 -w 100 {$ip_address}â);
Po, po, në atë kohë as puna me databazën nuk ishte diçka që e kisha zotëruar. Nuk e dija se proceset mund të ekzekutoheshin paralelisht dhe kalimi nëpër të gjitha nyjet e rrjetit merrte shumë kohë, sepse gjithçka ndodhte në një rrjedhë të vetme. Problemet bëheshin veçanërisht të dukshme kur disa nyje ishin të padisponueshme, sepse secila prej tyre e mbante të bllokuar skriptin për 300 ms. Në anën e klientit kishte një funksion të thjeshtë në cikël, i cili çdo disa sekonda shkarkonte informacionin e përditësuar nga serveri me një kërkesë Ajax dhe rifreskonte ndërfaqen. Më pas, pas 3 ping-esh të pasuksesshëm radhazi, nëse në kompjuter ishte e hapur faqja e monitorimit, luhej një melodi gazmore.
Kur gjithçka funksionoi, rezultati mĂ« frymĂ«zoi shumĂ« dhe mendova se çfarĂ« tjetĂ«r mund tâi shtoja (brenda njohurive dhe mundĂ«sive tĂ« mia). Por gjithmonĂ« nuk mĂ« kanĂ« pĂ«lqyer sistemet me njĂ« milion grafikĂ«, tĂ« cilĂ«t, siç mendoja atĂ«herĂ« dhe vazhdoj tĂ« mendoj edhe sot, nĂ« shumicĂ«n e rasteve janĂ« tĂ« panevojshĂ«m. Doja tĂ« shtoja vetĂ«m atĂ« qĂ« do tĂ« mĂ« ndihmonte realisht nĂ« punĂ«. Ky parim vazhdon tĂ« mbetet edhe sot themelor nĂ« zhvillimin e Veliam. MĂ« pas kuptova se do tĂ« ishte vĂ«rtet shumĂ« mirĂ« nĂ«se nuk do tĂ« duhej ta mbaja monitorimin gjithmonĂ« hapur pĂ«r tĂ« ditur pĂ«r problemet, por vetĂ«m kur ato tĂ« ndodhnin tĂ« hapja faqen dhe tĂ« shihja ku ndodhej nyja problematike e rrjetit dhe çfarĂ« duhej bĂ«rĂ« mĂ« tej. AtĂ«herĂ« nuk e lexoja email-in, thjesht nuk e pĂ«rdorja. NĂ« internet hasa se ekzistonin gateway pĂ«r SMS, ku mund tĂ« dĂ«rgoje njĂ« kĂ«rkesĂ« GET ose POST dhe ata do tĂ« mĂ« dĂ«rgonin nĂ« telefon njĂ« SMS me tekstin qĂ« do tĂ« shkruaja. E kuptova menjĂ«herĂ« se e doja shumĂ« kĂ«tĂ« mundĂ«si. Dhe fillova tĂ« studioja dokumentacionin. Pas ca kohe ia dola, dhe tani merrja SMS pĂ«r problemet nĂ« rrjet nĂ« celular, me emrin e âobjektit tĂ« rĂ«nĂ«â. Edhe pse sistemi ishte primitiv, ai ishte shkruar nga unĂ« vetĂ«, dhe mĂ« e rĂ«ndĂ«sishmja, ajo qĂ« mĂ« motivonte atĂ«herĂ« pĂ«r ta zhvilluar mĂ« tej ishte fakti qĂ« ishte njĂ« aplikacion praktik, qĂ« mĂ« ndihmonte realisht nĂ« punĂ«.
Dhe erdhi dita kur në punë ra njëri nga kanalet e internetit, ndërsa monitorimi im nuk ma sinjalizoi aspak këtë. Sepse DNS-të e Google vazhdonin ende të përgjigjeshin shumë mirë ndaj ping-ut. Erdhi koha të mendoja se si mund të monitorohej nëse kanali i komunikimit ishte aktiv. Kishte ide të ndryshme se si mund të bëhej kjo. Nuk kisha akses te të gjitha pajisjet. Duhej të gjeja një mënyrë për të kuptuar cili nga kanalet ishte aktiv, pa pasur mundësi ta kontrolloja këtë në çfarëdo mënyre drejtpërdrejt në pajisjet e rrjetit. Atëherë një koleg më hodhi idenë se ndoshta traceroute drejt serverëve publikë mund të ndryshonte në varësi të kanalit përmes të cilit po realizohej dalja në internet. E kontrollova dhe ashtu doli. Kishte rrugëzime të ndryshme gjatë traceroute.
system(âtracert -d -w 500 8.8.8.8â);
KĂ«shtu u shfaq edhe njĂ« skript tjetĂ«r, ose mĂ« saktĂ«, pĂ«r ndonjĂ« arsye traceroute u shtua nĂ« fund tĂ« po atij skripti qĂ« pingonte tĂ« gjitha pajisjet nĂ« rrjet. NĂ« fund tĂ« fundit, ky ishte edhe njĂ« proces tjetĂ«r i gjatĂ«, qĂ« ekzekutohej nĂ« tĂ« njĂ«jtin thread dhe ngadalĂ«sonte punĂ«n e tĂ« gjithĂ« skriptit. Por atĂ«herĂ« kjo nuk ishte aq e qartĂ«. SidoqoftĂ«, ai e bĂ«nte punĂ«n e vet: nĂ« kod ishte pĂ«rcaktuar nĂ« mĂ«nyrĂ« statike se çfarĂ« traceroute duhej tĂ« kishte secili kanal. KĂ«shtu filloi tĂ« funksiononte sistemi, i cili tashmĂ« monitoronte (fjalĂ« e madhe, sepse nuk mblidheshin metrika, por bĂ«hej thjesht ping) pajisjet e rrjetit (routerĂ«, switch-e, WiâFi etj.) dhe kanalet e komunikimit me botĂ«n e jashtme. SMS-tĂ« vinin rregullisht dhe nĂ« skemĂ« dukej gjithmonĂ« qartĂ« se ku ishte problemi.
Më pas, në punën e përditshme duhej të merresha me krosim. Dhe çdo herë që duhej të hyja në switch-et Cisco për të parë se cili interface duhej përdorur, kjo filloi të bëhej e lodhshme. Sa mirë do të ishte të klikoje mbi një objekt në monitorim dhe të shihje listën e interface-ve të tij me përshkrimet përkatëse. Kjo do të më kursente kohë. Për më tepër, në këtë skemë nuk do të ishte nevoja të hapje Putty ose SecureCRT, të fusje kredencialet dhe komandat. Thjesht klikoje në monitorim, shihje atë që të duhej dhe vazhdoje me punën. Fillova të kërkoja si mund të ndërveproja me switch-et. Me sa pashë, menjëherë dolën 2 opsione: SNMP ose të hyja në switch përmes SSH, të ekzekutoja komandat që më duheshin dhe të parsja rezultatin. SNMP e lashë mënjanë për shkak të kompleksitetit të zbatimit, sepse doja të merrja rezultat sa më shpejt. Me SNMP do të duhej të gërmoja gjatë në MIB dhe, mbi bazën e këtyre të dhënave, të formoja informacionin për interface-t. Në CISCO ka një komandë shumë të mirë
show interface statusAjo tregonte pikĂ«risht atĂ« qĂ« mĂ« duhej pĂ«r cross-connect-et. Mendova: pse tĂ« merrem me SNMP, kur unĂ« thjesht dua tĂ« shoh daljen e kĂ«saj komande. Pas pak kohe e realizova kĂ«tĂ« mundĂ«si. NĂ« faqen web klikoja mbi objektin. Aktivizohej njĂ« event, sipas tĂ« cilit klienti i dĂ«rgonte njĂ« kĂ«rkesĂ« serverit me AJAX, ndĂ«rsa serveri lidhej pĂ«rmes SSH me switch-in qĂ« mĂ« duhej (kredencialet ishin tĂ« futura drejtpĂ«rdrejt nĂ« kod; nuk kisha dĂ«shirĂ« ta rafinoja, tĂ« bĂ«ja menu tĂ« veçanta ku mund tĂ« ndryshoheshin llogaritĂ« nga ndĂ«rfaqja â mĂ« duhej rezultati dhe sa mĂ« shpejt), ekzekutonte aty komandĂ«n e sipĂ«rpĂ«rmendur dhe e kthente pĂ«rgjigjen te shfletuesi. KĂ«shtu fillova tĂ« shihja informacionin e interfejseve me njĂ« klikim tĂ« vetĂ«m tĂ« mausit. Ishte jashtĂ«zakonisht e pĂ«rshtatshme, sidomos kur duhej ta kontrolloja kĂ«tĂ« informacion njĂ«kohĂ«sisht nĂ« switch-e tĂ« ndryshĂ«m.
Monitorimi i kanaleve mbi bazën e traceroute-it në fund doli të mos ishte ideja më e mirë, sepse ndonjëherë kryheshin punime në rrjet dhe rruga e traceroute-it mund të ndryshonte, ndërsa monitorimi fillonte të më alarmonte se kishte probleme me kanalin. Por pasi harxhoja shumë kohë me analizë, kuptoja se të gjitha kanalet funksiononin dhe monitorimi im më çorientonte. Në fund, u kërkova kolegëve që menaxhonin switch-et që formonin kanalet të më dërgonin thjesht syslog kur ndryshonte gjendja e dukshmërisë së fqinjëve (neighbor). Kjo, natyrisht, ishte shumë më e thjeshtë, më e shpejtë dhe më e saktë se traceroute-i. Vinte një event i tipit neighbor lost, dhe unë menjëherë dërgoja një njoftim për rënien e kanalit.
Më pas, te daljet me klikim mbi objektin u shtuan edhe disa komanda të tjera dhe u përfshi SNMP për mbledhjen e disa metrikave; në thelb, aty përfundoi gjithçka. Sistemi nuk u zhvillua më tej. Bënte gjithçka që më duhej dhe ishte një mjet i mirë. Shumë lexues ndoshta do të më thonë se për zgjidhjen e këtyre detyrave tashmë kishte plot software në internet. Por në të vërtetë, atëherë nuk gjeta produkte të tilla falas dhe kisha shumë dëshirë të zhvilloja aftësitë e mia në programim; e çfarë mund të të shtyjë më mirë drejt kësaj sesa një detyrë reale praktike. Me kaq përfundoi versioni i parë i monitorimit dhe më pas nuk u modifikua më.
Krijimi i kompanisë Audit-Telekom
Koha kalonte dhe unë nisa të punoja paralelisht edhe për kompani të tjera, për fat të mirë orari i punës ma lejonte këtë. Kur punon në kompani të ndryshme, aftësitë rriten shumë shpejt në fusha të ndryshme dhe të zgjerohet ndjeshëm horizonti profesional. Ka kompani ku, siç thuhet zakonisht, duhet të bësh gjithçka vetë. Nga njëra anë, kjo është e vështirë, por nga ana tjetër, nëse nuk dembelosesh, bëhesh specialist me profil të gjerë dhe kjo të lejon të zgjidhësh detyrat më shpejt dhe më me efikasitet, sepse e kupton si funksionon edhe fusha përkatëse.
Miku im Pavel (gjithashtu IT specialist) përpiqej vazhdimisht të më shtynte drejt biznesit tim. Kishte ide të panumërta me variante të ndryshme për një sipërmarrje personale. Këtë e diskutuam për më shumë se një vit. Dhe në fund dukej se nuk do të çonte askund, sepse unë jam skeptik, ndërsa Pavel është ëndërrimtar. Sa herë që ai propozonte ndonjë ide, unë zakonisht nuk i besoja dhe refuzoja të përfshihesha. Megjithatë, dëshira për të hapur biznesin tonë ishte shumë e madhe.
MĂ« nĂ« fund arritĂ«m tĂ« gjenim njĂ« variant qĂ« na pĂ«rshtatej tĂ« dyve dhe tĂ« merreshim me atĂ« qĂ« dimĂ« tĂ« bĂ«jmĂ« mĂ« mirĂ«. NĂ« vitin 2016 vendosĂ«m tĂ« krijonim njĂ« kompani IT qĂ« do tâi ndihmonte bizneset nĂ« zgjidhjen e detyrave IT. Kjo pĂ«rfshinte implementimin e sistemeve IT (1C, terminal server, mail server etj.), mirĂ«mbajtjen e tyre, HelpDesk klasik pĂ«r pĂ«rdoruesit dhe administrimin e rrjetit.
TĂ« them tĂ« drejtĂ«n, nĂ« momentin kur u krijua kompania, unĂ« i besoja asaj vetĂ«m rreth 0,1%. Por Paveli disi arriti tĂ« mĂ« bindte ta provonim dhe, duke e thĂ«nĂ« qĂ« tani, doli se kishte tĂ« drejtĂ«. UnĂ« dhe Paveli vumĂ« nga 300 000 rubla secili, regjistruam njĂ« ĐĐĐ tĂ« re âAudit-Telekomâ, morĂ«m me qira njĂ« zyrĂ« fare tĂ« vogĂ«l, bĂ«mĂ« karta biznesi vĂ«rtet tĂ« mira dhe, si shumica e sipĂ«rmarrĂ«sve tĂ« rinj pa pĂ«rvojĂ«, nisĂ«m tĂ« kĂ«rkonim klientĂ«. KĂ«rkimi i klientĂ«ve Ă«shtĂ« njĂ« histori mĂ« vete. Ndoshta do tĂ« shkruajmĂ« edhe njĂ« artikull tĂ« veçantĂ« nĂ« blogun e kompanisĂ«, nĂ«se kjo do tâi interesojĂ« dikujt. Telefonata tĂ« ftohta, fletushka dhe gjĂ«ra tĂ« ngjashme. Kjo nuk po jepte asnjĂ« rezultat. Siç e kuptoj tani nga shumĂ« histori biznesi, nĂ« njĂ« mĂ«nyrĂ« apo tjetĂ«r, shumĂ« gjĂ«ra varen nga fati. Ne patĂ«m fat. Dhe fjalĂ« pĂ«r fjalĂ« vetĂ«m disa javĂ« pas krijimit tĂ« kompanisĂ«, na kontaktoi vĂ«llai im Vladimir, i cili na solli klientin e parĂ«. Nuk do tâju lodh me detaje tĂ« punĂ«s me klientĂ«t, sepse artikulli nuk flet pĂ«r kĂ«tĂ«; do tĂ« them vetĂ«m se shkuam pĂ«r auditim, identifikuam pikat kritike dhe ato pika dĂ«shtuan pikĂ«risht gjatĂ« kohĂ«s kur po merrej vendimi nĂ«se do tĂ« bashkĂ«punohej me ne nĂ« mĂ«nyrĂ« tĂ« vazhdueshme si outsourcer. Pas kĂ«saj, vendimi pozitiv u mor menjĂ«herĂ«.
MĂ« pas, kryesisht falĂ« rekomandimeve gojore pĂ«rmes tĂ« njohurve, nisĂ«n tĂ« vinin edhe kompani tĂ« tjera pĂ«r shĂ«rbim. Helpdesk ishte nĂ« njĂ« sistem. Lidhjet me pajisjet e rrjetit dhe serverĂ«t nĂ« njĂ« tjetĂ«r, ose mĂ« saktĂ«, secili i menaxhonte sipas mĂ«nyrĂ«s sĂ« vet. Disa ruanin shortcut-e, tĂ« tjerĂ« pĂ«rdornin librat e adresave tĂ« RDP. Monitorimi ishte edhe ai njĂ« sistem mĂ« vete. PĂ«r ekipin Ă«shtĂ« shumĂ« e papĂ«rshtatshme tĂ« punojĂ« nĂ« sisteme tĂ« shpĂ«rndara. Informacioni i rĂ«ndĂ«sishĂ«m humbet nga vĂ«mendja. PĂ«r shembull, serveri terminal i njĂ« klienti bĂ«het i padisponueshĂ«m. MenjĂ«herĂ« vijnĂ« kĂ«rkesa nga pĂ«rdoruesit e atij klienti. Specialisti i support-it regjistron njĂ« tiketĂ« (ajo ka ardhur me telefon). NĂ«se incidentet dhe kĂ«rkesat do tĂ« regjistroheshin nĂ« tĂ« njĂ«jtin sistem, specialisti i support-it do ta shihte menjĂ«herĂ« cili ishte problemi i pĂ«rdoruesit dhe do tâia thoshte atij, ndĂ«rkohĂ« qĂ« paralelisht do tĂ« lidhej me objektin e duhur pĂ«r tĂ« zgjidhur situatĂ«n. TĂ« gjithĂ« janĂ« nĂ« dijeni tĂ« situatĂ«s operative dhe punojnĂ« nĂ« mĂ«nyrĂ« tĂ« koordinuar. Ne nuk gjetĂ«m njĂ« sistem ku e gjithĂ« kjo tĂ« ishte e bashkuar. U bĂ« e qartĂ« se kishte ardhur koha tĂ« krijonim produktin tonĂ«.
Vazhdimi i punës për sistemin tonë të monitorimit
Ishte e qartë se sistemi i shkruar më parë nuk i përshtatej aspak detyrave aktuale, as për nga funksionaliteti dhe as për nga cilësia. Prandaj u mor vendimi që sistemi të ndërtohej nga e para. Edhe nga ana grafike ai duhej të dukej krejt ndryshe. Duhej të ishte një sistem hierarkik, që objekti i nevojshëm te klienti i duhur të hapej shpejt dhe me lehtësi. Skema si në versionin e parë në këtë rast ishte plotësisht e pajustifikuar, sepse klientët ishin të ndryshëm dhe nuk kishte fare rëndësi në cilat ambiente ndodhej pajisja. Kjo tashmë ishte zhvendosur në dokumentacion.
Pra, detyrat ishin:
- Strukturë hierarkike;
- NjĂ« pjesĂ« server-side, qĂ« mund tĂ« vendosej te klienti si makinĂ« virtuale pĂ«r mbledhjen e metrikave qĂ« na duheshin dhe dĂ«rgimin e tyre te serveri qendror, i cili do tâi pĂ«rmbledhte dhe do tâna i shfaqte;
- Njoftime. Të tilla që të mos mund të kaloheshin pa u vënë re, sepse në atë kohë nuk kishte mundësi që dikush të rrinte vetëm duke parë monitorin;
- Sistem kërkesash. Filluan të shfaqeshin klientë të cilëve u mirëmbanim jo vetëm pajisjet serverike dhe të rrjetit, por edhe stacionet e punës;
- MundĂ«sia pĂ«r tâu lidhur shpejt me serverĂ«t dhe pajisjet direkt nga sistemi;
Detyrat u përcaktuan dhe nisëm zhvillimin, duke trajtuar njëkohësisht edhe kërkesat e klientëve. Në atë kohë ishim tashmë 4 persona. Filluam menjëherë të zhvillonim të dyja pjesët: si serverin qendror, ashtu edhe serverin për instalim te klientët. Deri në atë moment Linux nuk ishte më diçka e panjohur për ne dhe u mor vendimi që makinat virtuale që do të vendoseshin te klientët të bazoheshin në Debian. Nuk do të kishte asnjë installer; thjesht do të krijonim projektin e pjesës server-side mbi një makinë virtuale të vetme konkrete, e më pas do ta klononim te klienti i nevojshëm. Kjo ishte një tjetër gabim. Më vonë u bë e qartë se në këtë skemë mekanizmi i përditësimeve nuk ishte menduar fare. Pra, ne shtonim një veçori të re dhe më pas përhapja e saj në të gjithë serverët e klientëve bëhej një problem i madh. Por te kjo do të kthehemi më vonë, me radhë.
Krijuam prototipin e parë. Ai mund të pingonte pajisjet e rrjetit të klientëve dhe serverët që na nevojiteshin, dhe t'i dërgonte këto të dhëna te serveri ynë qendror. Më pas, ky server i përditësonte këto të dhëna në masën e përgjithshme në serverin qendror. Këtu do të shkruaj jo vetëm historinë se çfarë funksiononte dhe si, por edhe për gabimet prej amatori që bëmë dhe si më pas na duhej ta paguanim këtë me kohë. Pra, e gjithë pema e objekteve ruhej në një skedar të vetëm si një objekt i serializuar. Për sa kohë që lidhëm me sistemin disa klientë, gjithçka ishte pak a shumë në rregull, megjithëse herë pas here shfaqeshin disa artefakte krejtësisht të pakuptueshme. Por kur lidhëm në sistem rreth dhjetë serverë, filluan të ndodhnin gjëra të çuditshme. Ndonjëherë, pa ndonjë arsye të qartë, të gjitha objektet në sistem thjesht zhdukeshin. Këtu është e rëndësishme të theksohet se serverët që ndodheshin te klientët dërgonin të dhëna në serverin qendror çdo disa sekonda përmes një kërkese POST. Lexuesi i vëmendshëm dhe programuesi me përvojë tashmë e ka kuptuar se problemi qëndronte te qasja e njëkohshme nga disa rrjedha te i njëjti skedar ku ruhej objekti i serializuar. Pikërisht në ato momente ndodhnin edhe këto çudira me zhdukjen e objekteve. Skedari thjesht bëhej bosh. Por kjo nuk u zbulua menjëherë, por vetëm gjatë përdorimit me disa serverë. Gjatë kësaj kohe u shtua funksionaliteti për skanimin e porteve (serverët i dërgonin serverit qendror jo vetëm informacion për disponueshmërinë e pajisjeve, por edhe për portet e hapura në to). Kjo u realizua duke thirrur komandën:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
rezultatet shpesh ishin të pasakta dhe skanimi zgjaste shumë. Harrova fare për ping-un, ai kryhej përmes fping:
system("fping -r 3 -t 100 {$this->ip}");
E gjithë kjo gjithashtu nuk ishte e paralelizuar, prandaj procesi zgjaste shumë. Më vonë, në fping kalonte menjëherë e gjithë lista e adresave IP që duhej të kontrolloheshin dhe në kthim merrej lista e gatshme e atyre që ishin përgjigjur. Ndryshe nga ne, fping dinte t'i paralelizonte proceset.
NjĂ« tjetĂ«r punĂ« rutinĂ« e shpeshtĂ« ishte konfigurimi i disa shĂ«rbimeve pĂ«rmes WEB. PĂ«r shembull, ECP i MS Exchange. NĂ« thelb, kjo Ă«shtĂ« thjesht njĂ« lidhje. Dhe vendosĂ«m qĂ« duhet tĂ« na jepet mundĂ«sia tâi shtojmĂ« kĂ«to lidhje drejtpĂ«rdrejt nĂ« sistem, qĂ« tĂ« mos i kĂ«rkojmĂ« nĂ« dokumentacion ose diku tjetĂ«r te faqeshĂ«nuesit se si tĂ« hyjmĂ« nĂ« ECP tĂ« njĂ« klienti tĂ« caktuar. KĂ«shtu lindi koncepti i lidhjeve tĂ« burimeve nĂ« sistem; funksionaliteti i tyre Ă«shtĂ« i disponueshĂ«m edhe sot e kĂ«saj dite dhe pothuajse nuk ka pĂ«suar ndryshime.
Si funksionojnë lidhjet e burimeve në Veliam
Lidhje në distancë
Ja si duket kjo në praktikë në versionin aktual të Veliam
NjĂ« nga detyrat ishte lidhja e shpejtĂ« dhe e pĂ«rshtatshme me serverĂ«t, tĂ« cilĂ«t tashmĂ« ishin bĂ«rĂ« shumĂ« (jo vetĂ«m disa qindra), dhe kĂ«rkimi mes miliona shortcut-eve RDP tĂ« ruajtura paraprakisht ishte jashtĂ«zakonisht i papĂ«rshtatshĂ«m. Na duhej njĂ« mjet. NĂ« internet ka softuer qĂ« funksionon si njĂ« lloj libri adresash pĂ«r lidhje tĂ« tilla RDP, por ato nuk janĂ« tĂ« integruara me sistemin e monitorimit dhe kredencialet nuk ruhen. TĂ« fusĂ«sh kredencialet çdo herĂ« pĂ«r klientĂ« tĂ« ndryshĂ«m Ă«shtĂ« njĂ« ferr i vĂ«rtetĂ«, kur gjatĂ« ditĂ«s lidhesh me dhjetĂ«ra herĂ« me serverĂ« tĂ« ndryshĂ«m. Me SSH situata Ă«shtĂ« pak mĂ« e mirĂ«: ka shumĂ« programe tĂ« mira ku kĂ«to lidhje mund tĂ« organizohen nĂ« dosje dhe tĂ« ruhen kredencialet pĂ«rkatĂ«se. Por ka 2 probleme. E para â pĂ«r lidhjet RDP dhe SSH nuk gjetĂ«m njĂ« program tĂ« vetĂ«m tĂ« unifikuar. E dyta â nĂ«se nĂ« njĂ« moment nuk jam te kompjuteri im dhe mĂ« duhet tĂ« lidhem shpejt, ose thjesht kam riinstaluar sistemin, do tĂ« mĂ« duhet tĂ« hyj nĂ« dokumentacion pĂ«r tĂ« parĂ« kredencialet e atij klienti. Kjo Ă«shtĂ« e papĂ«rshtatshme dhe humbje kohe.
Struktura hierarkike që na duhej për serverët e klientëve ekzistonte tashmë në produktin tonë të brendshëm. Na duhej vetëm të gjenim mënyrën si të integronim aty lidhje të shpejta me pajisjet e nevojshme. Si fillim, të paktën brenda rrjetit tonë.
Duke pasur parasysh se klient nĂ« sistemin tonĂ« ishte shfletuesi, i cili nuk ka qasje te burimet lokale tĂ« kompjuterit pĂ«r tĂ« marrĂ« thjesht dhe pĂ«r tĂ« nisur me ndonjĂ« komandĂ« aplikacionin qĂ« na duhej, u mendua qĂ« gjithçka tĂ« realizohej pĂ«rmes âWindows custom url schemeâ. KĂ«shtu u shfaq njĂ« lloj âpluginâ-i pĂ«r sistemin tonĂ«, i cili thjesht pĂ«rfshinte Putty dhe Remote Desktop Plus dhe gjatĂ« instalimit vetĂ«m regjistronte skemat URI nĂ« Windows. Tani, kur donim tĂ« lidheshim me njĂ« objekt pĂ«rmes RDP ose SSH, e aktivizonim kĂ«tĂ« veprim nĂ« sistemin tonĂ« dhe niste mekanizmi i Custom URI. Hapeshin mstsc.exe standard i integruar nĂ« Windows ose putty, qĂ« vinte si pjesĂ« e âpluginâ-it. FjalĂ«n plugin e vendos nĂ« thonjĂ«za, sepse kjo nuk Ă«shtĂ« njĂ« shtojcĂ« shfletuesi nĂ« kuptimin klasik.
Kjo tashmĂ« ishte tĂ« paktĂ«n diçka. NjĂ« libĂ«r adresash i pĂ«rshtatshĂ«m. Madje, nĂ« rastin e Putty, gjithçka funksiononte shumĂ« mirĂ«: si parametra hyrĂ«s mund tâi jepje edhe IP-nĂ« e lidhjes, edhe emrin e pĂ«rdoruesit, edhe fjalĂ«kalimin. Pra, me serverĂ«t Linux nĂ« rrjetin tonĂ« tashmĂ« lidheshim me njĂ« klikim, pa futur fjalĂ«kalime. Por me RDP nuk Ă«shtĂ« kaq e thjeshtĂ«. Te mstsc standard nuk mund tâi kalosh kredencialet si parametra. NĂ« ndihmĂ« erdhi Remote Desktop Plus. Ai e mundĂ«sonte kĂ«tĂ«. Sot tashmĂ« funksionojmĂ« pa tĂ«, por pĂ«r njĂ« kohĂ« tĂ« gjatĂ« ka qenĂ« njĂ« ndihmĂ«s besnik nĂ« sistemin tonĂ«. Me faqet HTTP(S) gjithçka Ă«shtĂ« e thjeshtĂ«: objekte tĂ« tilla thjesht hapeshin nĂ« shfletues dhe kaq. E pĂ«rshtatshme dhe praktike. Por kjo komoditet vlente vetĂ«m brenda rrjetit tĂ« brendshĂ«m.
Meqenëse shumicën dërrmuese të problemeve i zgjidhnim në distancë nga zyra, zgjidhja më e thjeshtë ishte të krijonim VPN deri te klientët. Dhe atëherë nga sistemi ynë mund të lidheshim edhe me ta. Por sërish kishte disa bezdi. Për çdo klient duhej të mbanim në çdo kompjuter një mori lidhjesh të ruajtura VPN dhe, përpara se të lidheshim me cilëndo prej tyre, duhej të aktivizonim VPN-në përkatëse. Këtë zgjidhje e përdorëm për një kohë mjaft të gjatë. Por numri i klientëve po rritej, po ashtu edhe numri i VPN-ve, dhe e gjithë kjo filloi të bëhej e lodhshme, ndaj duhej bërë diçka. Sidomos të vinte për të qarë pas riinstalimit të sistemit, kur duhej të rifusje dhjetëra lidhje VPN në profilin e ri të Windows. Mjaft e duruam këtë, thashë me vete, dhe nisa të mendoj çfarë mund të bëhej me këtë situatë.
KĂ«shtu ndodhi qĂ« tĂ« gjithĂ« klientĂ«t pĂ«rdornin pajisje tĂ« kompanisĂ« sĂ« njohur Mikrotik si ruterĂ«. Ato janĂ« mjaft funksionale dhe tĂ« pĂ«rshtatshme pĂ«r zgjidhjen e pothuajse çdo detyre. Nga anĂ«t negative â mund tĂ« komprometohen. KĂ«tĂ« problem e zgjidhĂ«m thjesht duke mbyllur tĂ« gjitha akseset nga jashtĂ«. Por na duhej gjithsesi tĂ« kishim qasje tek ato pa shkuar fizikisht te klienti, sepse kjo merrte shumĂ« kohĂ«. Zgjidhja jonĂ« ishte tĂ« krijonim tunele drejt secilit Mikrotik tĂ« tillĂ« dhe tâi ndanim nĂ« njĂ« pool mĂ« vete, pa asnjĂ« lloj rutimi, nĂ« mĂ«nyrĂ« qĂ« rrjeti ynĂ« tĂ« mos bashkohej me rrjetet e klientĂ«ve dhe as rrjetet e tyre me njĂ«ra-tjetrĂ«n.
Lindi ideja qĂ«, kur tĂ« klikohej mbi objektin qĂ« mĂ« duhej nĂ« sistem, serveri qendror i monitorimit, duke ditur kredencialet SSH pĂ«r tĂ« gjithĂ« Mikrotik-Ă«t e klientĂ«ve, tĂ« lidhej me pajisjen pĂ«rkatĂ«se dhe tĂ« krijonte njĂ« rregull port forwarding drejt hostit tĂ« kĂ«rkuar me portĂ«n e nevojshme. KĂ«tu kishte menjĂ«herĂ« disa nuanca. Zgjidhja nuk ishte universale â do tĂ« funksiononte vetĂ«m me Mikrotik, sepse sintaksa e komandave ndryshon nga njĂ« ruter te tjetri. PĂ«r mĂ« tepĂ«r, kĂ«to rregulla forwarding duhej tĂ« fshiheshin mĂ« pas nĂ« njĂ« farĂ« mĂ«nyre, ndĂ«rsa pjesa server-side e sistemit tonĂ« nĂ« thelb nuk mund tĂ« gjurmonte nĂ«se sesioni im i punĂ«s pĂ«rmes RDP kishte pĂ«rfunduar apo jo. Dhe njĂ« forwarding i tillĂ« pĂ«rbĂ«nte gjithashtu njĂ« cenueshmĂ«ri serioze pĂ«r klientin. Gjithsesi, universaliteti nuk ishte synimi ynĂ«, sepse produkti pĂ«rdorej vetĂ«m brenda kompanisĂ« sonĂ« dhe nuk kishim asnjĂ« plan ta publikonim.
Secili prej këtyre problemeve u zgjidh në mënyrën e vet. Kur krijohej rregulli, ky forwarding ishte i disponueshëm vetëm për një IP adresë të jashtme të caktuar (nga e cila ishte iniciuar lidhja). Kështu arritëm të shmangnim një boshllëk sigurie. Por me çdo lidhje të tillë shtohej një rregull në faqen NAT të Mikrotik-ut dhe ai nuk pastrohej. Dihet mirë se sa më shumë rregulla të ketë aty, aq më shumë ngarkohet CPU i ruterit. Dhe, në përgjithësi, nuk mund ta pranoja idenë që një ditë të hyja në ndonjë Mikrotik dhe të gjeja aty qindra rregulla të vdekura, të padobishme për askënd.
Meqë serveri ynë nuk mund ta monitoronte gjendjen e lidhjes, le ta bënte vetë Mikrotik. Kështu shkrova një skript që monitoronte vazhdimisht të gjitha rregullat e port forwarding me një përshkrim të caktuar (description) dhe kontrollonte nëse ekzistonte një lidhje TCP për rregullin përkatës. Nëse për njëfarë kohe nuk kishte një të tillë, atëherë ka shumë gjasa që lidhja të kishte përfunduar dhe ky forwarding mund të fshihej. Gjithçka funksionoi, skripti punonte mirë.
Ja ku është:
global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={
local dstport [/ip firewall nat get value-name="dst-port" $i]
local dstaddress [/ip firewall nat get value-name="dst-address" $i]
local dstaddrport "$dstaddress:$dstport"
#log warning message=$dstaddrport
local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
if ($thereIsCon = "") do={
set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
#:log warning message=($atmonrulecounter->$dstport)
if (($atmonrulecounter->$dstport) > 5) do={
#log warning message="Removing nat rules added automaticaly by atmon_script"
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
set ($atmonrulecounter->$dstport) 0
}
} else {
set ($atmonrulecounter->$dstport) 0
}
}
Sigurisht, mund tĂ« bĂ«hej mĂ« elegant, mĂ« i shpejtĂ« e kĂ«shtu me radhĂ«, por funksiononte, nuk i ngarkonte Mikrotik dhe e kryente punĂ«n shkĂ«lqyeshĂ«m. MĂ« nĂ« fund arritĂ«m tĂ« lidhemi me serverĂ«t dhe pajisjet e rrjetit tĂ« klientĂ«ve vetĂ«m me njĂ« klikim. Pa ngritur VPN dhe pa futur fjalĂ«kalime. Sistemi u bĂ« vĂ«rtet shumĂ« komod pĂ«r tâu pĂ«rdorur. Koha pĂ«r mirĂ«mbajtje shkurtohej dhe tĂ« gjithĂ« ne e shpenzonim kohĂ«n pĂ«r punĂ«, jo pĂ«r tâu lidhur me objektet e nevojshme.
Kopje rezervë të Mikrotik
Kishim konfiguruar kopje rezervĂ« tĂ« tĂ« gjithĂ« Mikrotik nĂ« FTP. NĂ« pĂ«rgjithĂ«si gjithçka ishte nĂ« rregull. Por kur duhej tĂ« merrje njĂ« backup, ishte e nevojshme tĂ« hapje atĂ« FTP dhe ta kĂ«rkoje aty. Ne e kemi tashmĂ« sistemin ku janĂ« regjistruar tĂ« gjithĂ« routerĂ«t dhe dimĂ« tĂ« komunikojmĂ« me pajisjet pĂ«rmes SSH. Pse tĂ« mos e bĂ«nim qĂ« sistemi tâi merrte vetĂ« çdo ditĂ« backup-et nga tĂ« gjithĂ« Mikrotik, mendova. Dhe nisa ta zbatoja. U lidhĂ«m, krijuam backup-in dhe e morĂ«m nĂ« ruajtje.
Kodi i skriptit PHP për të marrë backup nga Mikrotik:
<?php
$IP = '0.0.0.0';
$LOGIN = 'admin';
$PASSWORD = '';
$BACKUP_NAME = 'test';
$connection = ssh2_connect($IP, 22);
if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;
ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
stream_get_contents($connection);
ssh2_exec($connection, '/export file="atmon.rsc"');
stream_get_contents($connection);
sleep(40); // Waiting bakup makes
$sftp = ssh2_sftp($connection);
// Download backup file
$size = filesize("ssh2.sftp://$sftp/atmon.backup");
$stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . â.backupâ,$contents);
@fclose($stream);
sleep(3);
// Download RSC file
$size = filesize("ssh2.sftp://$sftp/atmon.rsc");
$stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read
Backup-i ruhet nĂ« dy formate â si binar dhe si konfigurim tekstual. Formati binar ndihmon pĂ«r tĂ« rikthyer shpejt konfigurimin e nevojshĂ«m, ndĂ«rsa versioni tekstual tĂ« lejon tĂ« kuptosh çfarĂ« duhet bĂ«rĂ« nĂ«se ndodh njĂ« zĂ«vendĂ«sim i detyruar i pajisjes dhe backup-i binar nuk mund tĂ« ngarkohet nĂ« tĂ«. Si rezultat, morĂ«m edhe njĂ« funksionalitet tjetĂ«r tĂ« dobishĂ«m nĂ« sistem. PĂ«r mĂ« tepĂ«r, gjatĂ« shtimit tĂ« MikroTik-Ă«ve tĂ« rinj nuk ishte e nevojshme tĂ« konfigurohej asgjĂ«: mjaftonte tĂ« shtoje objektin nĂ« sistem dhe tâi caktoje kredencialet e SSH. MĂ« pas, sistemi merrej vetĂ« me krijimin e backup-eve. NĂ« versionin aktual tĂ« SaaS Veliam ky funksionalitet ende nuk Ă«shtĂ« i disponueshĂ«m, por sĂ« shpejti do ta portojmĂ«.
Pamje ekrani se si dukej kjo në sistemin e brendshëm
Kalimi te ruajtja e duhur në bazën e të dhënave
Më sipër kam shkruar tashmë se shfaqeshin artefakte. Ndonjëherë thjesht zhdukej e gjithë lista e objekteve në sistem, herë të tjera gjatë redaktimit të një objekti informacioni nuk ruhej dhe duhej ta riemërtoje objektin edhe tri herë. Kjo i irritonte tmerrësisht të gjithë. Zhdukja e objekteve ndodhte rrallë dhe rikuperohej lehtë duke restauruar pikërisht atë skedar, por dështimi gjatë redaktimit të objekteve ndodhte vërtet shpesh. Ndoshta fillimisht nuk e bëra përmes një DB-je sepse nuk e konceptoja dot si mund të mbahej një pemë me të gjitha lidhjet e saj në një tabelë të sheshtë. Në fund të fundit, tabela është e sheshtë, ndërsa pema është hierarkike. Por zgjidhja e duhur për akses të shumëfishtë dhe më pas, me kompleksitetin në rritje të sistemit, edhe për transaksione, është një DBMS. Me siguri nuk isha i pari që ndeshej me këtë problem. Fillova të kërkoja në Google. Doli se gjithçka ishte shpikur tashmë para meje dhe ekzistojnë disa algoritme që ndërtojnë një pemë nga një tabelë e sheshtë. Pasi i shqyrtova, zbatova njërin prej tyre. Por kjo ishte tashmë një version i ri i sistemit, sepse në thelb u desh të rishkruhej një pjesë goxha e madhe. Rezultati ishte i pritshëm: problemet me sjelljen e rastësishme të sistemit u zhdukën. Dikush mund të thotë se këto gabime ishin mjaft amatore (skripte me një fije ekzekutimi, ruajtja në skedar e informacionit ndaj të cilit kishte akses të shumëfishtë të njëkohshëm nga fije të ndryshme etj.) në fushën e zhvillimit të softuerit. Ndoshta ashtu është, por puna ime kryesore ishte administrimi, ndërsa programimi ishte diçka dytësore, më tepër për pasion, dhe thjesht nuk kisha përvojë pune në një ekip programuesish, atje ku gjëra kaq elementare do të m'i kishin treguar menjëherë kolegët më me përvojë. Prandaj të gjitha këto i mësova vetë, duke i provuar mbi kurrizin tim, por e përvetësova shumë mirë materialin. Për më tepër, të kesh biznesin tënd do të thotë edhe takime me klientët, edhe përpjekje për promovimin e kompanisë, edhe një mori çështjesh administrative brenda saj, dhe shumë e shumë gjëra të tjera. Por sido që të jetë, ajo që ekzistonte tashmë ishte e kërkuar. Djemtë dhe unë vetë e përdornim produktin në punën e përditshme. Kishte edhe ide hapur të pasuksesshme, edhe zgjidhje ku u shpenzua kohë, por në fund u kuptua se ishte një mjet jofunksional, askush nuk e përdorte dhe nuk përfundoi në Veliam.
ShĂ«rbimi i mbĂ«shtetjes â HelpDesk
Vlen të përmendet edhe se si u krijua HelpDesk. Kjo është një histori më vete, sepse në Veliam kjo është tashmë versioni i tretë krejtësisht i ri, i ndryshëm nga të gjitha të mëparshmet. Tani është një sistem i thjeshtë, intuitiv dhe i kuptueshëm, pa zbukurime të panevojshme, me mundësi integrimi me domenin, si edhe me mundësinë për të hyrë në të njëjtin profil përdoruesi nga kudo përmes lidhjes në email. Dhe më e rëndësishmja, ekziston mundësia që nga çdo vend (qoftë në shtëpi apo në zyrë) të lidhem me aplikantin përmes VNC drejtpërdrejt nga kërkesa, pa VPN ose ridrejtim portesh. Do të tregoj se si arritëm deri këtu, çfarë kishim më parë dhe cilat zgjidhje të tmerrshme janë përdorur.
Ne lidheshim me pĂ«rdoruesit pĂ«rmes TeamViewer, qĂ« tĂ« gjithĂ« e njohin. NĂ« tĂ« gjithĂ« kompjuterĂ«t e pĂ«rdoruesve qĂ« ne mirĂ«mbanim ishte instaluar TV. Gabimi i parĂ« qĂ« bĂ«mĂ« dhe mĂ« pas e hoqĂ«m ishte lidhja e çdo klienti tĂ« HelpDesk me harduerin. Si hynte pĂ«rdoruesi nĂ« sistemin HelpDesk pĂ«r tĂ« lĂ«nĂ« njĂ« kĂ«rkesĂ«? PĂ«rveç TV, nĂ« kompjuterĂ«t e tĂ« gjithĂ«ve ishte instaluar njĂ« utility e veçantĂ« e shkruar nĂ« Lazarus (kĂ«tu shumĂ«kujt mund tâi hapen sytĂ« dhe madje tĂ« nxitojĂ« ta kĂ«rkojĂ« nĂ« Google se çfarĂ« Ă«shtĂ«, por nga gjuhĂ«t e kompilueshme unĂ« njihja mĂ« mirĂ« Delphi, ndĂ«rsa Lazarus Ă«shtĂ« pothuajse e njĂ«jta gjĂ«, vetĂ«m se falas). Me pak fjalĂ«, pĂ«rdoruesi ekzekutonte njĂ« batch file tĂ« posaçëm, i cili niste kĂ«tĂ« utility; ajo nga ana e saj lexonte HWID e sistemit, dhe mĂ« pas hapej shfletuesi dhe kryhej autentikimi. Pse e bĂ«mĂ« kĂ«tĂ«? NĂ« disa kompani, numri i pĂ«rdoruesve qĂ« mirĂ«mbahen llogaritet njĂ« mĂ« njĂ« dhe çmimi i shĂ«rbimit mujor pĂ«rcaktohet sipas numrit tĂ« njerĂ«zve. Kjo Ă«shtĂ« e kuptueshme, do tĂ« thoni ju, por pse lidhja me harduerin? ShumĂ« thjesht: disa individĂ« shkonin nĂ« shtĂ«pi dhe nga laptopi personal dĂ«rgonin kĂ«rkesa tĂ« tipit âma rregulloni kĂ«tu gjithçka bukurâ. PĂ«rveç leximit tĂ« HWID tĂ« sistemit, utility nxirrte nga regjistri edhe ID-nĂ« aktuale tĂ« TeamViewer dhe na e dĂ«rgonte edhe atĂ«. TeamViewer ka API pĂ«r integrim. Dhe ne e ndĂ«rtuam kĂ«tĂ« integrim. Por kishte njĂ« pengesĂ«. PĂ«rmes kĂ«tyre API-ve nuk mund tĂ« lidheshe me kompjuterin e pĂ«rdoruesit nĂ«se ai nuk e niste qartĂ«sisht vetĂ« seancĂ«n, dhe pas pĂ«rpjekjes pĂ«r tâu lidhur ai duhej ende tĂ« shtypte âkonfirmoâ. NĂ« atĂ« kohĂ«, na u duk logjike qĂ« pa lejen e pĂ«rdoruesit askush tĂ« mos lidhej, dhe nĂ«se personi ishte para kompjuterit, atĂ«herĂ« ai vetĂ« do ta niste seancĂ«n dhe do tâi pĂ«rgjigjej pozitivisht kĂ«rkesĂ«s pĂ«r lidhje nĂ« distancĂ«. Doli se nuk ishte kĂ«shtu. Ata qĂ« hapnin kĂ«rkesat harronin tĂ« nisnin seancĂ«n dhe duhej tâua kujtonim gjatĂ« bisedĂ«s telefonike. Kjo humbiste kohĂ« dhe i nervozonte tĂ« dyja palĂ«t. PĂ«r mĂ« tepĂ«r, nuk ishin aspak tĂ« rralla rastet kur dikush linte njĂ« kĂ«rkesĂ«, por e lejonte lidhjen vetĂ«m kur dilte nĂ« drekĂ«, sepse problemi nuk ishte kritik dhe nuk donte tâi ndĂ«rpritej puna. PĂ«r rrjedhojĂ«, ai nuk do tĂ« shtypte asnjĂ« buton pĂ«r tĂ« lejuar lidhjen. KĂ«shtu u shfaq funksionaliteti shtesĂ« gjatĂ« autorizimit nĂ« HelpDesk: leximi i ID-sĂ« sĂ« TeamViewer. Ne e dinim fjalĂ«kalimin e pĂ«rhershĂ«m qĂ« pĂ«rdorej gjatĂ« instalimit tĂ« TeamViewer. MĂ« saktĂ«, atĂ« e dinte vetĂ«m sistemi, sepse ishte i integruar nĂ« instalues dhe nĂ« sistemin tonĂ«. Si pasojĂ«, nĂ« kĂ«rkesĂ« kishte njĂ« buton lidhjeje, me klikimin e tĂ« cilit nuk duhej pritur asgjĂ«: TeamViewer hapej menjĂ«herĂ« dhe lidhja kryhej. NĂ« fund dolĂ«n dy lloje tĂ« mundshme lidhjesh: pĂ«rmes API zyrtare tĂ« TeamViewer dhe pĂ«rmes zgjidhjes sonĂ« tĂ« improvizuar. PĂ«r habinĂ« time, varianti i parĂ« pothuajse menjĂ«herĂ« pushoi sĂ« pĂ«rdoruri, edhe pse kishte udhĂ«zim tĂ« pĂ«rdorej vetĂ«m nĂ« raste tĂ« veçanta dhe kur vetĂ« pĂ«rdoruesi jepte pĂ«lqimin. NĂ« fund tĂ« fundit, sot tĂ« gjithĂ« flasin pĂ«r sigurinĂ«. Por rezultoi se pĂ«rdoruesve qĂ« hapnin kĂ«rkesa kjo nuk u nevojitej. Askush prej tyre nuk ishte kundĂ«r qĂ« tĂ« lidheshe pa butonin e konfirmimit. Dhe meqĂ« ishte kĂ«shtu, mĂ« vonĂ« funksionaliteti i lidhjes pĂ«rmes API u hoq fare si i panevojshĂ«m.
Kalimi te shumëfijësia në Linux
Prej kohĂ«sh ishte bĂ«rĂ« e qartĂ« nevoja pĂ«r tĂ« pĂ«rshpejtuar kalimin e skanerit tĂ« rrjetit pĂ«r kontrollin e hapjes sĂ« njĂ« liste portash tĂ« pĂ«rcaktuara paraprakisht, si edhe pĂ«r pingimin e thjeshtĂ« tĂ« objekteve tĂ« rrjetit. Zgjidhja e parĂ« qĂ« tĂ« vjen ndĂ«r mend kĂ«tu Ă«shtĂ« natyrshĂ«m shumĂ«fijĂ«sia. Pjesa mĂ« e madhe e kohĂ«s gjatĂ« pingimit shkon duke pritur kthimin e paketĂ«s dhe ping-u pasues nuk mund tĂ« nisĂ« pa u kthyer paketa e mĂ«parshme, ndaj edhe nĂ« kompani me vetĂ«m 20+ serverĂ«, plus pajisje rrjeti, kjo funksiononte mjaft ngadalĂ«. Thelbi Ă«shtĂ« se njĂ« paketĂ« mund edhe tĂ« humbasĂ«, por nuk ka kuptim tĂ« njoftohet menjĂ«herĂ« administratori i sistemit pĂ«r kĂ«tĂ«. Ai thjesht do tĂ« ndalojĂ« shumĂ« shpejt tâi kushtojĂ« vĂ«mendje njĂ« spami tĂ« tillĂ«. Kjo do tĂ« thotĂ« se çdo objekt duhet pinguar mĂ« shumĂ« se njĂ« herĂ« pĂ«rpara se tĂ« nxirret pĂ«rfundimi se Ă«shtĂ« i paarritshĂ«m. Pa hyrĂ« shumĂ« nĂ« detaje, paralelizimi Ă«shtĂ« i domosdoshĂ«m sepse, nĂ« tĂ« kundĂ«rt, ka shumĂ« gjasa qĂ« administratori i sistemit ta mĂ«sojĂ« pĂ«r problemin nga klienti dhe jo nga sistemi i monitorimit.
VetĂ« PHP, nĂ« konfigurimin standard, nuk mbĂ«shtet shumĂ«fijĂ«sinĂ«. Ai mbĂ«shtet shumĂ«procese dhe lejon forkim tĂ« proceseve. Por unĂ« nĂ« thelb e kisha tashmĂ« gati mekanizmin e kontrollit dhe doja ta organizoja punĂ«n nĂ« mĂ«nyrĂ« qĂ« njĂ« herĂ« tĂ« lexoja nga DB tĂ« gjitha nyjet qĂ« mĂ« duheshin, tâi pingoja tĂ« gjitha menjĂ«herĂ«, tĂ« prisja pĂ«rgjigjen nga secila dhe vetĂ«m pas kĂ«saj tâi shkruaja tĂ« dhĂ«nat njĂ«herĂ«sh. Kjo ul numrin e kĂ«rkesave pĂ«r lexim. NĂ« kĂ«tĂ« koncept shumĂ«fijĂ«sia pĂ«rshtatej nĂ« mĂ«nyrĂ« tĂ« pĂ«rkryer. PĂ«r PHP ekziston moduli PThreads, i cili mundĂ«son shumĂ«fijĂ«si tĂ« vĂ«rtetĂ«. VĂ«rtet u desh mjaft punĂ« pĂ«r ta konfiguruar nĂ« PHP 7.2, por ia dolĂ«m. Skanimi i porteve dhe pingimi u bĂ«nĂ« tĂ« shpejta. Dhe nĂ« vend tĂ«, pĂ«r shembull, 15 sekondave pĂ«r njĂ« cikĂ«l si mĂ« parĂ«, tani ky proces zgjaste 2 sekonda. Ishte njĂ« rezultat i mirĂ«.
Audit i shpejtë i kompanive të reja
Si u krijua funksionaliteti pĂ«r mbledhjen e metrikave dhe karakteristikave tĂ« ndryshme tĂ« harduerit? ShumĂ« thjesht. NganjĂ«herĂ« na porosisin thjesht njĂ« auditim tĂ« infrastrukturĂ«s aktuale IT. E njĂ«jta gjĂ« na duhet edhe pĂ«r tĂ« pĂ«rshpejtuar auditimin e njĂ« klienti tĂ« ri. Na duhej diçka qĂ« tĂ« na lejonte tĂ« shkonim nĂ« njĂ« kompani tĂ« mesme ose tĂ« madhe dhe tĂ« kuptonim shpejt se çfarĂ« kanĂ« realisht. Ping nĂ« rrjetin e brendshĂ«m, sipas mendimit tim, e bllokojnĂ« vetĂ«m ata qĂ« duan tâia vĂ«shtirĂ«sojnĂ« jetĂ«n vetes, dhe sipas pĂ«rvojĂ«s sonĂ« tĂ« tillĂ« ka pak. Por edhe tĂ« tillĂ« hasen. Prandaj, rrjetet mund tĂ« skanohen shpejt pĂ«r praninĂ« e pajisjeve me njĂ« ping tĂ« thjeshtĂ«. MĂ« pas, ato mund tĂ« shtohen dhe tĂ« skanohen pĂ«r portet e hapura qĂ« na interesojnĂ«. NĂ« thelb, ky funksionalitet ekzistonte tashmĂ«; duhej vetĂ«m tĂ« shtohej njĂ« komandĂ« nga serveri qendror te serveri vartĂ«s, nĂ« mĂ«nyrĂ« qĂ« ai tĂ« skanonte rrjetet e pĂ«rcaktuara dhe tĂ« shtonte nĂ« listĂ« gjithçka qĂ« gjente. Harrova tĂ« pĂ«rmend se supozohej qĂ« ne tashmĂ« kishim njĂ« image tĂ« gatshme me sistemin e konfiguruar (serveri vartĂ«s i monitorimit), tĂ« cilin mund ta vendosnim thjesht te klienti gjatĂ« auditimit dhe ta lidhnim me cloud-in tonĂ«.
Por rezultati i auditimit zakonisht përfshin një mori informacioni të ndryshëm, dhe një prej tyre është se çfarë pajisjesh ka në rrjet në përgjithësi. Para së gjithash, ne na interesonin serverët Windows dhe stacionet e punës Windows brenda domenit. Sepse në kompanitë e mesme dhe të mëdha, mungesa e një domeni është më tepër përjashtim sesa rregull. Që të flasim për të njëjtën gjë, sipas përfytyrimit tim, një kompani e mesme është 100+ persona. Duhej të gjendej një mënyrë për të mbledhur të dhëna nga të gjitha makinat dhe serverët Windows, duke ditur IP-të e tyre dhe llogarinë e administratorit të domenit, por pa instaluar ndonjë software në secilën prej tyre. Këtu në ndihmë vjen ndërfaqja WMI. Windows Management Instrumentation (WMI), në përkthim fjalë për fjalë, është instrumentari i menaxhimit të Windows. WMI është një nga teknologjitë bazë për menaxhimin e centralizuar dhe monitorimin e funksionimit të pjesëve të ndryshme të infrastrukturës kompjuterike që punon mbi platformën Windows. Marrë nga Wikipedia. Më pas u desh sërish pak punë për të ndërtuar wmic (ky është klienti WMI) për Debian. Pasi gjithçka ishte gati, mbetej vetëm të pyeteshin përmes wmic nyjet e nevojshme për të marrë informacionin e kërkuar. Përmes WMI mund të merret pothuajse çdo informacion nga një kompjuter Windows dhe, për më tepër, përmes tij mund edhe të administrohet kompjuteri, për shembull, të dërgohet për restartim. Kështu lindi në sistemin tonë mbledhja e informacionit për stacionet dhe serverët Windows. Krahas kësaj merrej edhe informacioni aktual për treguesit e ngarkesës së sistemit. Këto i kërkojmë më shpesh, ndërsa informacionin për hardware-in më rrallë. Pas kësaj, kryerja e auditimit u bë disi më e këndshme.
Vendimi për shpërndarjen e software-it
Ne vetĂ« e pĂ«rdorim sistemin çdo ditĂ« dhe ai Ă«shtĂ« gjithmonĂ« i hapur te secili punonjĂ«s teknik. Dhe menduam se mund ta ndanim me tĂ« tjerĂ«t atĂ« qĂ« tashmĂ« kishim. Sistemi ende nuk ishte aspak gati pĂ«r tâu shpĂ«rndarĂ«. Duhej tĂ« ripunohej shumëçka qĂ« versioni lokal tĂ« kthehej nĂ« SaaS. Kjo pĂ«rfshinte ndryshime nĂ« aspekte tĂ« ndryshme teknike tĂ« funksionimit tĂ« sistemit (lidhjet nĂ« distancĂ«, shĂ«rbimi i mbĂ«shtetjes), analizĂ«n e moduleve nga pikĂ«pamja e licencimit, sharding-un e bazave tĂ« tĂ« dhĂ«nave tĂ« klientĂ«ve, shkallĂ«zimin e secilit shĂ«rbim dhe zhvillimin e sistemeve tĂ« auto-update pĂ«r tĂ« gjitha pjesĂ«t. Por pĂ«r kĂ«tĂ« do tĂ« flasim nĂ« pjesĂ«n e dytĂ« tĂ« artikullit.
Përditëso
Burimi: habr.com
