🥇 Väljastusest arendusse (Osa 1)

Tere, minu nimi on Sergei Emeljančik. Olen ettevõtte Audit-Telekom juht, peaarenenud ja süsteemi Veliam autor. Otsustasin kirjutada artikli sellest, kuidas me sõbraga aoutsorsingu ettevõtte lõime, kirjutasime endale tarkvara ning hakkasime seda hiljem kõigile soovijatele SaaS-süsteemi kaudu levitama. Kuidas ma kategooriliselt ei uskunud, et see on võimalik. Artiklis räägitakse mitte ainult loo, vaid ka tehniliste detailide kohta, kuidas toode Veliam loodi. Sealhulgas mõned allika koodid. Räägin, milliseid vigu me tegime ja kuidas me neid hiljem parandasime. Oli kahtlusi, kas sellist artiklit avaldada. Aga mõtlesin, et parem on seda teha, saada tagasisidet ja paranda end, kui mitte avaldada artiklit ja mõelda, mis oleks, kui...

Eelalugu

Olin ühes ettevõttes IT-töötajana. Ettevõte oli üsna suur ja keerulise võrgu struktuuriga. Ma ei jää pikemalt peatuma oma ametikohustustel, vaid ütlen lihtsalt, et need kindlasti ei hõlmanud midagi arendamist.

Meil oli jälgimine, kuid puhtalt akadeemilise huvi pärast tahtsin proovida kirjutada oma lihtsama versiooni. Idee oli selline: tahtsin, et see oleks veebis, et oleks lihtne ilma mingite klientide installimata sisse logida ja vaadata, mis toimub võrgus igalt seadmel, sealhulgas mobiilseadmest Wi-Fi kaudu. Samuti tahtsin kiiresti mõista, millises ruumis on varustus, mis "hädas" oli, kuna reageerimise ajale oli seatud üsna ranged nõuded. Lõpuks sündis mul plaan kirjutada lihtne veebileht, kus taustaks oli JPEG võrguskeem, mille pealt lõikasin välja seadmed koos nende IP-aadressidega, ning üle pildi näidata õigetes koordinaatides dünaamilist sisu rohelise või vilkuva punase IP-aadressiga. Ülesanne on paika pandud, asume tööle.

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

Kirjutasin idee PHP-s. Apache server ja PHP olid Windowsis, kuna Linux tundus tol hetkel liiga keeruline ja arusaamatu, kuid hiljem selgus, et Linux on paljudes aspektides palju lihtsam kui Windows. See on aga eraldi teema ja kõik teavad, kui palju arutelusid selle üle on. Windowsi ülesande planeerija käivitas väikeste intervallidega (täpselt ei mäleta, kuid midagi sarnast kord kolme sekundi tagant) PHP skripti, mis küsis kõiki objekte tavalise ping-käsklusega ja salvestas seisundi faili.

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

Jah, andmebaasidega töötamine oli tol hetkel ka minu jaoks veel keeruline. Ma ei teadnud, et protsesside paralleelne töötlemine on võimalik, ja nägude külge kulumine võttis kaua aega, kuna see toimus ühes lõimes. Eriti tekkisid probleemid siis, kui mitu sõlme olid mittesaadaval, sest igaühe ooteaeg oli 300 ms. Kliendi poolel oli lihtne tsükliline funktsioon, mis paarisekundiliste intervallidega tõi serverist uuendatud informatsiooni, kasutades Ajaxi päringut, ja värskendas liidest. Ja kui 3 järjestikkust pingi katset ebaõnnestus, ja arvutis oli avatud veebileht monitooringuks, hakkas mängima lõbus meloodia.

Kuna kõik läks korda, olin tulemuse üle väga inspireeritud ja mõtlesin, et võiksin lisada veel (oma teadmiste ja võimaluste piires). Kuid mulle pole kunagi meeldinud süsteemid, kus on miljon graafikut, mida ma siis pidasin, ja pean siiani enamikul juhtudel ülearuseks. Soovisin lisada ainult seda, mis aitaks mind tegelikult töös. See põhimõte kehtib siiani Veliami arendamise aluseks. Edasi mõistsin, et oleks väga tore, kui ei peaks olema pidevalt avatud jälgimist ja teadma probleemidest, vaid kui need juhtuksid, siis avada leht ja vaadata, kus see probleemne võrguosa asub ning mida sellega edasi teha. Elektronposti ma toona ei lugenud, lihtsalt ei kasutanud. Leidsin internetist, et on SMS-i väravad, millele saab saata GET või POST-päringu, ja nad saadavad mulle mobiiltelefonile SMS-i tekstiga, mille ma kirja panen. Mõistsin kohe, et tahan seda väga. Ja hakkasin dokumentatsiooni õppima. Peagi suutsin, ja nüüd sain oma mobiiltelefoni SMS-e võrgu probleemide kohta, kus oli kirjas "kukkunud objekt". Kuigi süsteem oli primitiivne, oli see kirjutatud minu endi poolt, ja mis mind siis arendama motiveeris — see, et see praktiline programm aitab mind tõeliselt töös.

