🥇Nga kontraktimi në zhvillim (Pjesa 1)

Përshëndetje të gjithëve, emri im është Sergey Emelyanchik. Unë jam kreu i kompanisë Audit-Telecom, zhvilluesi dhe autori kryesor i sistemit Veliam. Vendosa të shkruaj një artikull se si shoku im dhe unë krijuam një kompani outsourcing, shkruam softuer për veten tonë dhe më pas filluam ta shpërndajmë atë tek të gjithë nëpërmjet sistemit SaaS. Për mënyrën se si kategorikisht nuk besoja se kjo ishte e mundur. Artikulli do të përmbajë jo vetëm një histori, por edhe detaje teknike se si u krijua produkti Veliam. Përfshirë disa pjesë të kodit burimor. Do t'ju tregoj se çfarë gabimesh kemi bërë dhe si i korrigjuam më vonë. Kishte dyshime nëse do të publikohej një artikull i tillë. Por mendova se ishte më mirë ta bëja, të merrja komente dhe të përmirësohesha, sesa të mos publikoja artikullin dhe të mendoja se çfarë do të kishte ndodhur nëse...

parahistorinë

Kam punuar në një kompani si punonjës IT. Kompania ishte mjaft e madhe me një strukturë të gjerë rrjeti. Nuk do të ndalem në përgjegjësitë e mia të punës, do të them vetëm se ato definitivisht nuk përfshinin zhvillimin e asgjëje.

Ne kishim monitorim, por thjesht për interes akademik doja të provoja të shkruaja më të thjeshtën time. Ideja ishte kjo: doja që të ishte në ueb, në mënyrë që të mund të hyja lehtësisht pa instaluar asnjë klient dhe të shihja se çfarë po ndodhte me rrjetin nga çdo pajisje, duke përfshirë një pajisje celulare përmes Wi-Fi, dhe gjithashtu vërtet donte të kuptonte shpejt se çfarë ka pajisje në dhomë që është bërë "mopas" sepse... kishte kërkesa shumë strikte për kohën e përgjigjes ndaj problemeve të tilla. Si rezultat, lindi një plan në kokën time për të shkruar një faqe të thjeshtë ueb në të cilën kishte një sfond jpeg me një diagram rrjeti, për të prerë vetë pajisjet me adresat e tyre IP në këtë foto dhe për të shfaqur përmbajtje dinamike në krye të foto në koordinatat e kërkuara në formën e një adrese IP të gjelbër ose të kuqe ndezëse. Detyra është vendosur, le të fillojmë.

Më parë, programoja në Delphi, PHP, JS dhe shumë sipërfaqësisht C++. Unë e di mjaft mirë se si funksionojnë rrjetet. VLAN, Routing (OSPF, EIGRP, BGP), NAT. Kjo ishte e mjaftueshme që unë të shkruaja vetë një prototip primitiv monitorimi.

E shkrova atë që kisha në mendje në PHP. Serveri Apache dhe PHP ishin të aktivizuar. Windows sepse Linux për mua në atë moment ishte diçka e pakuptueshme dhe shumë e vështirë, siç doli më vonë, gabohesha shumë dhe në shumë vende Linux shumë më e thjeshtë Windows, por kjo është një temë më vete, dhe të gjithë e dimë se sa luftëra të shenjta ka mbi këtë temë. Planifikuesi i detyrave Windows Ekzekutova një skript PHP në intervale të shkurtra (nuk më kujtohet saktësisht, por diçka si një herë në tre sekonda) që anketonte të gjitha objektet me një ping të thjeshtë dhe e ruante gjendjen në një skedar.

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

Po, po, puna me një bazë të dhënash në atë moment gjithashtu nuk ishte e zotëruar për mua. Nuk e dija që ishte e mundur të paralelizoheshin proceset, dhe kalimi nëpër të gjitha nyjet e rrjetit mori shumë kohë, sepse ... kjo ndodhi në një fije. Problemet u shfaqën veçanërisht kur disa nyje nuk ishin të disponueshme, sepse secili prej tyre e vonoi skenarin për 300 ms. Në anën e klientit kishte një funksion të thjeshtë looping që, në intervale prej disa sekondash, shkarkonte informacionin e përditësuar nga serveri me një kërkesë Ajax dhe përditësonte ndërfaqen. Epo, atëherë, pas 3 ping të pasuksesshëm me radhë, nëse një faqe në internet me monitorim ishte e hapur në kompjuter, luajti një përbërje gazmore.

Kur gjithçka funksionoi, u frymëzova shumë nga rezultati dhe mendova se mund t'i shtoja më shumë (për shkak të njohurive dhe aftësive të mia). Por gjithmonë nuk më kanë pëlqyer sistemet me një milion tabela, të cilat mendoja se atëherë, dhe ende i mendoj edhe sot e kësaj dite, janë të panevojshme në shumicën e rasteve. Doja të vendosja atje vetëm atë që do të më ndihmonte vërtet në punën time. Ky parim mbetet themelor për zhvillimin e Veliam deri më sot. Më tej, kuptova se do të ishte shumë mirë nëse nuk do të më duhej ta mbaja monitorimin hapur dhe të dija për problemet, dhe kur të ndodhte, hape faqen dhe shiko se ku ndodhet kjo nyje problematike e rrjetit dhe çfarë të bëj me të më pas . Në një farë mënyre nuk lexova email në atë kohë, thjesht nuk e përdora atë. Kam hasur në internet që ka porta SMS në të cilat mund të dërgoni një kërkesë GET ose POST dhe ata do të dërgojnë një SMS në celularin tim me tekstin që shkruaj. E kuptova menjëherë se e doja vërtet këtë. Dhe fillova të studioj dokumentacionin. Pas ca kohësh ia dola dhe tani mora një SMS në lidhje me problemet në rrjet në telefonin tim celular me emrin e një "objekti të rënë". Edhe pse sistemi ishte primitiv, ai u shkrua nga unë vetë dhe gjëja më e rëndësishme që më motivoi ta zhvilloja ishte se ishte një program aplikimi që më ndihmoi vërtet në punën time.

