🥇Nga outsourcing në zhvillim (Pjesa 1)

Përshëndetje të gjithëve, emri im është Sergey Emelyanchik. Unë jam drejtori i kompaniës Audit-Telecom, zhvilluesi kryesor dhe autori i sistemit Veliam. Vendosa të shkruaj një artikull mbi mënyrën se si unë dhe një mik krijuam një kompani outsourcing, zhvilluam software për veten tonë dhe më pas filluam ta shpërndajmë atë për të gjithë ata që ishin të interesuar për sistemin SaaS. Do të flas për mënyrën se si unë absolutisht nuk besoja se kjo ishte e mundur. Artikulli do të përmbajë jo vetëm një tregim, por edhe detaje teknike mbi se si u krijua produkti Veliam. Duke përfshirë disa pjesë të kodit burimor. Do të ndaj gabimet që bëmë dhe si i korrigjuam ato më pas. Kishim dyshime nëse duhej ta publikojmë një artikull të tillë. Por mendova se ishte më mirë ta bëja këtë, të merrja feedback dhe të përmirësohesha, sesa të mos e publikoj dhe të mendoj çfarë do të kishte ndodhur nëse...

Pas historia

Kam punuar në një kompani si punonjës IT. Kompania ishte mjaft e madhe me një strukturë të gjerë rrjetore. Nuk do të qëndroj te detyrat e mia, do të them vetëm se ato qartë nuk përfshinin zhvillimin e diçkaje.

Kemi pasur një monitorim, por thjesht për interes akademik doja të përpiqesha të shkruaj një të thjeshtë të mi. Ideja ishte kjo: doja që të ishte në web, në mënyrë që të ishte e lehtë të hynte dhe të shihte se çfarë po ndodhte me rrjetin nga çdo pajisje, duke përfshirë pajisjet mobile përmes Wi-Fi, dhe gjithashtu doja shumë të kuptoja shpejt në cilin ambient ndodhej pajisja që "kishte probleme", pasi kishte kërkesa mjaft të rrepta për kohën e reagimit ndaj problemeve të tilla. Në fund, në mendjen time lindi plani për të shkruar një faqe të thjeshtë web, ku prapa ishte një jpeg me diagramin e rrjetit, të prisja në këtë imazh vetë pajisjet me adresat e tyre IP, dhe mbi imazh në koordinatat përkatëse të tregoja përmbajtje dinamike në formën e një adrese IP të gjelbër ose që ndizoullonte me të kuqe. Detyra u vendos, le të fillojmë.

Më parë kam punuar me programimin në Delphi, PHP, JS dhe shumë sipërfaqësisht C++. E njoh mjaft mirë funksionimin e rrjeteve. VLAN, Ruterizimi (OSPF, EIGRP, BGP), NAT. Kjo ishte e mjaftueshme për të shkruar një prototip të monitorimit primitiv vetë.

Krijova atë që kisha menduar në PHP. Serveri Apache dhe PHP ishin në Windows sepse Linux për mua në atë moment ishte diçka e paqartë dhe shumë e komplikuar, siç doli më vonë, gabova shumë dhe në shumë raste Linux është më i thjeshtë se Windows, por kjo është një temë e veçantë dhe të gjithë e dimë sa shumë polemika ka rreth kësaj çështjeje. Planifikuesi i punëve në Windows ekzekutonte me një interval të vogël (nuk e mbaj mend saktësisht, por diçka si një herë në çdo tri sekonda) skenarin PHP, i cili virtytisht kontrollonte të gjithë objektet duke përdorur ping dhe ruante gjendjen në një skedë.

system("ping -n 3 -w 100 {$ip_address}");

Po, po, puna me BD në atë moment gjithashtu ishte diçka që nuk e kisha zhvilluar. Nuk dija se ishte e mundur të paralelizoheshin proceset, dhe kalimi përmes të gjitha nyjeve të rrjetit zgjaste një kohë të gjatë, pasi kjo ndodhte në një rrjedhë të vetme. Problemet sidomos shfaqeshin kur disa nyje ishin të padisponueshme, pasi çdo njëra ngadalësonte skriptin me 300 ms. Në anën e klientit kishte një funksion të thjeshtë të ciklit, i cili në intervale disa sekondash shkarkonte informacionin e azhurnuar nga serveri me një kërkesë Ajax dhe azhurnonte ndërfaqen. Më pas, pas 3 pingjeve të pasuksesshme radhazi, nëse në kompjuterin ishte e hapur një faqe web me monitorimin, lëshonte një kompozim të këndshëm.

Kur sapo të gjitha dolën mbarë, u inspirova shumë nga rezultati dhe mendova se mund të shtonim edhe më shumë (duke u bazuar në njohuritë dhe mundësitë e mia). Por gjithmonë nuk më kanë pëlqyer sistemet me një milion grafikë, që, siç mendova atëherë dhe ende mendoj, në shumicën e rasteve janë të panevojshme. Desha të shtoja vetëm ato që do më ndihmonin realisht në punë. Ky parim vazhdon të jetë thelbësor në zhvillimin e Veliam. Më pas, e kuptova se do ishte shumë e shkëlqyer nëse nuk do të duhej të mbaja të hapur monitorimin dhe të dija për problemet. Kur ndodhte një problem, do të mund të hapja faqen dhe të shihja ku ndodhej ky nyje problematike e rrjetit dhe çfarë duhej të bëja më pas. Në atë kohë nuk kisha lexuar ndonjëherë postën elektronike, thjesht nuk e përdorja. Gjeta në internet se ekzistojnë porta SMS, në të cilat mund të dërgoja një kërkesë GET ose POST, dhe ato do të më dërgonin në telefonin tim celular një SMS me tekstin që do të shkruaja. Menjëherë kuptova se e doja shumë këtë. Dhe fillova të studioja dokumentacionin. Pas një kohë të shkurtër arrita, dhe tani merrja SMS për problemet në rrjet në celularin tim me emrin e “objektit të rënë”. Edhe pse sistemi ishte primitiv, por ishte shkruar nga unë, dhe më e rëndësishmja, ajo që më motivonte atëherë për ta zhvilluar ishte se kjo ishte një program i aplikueshëm që me të vërtetë më ndihmonte në punë.