Ja tuli päev, mil üks internetikanalitest kukkus töö ajal alla, kuid minu jälgimine ei andnud sellest mingit märku. Google'i DNS-id pingenesid endiselt suurepäraselt. Nüüd oli aeg mõelda, kuidas kontrollida, kas sidekanal on aktiivne. Olin mõelnud erinevatele ideedele selle saavutamiseks. Kaugemale varustusele ei olnud mul ligipääsu. Pidin välja mõtlema, kuidas määrata, milline kanal on aktiivne, samas kui ei olnud võimalik mingil moel seda vaadata otse võrguseadmest. Siis viskas kolleeg idee, et võib-olla avalike serverite jälgimise teekond võib erineda sõltuvalt sellest, millise sidekanali kaudu internetti pääsemine toimub. Kontrollisin, ja see tõesti nii oligi. Jälgimise teekonnad olid erinevad.

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

Nii tekkis veel üks skript, täpsemalt lisati jälgimine mingil põhjusel selle sama skripti lõppu, mis pingis kõiki võrgus olevaid seadmeid. See oli veel üks pikk protsess, mis toimus samas teemas ja aeglustas kogu skripti tööd. Kuid tol ajal ei olnud see nii ilmne. Aga nii või teisiti tegi ta oma tööd, koodis oli kindlalt määratud, milline jälgimine iga kanali jaoks olema pidi. Nii hakkas tööle süsteem, mis jälgis (mille kohta öelda on palju, kuna mingit mõõtmete kogumist ei toimunud, vaid lihtsalt ping) võrgu seadmeid (ruuterid, lülitid, wi-fi jne) ja suhtluskanaleid välismaailmaga. SMS-id saabusid usaldusväärselt ja skeemil oli alati selgelt näha, kus probleem oli.

Edasi, igapäevases töös tuli tegeleda ristamisega. Ja igakord Cisco lülititesse sisenemine, et vaadata, millist liidest kasutada, hakkas tüütama. Kuidas oleks tore klõpsata jälgimises objektil ja näha selle liideste nimekirja koos kirjeldustega. See säästaks mulle aega. Ning sellises skeemis ei oleks vaja käivitada Putty või SecureCRT, sisestada kontod ja käsud. Lihtsalt klõpsas jälgimises, nägin, mida on vaja, ja läksin oma tööd tegema. Alustasin uurimist, kuidas saaks lülititega suhelda. Esimese hooga tuli 2 varianti: SNMP või SSH kaudu lülitisse sisenemine, vajalikud käsud sisestamine ja tulemuse töötlemine. SNMP lükati kõrvale, kuna selle rakendamine oleks keeruline, ma ei raatsinud oodata tulemust. SNMP puhul oleks pidanud pikalt MIBis nokitsema, nende andmete põhjal liideste kohta andmeid kokku panema. Cisco's on suurepärane käsk

show interface status