Dhe më pas erdhi dita kur një nga kanalet e internetit u ndërpre në punë dhe monitorimi im nuk më la të dija për këtë. Meqenëse Google DNS ende bën ping në mënyrë të përsosur. Është koha të mendoni se si mund të monitoroni që kanali i komunikimit është i gjallë. Kishte ide të ndryshme se si ta bëni këtë. Nuk kisha akses në të gjitha pajisjet. Ne duhej të kuptonim se si të kuptonim se cili nga kanalet është drejtpërdrejt, por pa qenë në gjendje ta shikonim disi në vetë pajisjet e rrjetit. Më pas, një koleg doli me idenë se është e mundur që gjurmimi i rrugës drejt serverëve publikë mund të ndryshojë në varësi të kanalit të komunikimit që përdoret aktualisht për të hyrë në internet. Kontrollova dhe kështu doli. Gjatë gjurmimit kishte rrugë të ndryshme.

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

Kështu që u shfaq një skenar tjetër, ose më saktë, për ndonjë arsye gjurma u shtua në fund të të njëjtit skenar, i cili pingoi të gjitha pajisjet në rrjet. Në fund të fundit, ky është një proces tjetër i gjatë që u ekzekutua në të njëjtën fillesë dhe ngadalësoi punën e të gjithë skenarit. Por atëherë nuk ishte aq e qartë. Por në një mënyrë apo tjetër, ai bëri punën e tij, kodi përcaktonte rreptësisht se çfarë lloj gjurmimi duhet të ishte për secilin prej kanaleve. Kështu filloi të funksionojë sistemi, i cili tashmë monitoronte (thahej me zë të lartë, sepse nuk kishte asnjë koleksion metrikë, por vetëm ping) pajisjet e rrjetit (ruterat, çelsat, wi-fi, etj.) dhe kanalet e komunikimit me botën e jashtme. . Mesazhet SMS vinin rregullisht dhe diagrami tregonte gjithmonë qartë se ku ishte problemi.

Më tej, në punën e përditshme më duhej të bëja kryqëzim. Dhe u lodha duke shkuar te çelsat Cisco çdo herë për të parë se cilën ndërfaqe të përdor. Sa bukur do të ishte të klikoni mbi një objekt në monitorim dhe të shihni një listë të ndërfaqeve të tij me përshkrime. Do të më kursente kohë. Për më tepër, në këtë skemë nuk do të kishte nevojë të ekzekutoni Putty ose SecureCRT për të futur llogari dhe komanda. Thjesht klikova mbi monitorim, pashë çfarë duhej dhe shkova të bëja punën time. Fillova të kërkoja mënyra për të bashkëvepruar me çelsat. Menjëherë hasa në 2 opsione: SNMP ose hyrje në çelës përmes SSH, futja e komandave që më duheshin dhe analizimi i rezultatit. Unë e hodha SNMP-në për shkak të kompleksitetit të zbatimit të tij, isha i paduruar për të marrë rezultatin. me SNMP, do t'ju duhet të gërmoni në MIB për një kohë të gjatë dhe, bazuar në këto të dhëna, të gjeneroni të dhëna për ndërfaqet. Ka një ekip të mrekullueshëm në CISCO

show interface status

Ai tregon saktësisht se çfarë më nevojitet për kryqëzime. Pse të shqetësohem me SNMP kur thjesht dua të shoh daljen e kësaj komande, mendova. Pas ca kohësh, e kuptova këtë mundësi. Klikoni në një objekt në një faqe interneti. U shkaktua një ngjarje nga e cila klienti AJAX kontaktoi serverin, dhe ai, nga ana tjetër, u lidh nëpërmjet SSH me çelësin që më duhej (kredencialet ishin të koduara në kod, nuk kishte dëshirë për ta rafinuar atë, për të krijuar disa menu të veçanta ku do të ishte e mundur të ndryshoja llogaritë nga ndërfaqja, më duhej rezultati dhe shpejt) Unë futa komandën e mësipërme atje dhe e dërgova përsëri në shfletues. Kështu që fillova të shoh informacione mbi ndërfaqet me një klikim të miut. Kjo ishte jashtëzakonisht e përshtatshme, veçanërisht kur ju duhej ta shikonit këtë informacion në çelësa të ndryshëm menjëherë.

Monitorimi i kanaleve të bazuara në gjurmë përfundoi duke mos qenë ideja më e mirë, sepse... ndonjëherë kryhej punë në rrjet, dhe gjurmimi mund të ndryshonte dhe monitorimi filloi të më bërtiste se kishte probleme me kanalin. Por pasi kalova shumë kohë për analiza, kuptova se të gjitha kanalet po funksiononin dhe monitorimi im po më mashtronte. Si rezultat, u kërkova kolegëve të mi që menaxhonin çelsat e formimit të kanaleve që thjesht të më dërgonin syslog kur ndryshonte statusi i dukshmërisë së fqinjëve. Prandaj, ishte shumë më e thjeshtë, më e shpejtë dhe më e saktë se gjurmimi. Një ngjarje si fqinji i humbur ka mbërritur dhe unë lëshoj menjëherë një njoftim për kanalin poshtë.

Më tej, disa komanda të tjera u shfaqën kur klikoni në një objekt, dhe SNMP u shtua për të mbledhur disa metrikë, dhe kjo është në thelb ajo. Sistemi nuk u zhvillua kurrë më tej. Ai bëri gjithçka që më duhej, ishte një mjet i mirë. Shumë lexues ndoshta do të më thonë se tashmë ka shumë softuer në internet për të zgjidhur këto probleme. Por në fakt, unë nuk kërkoja në Google produkte të tilla falas në atë kohë dhe doja shumë të zhvilloja aftësitë e mia programuese, dhe çfarë mënyre më të mirë për ta nxitur këtë sesa një problem real aplikimi. Në këtë pikë, versioni i parë i monitorimit përfundoi dhe nuk u modifikua më.