Dhe rasti erdhi kur një nga kanalet e internetit në punë ra, dhe monitorimi im nuk më dha asnjë shenjë për këtë. Duke qenë se DNS-të e Google vazhdojnë të pingohen shumë mirë. Koha për të menduar se si mund të monitorojmë nëse kanali i komunikimit është aktiv. Kishin lindur ide të ndryshme për ta bërë këtë. Nuk kisha akses në të gjitha pajisjet. Duhej të mendohesha se si të kuptoj cili kanal është aktiv, pa pasur mundësinë të shikoja asgjë në pajisjet rrjetit. Atëherë një koleg sugjeroi se ndoshta ndjekja e rrugës deri tek serverët publikë mund të ndryshonte në varësi të kanalit të komunikimit që po përdorej për daljen në internet. E kontrollova, dhe kështu rezultoi. Kishin pasur rrugë të ndryshme gjatë ndjekjes.

system(“tracert -d -w 500 8.8.8.8”);

Kështu u krijua një skenar tjetër, madje gjurmimi u shtua për ndonjë arsye në fund të të njëjtit skenar, i cili pinguesej të gjitha pajisjet në rrjet. Kjo është një proces tjetër i gjatë, i cili ekzekutohej në të njëjtën rrjedhë dhe ngadalësonte funksionimin e të gjithë skenarit. Por atëherë nuk ishte kaq e qartë. Sidoqoftë, ai po bënte punën e tij, në kod ishte e shkruar saktësisht se si duhej të ishte gjurmimi për secilin nga kanalet. Kështu filloi të funksionojë sistemi, i cili tashmë monitoronte (e thënë me zë të lartë, pasi nuk kishte grumbullim të ndonjë metri, por thjesht ping) pajisjet rrjetërore (routerët, switchët, wi-fi etj.) dhe kanalet e komunikimit me botën e jashtme. SMS-të vinin rregullisht dhe në diagram ishte gjithmonë e qartë se ku ishte problemi.

Në punën e përditshme, kam qenë i angazhuar me kryqëzimin. Çdo herë më dukej e mërzitshme të hyja në switch-at Cisco për të parë se cilin ndërfaqe duhej të përdorja. Si do të ishte bukur të klikosh në monitorim një objekt dhe të shihje një listë të ndërfaqeve të tij me përshkrime. Kjo do të më kursejë shumë kohë. Për më tepër, në këtë diagram nuk do të isha i detyruar të startoja Putty ose SecureCRT, të futja kredencialet dhe komandat. Thjesht do të klikosh në monitorim, do të shihje se çfarë nevojitej dhe do të shkoja të bëja punën time. Fillova të kërkoj si mund t'i ndërveproj me switch-at. Menjëherë më dolën dy mundësi: SNMP ose të hyja në switch përmes SSH, të futja komandat e nevojshme dhe të parse-ja rezultatin. E hoqa poshtë SNMP për shkak të vështirësisë në zbatim, nuk kisha durim të prisja rezultatin. Me SNMP do të duhej të isha duke kërkuar gjatë në MIB, duke formuar të dhënat për ndërfaqet mbi bazën e këtyre të dhënave. Ka një komandë të shkëlqyer në CISCO

show interface status

Ajo tregon pikërisht atë që më duhet për krushtime. Pse të vuaj me SNMP, kur thjesht dua të shoh rezultatin e këtij komandimi, mendoja. Pas disa kohësh, realizova një mundësi të tillë. Klikoja në faqen e internetit në objekt. Aktivizohej një ngjarje, me të cilën AJAX-i klientit i drejtohej serverit, dhe ai nga ana e tij lidhej përmes SSH me switch-in që më nevojitej (kredencialet ishin të koduara në kod, nuk kishte dëshirë të bëja ndonjë menynë të veçantë ku mund të ndryshoheshin kredencialet nga ndërfaqja, më duhej rezultati sa më shpejt) dërgoja komandën e përmendur më sipër dhe ia ktheja në browser. Kështu fillova të shihja informacionin për interfaces me një klikim të majtë. Kjo ishte jashtëzakonisht e përshtatshme, veçanërisht kur duhej të shihja këtë informacion në disa switch-e njëherësh.

Monitorimi i kanaleve në bazë të gjurmimit në fund doli të mos ishte ideja më e mirë, sepse ndonjëherë bëheshin punë në rrjet dhe gjurmimi mund të ndryshonte, duke bërë që monitorimi të më alarmonte për probleme me kanalin. Por, pas një shtëpie të gjatë analize, kuptoja se të gjitha kanalet funksiononin dhe monitorimi im po më mashtronte. Në fund, i kërkova kolegëve të mi, që menaxhonin switch-at formues të kanaleve, të më dërgonin thjesht syslog, kur ndryshonte gjendja e dukshmërisë së fqinjëve (neighbor). Kështu, ishte shumë më e thjeshtë, më e shpejtë dhe më e saktë se sa gjurmimi. Kur merrja një ngjarje si "neighbor lost", menjëherë dërgoja një njoftim për rënien e kanalit.

Më vonë, u shfaqën rezultatet kur klikohej në objekt, si dhe u shtua SNMP për mbledhjen e disa metrikave, dhe në thelb, kjo ishte e gjitha. Sistemi nuk u zhvillua më tej. Ai bënte gjithçka që më nevojitej, ishte një mjet i shkëlqyer. Shumë lexues ndoshta do të më thonë se për zgjidhjen e këtyre detyrave tashmë ka shumë software në internet. Por në të vërtetë, unë atëherë nuk gjetëm produkte falas të tilla dhe me të vërtetë doja të zhvilloja aftësitë e mia në programim, dhe çfarë mund të bëjë më mirë për këtë, sesa një detyrë reale praktike. Kështu që versioni i parë i monitorimit u përfundua dhe nuk u modifikua më.