See, just what I needed for cross-monitoring. Why struggle with SNMP when I just want to see the output of that command, I thought. After a while, I implemented such functionality. I would click on an object on the web page. An event would trigger, causing the client to send an AJAX request to the server, which in turn connected via SSH to the needed switch (credentials were hardcoded, as I didn't want to bother with making separate menus to change login details from the interface; I just needed results, and quickly). It would enter the stated command and return the output to the browser. This allowed me to view 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.

Kanalite jälgimine jälgimise põhjal osutus lõpuks mitte kõige paremaks ideeks, kuna vahel tehti võrku töid ja jälgimine võis muutuda, mistõttu teavitas see mind pidevalt kanali probleemidest. Kuid peale pika analüüsi sain aru, et kõik kanalid töötavad ja mu jälgimine petab mind. Lõpuks palusin kolleegidel, kes haldasid kanalite vahetusi, saata mulle lihtsalt syslog'i, kui naaberite nähtavuse olek muutus. Seega oli see palju lihtsam, kiirem ja usaldusväärsem kui jälgimine. Kui saabus sündmus, näiteks 'naaber kadunud', tegin kohe kanali paisumise teate.

Edasi liikudes, ilmusid objektile klikkides mõned tulemused, lisandusid ka SNMP teatud mõõdikute kogumiseks, aga selle osas on kõik. Süsteem ei arenenud edasi. See tegi kõike, mida ma vajas, see oli hea tööriist. Paljud lugejad ütlevad tõenäoliselt, et nende probleemide lahendamiseks on internetis juba hulk tarkvara. Aga tegelikult ei leidnud ma selliseid tasuta tooteid ja tahtsin väga arendada oma programmeerimisoskusi, ning mis võiks olla parem selleks kui reaalne praktiline probleem. Niisiis, esimene versioon jälgimisest oli lõpetatud ja enam ei muudetud.

Ettevõtte Audit-Telecom loomine

Aeg läks edasi, hakkasin töötama koos teiste ettevõtetega, kuna tööaeg võimaldas mul seda teha. Erinevates ettevõtetes töötamine suurendab kiiresti oskusi erinevates valdkondades ja laiendab silmaringi. On ettevõtteid, kus, nagu tavaliselt öeldakse, oled sa nii kingsepp, kui lõikaja, kui ka kõigis muudes ametites osav. Ühest küljest on see keeruline, kuid teisest küljest, kui sa ei laiselnud, saad taustaga spetsialistiks ning see võimaldab sul kiiremini ja efektiivsemalt probleeme lahendada, kuna sa tead, kuidas kõrvaline valdkond töötab.

Minu sõber Pavel (samuti IT-spetsialist) üritas mind pidevalt oma äri alustama saada. Oli lugematu arv ideid erinevate oma ettevõtete variantide kohta. Seda arutati mitte ühe aasta jooksul. Ja lõpuks ei pidanud see kuhugi viima, sest olin skeptik ja Pavel unistaja. Igal korral, kui ta pakkus läbi mõeldud ideed, ei uskunud ma kunagi sellesse ja keeldusin osalemast. Kuid meil oli tõeliselt soov avada oma äri.

Lõpuks leidsime mõlemale sobiva variandi ning saame teha seda, milles oleme head. 2016. aastal otsustasime luua IT-ettevõtte, mis aitaks ettevõtetel IT-ülesandeid lahendada. See hõlmas IT-süsteemide seadistamist (1C, terminaliserver, meiliserver jne), nende hooldamist, klassikalist HelpDeski kasutajatele ja võrgu haldamist.

Aus rääkides, ei uskunud ma ettevõtte asutamise hetkel sellesse umbes 99,9%. Kuid mingil moel suutis Pavel mind proovima sundida ja kiirustades ütlen, et ta oli õige. Me kogusime Pavliga 300 000 rubla, registreerisime uue OÜ "Audit-Telecom", üürisime väikese kontori, tegime ägedaid visiitkaarte, nagu see tõenäoliselt enamikule algajatele ettevõtjatele ja alustasime klientide otsimist. Kliendide otsimine on täiesti eraldi lugu. Võib-olla kirjutame sellest eraldi artikli meie ettevõtte blogi raames, kui see kedagi huvitab. Külmkõned, lendlehed ja muu selline. See ei andnud mingeid tulemusi. Nagu ma nüüd paljusid ärilugusid lugedes näen, sõltub paljuski õnnest. Meil vedas. Ja vaid paar nädalat pärast firma loomist pöördus meie poole minu vend Vladimir, kes tõi meile esimese kliendi. Ma ei hakka köitma teiega klientide töötlemise detailidega, see artikkel ei käsitle seda, ütlen vaid, et kuikusime auditeerimisel, avastasime kriitilised kohad ja need koha lõhkesid, samal ajal kui otsustati, kas koostööd teha meiega pideva väliseksternina. Pärast seda tehti kohe positiivne otsus.

Edasi, peamiselt läbi suusõnalise info tuttavate kaudu, hakkasid ilmuma ka teised teenusepakkujad. Helpdesk oli ühes süsteemis. Ühendused võrguseadmete ja serveritega olid teises, täpsemalt kuidas kellelgi. Keegi salvestas otseteed, keegi kasutas RDP kontaktiteateid. Jälgimine oli veel üks eraldi süsteem. Töö tegemine meeskonnale erinevates süsteemides on väga ebamugav. Tähtne teave jääb silma alt ära. Näiteks, kui kliendi terminaliserver muutub kättesaamatuks. Koheselt tuleb taotlusi selle kliendi kasutajatelt. Toetusteenuse spetsialist avab taotluse (see tuli telefoni teel). Kui sündmused ja taotlused registreeritaks ühes süsteemis, siis näeks toetuspetsialist kohe, mis probleem on kasutajal ja saaks sellele teada anda, samal ajal juba ühendudes vajaliku objektiga olukorra lahendamiseks. Kõik on teadlikud taktikalistest seisunditest ja töötavad ühtselt. Me ei leidnud sellist süsteemi, kus kõik oleks kokku pandud. Selgeks sai, et on aeg luua oma toode.

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

Selgelt oli näha, et varasemalt loodud süsteem ei sobinud praegustele ülesannetele ei funktsionaalsuse ega kvaliteedi osas. Seetõttu otsustati luua süsteem nullist. Visuaalselt pidi see välja nägema hoopis teisiti. See pidi olema hierarhiline süsteem, mis võimaldaks kiirelt ja mugavalt avada vajalikke objekte õige kliendi juures. Esimese versiooni skeem ei olnud käesoleval juhul absoluutselt põhjendatud, kuna kliendid olid erinevad ja ei omanud tähtsust, millistes ruumides seadmed asusid. See oli juba dokumentatsioonile üle viidud.

Nii et ülesanded:

Hierarhiline struktuur;
Mõni serveripoolne komponent, mille saaks paigaldada kliendi juurde virtuaalmasina kujul vajalikud mõõdikute kogumiseks ning edastamiseks keskserverisse, mis seda kõike kokku koondab ja meile kuvab;
Teavitused. Sellised, mida ei saa mööda lasta, kuna tol hetkel ei olnud kedagi, kes saaks lihtsalt monitori jälgida;
Päringute süsteem. Kliente hakkas tulema, kellele pakkusime teenuseid mitte ainult serverite ja võrgu seadmete osas, vaid ka tööjaamade osas;
Võimalus kiiresti ühenduda serverite ja seadmetega süsteemist;

Ülesanded on paika pandud, hakkame kirjutama. Samuti töötame klientide taotluste üles. Sel hetkel olime juba neli inimest. Hakkasime kohe kirjutama nii keskset serverit kui ka serverit paigaldamiseks klientidele. Sel hetkel polnud Linux meile teema ja otsustasime, et virtuaalmasinad, mis klientidel töötavad, saavad olema Debianil. Me ei hakka midagi installima, lihtsalt teeme serveriosa projekti ühele kindlale virtuaalmasinale, pärast kloonime selle vajalikule kliendile. See oli järgmine viga. Hiljem sai selgeks, et sellises skeemis ei olnud uuenduste mehhanism täiesti läbi töötatud. Ehk me lisasime mõne uue funktsiooni ja siis tekkis terve probleem selle levitamisel kõikidele klientide serveritele, aga sellest räägime hiljem, kõik õigel ajal.

Läbiviidud esimene prototüüp. Sellel oli võimalus pingida meie klientide ja serverite vajalikke võrgu seadmeid ning edastada need andmed meie keskserverisse. Selle tulemusena värskendas see andmeid kogu andmebaasis keskserveris. Kannan siin edasi mitte ainult loo, kuidas ja mida me saavutasime, vaid ka milliseid algaja vigu me tegime ning kuidas me hiljem selle eest ajaga maksime. Nii et kogu objektide puu salvestati ühte ainsasse faili kui serialiseeritud objekti kujul. Kuni me süsteemi mõned kliendid ühendasime, oli kõik enam-vähem normaalne, ehkki mõnikord esinesid mingid artefaktid, mis olid täiesti arusaamatud. Ent kui me süsteemi tosin serverit ühendasime, hakkasid imed toimuma. Mõnikord, tundmatul põhjusel, kadusid kõik objektid süsteemist lihtsalt. Siin on oluline märkida, et kliendi serverid saatsid andmeid keskserverisse iga paar sekundi järel POST-päringu kaudu. Tähelepanelik lugeja ja kogenud programmeerija juba aimab, et tekkis probleem sama faili juurdepääsuga, kus hoiti serialiseeritud objekti erinevatest voogudest korraga. Ja just siis, kui see juhtus, ilmusid ka imed objektide kadumises. Fail muutus lihtsalt tühjaks. Kuid neid probleeme ei avastatud kohe, vaid ainult mitme serveri kasutamise protsessis. Selle aja jooksul lisati funktsioon sadamate skannimiseks (serverid saatsid keskserverisse mitte ainult seadmete kättesaadavuse teavet, vaid ka avatud pordid). See toimus käsu väljakutse kaudu:

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

tulemused olid sageli valed ja skaneerimine toimis väga aeglaselt. Unustasin täiesti pinget, see tehti fpinguga:

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

See kõik ei olnud ka paralleelne, seetõttu oli protsess väga pikk. Hiljem edastati fpingule kohe terve nimekiri vajalike IP-aadressidest kontrollimiseks ja tagasi saime valmis nimekirja nendest, kes reageerisid. Erinevalt meist oskas fping protsesse paralleelseks muuta.

Teine sage rutiin oli mingite teenuste seadistamine läbi WEBi. Näiteks MS Exchange'i ECP. Suures plaanis on see lihtsalt link. Otsustasime, et meil peab olema võimalus lisada selliseid linke otse süsteemi, et mitte otsida dokumentatsioonist või mujalt, kuidas siseneda konkreetse kliendi ECP-sse. Nii tekkis mõiste ressursilinkide jaoks süsteemis, nende funktsioon on endiselt saadaval ja pole peaaegu muutunud.

Ressursilinkide töö 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 miljonite eelnevalt salvestatud RDP otsetee läbimine oli äärmiselt ebamugav. Oli vaja tööriista. Internetis on tarkvara, mis esindab end midagi nagu aadressiraamat selliste RDP ühenduste jaoks, kuid need ei ole integreeritud jälgimissüsteemiga ja kontoandmeid ei saa salvestada. Iga kord erinevate klientide jaoks kontode sisestamine on tõeline õudus, kui päeva jooksul ühendad sa erinevatesse serveritesse mitte ühe, vaid mitukümmend korda. SSH-ühendustega on olukord veidi parem; on palju head tarkvara, kus on võimalik sellised ühendused kaustadesse paigutada ja neid kontosid meeles pidada. Kuid on kaks probleemi. Esiteks, RDP ja SSH ühenduste jaoks ei leidnud me ühtegi ühtset programmi. Teiseks, kui ma mingil hetkel oma arvuti taga ei viibi ja tahan kiiresti ühenduda, või kui ma lihtsalt viisin süsteemi uuesti üles, pean ma piirdumas dokumentatsiooniga, et vaadata selle kliendi konto. See on ebamugav ja aeg läheb raisku.

Meile vajalik hierarhiline struktuur klientide serverites oli juba olemas meie siseproduktis. Tuleb vaid välja mõelda, kuidas sinna liita kiire ühendus vajalike seadmetega. Alguses, vähemalt oma võrgu sees.

Arvestades, et meie süsteemis esindas klienti brauser, millel ei ole juurdepääsu arvuti kohalikest ressurssidest, et lihtsalt võtta ja käivitada vajalik rakendus mõne käsuga, mõeldi välja, et kõik tehakse läbi "Windowsi kohandatud URL-i skeemi". Nii tekkis meie süsteemiga teatud "plugin", mis lihtsalt sisaldas enda koosseisus Putty ja Remote Desktop Plus ning registreeris installimisel lihtsalt URI skeemi Windowsis. Nüüd, kui soovisime objekti ühendama RDP või SSH kaudu, klõpsasime lihtsalt selle toimingu peal meie süsteemis ja aktiveerus Kohandatud URI töö. Käivitati Windowsisse integreeritud standardne mstsc.exe või putty, mis oli osa "pluginist". Kasutan sõna plugin jutumärkides, sest see ei ole klassikalisel mõttel brauseri plugin.

See on juba vähemalt midagi. Mugav aadressiraamat. Putty puhul läks kõik üldse hästi, selle sisendparameetritena sai edastada nii IP-ühenduse, kasutajanime kui ka parooli. St, Linuxi serveritesse oma võrgus saime ühendust luua ühe klõpsuga, ilma paroolide sisestamiseta. Kuid RDP-ga ei ole kõik nii lihtne. Standardsesse mstsc-sse ei saa sisestada sisselogimisteavet parameetritena. Appi tuli Remote Desktop Plus. See võimaldas seda teha. Praegu saame juba ilma selleta hakkama, kuid pikka aega oli see meie süsteemi usaldusväärne abimees. HTTP(S) veebisaitide puhul on kõik lihtne, sellised objektid avati lihtsalt brauseris ja kõik. Mugav ja praktiline. Kuid see oli õnn ainult sisevõrgus.

Kuna enamik probleeme lahendati eemalt kontorist, oli kõige lihtsam luua VPN-id klientidele. Ja siis sai meie süsteemist neile ühenduda. Kuid see oli ikkagi veidi ebamugav. Iga kliendi jaoks tuli igas arvutis hoida hunnik salvestatud VPN Ühenduste hulgas, enne kui midagi ühendada, pidime aktiveerima vastava VPN-i. Kasutasime seda lahendust piisavalt kaua. Kuid klientide arv suureneb, VPN-ide arv samuti ja see kõik hakkas pinget avaldama, seega pidime midagi ette võtma. Eriti valusaks läks asi pärast süsteemi uuesti installimist, kui tuli uuesti kümneid VPN-ühendusi uues Windowsi profiilis sisestada. Ma ei tahtnud enam seda taluda, ütlesin ma ja hakkasin mõtlema, mida sellega teha.

Nii on juhtunud, et kõigil klientidel oli marsruuteriteks tuntud firma Mikrotik seadmed. Need on väga funktsionaalsed ja mugavad, et lahendada praktiliselt igasuguseid ülesandeid. Puudusteks on nende ”kaaperdamine”. Me lahendasime selle probleemi lihtsalt, blokeerides kõik välised juurdepääsud. Kuid pidime leidma viisi nendele ligipääsemiseks, ilma et oleksime pidanud kliendi juurde kohale minema, kuna see võtab kaua aega. Me lihtsalt loome igasse sellesse mikrotikusse tunnelid ja eraldasime need eraldi basseiniks, ilma igasuguse marsruutimise ta, et oma võrku klientide ja nende võrkude vahel kokku ei segataks.

Sündis idee, et kui süsteemis vajutada soovitud objektile, siis keskne jälgimisserver, teades kõigi kliendi mikrotikute SSH kontosid, ühenduks vajalikuga, looks reegli edastamiseks soovitud hostile õiges sadamas. Siin on mitu aspekti. Lahendus ei ole universaalne — see töötab ainult mikrotiki puhul, kuna käskude süntaks on igal marsruuteril erinev. Lisaks tuleb sellised edastused hiljem kuidagi eemaldada, aga meie süsteemi serveripool ei suutnud kuidagi jälgida, kas lõpetasin oma RDP tööseansi. Ja selline edastus — see on augur klientide jaoks. Universaalsuse poole me ei püüelnud, kuna toode kasutati ainult meie ettevõtte sees ja avalikku ruumi viimisele isegi mõtteid ei olnud.

Iga probleem lahendati omamoodi. Kui reegel loodi, oli edastamine lubatud ainult ühe konkreetse välise IP-aadressi (millelt ühendus algatati) jaoks. Seega õnnestus turvaauke vältida. Kuid iga sellise ühenduse juures lisati mikrotikule NAT-le reegel, mis ei kustutatud. On üldiselt teada, et mida rohkem seal reegleid, seda rohkem koormab see ruuteri protsessorit. Ja ausalt öeldes ei suutnud ma aktsepteerida, et ma satun kunagi mingisse mikrotikusse, kus on sadu surnud ja kellelegi mittevajalikke reegleid.

Kuna meie server ei saa jälgida ühenduse staatust, las mikrotik jälgib neid ise. Kirjutasin skripti, mis pidevalt jälgis kõiki edastusreegleid, millel oli kindel kirjeldus (description), ja kontrollis, kas olemas on TCP-ühendus, kus on sobiv reegel. Kui mingit reeglit ei olnud juba mõnda aega, siis tõenäoliselt oli ühendus juba lõpetatud ja selle edastamine saab kustutada. Kõik õnnestus, 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 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
	}
}