Krijimi i kompanisë Audit-Telekom

Me kalimin e kohës, fillova të punoja me kohë të pjesshme në kompani të tjera, për fat të mirë, orari i punës më lejoi ta bëja këtë. Kur punoni në kompani të ndryshme, aftësitë tuaja në fusha të ndryshme rriten shumë shpejt dhe horizontet tuaja zhvillohen mirë. Ka kompani në të cilat, siç thonë ata, ju jeni një suedez, një korrës dhe një trumpetist. Nga njëra anë, është e vështirë, nga ana tjetër, nëse nuk je dembel, bëhesh gjeneralist dhe kjo të lejon t'i zgjidhësh problemet më shpejt dhe me efikasitet, sepse e di se si funksionon fusha përkatëse.

Miku im Pavel (gjithashtu specialist i IT-së) u përpoq vazhdimisht të më inkurajonte për të filluar biznesin e tij. Kishte ide të panumërta me variacione të ndryshme të asaj që ata po bënin. Kjo është diskutuar prej vitesh. Dhe në fund, nuk duhet të kishte ardhur në asgjë, sepse unë jam një skeptik, dhe Paveli është një ëndërrimtar. Sa herë që ai propozonte një ide, unë gjithmonë nuk besoja në të dhe refuzoja të merrja pjesë. Por ne vërtet donim të hapnim biznesin tonë.

Më në fund, ne mundëm të gjenim një opsion që na përshtatej të dyve dhe të bënim atë që dimë të bëjmë. Në vitin 2016, ne vendosëm të krijonim një kompani IT që do të ndihmonte bizneset të zgjidhnin problemet e IT. Ky është vendosja e sistemeve IT (1C, serveri terminal, serveri i postës, etj.), Mirëmbajtja e tyre, HelpDesk klasik për përdoruesit dhe administrimi i rrjetit.

Sinqerisht, në kohën e krijimit të kompanisë, nuk besoja në të rreth 99,9%. Por në një farë mënyre Pavel mundi të më bënte të provoja, dhe duke parë përpara, doli të kishte të drejtë. Paveli dhe unë ndamë nga 300 rubla secili, regjistruam një LLC të re "Audit-Telecom", morëm me qira një zyrë të vogël, bëmë karta biznesi të lezetshme, mirë, në përgjithësi, si ndoshta shumica e biznesmenëve të papërvojë, fillestarë dhe filluam të kërkonim klientë. Gjetja e klientëve është një histori krejtësisht e ndryshme. Ndoshta ne do të shkruajmë një artikull të veçantë si pjesë e blogut të korporatës nëse dikush është i interesuar. Thirrje të ftohta, fletushka etj. Kjo nuk dha asnjë rezultat. Siç lexova tani nga shumë histori për biznesin, në një mënyrë ose në një tjetër shumë varet nga fati. Ishim me fat. dhe fjalë për fjalë disa javë pas krijimit të kompanisë, vëllai im Vladimir na u afrua, i cili na solli klientin e parë. Nuk do t'ju mërzit me detajet e punës me klientët, nuk është për këtë artikulli, thjesht do të them që ne shkuam për një auditim, identifikuam zonat kritike dhe këto fusha u prishën ndërsa u mor vendimi nëse do të bashkëpunoni me ne në mënyrë të vazhdueshme si kontraktues jashtë. Pas kësaj, menjëherë u mor një vendim pozitiv.

Më pas, kryesisht përmes gojëdhënave nëpërmjet miqve, filluan të shfaqen kompani të tjera shërbimi. Helpdesk ishte në një sistem. Lidhjet me pajisjet e rrjetit dhe serverët janë të ndryshme, ose më mirë të ndryshme. Disa njerëz ruajtën shkurtore, të tjerë përdorën libra adresash RDP. Monitorimi është një sistem tjetër i veçantë. Është shumë e papërshtatshme që një ekip të punojë në sisteme të ndryshme. Një informacion i rëndësishëm humbet nga sytë. Epo, për shembull, serveri i terminalit të klientit u bë i padisponueshëm. Aplikacionet merren menjëherë nga përdoruesit e këtij klienti. Specialisti i mbështetjes hap një kërkesë (është marrë me telefon). Nëse incidentet dhe kërkesat do të regjistroheshin në një sistem, atëherë specialisti i mbështetjes do të shihte menjëherë se cili është problemi i përdoruesit dhe do t'i tregonte atij për të, duke u lidhur njëkohësisht me objektin e kërkuar për të zgjidhur situatën. Të gjithë janë të vetëdijshëm për situatën taktike dhe punojnë në mënyrë harmonike. Ne nuk kemi gjetur një sistem ku të gjitha këto të kombinohen. U bë e qartë se ishte koha për të bërë produktin tonë.

Vazhdoni punën në sistemin tuaj të monitorimit

Ishte e qartë se sistemi që ishte shkruar më parë ishte plotësisht i papërshtatshëm për detyrat aktuale. As nga funksionaliteti dhe as nga cilësia. Dhe u vendos që të shkruhet sistemi nga e para. Grafikisht duhet të dukej krejtësisht ndryshe. Duhet të ishte një sistem hierarkik në mënyrë që të ishte e mundur të hapej shpejt dhe me lehtësi objekti i duhur për klientin e duhur. Skema si në versionin e parë nuk ishte absolutisht e justifikuar në rastin aktual, sepse Klientët janë të ndryshëm dhe nuk kishte fare rëndësi se në cilin ambient ndodheshin pajisjet. Kjo tashmë është transferuar në dokumentacion.

Pra, detyrat:

Struktura hierarkike;
Një lloj pjese serveri që mund të vendoset në ambientet e klientit në formën e një makinerie virtuale për të mbledhur matjet që na nevojiten dhe për ta dërguar në serverin qendror, i cili do t'i përmbledhë të gjitha këto dhe do t'i tregojë neve;
Alarmet. Ato që nuk mund të mungojnë, sepse... në atë kohë nuk ishte e mundur që dikush të ulej dhe të shikonte vetëm monitorin;
Sistemi i aplikimit. Filluan të shfaqen klientë për të cilët ne shërbyem jo vetëm pajisjet e serverit dhe rrjetit, por edhe stacionet e punës;
Aftësia për t'u lidhur shpejt me serverët dhe pajisjet nga sistemi;

Detyrat u caktuan dhe ne filluam të shkruanim. Gjatë rrugës, përpunuam kërkesat nga klientët. Në atë pikë, ishim tashmë katër veta. Filluam të shkruanim të dyja pjesët njëherësh: serverin qendror dhe serverin për instalimin e klientit. Në këtë pikë, Linux nuk ishte më i huaj për ne dhe u vendos që makinat virtuale që do të instaloheshin te klientët do të ishin në DebianNuk do të ketë instalues; thjesht do të krijojmë një projekt nga ana e serverit në një makinë të vetme virtuale dhe pastaj thjesht do ta klonojmë atë te klienti i kërkuar. Ky ishte një tjetër gabim. Më vonë u bë e qartë se ky konfigurim nuk kishte absolutisht asnjë mekanizëm përditësimi. Pra, do të shtonim disa veçori të reja dhe më pas do të ishte një telashe e vërtetë ta shpërndanim atë në të gjithë serverët e klientëve. Por do të merremi me këtë më vonë, në kohën e duhur.

Ne bëmë prototipin e parë. Ai ishte në gjendje të bënte ping pajisjet e rrjetit të klientit dhe serverët që na duheshin dhe t'i dërgonte këto të dhëna në serverin tonë qendror. Dhe ai, nga ana tjetër, i përditësoi këto të dhëna në masë në serverin qendror. Këtu do të shkruaj jo vetëm një histori se si dhe çfarë ishte e suksesshme, por edhe çfarë gabimesh amatore u bënë dhe si më vonë duhej ta paguaja me kohë. Pra, e gjithë pema e objekteve u ruajt në një skedar të vetëm në formën e një objekti të serializuar. Ndërsa lidhëm disa klientë me sistemin, gjithçka ishte pak a shumë normale, megjithëse ndonjëherë kishte disa artefakte që ishin krejtësisht të pakuptueshme. Por kur lidhëm një duzinë serverësh me sistemin, mrekullitë filluan të ndodhin. Ndonjëherë, për ndonjë arsye të panjohur, të gjitha objektet në sistem thjesht zhdukeshin. Është e rëndësishme të theksohet këtu se serverët që klientët kishin dërguar të dhëna në serverin qendror çdo disa sekonda përmes një kërkese POST. Një lexues i vëmendshëm dhe një programues me përvojë tashmë menduan se kishte një problem të aksesit të shumëfishtë në vetë skedarin në të cilin objekti i serializuar ruhej nga tema të ndryshme në të njëjtën kohë. Dhe pikërisht në momentin që po ndodhte kjo, ndodhën mrekullitë me zhdukjen e objekteve. Skedari thjesht u zbraz. Por e gjithë kjo nuk u zbulua menjëherë, por vetëm gjatë funksionimit me disa serverë. Gjatë kësaj kohe, u shtua funksionaliteti i skanimit të portit (serverët dërguan në qendër jo vetëm informacione për disponueshmërinë e pajisjeve, por edhe për portet e hapura në to). Kjo u bë duke thirrur komandën:

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

rezultatet shpesh ishin të pasakta dhe skanimet kërkonin shumë kohë për t'u përfunduar. Kam harruar plotësisht ping, është bërë përmes fping:

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

Edhe kjo nuk u paralelizua dhe për këtë arsye procesi ishte shumë i gjatë. Më vonë, e gjithë lista e adresave IP të kërkuara për verifikim u dërgua menjëherë në fping dhe mbrapa morëm një listë të gatshme të atyre që u përgjigjën. Ndryshe nga ne, fping ishte në gjendje të paralelizonte proceset.

Një punë tjetër rutinë e zakonshme ishte vendosja e disa shërbimeve nëpërmjet WEB-it. Epo, për shembull, ECP nga MS Exchange. Në thelb është vetëm një lidhje. Dhe vendosëm që duhet të jemi në gjendje të shtojmë lidhje të tilla drejtpërdrejt në sistem, në mënyrë që të mos kërkojmë në dokumentacion ose diku tjetër në faqerojtësit se si të qasemi në ECP të një klienti specifik. Kështu u shfaq koncepti i lidhjeve të burimeve për sistemin, funksionaliteti i tyre është i disponueshëm edhe sot e kësaj dite dhe nuk ka ndryshuar, mirë, pothuajse.

Si funksionojnë lidhjet e burimeve në Veliam

Lidhjet në distancë

Kështu duket në veprim në versionin aktual të Veliam

Një nga detyrat ishte lidhja e shpejtë dhe e përshtatshme me serverët, nga të cilët tashmë kishte shumë (më shumë se njëqind) dhe renditja e miliona shkurtoreve të ruajtura paraprakisht të RDP ishte jashtëzakonisht e papërshtatshme. Duhej një mjet. Ka softuer në internet që është diçka si një libër adresash për lidhje të tilla RDP, por ato nuk janë të integruara me sistemin e monitorimit dhe llogaritë nuk mund të ruhen. Futja e llogarive për klientë të ndryshëm çdo herë është ferr i pastër kur lidhni dhjetëra herë në ditë me serverë të ndryshëm. Me SSH, gjërat janë pak më mirë, ka shumë softuer të mirë që ju lejon të organizoni lidhje të tilla në dosje dhe të mbani mend llogaritë prej tyre. Por ka 2 probleme. E para është se ne nuk gjetëm një program të vetëm për lidhjet RDP dhe SSH. E dyta është që nëse në një moment nuk jam në kompjuterin tim dhe më duhet të lidhem shpejt, ose thjesht e riinstalova sistemin, do të më duhet të futem në dokumentacion për të parë llogarinë nga ky klient. Është e papërshtatshme dhe humbje kohe.

