🥇Avalt täitmine väljastusest arendusse (Osa 1)

Tere kõigile, minu nimi on Sergei Emeljančik. Olen ettevõtte Audit-Telecom juht, peaarendaja ja süsteemi Veliam autor. Otsustasin kirjutada artikli sellest, kuidas me sõbraga loomineoutsourcing ettevõte, kirjutasime tarkvara enda tarbeks ja hiljem hakkasime seda kõigile soovijatele jagama SaaS süsteemi kaudu. Kuidas ma absoluutelt ei uskunud, et see on võimalik. Artiklis ei ole ainult lugu, vaid ka tehnilised detailid, kuidas Veliam toode loodi. Sealhulgas mõned algse koodi lõigud. Räägin, milliseid vigu me tegime ja kuidas me neid hiljem parandama pidime. Oli kahtlusi, kas sellist artiklit avaldada. Kuid mõtlesin, et on parem seda teha, saada tagasisidet ja parandada end, kui mitte avaldada artiklit ja mõelda, kuidas oleks olnud, kui…

Eellugu

Töötasin ühes ettevõttes IT töötajana. Ettevõte oli üsna suur ja keerulise võrgustruktuuriga. Ma ei kavatse peatuda oma ametikohtades, ütlen vaid, et need ei sisaldanud kindlasti millegi arendamist.

Meil oli jälgimine, kuid puhtast akadeemilisest huvist tahtsin proovida kirjutada oma lihtsaimat versiooni. Idee oli selline: soovisin, et see oleks veebis, et saaksin lihtsalt ilma kliendi installimiseks sisse logida ja vaadata, mis toimub võrgus igalt seadmelt, sealhulgas mobiilsetelt seadmetelt Wi-Fi kaudu, ning väga soovisin kiiresti mõista, millises ruumis asub seade, mis "haigestus", kuna meil olid väga ranged nõuded reageerimise ajale sellistele probleemidele. Lõpuks tekkis mul peas plaan kirjutada lihtne veebileht, mille taustaks oli JPEG, kus oli võrguskeem, lõigata selle pildilt välja seadmed koos nende IP aadressidega ja kuvada pildi peal õigetes koordinaatides dünaamilist sisu rohelise või vilkuva punase IP aadressina. Ülesanne on püstitatud, alustame.

Varem olin tegelenud programmeerimisega Delphi, PHP, JS ja väga pinnapealselt C++. Tunnen üsna hästi võrkude tööd. VLAN, marsruutimine (OSPF, EIGRP, BGP), NAT. Seda oli piisavalt, et kirjutada primitiivse jälgimise prototüüp iseseisvalt.

Kirjutasin mõeldud PHP-s. Apache server ja PHP olid Windowsis, kuna Linux oli mulle tol hetkel midagi arusaamatut ja väga keerulist. Nagu selgus hiljem, eksisin ma tugevalt ja paljudes kohtades on Linux palju lihtsam kui Windows, aga see on eraldi teema ja me kõik teame, kui palju vaidlusi sellel teemal on. Windowsi ülesannete ajastaja kutsus väikse intervalli järel (täpselt ei mäleta, aga midagi umbes ühte korda kolme sekundi jooksul) PHP skripti, mis küsis kõikidelt objektidelt banaalse pingi ja salvestas oleku faili.

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

Jah, andmebaasidega töötamine oli tol hetkel mulle ka veel tundmatu. Ma ei teadnud, et protsesse saab paralleelseks muuta ning läbitav aeg, et külastada kõiki võrgu sõlmi, oli pikk, kuna see toimus ühes voos. Erinevad probleemid tekkisid siis, kui mitu sõlme ei olnud saadaval, kuna igaühega viibis skript 300 ms. Klientpooles oli lihtne tsükliline funktsioon, mis paarisekundiliste intervallidega laadis uuendatud teavet serverist Ajax päringuga ja uuendas liidest. Kui pärast kolme järjestikust ebaõnnestunud pingi katset, kui arvutis oli avatud veebileht jälgimiseks, mängis tore meloodia.

Kui kõik õnnestus, inspireeris mind tulemus väga ning arvasin, et võiksin sinna veel lisada (oma teadmiste ja võimaluste tõttu). Kuid mulle ei ole kunagi meeldinud süsteemid, kus on miljon graafikut, mis, nagu ma siis arvasin, ja arvan siiani, on enamikul juhtudel tarbetud. Soovisin lisada ainult seda, mis minule töökorralduses tõeliselt abiks oleks. See põhimõte kehtib siiani Veliam'i arendamise aluseks. Seejärel mõistsin, et oleks väga tore, kui ei peaks pidevalt vaatama seiret ja teadma probleemidest, vaid avaks lehe vaid siis, kui mingi probleem ilmneb, et vaadata, kus see probleemne võrgusõlm asub ja mis edasi teha. Tol ajal ei lugenud ma e-kirju, ei kasutanud neid lihtsalt. Jõudsin internetis infoni, et on SMS-väravad, kuhu saab saata GET või POST päringu, ja need saadavad mulle minu mobiiltelefonile SMS-i tekstiga, mille ma kirjutan. Mõistsin kohe, et seda ma soovin. Alustasin dokumentatsiooni uurimist. Mõne aja pärast õnnestus mul see, ja nüüd sain SMS-e võrgu probleemide kohta mobiltelefonile „kukkunud objekti” nimega. Kuigi süsteem oli primitiivne, oli see minu poolt kirjutatud ja mis kõige tähtsam, mis mind siis selle arendama motiveeris — see oli rakendusprogramm, mis aitas mind tõeliselt töös.