Ilmselt oleks saanud selle ilusamaks, kiiremaks jne, kuid see töötas, ei koormanud mikrotikke ja sai suurepäraselt hakkama. Me saime lõpuks ühenduda klientide serverite ja võrku seadmetega lihtsalt ühe hiireklõpsuga. Ilma VPN-i tõstmist ja paroolide sisestamiseta. Süsteemiga oli tõeliselt mugav töötada. Teenindusaeg vähenes, ja me kõik kulutasime aega tööle, mitte vajalike objektide ühendamisele.

Mikrotik varundamine

Meil oli kõikide MikroTikide varukoopiate seade FTP-le. Üldiselt oli kõik hästi. Kuid kui varukoopia välja tõmmata, tuli FTP avada ja sealt otsida. Meil on süsteem, kuhu kõik ruuterid on registreeritud, ning suudame seadmetega SSH kaudu suhelda. Miks me ei võiks teha nii, et süsteem igapäevaselt kõikidelt MikroTikidelt varukoopiad ise kogub, mõtlesin. Ja asusin seda ellu viima. Ühendasime, tegime varukoopia ja viisime selle hoiustamisse.

PHP skriptikood MikroTikilt varukoopia võtmiseks:

<?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); // Ootame varukoopia loomist

    $sftp = ssh2_sftp($connection);

    // Laadi varukoopia fail
    $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);
    // Laadi RSC fail
    $size = filesize("ssh2.sftp://$sftp/atmon.rsc");
    $stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read