Struktura hierarkike që na nevojitej për serverët e klientëve ishte tashmë e disponueshme në produktin tonë të brendshëm. Thjesht duhej të kuptoja se si të lidhja lidhje të shpejta me pajisjet e nevojshme atje. Për fillestarët, të paktën brenda rrjetit tuaj.

Duke pasur parasysh që klienti në sistemin tonë ishte një shfletues që nuk kishte qasje në burimet lokale të kompjuterit, për të nisur thjesht aplikacionin që na duhej me ndonjë komandë, u vendos që gjithçka të bëhej përmes "Windows skemë url-i të personalizuar." Kështu u shfaq një "shtojcë" për sistemin tonë, e cila thjesht përfshinte Putty dhe Remote Desktop Plus dhe, pas instalimit, thjesht regjistroi skemën URI në WindowsTani, sa herë që donim të lidheshim me një objekt nëpërmjet RDP ose SSH, ne do të klikonim atë veprim në sistemin tonë dhe do të aktivizohej URI i Personalizuar. Mstsc.exe standard i integruar në Windows ose PuTTY, i cili u përfshi si pjesë e një "plugin". E vendosa fjalën "plugin" në thonjëza sepse nuk është një plugin shfletuesi në kuptimin klasik.

Kjo ishte të paktën diçka. Një libër adresash i përshtatshëm. Dhe në rastin e Putty, gjithçka ishte në rregull; mund të jepej adresa IP e lidhjes, emri i përdoruesit dhe fjalëkalimi si parametra hyrës. Kjo do të thotë, Linux Ne tashmë po lidheshim me serverat në rrjetin tonë me një klikim, pa futur fjalëkalime. Por RDP nuk është kaq i thjeshtë. Nuk mund t'i kalosh kredencialet si parametra në mstsc standard. Remote Desktop Plus erdhi në ndihmë. Na lejoi ta bënim këtë. Që atëherë ia kemi dalë mbanë pa të, por për një kohë të gjatë, ishte një asistent i besueshëm në sistemin tonë. Faqet HTTP(S) janë të lehta; objekte të tilla thjesht hapen në shfletues dhe kaq. I përshtatshëm dhe praktik. Por kjo ishte vetëm një bekim në rrjetin e brendshëm.

Meqenëse i zgjidhnim shumicën dërrmuese të problemeve nga distanca nga zyra, mënyra më e lehtë ishte të konfiguronim VPN-të për klientët. Pastaj mund të lidheshim me ta nga sistemi ynë. Por prapëseprapë ishte disi e papërshtatshme. Për secilin klient, na duhej të mbanim një mori fjalëkalimesh të ruajtura në secilin kompjuter. VPN Lidhjet, dhe para se të lidhesha me ndonjë, VPN-ja përkatëse duhej të aktivizohej. Ne e përdorëm këtë zgjidhje për një kohë mjaft të gjatë. Por numri i klientëve po rritej, ashtu si edhe numri i VPN-ve, dhe e gjithë kjo po fillonte të bëhej bezdisëse, dhe diçka duhej bërë për këtë. Ishte veçanërisht e dhimbshme pas riinstalimit të sistemit, kur më duhej të rifutja dhjetëra lidhje VPN në një profil të ri të Windows. Thashë, "Mjaft me këtë", dhe fillova të mendoja se çfarë mund të bëhej për këtë.

Ndodhi që të gjithë klientët të kishin pajisje të kompanisë së njohur Mikrotik si ruter. Ato janë shumë funksionale dhe të përshtatshme për të kryer pothuajse çdo detyrë. E keqja është se ata janë "rrëmbyer". Ne e zgjidhëm këtë problem thjesht duke mbyllur të gjithë aksesin nga jashtë. Por ishte e nevojshme që në njëfarë mënyre të kishim akses në to pa ardhur në vendin e klientit, sepse ... është e gjatë. Ne thjesht bëmë tunele për secilin Mikrotik të tillë dhe i ndamë në një pishinë të veçantë. pa asnjë rrugëzim, në mënyrë që të mos ketë lidhje të rrjetit tuaj me rrjetet e klientëve dhe rrjetet e tyre me njëra-tjetrën.

Ideja lindi për t'u siguruar që kur klikoj në objektin që më nevojitet në sistem, serveri qendror i monitorimit, duke njohur llogaritë SSH të të gjithë klientëve Mikrotik, të lidhet me atë të dëshiruar, të krijojë një rregull përcjelljeje në hostin e dëshiruar me porti i kërkuar. Këtu ka disa pika. Zgjidhja nuk është universale - do të funksionojë vetëm për Mikrotik, pasi sintaksa e komandës është e ndryshme për të gjithë ruterat. Gjithashtu, përcjellje të tilla më pas duhej të fshiheshin disi dhe pjesa e serverit të sistemit tonë në thelb nuk mund të gjurmonte në asnjë mënyrë nëse e kisha përfunduar seancën time RDP. Epo, një përcjellje e tillë është një vrimë për klientin. Por ne nuk ndoqëm universalitetin, sepse... produkti është përdorur vetëm brenda kompanisë sonë dhe nuk ka pasur asnjë mendim për ta nxjerrë në publik.

Secila nga problemet u zgjidh në mënyrën e vet. Kur u krijua rregulli, ky përcjellje ishte i disponueshëm vetëm për një adresë IP specifike të jashtme (nga e cila u inicializua lidhja). Kështu u shmang një vrimë sigurie. Por me çdo lidhje të tillë, një rregull Mikrotik shtohej në faqen NAT dhe nuk u fshi. Dhe të gjithë e dinë se sa më shumë rregulla të ketë, aq më shumë ngarkohet procesori i ruterit. Dhe në përgjithësi, nuk mund të pranoja që një ditë të shkoja në ndonjë Mikrotik dhe të kishte qindra rregulla të vdekura, të kota.