Krijimi i kompanisë Audit-Telecom

Me kaluan vetëm nga koha në kohë, fillova të punoj në kompani të tjera përveç punës që bënte, pasi orari i punës më lejonte ta bëja këtë. Kur punon në kompani të ndryshme, aftësitë e tua rriten shumë shpejt në disa fusha dhe horizontet e tua zhvillohen mirë. Ka kompani në të cilat, siç thonë, je si një qepës, një rrethues dhe një muzikant në timpani. Nga njëra anë, është e vështirë, nga ana tjetër, nëse nuk je lenë, bëhesh një specialist i gjerë dhe kjo të lejon të zgjidhësh problemet më shpejt dhe më efektivisht, sepse e di se si funksionon fusha përkatëse.

Miku im Pavel (edhe ai IT) vazhdimisht përpiqej të më inkurajonte për biznesin e tij. Kishim një numër të pafund idesh me variante të ndryshme për punë të vetë. Kjo u diskutua për disa vite. Dhe në fund, asgjë nuk duhej të ndodhte, sepse unë isha skeptic, ndërsa Pavel ishte një fantazist. Çdo herë që ai propozonte një ide, unë gjithmonë dyshoja dhe refuzoja të merrja pjesë. Por na kishte shumë për zemër të hapnim biznesin tonë.

Finalmente, arritëm të gjejmë një opsion që na kënaq të dyve dhe të merremi me atë që dinë të bëjmë. Në vitin 2016, vendosëm të krijojmë një kompani IT që do të ndihmonte bizneset me zgjidhjen e problemeve IT. Ky përfshin vendosjen e sistemeve IT (1C, server terminal, server posti etj.), mbështetje, HelpDesk klasik për përdoruesit dhe administrimin e rrjetit.

Sinjësisht, në momentin e krijimit të kompanisë, nuk e besoja atë rreth 99.9%. Por, ndonjë mënyrë, Pavel arriti të më bindë të provoja dhe prapa, ai kishte të drejtë. Ne kontribuam secili 300,000 rubla, regjistruam një SHPK të re "Audit-Telekom", morëm një zyrë të vogël, bëmë vizitkartë të shkëlqyera, siç ndoshta bën shumica e sipërmarrësve të rinj dhe filluam të kërkojmë klientë. Kërkimi i klientëve - është një histori krejt e veçantë. Ndoshta do të shkruajmë një artikull të veçantë në blogun e korporatës nëse dikujt do t'i interesonte. Telefonat e ftohtë, broshurat dhe të tjera. Kjo nuk na dha asnjë rezultatin. Siç po lexoja tani për tani, nga shumë histori mbi biznesin, shumë varet nga fati. Na ndodhi fat. Dhe vetëm disa javë pas krijimit të firmës, vëllai im Vladimir na u afrua dhe na solli klientin e parë. Nuk do t'ju lodh me detaje të punës me klientët, artikulli nuk është për këtë; do të them vetëm se shkuam për auditim, identifikuam vendet kritike dhe ato u prishën gjatë periudhës kur po merrej vendimi nëse do të bashkëpunonin me ne si outsourcing të vazhduar. Pas kësaj u mor një vendim pozitiv menjëherë.

Më pas, kryesisht përmes rekomandimeve, filluan të shfaqen edhe tjera kompani në shërbim. Helpdesk ishte në një sistem. Lidhet me pajisjet rrjetore dhe serverët në një tjetër, konkretisht si e kishin secili. Disa ruanin shkurtesa, disa përdornin librat e adresave RDP. Monitorimi ishte një sistem krejtësisht i veçantë. Të punosh në sisteme të ndara është shumë e pakëndshme për ekipin. Informacioni i rëndësishëm humbet nga pamja. Për shembull, serveri terminal i klientit bëhet i paaksesueshëm. Menjëherë vijnë kërkesat nga përdoruesit e këtij klienti. Specialist i shërbimit të mbështetjes krijon një kërkesë (ajo ka ardhur me telefon). Po të regjistroheshin incidentet dhe kërkesat në një sistem, specialisti i mbështetjes do të shihte menjëherë se çfarë problemi kishte përdoruesi dhe do t'i fliste atij për këtë, duke u lidhur paralelisht me objektin për të trajtuar situatën. Të gjithë janë në dijeni të situatës taktike dhe punojnë në harmoni. Ne nuk gjetëm një sistem të tillë ku gjithçka është e bashkuar. U bë e qartë se ishte koha për të krijuar produktin tonë.

Vazhdimi i punës në sistemin tonë të monitorimit

Ishte e qartë se sistemi, i cili ishte shkruar më parë, nuk ishte aspak i përshtatshëm për detyrat aktuale. As në aspektin e funksionalitetit dhe as në cilësi. Pra, u mor vendimi për të shkruar sistemin nga e para. Grafikisht, ai duhej të dukej ndryshe. Duhej të ishte një sistem hierarkik, në mënyrë që të mund të hapnim shpejt dhe lehtësisht objektet e nevojshme për klientët e nevojshëm. Skema si në versionin e parë në këtë rast ishte krejtësisht e pavlerë, pasi klientët ishin të ndryshëm dhe nuk kishte rëndësi në cilat ambiente ndodhej pajisja. Kjo tashmë ishte përcaktuar në dokumentacion.

Pra, detyrat:

Struktura hierarkike;
Një pjesë serveri, që mund të vendoset te klienti në formën e një makine virtuale për të mbledhur metrikat që na nevojiten dhe për t'i dërguar në serverin qendror, i cili do t'i përmbledhë dhe do t'i tregojë ato për ne;
Njoftime. Të tilla që nuk mund të humbasin, pasi në atë kohë nuk kishte mundësi që dikush t'i shikonte vazhdimisht monitorin;
Sistemi i kërkesave. Filluan të shfaqeshin klientët, për të cilët ne shërbenim jo vetëm pajisjet serverike dhe rrjetore, por edhe stacionet e punës;
Mundësia për t'u lidhur shpejt me serverët dhe pajisjet nga sistemi;

Detyrat janë caktuar, fillojmë të shkruajmë. Ndërkohë, përpunojmë kërkesat nga klientët. Në atë moment ishim tashmë katër persona. Filluam të shkruajmë menjëherë të dy pjesët, serverin qendror dhe serverin për instalim te klientët. Në këtë moment, Linux nuk ishte më i panjohur për ne dhe është marrë vendimi që makinat virtuale që do të vendosen te klientët do të jenë në Debian. Nuk do të ketë asnjë instalues, thjesht do të krijojmë projektin e pjesës serverike në një makinë virtuale të caktuar dhe më pas thjesht do ta klonojmë te klienti përkatës. Kjo ishte një tjetër gabim. Më vonë u kuptua se në një skemë të tillë mekanizmi i azhurnimeve nuk ishte plotësisht i punuar. Domethënë, ne shtonim ndonjë funksionalitet të ri dhe më pas kishte një problem të madh për ta shpërndarë atë në të gjitha serverët e klientëve, por për këtë do të kthehemi më vonë, gjithçka në radhë.

Kemi realizuar prototipin e parë. Ai kishte aftësinë të pingonte pajisjet rrjetësore të klientëve dhe serverët tanë dhe t’i dërgonte këto të dhëna në serverin tonë qendror. Ai, nga ana e tij, 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ë e asaj që arritëm, por gjithashtu dhe gabimet amatore që bëmë dhe si më pas na duhej të paguajmë për to me kohë. Pra, e gjithë struktura e objekteve ishte e ruajtur në një skedar të vetëm si një objekt i serializuar. Derisa lidhëm disa klientë me sistemin, gjithçka ishte më shumë-më pak në rregull, megjithëse ndonjëherë kishte disa artefakte që ishin krejtësisht të paqartë. Por kur lidhëm një duzinë serverësh me sistemin, filluan mrekullira të çuditshme. Ndonjëherë, pa ndonjë shkak të qartë, të gjithë objektet në sistem thjesht shuheshin. Është e rëndësishme të theksohet se serverët që kishin klientët po dërgonin të dhëna në serverin qendror çdo disa sekonda përmes një kërkese POST. Lexuesi i kujdesshëm dhe programatori me përvojë tashmë ka kuptuar se problemi që ishte shfaqur ishte aksesimi i shumëfishtë të atij skedari ku ishte ruajtur objekti i serializuar nga rrjedha të ndryshme në të njëjtën kohë. Dhe pikërisht kur ndodhte kjo, shfaqeshin mrekullira me zhdukjen e objekteve. Skedari thjesht bëhej bosh. Por kjo u zbulua jo menjëherë, por vetëm gjatë eksplorimit me disa serverë. Gjatë kësaj kohe u shtua funksionaliteti për skanimin e porteve (serverët dërgonin në qendër jo vetëm informacionin mbi disponueshmërinë e pajisjeve, por edhe për portet që ishin të hapura në to). Kjo u realizua duke e thirrur komandën:

$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);

rezultatet shpesh ishin të gabuara dhe skanimi zgjaste shumë. Plotësisht e harrova ping-un, ai u ekzekutua përmes fping:

system("fping -r 3 -t 100 {$this->ip}");

Kjo gjithashtu nuk ishte paralelizuar dhe prandaj procesi ishte shumë i gjatë. Më vonë në fping u dërgua menjëherë lista e të gjithë IP adresave që duhej të kontrolloheshin dhe morëm një listë të gatshme të atyre që iu përgjigjën. Ndryshe nga ne, fping dinte të paralelizonte proceset.

Një tjetër punë e zakonshme ishte konfigurimi i disa shërbimeve përmes WEB. Për shembull, ECP nga MS Exchange. Në thelb, kjo është thjesht një lidhje. Dhe ne vendosëm që duhet të na jepnin mundësinë për të shtuar ato lidhje drejtpërdrejt në sistem, në mënyrë që të mos kërkonim në dokumentacion ose ndonjë vend tjetër në shënime se si të hynim në ECP-në e një klienti të caktuar. Kështu lindi koncepti i lidhjeve burimore për sistemin, funksionaliteti i tyre është i aksesueshëm edhe sot dhe nuk ka pësuar ndryshime, mirë, pothuajse.

Puna e lidhjeve burimore në Veliam

Koneksionet e largëta

Ja si duket në praktikë në versionin aktual të Veliam

Një nga detyrat ishte lidhja e shpejtë dhe e lehtë me serverët, të cilët tashmë ishin shumë (më shumë se njëqind) dhe kalimi përmes milionave lidhjeve të ruajtura RDP ishte tejet e pakëndshme. Na duhej një mjet. Ekziston në internet një softuer që paraqet diçka si një libër adresash për këto lidhje RDP, por ato nuk janë të integruara me sistemin e monitorimit, dhe nuk mund të ruash llogaritë. Të tërhiqesh çdo herë llogaritë për klientë të ndryshëm është një ferr, kur në një ditë lidhem disa herë me serverë të ndryshëm. Për SSH, gjërat janë pak më të mira, ka shumë softuer të mirë që ofron mundësinë për të organizuar këto lidhje në dosje dhe për të ruajtur llogaritë e tyre. Por ka dy probleme. E para — për lidhjet RDP dhe SSH nuk gjetëm një program të vetëm. E dyta — nëse në një moment nuk kam në dorë kompjuterin tim dhe më duhet të lidhem shpejt, ose thjesht e kam rindërtuar sistemin, do të duhet të kërkoj në dokumentacion për të parë llogarinë e këtij klienti. Kjo është e pakëndshme dhe një humbje kohe.