Ja siis saabus päev, mil töö juures kukkus üks internetiühendustest, kuid minu seire ei andnud mulle sellest mingeid teadmisi. Kuna Google'i DNS-id olid endiselt suurepäraselt pingitavad. Aeg oli mõelda, kuidas jälgida, et suhtluskanal töötab. Olin erinevaid ideid, kuidas seda teha. Mitte kõikidele seadmetele ei olnud mul ligipääsu. Pidin välja mõtlema, kuidas mõista, milline kanal töötab, kuid samas ei olnud võimalik seda kuidagi vaadata reaalsetes võrguseadmetes. Siis pakkus kolleeg mõtte, et võib-olla võib avalike serverite jälgimise jälgimine varieeruda selle järgi, millise suhtluskanali kaudu praegu internetti sisenetakse. Kontrollisin, ja nii oligi. Jälgimise korral olid erinevad marsruudid.

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

Nii tekkis veel üks skript, täpsemalt oli jälgimine mingil põhjusel lisatud selle sama skripti lõppu, mis pingis kõiki seadmeid võrgus. See oli veel üks pikk protsess, mis toimus samas käigus ja pidurdas kogu skripti tööd. Kuid tol ajal ei olnud see nii ilmne. Nii või naa, ta tegi oma tööd, koodis oli kindlalt määratud, milline jälgimine iga kanalil olema pidi. Nii hakkas tööle süsteem, mis jälgis (ülevaatus on tugev sõna, kuna mingite mõõdikute kogumist ei olnud, lihtsalt ping) võrguseadmeid (ruuterid, lülitid, wi-fi jne) ja sidekanaleid välismaailmaga. SMS-id saabusid regulaarselt ja skeemilt oli alati hästi näha, kus oli probleem.

Edasi, igapäevases töös tuli tegeleda ristmikega. Iga kord lülititelt Cisco seadmetele siseneda, et näha, millist liidest kasutada, hakkas tüütama. Kui tore oleks see, kui saaks monitorimisel objektile klikata ja näha tema liideste nimekirja koos kirjeldustega. See säästaks mulle aega. Samuti ei oleks selle skeemi järgi vaja käivitada Putty või SecureCRT, sisestada kasutajanimesid ja käske. Lihtsalt klikiks monitorimisel, näeks, mis on vajalik, ja läheks enda tööd tegema. Hakkasin otsima, kuidas lülititega suhelda. Esmalt tuli kohe kaks varianti: SNMP või siseneda lülitisse SSH kaudu, sisestada vajalikud käsud ja töödelda tulemust. SNMP jätsin kõrvale teostuskeerukuse tõttu, mul oli tulemuse saamisega kiire. SNMP puhul peaksin pikka aega MIB-is kaevama, selle põhjal andmeid liideste kohta genereerima. Cisco-s on suurepärane käsk,

show interface status

See, that's exactly what I need for cross-referencing. Why suffer with SNMP when I just want to see the output of this command, I thought. After a while, I implemented this feature. I clicked on the object on the web page. An event triggered that made the client send an AJAX request to the server, which then connected via SSH to the required switch (the credentials were hardcoded, I didn’t want to bother beautifying it, creating some separate menus where I could change credentials from the interface; I just needed the result quickly) entered the aforementioned command there and sent it back to the browser. This way, I started to see interface information with a single mouse click. It was extremely convenient, especially when I had to check this information on different switches at the same time.

Monitoring channels based on tracing turned out to be not the best idea, as sometimes work was being done on the network, and the tracing could change, causing the monitoring to scream at me that there were problems with the channel. But after spending a lot of time analyzing, I realized that all channels were working, and my monitoring was misleading me. In the end, I asked colleagues who managed the channel-forming switches to just send me syslog when the visibility status of neighbors changed. Accordingly, this was much simpler, faster, and more truthful than tracing. When an event like 'neighbor lost' occurred, I would immediately trigger an alert about the channel drop.

Next, outputs for clicking on the object appeared with several more commands, and SNMP was added for collecting some metrics, and that was essentially it. The system did not evolve further. It did everything I needed; it was a good tool. Many readers might say that there’s a ton of software online for these tasks already. But in reality, I couldn't find any free products back then, and I was eager to develop my programming skills, and what could be better for that than a real practical task? So, the first version of the monitoring was completed and was no longer modified.

Establishing the company Audit-Telecom

Aeg läks edasi ja ma hakkasin teiste ettevõtetes kõrvaltegevusi tegema, kuna minu töögraafik võimaldas seda. Erinevates ettevõtetes töötades kasvavad oskused kiiresti ja silmaring areneb hästi. On olemas ettevõtteid, kus, nagu öeldakse, oled sa kõikehõlmav spetsialist. Ühelt poolt on see keeruline, teisalt, kui mitte laisk olla, saad laia profiiliga spetsialistiks ja see võimaldab kiiremini ja tõhusamalt ülesandeid lahendada, sest tead, kuidas külgne ala töötab.