Meqenëse serveri ynë nuk mund të gjurmojë statusin e lidhjes, lejo Mikrotik t'i gjurmojë vetë. Dhe unë shkrova një skenar që monitoronte vazhdimisht të gjitha rregullat e përcjelljes me një përshkrim specifik dhe kontrolloja nëse lidhja TCP kishte një rregull të përshtatshëm. Nëse nuk ka një të tillë për disa kohë, atëherë lidhja ndoshta tashmë është përfunduar dhe kjo përcjellje mund të fshihet. Gjithçka funksionoi, skenari funksionoi mirë.

Nga rruga, këtu ë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
	}
}

Me siguri mund të ishte bërë më e bukur, më e shpejtë etj., por funksionoi, nuk e ngarkoi Mikrotik dhe bëri një punë të shkëlqyer. Më në fund arritëm të lidheshim me serverët e klientëve dhe pajisjet e rrjetit me vetëm një klik. Pa hapur një VPN ose pa futur fjalëkalime. Sistemi është bërë vërtet i përshtatshëm për të punuar me të. Koha e shërbimit u zvogëlua dhe ne të gjithë kaluam kohë duke punuar në vend që të lidheshim me objektet e nevojshme.

Mikrotik Backup

Ne konfiguruam kopje rezervë të të gjithë Mikrotik në FTP. Dhe në përgjithësi gjithçka ishte mirë. Por kur të duhej të merrje një kopje rezervë, duhej të hapje këtë FTP dhe ta kërkoje atje. Ne kemi një sistem ku të gjithë ruterët janë të lidhur, ne mund të komunikojmë me pajisjet përmes SSH. Pse të mos e bëjmë që vetë sistemi të marrë kopje rezervë nga i gjithë Mikrotik çdo ditë, mendova. Dhe ai filloi ta zbatonte atë. U lidhëm, bëmë një kopje rezervë dhe e çuam në ruajtje.

Kodi i skriptit në PHP për marrjen e një kopje rezervë 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 < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
    @fclose($stream);

    ssh2_exec($connection, '/file remove atmon.backup');
    ssh2_exec($connection, '/file remove atmon.rsc');

?>

Rezervimi merret në dy forma - konfigurim binar dhe tekst. Binar ndihmon për të rivendosur shpejt konfigurimin e kërkuar, dhe teksti ju lejon të kuptoni se çfarë duhet bërë nëse ka një zëvendësim të detyruar të pajisjeve dhe binar nuk mund të ngarkohet në të. Si rezultat, ne morëm një funksion tjetër të përshtatshëm në sistem. Për më tepër, kur shtoja Mikrotik të ri, nuk kishte nevojë të konfiguroja asgjë, thjesht shtova objektin në sistem dhe vendosa një llogari për të nëpërmjet SSH. Pastaj vetë sistemi u kujdes për marrjen e kopjeve rezervë. Versioni aktual i SaaS Veliam nuk e ka ende këtë funksionalitet, por do ta portojmë së shpejti.

Pamjet e ekranit se si dukej në sistemin e brendshëm

Kalimi në ruajtjen normale të bazës së të dhënave

Unë tashmë shkrova më lart se u shfaqën artefakte. Ndonjëherë e gjithë lista e objekteve në sistem thjesht zhdukej, ndonjëherë kur redaktoni një objekt, informacioni nuk ruhej dhe objekti duhej të riemërohej tre herë. Kjo i acaroi tmerrësisht të gjithë. Zhdukja e objekteve ndodhte rrallë dhe u rikthye lehtësisht duke rivendosur pikërisht këtë skedar, por dështimet gjatë redaktimit të objekteve ndodhën mjaft shpesh. Ndoshta, fillimisht nuk e bëra këtë përmes bazës së të dhënave, sepse nuk më shkonte në mendje se si ishte e mundur të mbash një pemë me të gjitha lidhjet në një tryezë të sheshtë. Është e sheshtë, por pema është hierarkike. Por një zgjidhje e mirë për akses të shumëfishtë, dhe më pas (pasi sistemi bëhet më kompleks) transaksional, është një DBMS. Ndoshta nuk jam i pari që has këtë problem. Fillova të googloj. Doli që gjithçka ishte shpikur tashmë para meje dhe ka disa algoritme që ndërtojnë një pemë nga një tryezë e sheshtë. Pasi pashë secilën, zbatova njërën prej tyre. Por ky ishte tashmë një version i ri i sistemit, sepse... Në fakt, për shkak të kësaj, më duhej të rishkruaja shumë. Rezultati ishte i natyrshëm, problemet e sjelljes së rastësishme të sistemit u larguan. Disa mund të thonë se gabimet janë shumë amatore (skriptet me një fije, ruajtja e informacionit që është aksesuar disa herë në të njëjtën kohë nga tema të ndryshme në një skedar, etj.) në fushën e zhvillimit të softuerit. Ndoshta kjo është e vërtetë, por puna ime kryesore ishte administrimi, dhe programimi ishte një ngutje anësore për shpirtin tim, dhe thjesht nuk kisha përvojë të punoja në një ekip programuesish, ku gjëra të tilla themelore do të më sugjeroheshin menjëherë nga i moshuari im. shokët. Ndaj të gjitha këto gunga i kam mbushur vetë, por materialin e kam mësuar shumë mirë. Dhe gjithashtu, puna ime përfshin takime me klientët, veprime që synojnë të promovojnë kompaninë, një mori çështjesh administrative brenda kompanisë dhe shumë e shumë më tepër. Por në një mënyrë apo tjetër, ajo që ishte tashmë atje ishte e kërkuar. Djemtë dhe unë vetë e përdorëm produktin në punën tonë të përditshme. Sinqerisht kishte ide dhe zgjidhje të pasuksesshme për të cilat humbej kohë, por në fund u bë e qartë se ky nuk ishte një mjet pune dhe askush nuk e përdori dhe nuk përfundoi në Veliam.