Struktura hierarkike që na nevojitej për serverët e klientëve tashmë ekzistonte në produktin tonë të brendshëm. Duhej vetëm të mendonim se si të lidhim shpejt me pajisjet e nevojshme. Për fillim, të paktën brenda rrjetit tonë.

Duke pasur parasysh se klienti ynë në sistemin tonë ishte shfletuesi, i cili nuk kishte qasje në burimet lokale të kompjuterit, për të thjesht për të marr një komandë dhe për të nisur aplikacionin që na nevojitej, u mendua për të bërë gjithçka përmes “Windows custom url scheme”. Kështu erdhi në jetë një “plugin” për sistemin tonë, që thjesht përfshinte Putty dhe Remote Desktop Plus dhe gjatë instalimit regjistronte URI-në e skemës në Windows. Tani, kur donim të lidhnim me objektin përmes RDP ose SSH, ne të shtypnim këtë veprim në sistemin tonë dhe aktivizohej puna e Custom URI. Nisnin standardi mstsc.exe i integruar në Windows ose putty, i cili ishte pjesë e “plugin-it”. E përmend fjalën plugin në mes thonjëzave, sepse nuk është një plugin shfletuesi në sensin klasik.

Kjo ishte tashmë ndonjë gjë. Një libër adresash komod. Sidomos në rastin e Putty, gjithçka ishte mirë, sepse mund të pranoja si parametra hyrës IP-në dhe emrin e përdoruesit e fjalëkalimin. Pra, për serverët Linux në rrjetin tim, ne lidhnim me vetëm një klikim pa futur fjalëkalimet. Por me RDP nuk është kaq e thjeshtë. Në mstsc standard nuk mund të jepeshin akreditimet si parametra. Në ndihmë erdhi Remote Desktop Plus. Ai e lejonte këtë. Tani ne shijojmë pa të, por për një kohë të gjatë ai ishte një ndihmës i besueshëm në sistemin tonë. Me sitet HTTP(S) gjithçka ishte e thjeshtë, ato thjesht hapej në shfletues dhe gjithë. E përshtatshme dhe praktike. Por kjo ishte lumturi vetëm në rrjetin e brendshëm.

Duke pasur parasysh se shumica e problemeve i zgjidhim nga zyra, mënyra më e thjeshtë ishte të bënim VPN për klientët. Kështu, mund të lidhnim edhe me ta nga sistemi ynë. Por ndonjëherë ishte paksa e pakëndshme. Për çdo klient duhej të mbaja në çdo kompjuter një sasi të madhe të ruajtur. VPN Lidhjet dhe përpara se të lidhesha me ndonjë, duhej të aktivizoja VPN-in përkatës. Ne e përdorëm këtë zgjidhje për një kohë të gjatë. Por numri i klientëve po rritej, numri i VPN-eve gjithashtu dhe gjithë kjo filloi të bëhej ngarkesë dhe duhej të bënim diçka lidhur me këtë. Sidomos ishim në lot pas ri-instalim të sistemit, kur duhej të futnim përsëri dhjetëra lidhje VPN në profilin e ri të Windows. Mjaft më me këtë, thashë dhe fillova të mendoj se çfarë mund të bëjmë për këtë.

Ishte zakon që të gjithë klientët të kishin si ruterë pajisje nga firma e njohur Mikrotik. Ato janë tepër funksionale dhe të përshtatshme për të përmbushur pothuajse çdo detyrë. Nga ana tjetër, probleme kishim me 'rrëmbimin' e tyre. Ne e zgjidhëm këtë problem thjesht duke mbyllur të gjitha qasjet nga jashta. Por duhej të kishim njëfarë qasjeje te ata, pa shkuar fizikisht te klienti, për shkak se kjo ishte e gjatë. Thjesht krijuam tunel për secilin Mikrotik dhe i ndamë ata në një grup të veçantë, pa ndonjë ruterizim, në mënyrë që të mos kishte bashkimit të rrjetit tonë me rrjetet e klientëve dhe mes rrjetesh.

Iu bë ideja që, kur të klikoj në objektin e nevojshëm në sistem, serveri qendror i monitorimit, duke ditur llogaritë SSH të të gjithë mikrotiqëve të klientëve, të lidhte me të duhurin, të krijonte një rregull për kalimin në hostin e duhur me portin e nevojshëm. Këtu ka disa çështje. Ky zgjidhje nuk është universale — do të funksionojë vetëm për mikrotiq, pasi sintaksa e komandave është unike për çdo ruter. Po ashtu, këto kalime duhej të hiqeshin ndonjëherë, por pjesa server e sistemit tonë praktikisht nuk mund të ndjekë nëse unë përfundova seancën time të punës në RDP. Dhe një kalim i tillë është një hapësirë e madhe për klientin. Nuk kemi ndjekur universalisht, pasi produkte përdorej vetëm brenda kompanisë sonë dhe nuk kishte mendime për ta sjellë në publik.

Çdo problem u zgjidh në mënyrën e vet. Kur u krijua rregulli, ky portim ishte i aksesueshëm vetëm për një adresë IP të jashtme specifike (nga e cila ishte inicializuar lidhja). Kështu që u arrit të shmangen vrimat e sigurimit. Por me çdo lidhje të tillë, një rregull shtohej në mikrotik në faqen NAT dhe nuk fshihej. Të gjithë e dinë se sa më shumë rregulla të ketë aty, aq më shumë ngarkohet procesori i router-it. Po ashtu, nuk mund ta pranoja që një ditë të hyja në ndonjë mikrotik dhe aty të ishin qindra rregulla të vdekura që nuk ishin të nevojshme për askënd.