Varundus tehakse kahel kujul — binaarne ja tekstiline konfig. Binaarne aitab kiiresti taastada vajalikku konfi, samas kui tekstiline võimaldab mõista, mida teha, kui on toimunud sundvahetus riistvaras ja binaari sellele laadida ei saa. Võtsime kokku veel ühe mugava funktsionaalsuse süsteemis. Uute MikroTik seadmete lisamisel ei olnud vaja midagi konfigureerida, lihtsalt lisasin objekti süsteemi ja määrasin sellele SSH kasutaja. Edasi hoolitses süsteem ise varunduste tegemise eest. Praegusel versioonil SaaS Veliam selle funktsionaalsust veel ei ole, kuid peagi portime selle.

Kuna see nägi välja meie sise süsteemis

Üleminek normaalsele andmebaasi salvestusele

Olen juba varem maininud, et esines artefakte. Mõnikord kadus süsteemis lihtsalt kogu objektide nimekiri ning mõnikord, kui objekti redigeeriti, ei salvestatud teavet ning tuli objekte ümber nimetada kolm korda. See ajas kõiki meeletult närvi. Objektide kadumine toimus harva ja oli kergesti taastatav selle faili taastamise teel, kuid objekti redigeerimise ebaõnnestumine oli tõeliselt sage. Tõenäoliselt ei teinud ma seda algselt andmebaasi kaudu, sest ei suuda mõista, kuidas hoida puu koos kõigi suhetega tasapinnalises tabelis. See on ju tasapind ning puu on hierarhiline. Kuid hea lahendus korduvkasutuseks ja hiljem (süsteemi keerukuse kasvades) ka tehingute jaoks on andmebaasihaldussüsteem. Ma ei ole tõenäoliselt esimene, kes sellise probleemiga silmitsi seisab. Hakkasin Google'ist otsima. Selgus, et kõik on juba enne mind välja mõeldud ja on mitmeid algoritme, mis ehitavad puu tasapinnalisest tabelist. Vaadates igaüht neist, rakendasin ma ühte neist. Kuid see oli juba uus süsteemi versioon, kuna põhimõtteliselt tuli seda palju ümber kirjutada. Tulemus oli loogiline: süsteemi juhuslik käitumine kadus. Keegi võib öelda, et vead olid üsna amatöörlikud (ühe sõltuva skriptid, teabe hoidmine, millele ligipääs oli mitmest allikast failis jne.) tarkvaraarenduse valdkonnas. Võib-olla on see tõsi, kuid minu põhitegevus oli haldamine ning programmeerimine oli minu jaoks kõrvaline tegevus, ja mul polnud lihtsalt kogemust töötada programmide arendajate meeskonnas, kus sellised elementaarsed asjad oleksid mind kohe vanemate kolleegide poolt juhendatud. Seepärast kogusin kõik need peavalud iseseisvalt, kuid õppisin materjali väga hästi. Lisaks sisaldab see, mida ma teen — kohtumisi klientidega, tegevusi, mille eesmärgiks on firma edendamine, ja hulga haldusprobleeme ettevõtte sees ning palju muud. Aga niisiis, see, mis oli, oli juba nõutud. Meeskond ja mina kasutasime toodet igapäevases töös. Oli ka piinlikke ebaõnnestunud ideid ja lahendusi, mille peale raisati aega ning tulemuseks oli, et see ei olnud toimiv tööriist ja keegi ei kasutanud seda ning see ei jõudnud Veliami.