Minu sõber Pavel (ka IT-ettevõtja) üritas pidevalt mind oma äri looma innustada. Olid hulgaliselt ideid erinevate äri variantide kohta. Seda arutati mitmeid aastaid. Lõppkokkuvõttes ei viinud see kuhugi, kuna olin skeptik ja Pavel unistaja. Iga kord, kui ta mõne idee pakkus, ei uskunud ma sellesse kunagi ja keeldusin osalemast. Kuid väga tahtsime oma äri avada.

Lõpuks suutsime leida mõlemaid rahuldava variandi ja hakata tegema seda, milles oleme head. 2016. aastal otsustasime luua IT-ettevõtte, mis aitaks äri IT-ülesannete lahendamisel. See hõlmab IT-süsteemide (1C, terminaliserver, meiliserver jms) juurutamist, nende tuge, klassikalist kasutajatoe teenust ja võrgu haldamist.

Austatud öeldes, kui ettevõte loodi, ei uskunud ma sellesse umbes 99,9%. Kuid mingil moel suutis Pavel mind proovima panna, ja tagasi vaadates, tal oli õigus. Me panime Pavliga kokku 300 000 rubla, registreerisime uue OÜ "Audit-Telecom", rentisime pisikese kontori, tegime ägedaid visiitkaarte, no, üldiselt nagu enamus kogenematuid, alustavaid ettevõtjaid, ja hakkasime kliente otsima. Klientide otsimine on täiesti eraldi lugu. Võib-olla kirjutame me selle kohta eraldi artikli meie ettevõtte blogis, kui kellelegi huvi pakub. Külmkõned, flaierid ja muu. See ei andnud mingeid tulemusi. Nagu ma nüüd loen, sõltub paljuski kohati vedamisest. Meil vedas. Ja vaid paar nädalat pärast ettevõtte loomist pöördus meie poole minu vend Vladimir, kes tõi meile esimese kliendi. Ei taha teid tüüdata detailidega töö tegemisest klientidega, artikkel ei ole sellest, ütleksin vaid, et käisime auditis, tuvastasime kriitilised kohad ja need kohad purunesid, kui tehti otsust, kas teha meiega pidevat koostööd allhanke kaudu. Pärast seda tehti kohe positiivne otsus.

Seejärel, peamiselt kuulujuttude kaudu tuttavate kaudu, hakkasid ilmuma ka teised teenindatavad ettevõtted. Helpdesk oli ühes süsteemis. Ühendused võrgu- ja serveriseadmestiku juurde olid teises, või õigemini, kes kuidas. Keegi salvestas otseteed, keegi kasutas RDP aadressiraamatuid. Jälgimine oli veel üks eraldi süsteem. Meeskonnal töötada killustunud süsteemides on väga ebamugav. Oluline teave kaob silmist. Näiteks, kui kliendi terminserver hakkas kättesaamatuks muutuma. Koheselt tulevad taotlused selle kliendi kasutajatelt. Toetuste spetsialist avab taotluse (see received telefonitsi). Kui juhtumid ja taotlused registreeritaks ühes süsteemis, siis saaks tugimüüja kohe näha, mis probleem kasutajal on ja räägiks sellest, samal ajal juba ühendudes vajaliku objektiga olukorra lahendamiseks. Kõik on teadlikud taktikalistest olukordadest ja töötavad koordineeritult. Me ei leidnud sellist süsteemi, kus kõik see oleks ühendatud. Sai selgeks, et on aeg teha oma toode.

Töö jätkumine oma jälgimissüsteemi kallal

Selge oli, et varasemalt kirjutatud süsteem ei sobinud praeguste ülesannete jaoks ei funktsionaalsuse ega kvaliteedi poolest. Seega otsustati kirjutada süsteem nullist. Visuaalselt pidi see välja nägema täiesti erinev. See pidi olema hierarhiline süsteem, et saaks kiiresti ja mugavalt avada vajaliku objekti vajaliku kliendi juures. Esimese versiooni skeem ei olnud antud juhul üldse põhjendatud, kuna kliendid on erinevad ja ei olnud oluline, millistes ruumides seadmed asuvad. See oli juba dokumentatsiooni peale pandud.

Nii et ülesanded:

Hierarhiline struktuur;
Mingisugune serveriosamoodul, mille saab kliendi juures paigutada virtuaalmasina kujul, et koguda vajalikud mõõdikud ja saata need keskserverisse, mis kõik kokku kogub ja meile näitab;
Teavitused. Sellised, mida ei saa vahele jätta, kuna sel hetkel ei olnud kedagi, kes lihtsalt monitori jälgiks;
Kinnitusüsteem. Alguses hakkasid ilmuma kliendid, kellele me hooldasime mitte ainult serveri- ja võr equipments, vaid ka tööjaamu;
Võime kiiresti ühenduda serverite ja seadmetega süsteemist;