Duke qenë se serveri ynë nuk mund të ndjekë gjendjen e lidhjes, le të ndjekë mikrotik vetë. Kështu që shkrova një skript që ndjekte vazhdimisht të gjitha rregullat e portimit me një përshkrim të caktuar (description) dhe kontrollonte nëse kishte lidhje TCP që përputhej me rregullin. Nëse e tillë nuk ishte për një kohë të gjatë, atëherë ndoshta lidhja kishte përfunduar dhe portimi mund të fshihej. Të gjitha dolën mirë, skripti funksionoi shumë mirë.

Kështu që ja ai:

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ë ishte bërë më bukur, më shpejt, etj., por funksionoi, nuk e ngarkonte mikrotikun dhe e përballonte shkëlqyer. Më në fund, mundëm të lidhemi me serverët dhe pajisjet rrjetore të klientëve me një klik të vetëm. Pa ngritur VPN dhe pa futur fjalëkalime. Punimi me sistemin u bë realisht shumë i përshtatshëm. Koha për mbështetje u shkurtua, dhe të gjithë ne e kalonim kohën në punë, jo duke u lidhur me objektet e nevojshme.

Backup Mikrotik

Ne kemi pasur të konfiguruar kopjimin e të gjitha mikrotikëve në FTP. Në përgjithësi, gjithçka ka qenë në rregull. Por kur duhej të merrnim backup-in, duhet të hapnim këtë FTP dhe të kërkonim atje. Kemi sistemin ku janë regjistruar të gjitha routerat, dimë të komunikojmë me pajisjet përmes SSH. Pse të mos e bëjmë që sistemi të marrë automatikisht çdo ditë backup-et nga të gjithë mikrotikët, mendova. Dhe fillova të realizoj. U lidhëm, morëm backup-in dhe e transferuam në magazinë.

Kodi i skriptit në PHP për të marrë backup-in nga mikrotiku:

<?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-u merret në dy forma — binar dhe konfigurim tekstual. Binarja ndihmon për të rikuperuar shpejt konfigurimin e nevojshëm, ndërsa konfigurimi tekstual lejon të kuptohet çfarë duhen bërë nëse ndodhi një ndërrim i detyrueshëm i pajisjeve dhe binarja nuk mund të ngarkohet mbi të. Kështu, morëm një veçori të re të dobishme në sistem. Ndërsa për shtimin e mikrotikrave të rinj, nuk kishte nevojë të bëhej asnjë konfigurim, thjesht shtove objektin në sistem dhe i dhe llogarinë SSH. Më pas, sistemi kujdesej vet për marrjen e backup-eve. Në versionin aktual të SaaS Veliam, kjo veçori ende nuk është e pranishme, por së shpejti do ta portojmë.

Screenshot-et se si dukej në sistemin e brendshëm

Kalimi në ruajtje normale në bazën e të dhënave

Më herët kam shkruar për shfaqjen e artefakteve. Ndonjëherë lista e objekteve në sistem thjesht zhdukej, ndonjëherë gjatë redaktimit të një objekti, informacioni nuk ruhej dhe duhej ta rinovoja atë deri në tre herë. Kjo është shqetësuese për të gjithë. Zhdukja e objekteve ndodhte rrallë dhe lehtësisht të rikuperohej duke rikuperuar skedarin përkatës, por problemet gjatë redaktimit të objekteve ndodhnin shpesh. Mund të jetë që fillimisht nuk e kam bërë këtë përmes DB-së, sepse nuk më kalonte nëpër mend se si mund të mbash një pemë me të gjitha lidhjet në një tabelë të sheshtë. Ajo është e sheshtë, ndërsa një pemë është hierarkike. Por një zgjidhje e mirë për akses të shumëfishtë, dhe më pas (kur sistemi komplikohej) për transaksionet — kjo është SGBD. Sigurisht, nuk jam i pari që kam hasur këtë problem. Fillova të kërkoj në Google. Doli se gjithçka ishte menduar përpara me mua dhe ekzistojnë disa algoritme që ndërtuan një pemë nga një tabelë të sheshtë. Pasi e shqyrtova çdo një prej tyre, implementova një nga ato. Por kjo ishte një version i ri i sistemit, pasi në thelb u desh të shkruaja përsëri shumë gjëra për këtë arsye. Rezultati ishte i parashikueshëm, problemet e sjelljes rastësore të sistemit u zhduken. Disa mund të thonë se gabimet ishin shumë amatore (skripte njëkanalëshe, ruajtja e informacionit për të cilin ishte akses i shumëfishtë në të njëjtën kohë nga drejtime të ndryshme në një skedar etj.) në fushën e zhvillimit të softuerit. Mund të jetë e vërtetë, por puna ime kryesore ishte administrimi, dhe programimi ishte një aktivitet anësor për kënaqësi, dhe thjesht nuk kisha përvojë në punën në ekip me programuesit, aty ku gjëra kaq elementare do të më tregonin mençurisht kolegët më të mëdhenj. Prandaj kam mësuar këto gjëra përmes përvojës, por e kam bërë atë shumë mirë. Po ashtu, puna ime është dhe takime me klientët, dhe veprimet e drejtuara për të promovuar kompaninë, si dhe një mori çështjesh administrative brenda kompanisë dhe shumë, shumë gjëra të tjera. Por ashtu siç është, ajo që ishte tashmë — ishte e kërkuar. Djemtë dhe unë vetë përdorim produktin në punën e përditshme. Kishim edhe ide që ishin në të vërtetë të dështuar, dhe zgjidhje për të cilat ishte shpenzuar kohë, dhe në fund u kuptua se ishte një instrument jo funksional që askush nuk e përdorte dhe që nuk arriti në Veliam.

Shërbimi i Mbështetjes — HelpDesk