Klienditugi — HelpDesk

Tasub mainida, kuidas HelpDesk välja kujunes. See on hoopis eraldi lugu, kuna Veliamis on see juba kolmas täiesti uus versioon, mis erineb kõigist eelnevatest. Praegu on see lihtne süsteem, intuitiivne ja ülemääraste keerukusteta, pakub integreerimist domeeni ja võimalust pääseda sellele samale kasutajaprofiilile igast kohast, järgides linki e-kirjast. Mis on kõige olulisem, on võimalus ühenduda taotlejaga igast kohast (olen kodus või kontoris) VNC kaudu otse taotluse seest, ilma VPN-i või portide edasi suunamata. Räägin, kuidas me sinna jõudsime, mis oli enne seda ja millised kohutavad lahendused olid.

Me ühendasime kasutajad läbi tuntud TeamViewer'i. Kõikidel arvutitel, mille kasutajaid me teenindasime, oli TV installitud. Esimene viga, mille me tegime ja hiljem kõrvaldada otsustasime, oli iga kliendi HD sidumine riistvaraga. Kuidas kasutaja sisenes HD süsteemi, et teha taotlust? Kõikide arvutite jaoks, välja arvatud TV, oli installitud spetsiaalne utiliit, mis oli kirjutatud Lazaruses (paljud võivad nüüd silmi kokku pigistada ja võib-olla isegi Google'ist otsima hakata, mis see on, kuid parima compileritena teadsin ma Delphi't, ja Lazarus on peaaegu sama, ainult tasuta). Kokkuvõttes käivitas kasutaja oma arvutis spetsiaalse skripti, mis käivitas selle utiliidi, mis omakorda luges süsteemi HWID ja seejärel avas brauseri ning toimus autentimine. Miks see tehti? Mõnes ettevõttes loetakse teenindatavaid kasutajaid ükshaaval ja teeninduse hind kuus kujuneb sõltuvalt inimeste arvust. See on arusaadav, ütlete teie, aga miks seadmega sidumine? Väga lihtsalt, mõned isikud tulid koju ja tegid kodu sülearvutist taotlusi stiilis “tehke mulle siin kõik ilusaks”. Peale HWID lugemist tõmbas utiliit registreerimisest ka jooksva TeamViewer'i ID ja edastas selle meile. TeamViewer'il on integratsiooni jaoks API. Ja me tegime selle integratsiooni. Kuid oli üks probleem. Nende API-de kaudu ei saa kasutaja arvutisse ühenduda, kui ta ei alusta seda seanssi ise ja peale ühendumise katset peab ta veel ” kinnitama”. Tol ajal tundus meile loogiline, et ilma kasutaja nõusolekuta ei tohiks keegi sisse logida, ja kuna inimene on arvuti taga, siis ta algatab seansi ja vastab positiivselt kaugühenduse taotlusele. Kõik polnud aga niivõrd lihtne. Taotlejad unustasid seansi algatamise vajutamise, ja tuli telefonikõnes rääkida sellest. See võttis aega ja ajas mõlemad osapooled närvi. Veelgi enam, sellised hetked, mil inimene jätab taotluse, kuid lubab sisse logida alles siis, kui ta läheb lõunale, ei ole haruldased. Sest probleem pole kriitiline ja nad ei taha, et nende töörutiin katkeks. Seetõttu ei vajuta nad ühtegi nuppu, et lubada ühenduda. Nii tekkis lisafunktsionaalsus HelpDeski autentimise ajal — TeamViewer'i ID lugemine. Me teadsime püsivat parooli, mida kasutati TeamViewer'i installimisel. Täpsemalt teadis seda ainult süsteem, kuna see oli sisse kirjutatud installijasse ja meie süsteemi. Seega oli nupp taotlusest ühendamiseks, millele vajutades ei pidanud enam ootama, vaid avanes kohe TeamViewer ja toimus ühendamine. Lõpptulemusena tekkis kaks võimalikku ühendusviisi. Ameti TeamViewer'i ametlik API kaudu ja meie enda lahendus. Minu üllatuseks lõpetati esimene peaaegu kohe kasutamine, kuigi oli juhis kasutada seda ainult erilistel juhtudel ja kui kasutaja selleks nõusoleku annab. Kõik sõltub nüüd turvalisusest. Kuid selgus, et taotlejatele polnud see vajalik. Nad ei olnud sugugi mitte vastu, et nende juurde ühendatakse ilma kinnitamisnuputa. Ja kuna nii on, siis ka API kaudu ühendamine kaotati edaspidi tarbetusena.