Ülesanded püstitatud, hakkame kirjutama. Samal ajal töötame klientide taotlustega. Sel hetkel olime juba 4 inimest. Alguses hakkasime kirjutama mõlemat osa: keskserverit ja serverit klientide paigaldamiseks. Selleks ajaks ei olnud Linux meile enam võõras ja oli otsustatud, et virtuaalmasinad, mis on klientide juures, saavad olema Debianil. Ei mingeid installereid, lihtsalt teeme serveri osa projekti ühe kindla virtuaalmasina peal ja siis kloonime selle lihtsalt vajalikule kliendile. See oli järjekordne viga. Hiljem sai selgeks, et sellises skeemis ei olnud uuenduste mehhanism täielikult läbimõeldud. See tähendab, et me lisasime mõne uue funktsiooni, aga hiljem oli probleem selle levitamisega kõikidele kliendi serveritele, aga rääkime sellest hiljem, kõik omas järjekorras.

Tegime esimesed prototüübid. See suutis pingida meie klientide vajalikke võrguseadmeid ja servereid ning saata need andmed meie keskserverisse. See omakorda uuendas neid andmeid keskserveris olevas üldmasinas. Siin kirjutan ma mitte ainult loo sellest, kuidas ja mis õnnestus, vaid ka millised amatöörvead tehti ja kui palju aega selle eest hiljem maksta tuli. Nii et, kogu objektide puu hoiti ühes ainsas failis serialiseeritud objektina. Kui me süsteemi ühendame paar klienti, oli kõik enam-vähem normaalne, kuigi aeg-ajalt esines mõningaid artefakte, mis olid täiesti arusaamatud. Kuid kui me ühendame süsteemi tosin serverit, hakkasid toimuma imed. Vahel, arusaamatul põhjusel, kadusid kõik objektid süsteemist lihtsalt. Siinkohal on oluline märkida, et serverid, mis olid klientidel, saatsid andmeid keskserverisse iga paari sekundi tagant POST-päringu kaudu. Tark lugeja ja kogenud programmeerija on juba arvanud, et probleemi põhjustas juurdepääsu konflikt sama failile, kus hoiti serialiseeritud objekti paralleelsete lõimede poolt. Ja just sel hetkel, kui see juhtus, ilmusid imed objektide kadumisega. Fail muutus lihtsalt tühjaks. Kuid see avastati mitte kohe, vaid alles siis, kui kasutati mitme serveriga. Sel ajal lisati portide skaneerimise funktsionaalne (serverid saatsid keskserverile mitte ainult teavet seadmete kättesaadavuse kohta, vaid ka avatud sadamate kohta). See tehti käsu kutsumise teel:

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

tulemused olid sageli vale ja skaneerimine kestis väga kaua. Täiesti unustasin pingimise, see toimus fpingu kaudu:

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

Ka see ei olnud paralleelne ja seetõttu oli protsess väga pikaajaline. Hiljem sai fpingusse kohe edasi anda kogu loetelu vajalikest IP-aadressidest, mida kontrollida, ja tagasi saime valmis nimekirja nendest, kes vastasid. Erinevalt meist suutis fping protsesse paraleliseerida.

Teine tavaline igapäevane ülesanne oli seadistada erinevaid teenuseid veebis. Näiteks MS Exchange'i ECP. Tegelikult on see vaid link. Otsustasime, et peame saama lisada selliseid linke otse süsteemi, et mitte otsida dokumentatsioonist või kuskil järjehoidjatest, kuidas pääseda konkreetse kliendi ECP-le. Nii tekkis mõisted ressursslinkidele süsteemis, nende funktsionaalsus on saadaval ja pole ajaga muutunud, no peaaegu.

Ressursslinkide toimimine Veliamis

Kaugühendused

Nii see välja näeb praeguses Veliami versioonis

Üheks ülesandeks oli kiire ja mugav ühendamine serveritega, mida on juba palju (mitu sada), ja miljoneid eelnevalt salvestatud RDP otsettehti sirvida on äärmiselt ebamugav. Vajasime tööriista. Internetis on tarkvara, mis esindab midagi nagu RDP ühenduste adresseerimisraamat, kuid need pole integreeritud jälgimisse süsteemi ning kontosid ei saa salvestada. Iga kord erinevate klientide jaoks kontode sisestamine on tõeline põrgu, kui päevas ühendate mitu korda erinevatele serveritele. SSH-ga on asjad veidi paremad, on palju head tarkvara, mis võimaldab selliseid ühendusi kaustades korraldada ja salvestada kontosid. Kuid on kaks probleemi. Esiteks — RDP ja SSH ühenduste jaoks ei leidnud me ühtset programmi. Teiseks — kui ma mingil hetkel ei viibi oma arvuti taga ja pean kiiresti ühenduma või kui ma lihtsalt installisin süsteemi uuesti, pean ma vaatama dokumentatsioonist, et leida selle kliendi konto. See on ebamugav ja aja raiskamine.

Meie vajadustele vastav klientide serverite hierarhiline struktuur oli juba olemas meie siseproduktis. Oli vaja vaid mõelda, kuidas luua kiireid ühendusi vajaliku varustusega. Alguses, vähemalt oma võrgu sees.