Nuk do ishte e tepërt të përmendej si u krijua HelpDesk. Në të vërtetë, kjo është një histori e veçantë, pasi në Veliam kjo është versioni i tretë krejtësisht i ri, që ndryshon nga të gjitha të mëparshmet. Tani është një sistem i thjeshtë, intuitiv pa zbukurime të panevojshme dhe me mundësinë për t'u integruar me domenin, si dhe me akses në këtë profil përdoruesi nga çdo vend përmes një lidhjeje në email. Dhe ajo që është më e rëndësishme, ka mundësinë në çdo kohë (qoftë në shtëpi ose në zyrë) për t'u lidhur me kërkuesin përmes VNC direkt nga kërkesa pa VPN ose kalime portash. Do të tregoj se si arritëm këtu, çfarë ndodhi më parë dhe cilat ishin zgjidhjet e tmerrshme.

Ne kemi lidhur me përdoruesit përmes TeamViewer-it, i njohur për të gjithë. Në të gjitha kompjuterat e përdoruesve që ne shërbejmë është instaluar TV. Gjëja e parë që bëmë gabim dhe më pas e hoqëm - ishte lidhja e çdo klienti HWID me harduerin. Si hynte një përdorues në sistemin HW për të lënë një kërkesë? Përveç TV-së, në kompjuterët kishim instaluar një utilitar special, i shkruar në Lazarus (disa do të lëvizin sy të gjerë, ndoshta madje do të bëjnë një kërkim në Google se çfarë është, por më së miri të shpjegoj se nga gjuhët e kompilueshme, unë dija Delphi, dhe Lazarus është pothuajse të njëjtën gjë, vetëm falas). Përdoruesi aktivizonte një batnik të veçantë, që gjithashtu aktivizonte këtë utilitar, e cila lexonte HWID e sistemit dhe më pas aktivizohej shfletuesi për të bërë autentifikimin. Pse u bë kjo? Në disa kompani, numërimi i përdoruesve të shërbyer bëhet individual, dhe çmimi i shërbimit për çdo muaj formohet në bazë të numrit të njerëzve. Kjo është e qartë, do të thoni ju, por pse lidhen me harduerin? Shumë thjesht, disa individë, ktheheshin në shtëpi dhe bënin një kërkesë nga laptopi i shtëpisë me stilin “bëni çdo gjë këtu të duket bukur”. Përveç leximit të HWID e sistemit, utilitari nxirrte nga regjistri ID-në aktuale të TeamViewer-it dhe gjithashtu e transmetonte te ne. TeamViewer ka një API për integrim. Ne bëmë këtë integrim. Mirëpo, kishte një pengesë. Përmes këtyre API-ve nuk mund të lidhej me kompjuterin e përdoruesit nëse ai nuk e iniciativuar qartë këtë sesion dhe pas përpjekjes për t'u lidhur me të, ai duhet gjithashtu të klikonte “konfirmo”. Në atë moment, na dukeshin logjike që askush nuk duhet të lidhet pa lejen e përdoruesit, dhe pasi që njeriu është përpara kompjuterit, ai gjithashtu do të iniciativë sesionin dhe do të përgjigjet pozitivisht në kërkesën për lidhje të largët. Çdo gjë nuk ishte ashtu. Aplikantët harrojnë të nisin sesionin, dhe ne duhej t'u thonim këtë gjatë bisedës telefonike. Kjo merrte kohë dhe nervozonte të dyja palët e procesit. Më shumë se kaq, nuk ishte çudi që ndodhnin raste kur një njeri lë një kërkesë, por lejon të lidhem vetëm kur ai del në drekë. Sepse problemi nuk ishte kritik dhe nuk donte që procesi i tij të ndërpritej. Kështu që ai nuk do të klikoje asnjë buton për të lejuar lidhjen. Kështu që u krijua një funksion tjetër gjatë autentifikimit në HelpDesk - leximi i ID-së së TeamViewer-it. Ne e dinim fjalëkalimin e përhershëm, i cili ishte përdorur gjatë instalimit të TeamViewer-it. Saktësisht, vetëm sistemi e dinte atë, pasi ishte i integruar në instalues dhe me sistemin tonë. Si rezultat, kishte një buton lidhjeje nga aplikimi, i cili me një klikim nuk duhej të priste asgjë dhe menjëherë hapte TeamViewer dhe ndodhi lidhja. Në fund të fundit u bënë dy lloje të lidhjeve të mundshme. Përmes API-së zyrtare të TeamViewer-it dhe tonën të prodhuar vetë. Për habinë time, që i pari pothuajse menjëherë u braktis, megjithëse ishte udhëzim të përdorej vetëm në raste të veçanta dhe kur përdoruesi jepte miratimin për këtë. Sidoqoftë, tani kërkohet siguria. Por rezultoi se aplikantët nuk e kishin nevojë këtë. Ata ishin të gjithë absolutisht të gatshëm që të lidhen pa nevojën e një butoni konfirmimi. Dhe si rezultat, më vonë funksionaliteti i lidhjes përmes API-së u hoq për shkak të pamjaftueshmërisë.

Kalimi në shumëprocese në Linux

Kohë më parë kishte filluar të shfaqej pyetja për përshpejtimin e kalimit të skanerit të rrjetit për të evidentuar hapjen e një liste të caktuar portesh dhe thjesht një pingim të objekteve të rrjetit. Zgjidhja e parë që vijën në mendje është — shumëprocese. Duke qenë se kohëzgjatja kryesore që shpenzohet për ping është pritja e kthimit të paketës, dhe pingimi tjetër nuk mund të fillojë derisa paketa e mëparshme të kthehet, në kompanitë që kanë edhe 20+ serverë përveç pajisjeve të rrjetit, kjo funksiononte tashmë mjaft ngadalë. Qëllimi është që një paketë mund të humbasë dhe nuk është e nevojshme që administratorit të sistemit t'i njoftohet menjëherë për këtë. Ai thjesht do të ndalë së perceptuari këtë spamin shumë shpejt. Kështu që duhet të pingojmë çdo objekt më shumë se një herë përpara se të nxjerrim përfundimin për paaftësinë e tij. Nëse nuk hyjmë shumë në detaje, duhet të bëjmë paralelizimin, sepse nëse nuk e bëjmë këtë, është shumë e mundshme që administratorin e sistemit ta njohë problemin nga klienti dhe jo nga sistemi i monitorimit.