Helpdesk - HelpDesk

Nuk do të ishte e gabuar të përmendim se si u formua HelpDesk. Kjo është një histori krejtësisht e ndryshme, sepse... në Veliam ky është tashmë versioni i 3-të krejtësisht i ri, i cili është i ndryshëm nga të gjithë të mëparshmet. Tani është një sistem i thjeshtë, intuitiv pa këmbanat dhe bilbilat e panevojshme, me aftësinë për t'u integruar me një domen, si dhe aftësinë për të hyrë në të njëjtin profil përdoruesi nga kudo duke përdorur një lidhje nga një email. Dhe më e rëndësishmja, është e mundur të lidheni me aplikantin nëpërmjet VNC nga kudo (në shtëpi ose në zyrë) direkt nga aplikacioni pa VPN ose përcjellje porti. Unë do t'ju tregoj se si arritëm në këtë, çfarë ndodhi më parë dhe çfarë vendime të tmerrshme u morën.

Ne u lidhëm me përdoruesit përmes TeamViewer-it të mirënjohur. Të gjithë kompjuterët, përdoruesve të të cilëve u shërbejmë, kanë të instaluar TV. Gjëja e parë që bëmë gabim, dhe më pas e hoqëm atë, ishte lidhja e çdo klienti HD me harduerin. Si u fut përdoruesi në sistemin HD për të lënë një kërkesë? Përveç televizorit, të gjithë kishin një mjet të posaçëm të instaluar në kompjuterët e tyre, të shkruar në Lazarus (shumë njerëz këtu do të rrotullojnë sytë dhe ndoshta do të shkojnë në Google se çfarë është, por gjuha më e mirë e përpiluar që dija ishte Delphi, dhe Lazarus është pothuajse e njëjta gjë, vetëm falas). Në përgjithësi, përdoruesi lançoi një skedar të veçantë grupi që nisi këtë mjet, i cili nga ana e tij lexoi HWID të sistemit dhe pas kësaj u hap shfletuesi dhe ndodhi autorizimi. Pse u bë kjo? Në disa kompani, numri i përdoruesve të shërbimit llogaritet individualisht dhe çmimi i shërbimit për çdo muaj bazohet në numrin e njerëzve. Kjo është e kuptueshme, thoni ju, por pse është e lidhur me harduerin? Është shumë e thjeshtë, disa individë erdhën në shtëpi dhe bënë një kërkesë nga laptopi i shtëpisë së tyre në stilin "bëj gjithçka të bukur për mua këtu". Përveç leximit të sistemit HWID, programi nxori ID-në aktuale të Teamviewer nga regjistri dhe gjithashtu na e transmetoi atë. Teamviewer ka një API për integrim. Dhe ne e bëmë këtë integrim. Por kishte një kapje. Nëpërmjet këtyre API-ve, është e pamundur të lidheni me kompjuterin e përdoruesit kur ai nuk e nis në mënyrë eksplicite këtë seancë dhe pasi tenton të lidhet me të, duhet të kliko edhe “konfirmo”. Në atë kohë, na dukej logjike që askush nuk duhet të lidhet pa kërkesën e përdoruesit, dhe duke qenë se personi është në kompjuter, ai do të inicojë seancën dhe do t'i përgjigjet pozitivisht kërkesës për lidhje në distancë. Gjithçka doli e gabuar. Aplikantët harruan të shtypnin fillimin e seancës, dhe këtë iu desh t'ua tregonin në një bisedë telefonike. Kjo humbi kohë dhe ishte zhgënjyese në të dyja anët e procesit. Për më tepër, nuk janë aspak të rralla momente të tilla kur një person lë një kërkesë, por lejohet të lidhet vetëm kur niset për drekë. Sepse problemi nuk është kritik dhe ai nuk do që t'i ndërpritet procesi i punës. Prandaj, ai nuk do të shtypë asnjë buton për të lejuar lidhjen. Kështu u shfaq funksionaliteti shtesë kur hyni në HelpDesk - duke lexuar ID-në e Teamviwer. Ne e dinim fjalëkalimin e përhershëm që përdorej gjatë instalimit të Teamviwer. Më saktësisht, vetëm sistemi e dinte këtë, pasi ishte i integruar në instaluesin dhe në sistemin tonë. Prandaj, kishte një buton lidhjeje nga aplikacioni duke klikuar mbi të cilin nuk kishte nevojë të priste asgjë, por Teamviewer u hap menjëherë dhe ndodhi një lidhje. Si rezultat, kishte dy lloje të lidhjeve të mundshme. Nëpërmjet API-së zyrtare të Teamviewer dhe asaj të krijuar vetë. Për habinë time, ata ndaluan përdorimin e të parës pothuajse menjëherë, megjithëse kishte një udhëzim për ta përdorur atë vetëm në raste të veçanta dhe kur vetë përdoruesi jep miratimin. Megjithatë, më jep siguri tani. Por doli që aplikantëve nuk u duhej kjo. Ata janë të gjithë absolutisht mirë me lidhjen me ta pa një buton konfirmimi. Dhe meqenëse ky është rasti, funksionaliteti i lidhjes API u eliminua më pas si i panevojshëm.

Kalimi në shumëfillezim në Linux

Çështja e përshpejtimit të kalimit të një skaner rrjeti për hapjen e një liste të paracaktuar portash dhe ping të thjeshtë të objekteve të rrjetit ka filluar të lindë prej kohësh. Këtu, sigurisht, zgjidhja e parë që vjen në mendje është multithreading. Meqenëse koha kryesore e shpenzuar në ping është në pritje të kthimit të paketës dhe ping-u tjetër nuk mund të fillojë derisa të kthehet paketa e mëparshme, në kompanitë që kishin edhe mbi 20 serverë plus pajisje rrjeti, kjo tashmë funksiononte mjaft ngadalë. Çështja është se një paketë mund të zhduket, por mos e njoftoni menjëherë administratorin e sistemit për këtë. Ai thjesht do të ndalojë së pranuari një spam të tillë shumë shpejt. Kjo do të thotë që ju duhet të bëni ping çdo objekt më shumë se një herë përpara se të bëni një përfundim për paarritshmërinë. Pa u futur në shumë detaje, është e nevojshme të paralelizohet sepse nëse kjo nuk bëhet, atëherë me shumë mundësi administratori i sistemit do të mësojë për problemin nga klienti, dhe jo nga sistemi i monitorimit.