Arvestades, et meie süsteemis oli kliendiks brauser, mis ei pääsenud kohalikele arvutiressurssidele, et lihtsalt mõne käsuga vajalikku rakendust käivitada, tuli välja mõelda, kuidas kõik teha Windowsi kohandatud URL-i skeemi kaudu. Nii tekkis mingi 'plugin' meie süsteemi, mis hõlmas endas Puttyt ja Remote Desktop Plusi ning installimisel registreeris lihtsalt URI skeemid Windowsis. Nüüd, kui soovisime RDP või SSH kaudu objektiga ühendust luua, klõpsasime seda toimingut meie süsteemis ja käivitati Kohandatud URI. Käivitati Windowsi integreeritud mstsc.exe või putty, mis kuulus 'plugini' koostisosade hulka. Kasutan sõna plugin kursi sees, sest see ei ole klassikalises mõttes brauseri plugin.

See oli juba vähemalt midagi. Mugav aadressiraamat. Eriti Putty puhul oli kõik väga hea, kuna sellele võis sisse anda nii ühenduse IP-d, kasutajanime kui ka parooli. St, meie võrgu Linuxi serveritega saime nüüd juba ühe klikiga ühendust luua ilma paroolide sisestamiseta. Kuid RDP-ga ei olnud kõik nii lihtne. Tavalisse mstsc-sse ei saanud kasutajakontosid parameetritena anda. Appi tuli Remote Desktop Plus. See võimaldas seda teha. Praegu saame juba ilma selleta hakkama, kuid pikka aega oli see meie süsteemis usaldusväärne abimees. HTTP(S) saitide puhul oli kõik lihtne, sellised objektid avati lihtsalt brauseris ja kõik. Mugav ja praktiline. Kuid see oli õnn vaid sisevõrgus.

Kuna enamik probleeme lahendasime eemalt kontorist, oli kõige lihtsam teha VPN-e klientidele. Ja siis meie süsteemiga oli võimalik nendega ühendust luua. Kuid see oli ikkagi veidi ebamugav. Iga kliendi jaoks tuli igas arvutis hoida palju salvestatud VPN ühendusi ja enne millegagi ühenduse loomist tuli vastav VPN sisse lülitada. Sellist lahendust kasutasime üsna pikka aega. Kuid klientide arv kasvas, samuti VPN-ide arv ja see kõik hakkas tekitama pinget ning midagi tuli sellega ette võtta. Erakordselt tekitas pisarate voolu silmist pärast süsteemi uuesti installimist, kui tuli uuesti sisestada kümneid VPN-i ühendusi uude Windowsi profiili. Piisab kannatamisest, ütlesin ma ja hakkasin mõtlema, mida sellega ette võtta.

On see nii, et kõigil klientidel olid marsruuteriteks tuntud firma Mikrotiki seadmed. Need on äärmiselt funktsionaalsed ja mugavad enamikku ülesannete täitmiseks. Miinusteks on see, et neid „kaaperdatakse“. Me lahendasime selle probleemi lihtsalt, sulgedes kõik välised juurdepääsud. Kuid oli vaja kuidagi neile ligipääs saada, ilma et peaks kliendi juurde kohale minema, sest see käis liiga aeglaselt. Me tegime lihtsalt iga Mikrotiku juurde tunnelid ja eraldasime need eraldi puuli. Ilma igasuguse marsruutimiseta, et vältida oma võrgu ja klientide vaheliste võrkude ühendamist.

Küpses idee teha nii, et kui vajutan soovitud objekti süsteemis, keskserver, teades SSH kontosid kõigi klientide Mikrotikide jaoks, ühenduks vajalikku seadmestiku, luues reegli portide suunamiseks soovitud hostile soovitud porti. Siit kerkib esile mitu punkti. Lahendus ei ole universaalne — see töötab ainult Mikrotikide puhul, kuna käsusüntaks on igal marsruuteril oma. Samuti tuli sellised suunamised hiljem kuidagi eemaldada, aga meie süsteemi serveripool ei saanud praktikas mingil viisil jälgida, kas lõpetasin RDP töö seansi. Ja selline suunamine on kliendi jaoks ohukoht. Me ei püüdlenud universaalsuse poole, kuna toode kasutati ainult meie ettevõttes ja avalikku ei olnud plaanitud välja viia.

Iga probleem lahendati omamoodi. Kui reegel loodi, oli see suunamine saadaval ainult ühe konkreetse välise IP-aadressi jaoks (millelt ühendus algas). Nii õnnestus vältida turvaauke. Kuid iga sellise ühenduse korral lisati reegel Mikrotikule NAT lehele ning seda ei kustutatud. Ja kõigile on teada, et mida rohkem on seal reegleid, seda rohkem koormab marsruuteri protsessorit. Ja laiemalt, ma ei suutnud aktsepteerida seda, et kunagi sisenen mõnda Mikrotikusse ja seal on sadu surnud, kellelegi mittevajalikku reeglit.

Kuna meie server ei suuda ühenduse staatust jälgida, las Mikrotik jälgib neid ise. Kirjutasin skripti, mis pidevalt jälgis kõiki edastamise reegleid kindla kirjeldusega (description) ja kontrollis, kas olemas on TCP ühendus sobiva reegli jaoks. Kui sellist ei olnud juba mõnda aega, siis tõenäoliselt on ühendus lõpetatud ja edastus seda võib eemaldada. Kõik töötas hästi, skript töötas hästi.