PHP vetë nga kutia nuk e mbështet shumëprocesorësinë. Ai mbështet shumëproçesinë, mund të bëhen fork. Por, unë tashmë kisha shkruar mekanizmin e pyetjeve dhe doja të bëja që një herë të lexoja të gjitha nyjat që më nevojiteshin nga DB, të pingoja të gjithë njëherësh, të prisja përgjigjen nga secili dhe vetëm pasi të kisha marrë përgjigjet, të shkruaja të dhënat. Kjo kursente numrin e kërkesave për lexim. Kjo ide përputhej përsosmërisht me shumëprocesorin. Për PHP ka një modul PThreads, i cili mundëson vërtet shumëproçesorin, por duhej të punoja shumë për ta konfiguruar këtë në PHP 7.2, por u bë. Skanime të porteve dhe ping ishin bërë të shpejta. Dhe në vend që, për shembull, të merrte 15 sekonda për një cikël më parë, këtë proces tani e merrte 2 sekonda. Ishte një rezultat i mirë.

Audit i shpejtë i kompanive të reja

Si ndodhi që u krijua funksionaliteti për mbledhjen e metrikave dhe karakteristikave të ndryshme të harduerit? Është shumë e thjeshtë. Ndonjëherë na porositin thjesht një auditim të infrastrukturës aktuale IT. Po ashtu, e njëjta gjë nevojitet për të përshpejtuar auditet e klientëve të rinj. Duhej diçka që do të lejonte të hynim në një kompani të mesme ose të madhe dhe të orientoheshim shpejt mbi atë që ata kanë. Ping-un në rrjetin e brendshëm e bllokojnë, sipas mendimit tim, vetëm ata që duan të komplikojnë jetën e vet, dhe në përvojën tonë, të tillë janë pak. Por, ata gjithashtu ekzistojnë. Prandaj, është e mundur të skanohet shpejt rrjeti për prezencën e pajisjeve përmes një ping-u të thjeshtë. Më pas, mund t'i shtojmë ato dhe t'i skanojmë për porte të hapura që na interesojnë. Në thelb, ky funksionalitet tashmë ekzistonte, vetëm se duhej shtuar një komandë nga serveri qendror në atë subordinate, në mënyrë që ky i fundit të skanojë rrjetet e caktuara dhe të shtojë në listë gjithçka që gjen. Harrova të përmend, supozohej që ne tashmë kishim një pamje të gatshme me sistemin e konfiguruar (serveri monitorues subordinate) që mund ta shpërndanim thjesht te klienti gjatë auditi dhe ta lidhim me cloud-in tonë.

Porosia e auditu zakonisht përfshin një sasi të madhe informacioni dhe një prej tyre është - cilat janë saktësisht pajisjet në rrjet. Së pari, na interesonin serverët Windows dhe punonjësit Windows në përbërje të domenit. Në kompani të mesme dhe të mëdha mungesa e domenit është ndoshta një përjashtim nga rregulli. Për të folur një gjuhë të përbashkët, një mesatare, në mendimin tim, është mbi 100 persona. Duhej të gjenim një mënyrë për të mbledhur të dhëna nga të gjitha makinat dhe serverët Windows, duke ditur IP-në e tyre dhe llogarinë e administratorit të domenit, por pa instaluar ndonjë softuer në secilën prej tyre. Dëgjuam përndihmën e WMI. Windows Management Instrumentation (WMI) në një përkthim të drejtpërdrejtë - është një mjet menaxhimi për Windows. WMI është një nga teknologjitë bazë për menaxhimin dhe monitorimin e drejtpërdrejtë të pjesëve të ndryshme të infrastrukturës kompjuterike nën platformën Windows. E marrë nga wiki. Më pas, duhej të merreshim përsëri me mbledhjen e wmic (ky është klienti WMI) për Debian. Pas përfundimit të gjithçkaje, mbeti thjesht të pyesim përmes wmic nodet e nevojshme për informacionin e kërkuar. Përmes WMI mund të nxjerrim pothuajse çdo informacion nga një kompjuter Windows dhe, më shumë, përmes tij mund të menaxhojmë kompjuterin, për shembull, të dërgojmë në rinisje. Ashtu u krijua mbledhja e informacionit për stacionet dhe serverët Windows në sistemin tonë. Një avantazh shtesë ishte informacioni aktual mbi treguesit e ngarkesës së sistemit. I kemi kërkuar ata më shpesh, ndërsa informacionin për harduerin më rrallë. Pas kësaj, të kryesh auditur u bë pak më e këndshme.

Vendimi për shpërndarjen e softuerit

Ne e përdorim sistemin çdo ditë, dhe ai është gjithmonë i hapur për çdo punonjës teknik. Dhe menduam se mund të ndajmë me të tjerët atë që kemi. Sistemi ende nuk ishte plotësisht i gatshëm për t'u shpërndarë. Duhej të rregullohej shumë që versioni lokal të shndërrohej në SaaS. Kjo përfshinte ndryshime të shumta teknike në funksionimin e sistemit ( lidhje të largët, shërbim mbështetje), analiza e moduleve në lidhje me licencimin, shardimi i bazave të të dhënave të klientëve, dhe shkallëzimi i secilës nga shërbimet, si dhe zhvillimi i sistemeve të përditësimeve automatik për të gjitha pjesët. Por për këtë do të flasim në pjesën e dytë të artikullit.

Update

Pjesa e dytë

Burimi: habr.com