Liikumine mitmeprogrammilisusele Linuxis

On ammu tekkinud küsimus, kuidas kiirendada võrgu skanneri läbimist, et kontrollida eelnevalt määratud sadamate loendi avatusi ja lihtsalt objektide võrgupingutust. Siin on loomulik esimenene lahendus, mis pähe tuleb — mitmeprogrammilisus. Kuna peamine aeg, mis pingil kulub, on paketi vastuse ootamine ja järgmine ping ei saa alata, enne kui eelmine pakett tagasi ei tule, võib see äärmiselt aeglaselt töötada ettevõtetes, kus on isegi 20+ serverit ja võrgu seadmeid. Küsimus on selles, et üks pakett võib ka kaduda ning ei saa ju sellest kohe süsteemiadministraatorit teavitada. Ta lihtsalt lõpetab sellise spämmimise väga kiiresti tuntuks saamast. Seega on vaja igat objekti pingida veel mitu korda enne, kui teha järeldusi puudumise kohta. Ilma liialdamata, tuleb seda paralleelselt teha, sest vastasel korral saab süsteemiadministraator probleemist teada pigem kliendi käest, mitte jälgimissüsteemist.

PHP ei toeta enamasti mitme lõime kasutamist, vaid toetab mitme protsessi loomist, seega on võimalik teha fork. Mul oli juba olemas küsitlusmehhanism ja soovisin lugeda kõik vajalikud sõlmed andmebaasist, pingutada need kõik korraga, oodata igalt vastust ja alles siis kirjutada andmed. See säästab lugemisepäringute arvu. Sellesse ideesse sobis suurepäraselt multithreading. PHP jaoks on olemas PThreads moodul, mis võimaldab luua reaalselt mitme lõime kasutamist, kuigi pidin selle seadistamise kallal veidi vaeva nägema PHP 7.2 jaoks, kuid see õnnestus. Portide skaneerimine ja pingid muutusid kiiresti. Näiteks 15 sekundit ühe ringi kohta varem, nüüd kulus sellele protsessile vaid 2 sekundit. See oli hea tulemus.