Muide, siin see on:

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 automatically 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
	}
}

Kindlasti oleks saanud selle ilusamaks, kiiremaks jne teha, kuid see töötas, ei koormanud Mikrotikke ja täitis ülesannet hästi. Lõpuks saime serveritele ja klientide seadmetele ühendada lihtsalt ühe hiireklõpsuga. Ilma VPN-i tõstmiseta või salasõnu sisestamata. Süsteemiga oli tõesti väga mugav töötada. Aeg hooldamiseks vähenes ja me kõik kulutasime aega tööle, mitte sellele, et vajalikesse objektidesse sisse logida.

Mikrotiki varukoopia

Meil oli seadistatud kõigi Mikrotikute varukoopia FTP-sse. Ja üldiselt oli kõik hästi. Kuid kui varukoopia välja võtta, pidi seda FTP-d avama ja seal otsima. Süsteem, kuhu kõik ruuterid on registreeritud, on meil olemas, oleme seadmetega SSH kaudu suhtlemiseks osavad. Miks mitte teha nii, et süsteem kogub igapäevaselt kõigist Mikrotikest varukoopiaid, mõtlesin ma. Ja asusin seda ellu viima. Ühendasime, tegime varukoopia ja võtsime selle salvestusse.

PHP skripti kood Mikrotikust varukoopia tegemiseks:

<?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

Varundamine toimub kahes vormis — binaar ja tekstiline konfiguratsioon. Binaar aitab kiiresti vajalikku konfiguratsiooni taastada, samas kui tekstiline võimaldab mõista, mida teha, kui seadme kohustuslik vahetus toimub ja binaari sellele paigaldada ei saa. Tulemuseks saime süsteemis veel ühe mugava funktsionaalsuse. Samuti ei olnud uute mikrotikide lisamisel vaja midagi seadistada, lihtsalt lisasin objekti süsteemi ja määrasin SSH jaoks kasutaja. Edasi tegeles süsteem ise varundamise tegemisega. Praeguses SaaS Veliam versioonis seda funktsionaalsust veel ei ole, kuid pe soon portime selle.

Skrinshootid, kuidas see nägi välja sise süsteemis

Üleminek normaalsele andmebaasi hoidmisele

Olen juba kirjutanud, et ilmusid artefaktid. Mõnikord kadus lihtsalt kogu objektide nimekiri süsteemist, mõnikord ei salvestatud objekti redigeerimisel teavet ja tuli objekti kolm korda ümber nimetada. See ajas kõik hulluks. Objektide kadumine toimus harva ja seda oli lihtne taastada selle faili taastamise teel, kuid objekti redigeerimise ebaõnnestumisi juhtus tihti. Tõenäoliselt, ma ei teinud seda algselt andmebaasi kaudu, sest ei suutnud mõista, kuidas hoida puu koos kõigi suhetega tasapinnalises tabelis. See on ju tasapinnaline, aga puu on hierarhiline. Kuid hea lahendus mitme pääsu jaoks ja hiljem (süsteemi keerulisemaks muutumisel) ka tehingute jaoks on andmebaas. Ma ei ole ilmselt esimene, kes selle probleemiga silmitsi seisab. Läksin Google'isse. Selgus, et kõik oli juba minu ees välja mõeldud ja mõned algoritmid, mis ehitavad puu tasapinnalisest tabelist, on juba olemas. Vaadates igaüht, implementeerisin ühe neist. Kuid see oli juba süsteemi uus versioon, kuna pidin selle tõttu palju ümber kirjutama. Tulemus oli määratletud, süsteemi juhusliku käitumise probleemid kadusid. Keegi võib öelda, et vead on üsna algelised (ühekiiruselised skriptid, teabe hoidmine, millele oli samal ajal mitme voolu kaudu juurdepääs failis jne.) tarkvaraarenduse valdkonnas. Võib olla nii, aga minu peamine töö oli haldamine, ja programmeerimine oli hingele suunatud kõrvaltegevus, ja mul polnud lihtsalt meeskonnas töötamise kogemust, kus sellised elementaarsed asjad oleks kohe vanemate kolleegide poolt välja õpetatud. Seetõttu sain kõik need õppetunnid iseseisvalt, kuid õppisin materjali väga hästi. Ja veel, minu töö on ka kohtumised klientidega, tegevused, mis on suunatud firma reklaamimisele, ja hulk haldusprobleeme ettevõttes ning palju muud. Kuid igal juhul oli see, mis oli, väga nõutud. Poiss ja mina kasutasime toodet igapäevases töös. Oli ka ilmseid ebaõnnestunud ideid, ja lahendusi, millele kulutati aega, kuid lõpuks selgus, et see on mittetöötav tööriist ja seda ei kasutatud ning see ei leidnud Veliamis kohta.

Klienditugi — HelpDesk