Vetë PHP nuk mbështet multithreading jashtë kutisë. I aftë për përpunim të shumëfishtë, ju mund të piruni. Por, në fakt, unë tashmë kisha një mekanizëm votimi të shkruar dhe doja ta bëja në mënyrë që të numëroja të gjitha nyjet që më duheshin nga baza e të dhënave, të bëja ping menjëherë, të prisja një përgjigje nga secili dhe vetëm pas kësaj të shkruaj menjëherë të dhënat. Kjo kursen në numrin e kërkesave të leximit. Multithreading përshtatet në mënyrë të përkryer në këtë ide. Për PHP ekziston një modul PThreads që ju lejon të bëni një multithreading të vërtetë, megjithëse u desh një sasi e madhe ndërlikimi për ta vendosur këtë në PHP 7.2, por u bë. Skanimi i portit dhe ping-u tani janë të shpejta. Dhe në vend të, për shembull, 15 sekonda për xhiro më herët, ky proces filloi të zgjasë 2 sekonda. Ishte një rezultat i mirë.

Auditim i shpejtë i kompanive të reja

Si lindi funksionaliteti për mbledhjen e metrikave të ndryshme dhe karakteristikave të harduerit? Është e thjeshtë. Ndonjëherë thjesht na urdhërohet të auditojmë infrastrukturën aktuale të TI-së. Epo, e njëjta gjë është e nevojshme për të shpejtuar auditimin e një klienti të ri. Ne kishim nevojë për diçka që do të na lejonte të shkonim në një kompani të mesme ose të madhe dhe të kuptonim shpejt se çfarë kanë. Për mendimin tim, ping-u në rrjetin e brendshëm bllokohet vetëm nga ata që duan të ndërlikojnë jetën e tyre, dhe në përvojën tonë ka pak prej tyre. Por ka edhe njerëz të tillë. Prandaj, mund të skanoni shpejt rrjetet për praninë e pajisjeve me një ping të thjeshtë. Më pas mund t'i shtojmë dhe të skanojmë për porte të hapura që na interesojnë. Në fakt, ky funksionalitet ekzistonte tashmë, ishte e nevojshme vetëm të shtohej një komandë nga serveri qendror në atë skllav, në mënyrë që ai të skanonte rrjetet e specifikuara dhe të shtonte gjithçka që gjeti në listë. Harrova të përmendja, supozohej se kishim tashmë një imazh të gatshëm me një sistem të konfiguruar (server monitorimi skllevër) që thjesht mund ta nxjerrim nga klienti gjatë një auditimi dhe ta lidhnim me renë tonë.

Por rezultati i auditimit zakonisht përfshin një mori informacionesh të ndryshme, dhe një prej tyre është se çfarë lloj pajisjesh janë në rrjet. Ne ishim të interesuar kryesisht në Windows servera dhe stacione pune Windows Si pjesë e një domeni. Në kompanitë e mesme dhe të mëdha, mungesa e një domeni është ndoshta përjashtim sesa rregull. Për të folur të njëjtën gjuhë, një kompani e mesme, sipas mendimit tim, është 100+ persona. Ne duhej të gjenim një mënyrë për të mbledhur të dhëna nga të gjitha makinat dhe serverat Windows, duke ditur adresat e tyre IP dhe llogaritë e administratorit të domenit, pa pasur nevojë të instalonim ndonjë program në secilën prej tyre. Ndërfaqja WMI erdhi në ndihmë. Windows Instrumentimi i Menaxhimit (WMI) fjalë për fjalë do të thotë instrumentim menaxhimi. WindowsWMI është një nga teknologjitë themelore për menaxhimin dhe monitorimin e centralizuar të pjesëve të ndryshme të infrastrukturës kompjuterike nën kontrollin e platformës. WindowsMarrë nga wiki. Pastaj më është dashur të bëj disa ndryshime përsëri për të ndërtuar wmic (një klient WMI) për DebianPasi gjithçka ishte gati, e tëra çfarë mbetej ishte të pyeteshin nyjet e kërkuara nëpërmjet wmic për informacionin e kërkuar. Nëpërmjet WMI, mund të merrni Windows kompjuteri pothuajse çdo informacion, dhe për më tepër, ju gjithashtu mund ta kontrolloni kompjuterin përmes tij, për shembull, ta dërgoni atë për të rinisur. Kështu mblidhen informacionet rreth Windows stacionet dhe serverat në sistemin tonë. Kjo u plotësua nga informacioni aktual rreth treguesve aktualë të ngarkesës së sistemit. Ne i kërkojmë këto më shpesh, ndërsa informacioni i harduerit është më pak i shpeshtë. Pas kësaj, auditimi u bë pak më i këndshëm.

Vendimi për shpërndarjen e softuerit

Ne vetë e përdorim sistemin çdo ditë, dhe ai është gjithmonë i hapur për çdo punonjës teknik. Dhe ne menduam se mund të ndajmë me të tjerët atë që kemi tashmë. Sistemi nuk ishte ende gati për t'u shpërndarë. Duhej ripunuar shumë në mënyrë që versioni lokal të shndërrohej në SaaS. Këto përfshijnë ndryshime në aspekte të ndryshme teknike të sistemit (lidhjet në distancë, shërbimi mbështetës), analiza e moduleve për licencim, ndarje e bazave të të dhënave të klientëve, shkallëzimi i secilit shërbim dhe zhvillimi i sistemeve të përditësimit automatik për të gjitha pjesët. Por kjo do të jetë pjesa e dytë e artikullit.