Uute ettevõtete kiire ülevaatus

Kuidas tekkis funktsioon erinevate meetrite ja riistvara omaduste kogumiseks? Kõik on tegelikult lihtne. Meilt tellitakse vahel lihtsalt olemasoleva IT-infrastruktuuri audit. Samuti on see vajalik uue kliendi auditi kiiremaks läbiviimiseks. Vajasime midagi, mis võimaldaks keskmise või suure ettevõttega kiiresti tutvuda, milline on nende varustus. Pingitõkked sisemise võrgu vahel kehtestavad minu arvates vaid need, kes tahavad endale elu keerulisemaks teha, ja meie kogemuste põhjal on neid vähe. Kuid ka selliseid kohtame. Seega on võimalik võrke kiiresti seadmete olemasolu osas lihtsa pingiga skaneerida. Edasi saab need seadmed lisada ja skaneerida avatud portide osas, mis meid huvitavad. Sisuliselt oli see funktsioon juba olemas, tuli vaid lisada käsk keskserverilt alamserverile, et viimane skaneeriks määratud võrke ja lisaks loendisse kõik, mida leiab. Unustasin mainida, et oletati, et meil on juba valmis pilt seadistatud süsteemiga (alamserveri monitooring), mille saime lihtsalt kliendi juures auditi käigus seadistada ja oma pilve ühendada.

Kuid auditi tulemus hõlmab tavaliselt hulgaliselt erinevat teavet, millest üks on — millised seadmed võrgus üldse on. Esiteks olid meid huvitavad Windows serverid ja Windows töökohad, mis kuuluvad domeeni. Kuna keskmistes ja suurtes ettevõtetes on domeeni puudumine tõenäoliselt erand reeglist. Et saada ühte keelt rääkida, pean silmas keskmist, mis minu arvates on 100+ inimest. Tuli leida viis, kuidas koguda andmeid kõigilt Windows masinailt ja serveritelt, teades nende IP-aadresse ja domeenihalduri kontot, kuid samas mitte installides igale neist mingit tarkvara. Appi tuli WMI liides. Windows Management Instrumentation (WMI) tõlgituna tähendab Windows'i haldamise tööriistu. WMI on üks põhilisi tehnoloogiaid Windows'i platvormi all olevate erinevate osade tsentraliseeritud haldamiseks ja jälgimiseks. See on välja võetud vikist. Edasi tuli jälle natuke vaeva näha, et koguda wmic (see on WMI klient) Debianile. Pärast seda, kui kõik oli valmis, jäi vaid küsida wmic'iga vajalikke sõlmesid vajalikku teavet. WMI-ga on võimalik Windows arvutist välja tõmmata peaaegu ükskõik milline teave, ja mis veelgi enam, selle abil saab ka arvutit juhtida, näiteks saata see taaskäivitama. Nii tekkis info kogumine Windows töökohadest ja serveritest meie süsteemis. Lisaväärtuseks tuli pidev teave süsteemi koormuse näitajate kohta. Neid küsime tihedamalt, samas kui riistvara teavet harvem. Pärast seda oli auditi läbiviimine natuke meeldivam.

Tarkvaralahenduse levitamine

Kasutame süsteemi igapäevaselt, ja see on alati avatud iga tehnilise töötaja jaoks. Mõtlesime, et võiksime jagada seda, mis meil juba olemas on. Süsteem ei olnud veel valmis levitatavaks. Oli vajalik teha mitmeid muudatusi, et kohalik versioon muutuks SaaS-iks. See hõlmas erinevaid tehnilisi muudatusi süsteemi töös (kaugühendused, tugiteenused), moodulite litsentsimise analüüsi, klientide andmebaaside jagamist, igas teenuses skaalamist ning automaatse ajakohastamise süsteemide väljatöötamist kõigile osadele. Kuid sellest räägib artikli teine osa.