Ei oleks üleliigne mainida, kuidas HelpDesk loodi. See on tegelikult täiesti eraldi lugu, kuna Veliamis on see juba kolmas täiesti uus versioon, mis erineb kõikidest varasematest. Praegu on see lihtne süsteem, intuitiivselt arusaadav ilma liigsete funktsioonide ja kaunistusteta ning võimalusega integreeruda domeeniga ning pääseda sellele samale kasutajaprofiilile igalt poolt lingi kaudu e-kirjast. Ja mis kõige olulisem, on võimalik igast kohast (kas kodust või kontorist) ühendada taotlejat VNC kaudu otse taotlusest ilma VPN-i või portide edasi suunamiseta. Räägin, kuidas me selleni jõudsime, mis enne seda oli ja millised kohutavad lahendused olid.

Me ühendusime kasutajatega tuntud TeamVieweri kaudu. Kõikidel arvutitel, mida me haldasime, oli paigaldatud TV. Esimene vale samm, mille tegime ja hiljem kõrvaldasime, oli iga kliendi sidumine riistvaraga. Kuidas kasutaja sisenes HD süsteemi, et teha taotlus? Kõikidel arvutitel, lisaks TV-le, oli installitud spetsiaalne utiliit, mis oli kirjutatud Lazaruse keeles (paljud võivad selle peale silmi pöörata ja võib-olla isegi Google'st uurida, mis see on, kuid kõigist kompileeritavatest keeltest tundsin ma kõige paremini Delphi't, ja Lazarus on peaaegu sama, lihtsalt tasuta). Ühesõnaga, kasutaja käivitas oma arvutis spetsiaalse skripti, mis käivitas selle utiliidi, mis omakorda luges süsteemi HWID ja seejärel käivitus brauser ja toimus autentimine. Miks see nii tehti? Mõnes ettevõttes loetakse hallatavaid kasutajaid individuaalselt ning teenuse hind kuus määratakse inimese arvu põhjal. See on arusaadav, ütlete teie, kuid miks sidumine riistvaraga? Väga lihtsalt, mõned isikud tulid koju ja tegid kodus olevast sülearvutist taotluse stiilis "tehke mulle siin kõik ilusaks". Lisaks süsteemi HWID lugemisele tõi utiliit registrist välja praeguse TeamVieweri ID ja edastas selle meile. TeamVieweril on API integratsiooni jaoks. Ja me tegime selle integratsiooni. Kuid oli üks konks. Nende API kaudu ei saanud kasutaja arvutisse ühendada, kui ta selgelt ei algata seanssi ja peale katset ühenduda pidi ta veel vajutama "kinnita". Sel hetkel tundus meile küsimiseks, et ilma kasutaja nõusolekuta ei peaks keegi ühenduma, ja kuna inimene on arvuti taga, initsiatiivib ta seanssi ja vastab jaatavusega kauglaienduse palvele. Kõik osutus aga teistsuguseks. Taotluse esitajad unustasid vajutada seansi initsiatsiooni nuppu, ja pidime neile telefoni teel rääkima. See kulutas aega ja ärritas mõlemat osalist protsessis. Veelgi enam, ei olnud harv olukord, kui inimene jätab taotluse, kuid lubab ühendudes ainult siis, kui ta läheb lõunale. Kuna probleem ei ole kriitiline, ei soovi ta oma tööprotsessi katkestada. Seetõttu ei vajuta ta mingeid nuppe, et lubada ühenduda. Nii ilmus lisafunktsioon autoriseerimisel HelpDeskis — TeamVieweri ID lugemine. Me teadsime pidevat parooli, mis kasutati TeamVieweri paigaldamisel. Tegelikult teadis seda ainult süsteem, kuna see oli sisse kirjutatud paigaldajasse ja meie süsteemi. Seetõttu oli taotluses ühenduse nupp, millele vajutades ei pidanud ootama, vaid TeamViewer avanes kohe ja toimus ühendus. Lõpuks oli võimalik kahte tüüpi ühendusi. Ametliku TeamVieweri API kaudu ja meie omavalmistatud. Minu üllatuseks lõpetati esimese kasutamine peaaegu kohe, kuigi oli ette nähtud, et seda kasutada ainult erilistel juhtudel ja siis, kui kasutaja ise selle heaks kiidab. Lõppude lõpuks tahetakse nüüd alati turvalisust. Kuid osalejatele polnud see vajalik. Nad kõik olid täiesti rahul, et neid ühendatakse ilma kinnituse nupule vajutamata. Ja kui nii on, siis ka edaspidi viidati API kaudu ühenduse loomise funktsioonile, kuna see ei olnud enam vajalik.

Üleminek mitme lõimelisusele Linuxis

Juba mõnda aega on olnud küsimus, kuidas kiirendada võrgu skanneri läbimist teatud sadamate avatud loendi ja lihtsa pingimise osas. Esimene lahendus, mis pähe tuleb, on mitme lõimelisus. Kuna peamine aeg, mis kulub pingile, on vastuse paketi ootamine, ning järgmine ping ei saa alata enne, kui eelmine paket on tagasi tulnud, töötavad ettevõtetes, kus on isegi 20+ serverit ja võrgu seadmeid, asjad juba üsna aeglaselt. Tähtis on see, et üks pakett võib kaduda, kuid süsteemiadministraatorit sellest kohe teavitada ei saa. Ta lõpetab sellise rämpsposti väga kiiresti käsitlemise. Seega tuleb iga objekti osas pingida veel mitu korda, enne kui teha järeldusi kättesaamatuse kohta. Kui ei süübi täielikult detailidesse, siis tuleb ühtlustada, sest kui seda ei tee, siis tõenäoliselt saab süsteemiadministraator probleemi kohta teada kliendilt, mitte jälgimisseatest.

PHP ei oska iseseisvalt mitme lõimelisust. Ta oskab mitme protsessi tööde teostamise kaudu forkida. Kuid mul oli juba põhimõtteliselt olemas küsitlemise mehhanism ja soovisin, et ma loeksin kõik vajalikud sõlmed andmebaasist ühe korra, pingiksin kõik kohe ja ootaksin vastust igaühelt ning alles seejärel kirjutaksin andmed. See säästab lugematut arvu lugemisõigusi. Sellesse ideesse sobis suurepäraselt mitme lõimelisus. PHP jaoks on olemas PThreads moodul, mis võimaldab reaalse mitme lõimelisuse loomist, kuid tuli päris palju vaeva näha, et seda PHP 7.2 peal seadistada, kuid asi sai tehtud. Sadamate skaneerimine ja pingimine muutusid kiireks. Ja näiteks kui varem kulus ringile 15 sekundit, siis nüüd kulub selle protsessi peale 2 sekundit. See oli hea tulemus.

Kiire uute ettevõtete audit

Kuidas tekkis funktsioon erinevate meetrikate ja riistvara omaduste kogumiseks? Kõik on lihtne. Mõnikord tellitakse meilt lihtsalt praeguse IT-infrastruktuuri audit. Sama on vajalik ka uue kliendi auditi kiirendamiseks. Vaja oli midagi, mis võimaldaks keskmistele või suurtele ettevõtetele kiiresti aru saada, mis neil üldse on. Pinget siseserveris blokeerivad minu arvates ainult need, kes tahavad endale elu keeruliseks teha, ja selliseid meie kogemusel on vähe. Kuid ka neid kohtab. Vastavalt sellele saab kiiresti skaneerida võrku seadmete olemasolu suhtes lihtsa pingiga. Edasi saab need lisada ja skaneerida avatud portide osas, mis meid huvitavad. Sisuliselt oli see funktsioon juba olemas, tuli vaid lisada käsk kesksest serverist alluvatele, et nad skaneeriksid määratud võrgud ja lisaksid loendisse kõik, mis nad leiavad. Unustasin mainida, et eeldati, et meil on juba valmis pilt seadistatud süsteemiga (alluv järelevalveserver), mille saime lihtsalt kliendi juures auditi käigus rakendada ja siduda oma pilve.

Entusiastide auditiga kaasnevad tavaliselt mitmesugused andmed, millest üks on, millised seadmed võrgus on. Esiteks huvitavad meid Windows serverid ja Windows tööjaamad domeenis. Sest keskmistes ja suurtes ettevõtetes on domeeni puudumine tõenäoliselt erand. Ühtse keele rääkimiseks on keskmine, mida mina silmas pean, rohkem kui 100 inimest. Pidi leidma viisi, kuidas koguda andmeid kõigilt Windows masinatelt ja serveritelt, teades nende IP-aadressi ja domeeni administraatori kontot, kuid samas mitte installides neile mingit tarkvara. Siin tuleb appi WMI liides. Windowsi haldusteenused (WMI) on tõlkes Windowsi haldusteenused. WMI on üks põhitehnoloogiaid Windowsi platvormi haldamise ja erinevate arvutinfrastruktuuri osade töö jälgimiseks. Võetud on Wiki. Edasi pidi jälle natuke vaeva nägema, et koostada wmic (see on WMI klient) Debianile. Pärast seda, kui kõik oli valmis, jäi lihtsalt küsida wmic kaudu vajalike sõlmede kohta vajalikku teavet. WMI kaudu saab Windowsi arvutist kätte peaaegu kogu informatsiooni ja lisaks sellele saab seda ka hallata, näiteks käivitada restart. Nii sündis teabe kogumine Windowsi jaamadest ja serveritest meie süsteemis. Sellele lisandus ka jooksva süsteemi koormuse teave. Seda küsime sagedamini, materjalide teabe aga harvemini. Pärast seda on auditi läbiviimine muutunud veidi meeldivamaks.

Otsus tarkvara levitamise kohta

Me kõik kasutame süsteemi igapäevaselt ning see on iga tehnilise töötaja jaoks alati avatud. Ja mõtlesime, et võiksime jagada olemasolevat ka teistega. Süsteem ei olnud veel täielikult valmis levitamiseks. Oli vaja ümber töötada väga paljusid aspekte, et kohalik versioon muutuks SaaS-iks. See hõlmas erinevate tehniliste aspektide muutmist süsteemi tööprotsessis (kaugühendused, tugiteenused), moduldade litsentseerimise analüüsi, kliendibaaside shardimist, iga teenuse skaleerimist ja automaatse värskendamise süsteemide väljatöötamist kõigis osades. Kuid sellest räägib artikli teine osa.