🥇Fra outsourcing til udvikling (del 1)

Hej alle sammen, mit navn er Sergey Emelyanchik. Jeg er leder af Audit-Telecom-virksomheden, hovedudvikleren og forfatteren af Veliam-systemet. Jeg besluttede at skrive en artikel om, hvordan min ven og jeg oprettede et outsourcingfirma, skrev software til os selv og begyndte efterfølgende at distribuere det til alle via SaaS-systemet. Om hvordan jeg kategorisk ikke troede på, at dette var muligt. Artiklen vil ikke kun indeholde en historie, men også tekniske detaljer om, hvordan Veliam-produktet blev skabt. Herunder nogle stykker kildekode. Jeg fortæller dig, hvilke fejl vi lavede, og hvordan vi rettede dem senere. Der var tvivl om, hvorvidt man skulle publicere sådan en artikel. Men jeg tænkte, at det var bedre at gøre det, få feedback og forbedre, end ikke at udgive artiklen og tænke over, hvad der ville være sket, hvis...

forhistorie

Jeg arbejdede i en virksomhed som IT-medarbejder. Virksomheden var ret stor med en omfattende netværksstruktur. Jeg vil ikke dvæle ved mine arbejdsopgaver, jeg vil kun sige, at de bestemt ikke omfattede udvikling af noget.

Vi havde overvågning, men udelukkende af akademisk interesse ville jeg prøve at skrive min egen enkleste. Ideen var denne: Jeg ønskede, at det skulle være på nettet, så jeg nemt kunne gå ind uden at installere nogen klienter og se, hvad der skete med netværket fra enhver enhed, inklusive en mobilenhed via Wi-Fi, og jeg ville hurtigt forstå, hvad Der er udstyr i rummet, der er blevet "mopey" fordi... der var meget strenge krav til responstid på sådanne problemer. Som et resultat blev der født en plan i mit hoved om at skrive en simpel webside, hvor der var en jpeg-baggrund med et netværksdiagram, skære selve enhederne ud med deres IP-adresser på dette billede og vise dynamisk indhold oven på billede i de nødvendige koordinater i form af en grøn eller blinkende rød IP-adresse. Opgaven er sat, lad os komme i gang.

Tidligere programmerede jeg i Delphi, PHP, JS og meget overfladisk C++. Jeg ved godt, hvordan netværk fungerer. VLAN, Routing (OSPF, EIGRP, BGP), NAT. Dette var nok for mig til selv at skrive en primitiv overvågningsprototype.

Jeg skrev hvad jeg havde planlagt i PHP. Apache- og PHP-serveren var på Windows, fordi... Linux for mig på det tidspunkt var noget uforståeligt og meget komplekst, som det viste sig senere, tog jeg meget fejl, og mange steder er Linux meget enklere end Windows, men dette er et separat emne, og vi ved alle, hvor mange holivarer der er på dette emne. Windows-opgaveplanlæggeren trak med et lille interval (jeg husker ikke præcist, men noget i retning af en gang hvert tredje sekund) et PHP-script, der pollede alle objekter med et banalt ping og gemte tilstanden til en fil.

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

Ja, ja, at arbejde med en database på det tidspunkt var heller ikke mestret for mig. Jeg vidste ikke, at det var muligt at parallelisere processer, og det tog lang tid at gå igennem alle netværksnoder, fordi... dette skete i en tråd. Problemer opstod især, når flere noder var utilgængelige, pga hver af dem forsinkede scriptet i 300 ms. På klientsiden var der en simpel looping-funktion, der med et par sekunders mellemrum downloadede opdateret information fra serveren med en Ajax-anmodning og opdaterede interfacet. Nå, så, efter 3 mislykkede ping i træk, hvis en webside med overvågning var åben på computeren, spillede en munter komposition.

Da alt fungerede, blev jeg meget inspireret af resultatet og tænkte, at jeg kunne tilføje mere til det (grundet min viden og evner). Men jeg har altid ikke kunne lide systemer med en million diagrammer, hvilket jeg troede dengang, og stadig synes den dag i dag, er unødvendigt i de fleste tilfælde. Jeg ville kun lægge det der virkelig ville hjælpe mig i mit arbejde. Dette princip forbliver grundlæggende for udviklingen af Veliam den dag i dag. Yderligere indså jeg, at det ville være meget fedt, hvis jeg ikke behøvede at holde overvågningen åben og vide om problemer, og når det skete, så åbne siden og se, hvor denne problematiske netværksknude er placeret, og hvad jeg skal gøre med den næste . På en eller anden måde læste jeg ikke e-mail dengang, jeg brugte den simpelthen ikke. Jeg stødte på Internettet, at der er SMS-gateways, som man kan sende en GET eller POST-anmodning til, og de sender en SMS til min mobiltelefon med den tekst, som jeg skriver. Jeg indså straks, at jeg virkelig gerne ville det her. Og jeg begyndte at studere dokumentationen. Efter nogen tid lykkedes det, og nu modtog jeg en SMS om problemer på netværket på min mobiltelefon med navnet på en "falden genstand". Selvom systemet var primitivt, var det skrevet af mig selv, og det vigtigste, der motiverede mig til at udvikle det, var, at det var et applikationsprogram, der virkelig hjalp mig i mit arbejde.

Og så kom dagen, hvor en af internetkanalerne gik ned på arbejde, og min overvågning gav mig ikke besked om det. Da Google DNS stadig pingede perfekt. Det er tid til at tænke over, hvordan du kan overvåge, at kommunikationskanalen er i live. Der var forskellige ideer til, hvordan dette skulle gøres. Jeg havde ikke adgang til alt udstyret. Vi skulle finde ud af at forstå, hvilken af kanalerne der er live, men uden at kunne se det på selve netværksudstyret. Så kom en kollega med den idé, at det er muligt, at rutesporingen til offentlige servere kan variere afhængigt af, hvilken kommunikationskanal der i øjeblikket bruges til at få adgang til internettet. Jeg tjekkede og det viste sig sådan. Der var forskellige ruter ved sporing.

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

Så et andet script dukkede op, eller rettere, af en eller anden grund blev sporet tilføjet til slutningen af det samme script, som pingede alle enheder på netværket. Dette er trods alt endnu en lang proces, der blev udført i samme tråd og bremsede arbejdet med hele scriptet. Men så var det ikke så tydeligt. Men på en eller anden måde gjorde han sit arbejde, koden definerede strengt, hvilken slags sporing der skulle være for hver af kanalerne. Sådan begyndte systemet at fungere, som allerede overvågede (højt sagt, fordi der ikke var nogen indsamling af nogen metrik, men bare ping) netværksenheder (routere, switches, wi-fi osv.) og kommunikationskanaler med omverdenen . SMS-beskeder kom jævnligt, og diagrammet viste altid tydeligt, hvor problemet var.

Yderligere skulle jeg i det daglige arbejde krydse. Og jeg blev træt af at gå til Cisco-switche hver gang for at se, hvilken grænseflade jeg skulle bruge. Hvor fedt det ville være at klikke på et objekt i overvågning og se en liste over dets grænseflader med beskrivelser. Det ville spare mig tid. Desuden ville der i denne ordning ikke være behov for at køre Putty eller SecureCRT for at indtaste konti og kommandoer. Jeg klikkede bare på overvågningen, så hvad der skulle til og gik for at udføre mit arbejde. Jeg begyndte at lede efter måder at interagere med switches på. Jeg stødte straks på 2 muligheder: SNMP eller at logge på switchen via SSH, indtaste de kommandoer, jeg havde brug for, og parse resultatet. Jeg afviste SNMP på grund af kompleksiteten af dens implementering; jeg var utålmodig efter at få resultatet. med SNMP, ville du skulle grave i MIB i lang tid og, baseret på disse data, generere data om grænsefladerne. Der er et vidunderligt team hos CISCO

show interface status

Det viser præcis, hvad jeg skal bruge til krydskrydsninger. Hvorfor bøvle med SNMP, når jeg bare vil se outputtet af denne kommando, tænkte jeg. Efter nogen tid indså jeg denne mulighed. Klik på et objekt på en webside. En hændelse blev udløst, hvorved AJAX-klienten kontaktede serveren, og den tilsluttede sig til gengæld via SSH til den switch, jeg havde brug for (legitimationsoplysningerne blev hardkodet ind i koden, der var ikke noget ønske om at forfine den, for at lave nogle separate menuer, hvor det ville være muligt at ændre konti fra grænsefladen, jeg havde brug for resultatet og hurtigt) Jeg indtastede ovenstående kommando der og sendte den tilbage til browseren. Så jeg begyndte at se information om grænseflader med et enkelt klik med musen. Dette var ekstremt praktisk, især når du skulle se disse oplysninger på forskellige switches på én gang.

Sporbaseret kanalovervågning endte med ikke at være den bedste idé, fordi... nogle gange blev der arbejdet på netværket, og sporingen kunne ændre sig, og overvågningen begyndte at skrige af mig, at der var problemer med kanalen. Men efter at have brugt meget tid på analyser, indså jeg, at alle kanaler fungerede, og min overvågning bedragede mig. Som et resultat bad jeg mine kolleger, der administrerede kanaldannende switche, om blot at sende mig syslog, når naboernes synlighedsstatus ændrede sig. Derfor var det meget enklere, hurtigere og mere præcist end sporing. En begivenhed som nabo tabt er ankommet, og jeg udsteder straks en notifikation om kanalen nede.

Yderligere dukkede flere kommandoer op, når du klikkede på et objekt, og SNMP blev tilføjet for at indsamle nogle metrikker, og det er i bund og grund det. Systemet udviklede sig aldrig yderligere. Det gjorde alt, hvad jeg havde brug for, det var et godt værktøj. Mange læsere vil sikkert fortælle mig, at der allerede findes en masse software på internettet til at løse disse problemer. Men faktisk googlede jeg ikke sådanne gratis produkter dengang, og jeg ville virkelig gerne udvikle mine programmeringsevner, og hvilken bedre måde at presse på for dette end et reelt applikationsproblem. På dette tidspunkt var den første version af overvågningen afsluttet og blev ikke længere ændret.

Oprettelse af Audit-Telecom selskabet

Som tiden gik, begyndte jeg at arbejde deltid i andre virksomheder, heldigvis tillod min arbejdsplan mig at gøre dette. Når du arbejder i forskellige virksomheder, vokser dine kompetencer på forskellige områder meget hurtigt, og din horisont udvikler sig godt. Der er selskaber, hvor man, som man siger, er en svensker, en mejer og en trompetist. På den ene side er det svært, på den anden side, hvis du ikke er doven, bliver du generalist, og det giver dig mulighed for at løse problemer hurtigere og mere effektivt, fordi du ved, hvordan det relaterede felt fungerer.

Min ven Pavel (også IT-specialist) forsøgte konstant at opmuntre mig til at starte sin egen virksomhed. Der var utallige ideer med forskellige variationer af, hvad de lavede. Dette har været diskuteret i årevis. Og i sidste ende skulle det ikke være blevet til noget, for jeg er skeptiker, og Pavel er en drømmer. Hver gang han foreslog en idé, troede jeg altid ikke på den og nægtede at deltage. Men vi ville virkelig gerne åbne vores egen virksomhed.

Endelig var vi i stand til at finde en mulighed, der passede til os begge og gøre, hvad vi ved, hvordan man gør. I 2016 besluttede vi at oprette en it-virksomhed, der skulle hjælpe virksomheder med at løse it-problemer. Dette er udrulning af IT-systemer (1C, terminalserver, mailserver, etc.), deres vedligeholdelse, klassisk HelpDesk til brugere og netværksadministration.

Helt ærligt, da jeg oprettede virksomheden, troede jeg ikke på det omkring 99,9%. Men på en eller anden måde var Pavel i stand til at få mig til at prøve, og ser fremad, viste han sig at have ret. Pavel og jeg chippede 300 rubler ind hver, registrerede en ny LLC "Audit-Telecom", lejede et lille kontor, lavede seje visitkort, ja, generelt, som nok de fleste uerfarne, nybegyndere forretningsmænd, og begyndte at lede efter kunder. At finde kunder er en helt anden historie. Måske vil vi skrive en separat artikel som en del af virksomhedens blog, hvis nogen er interesseret. Cold calls, flyers mv. Dette gav ingen resultater. Som jeg nu læser fra mange historier om forretning, på den ene eller anden måde, afhænger meget af held. Vi var heldige. og bogstaveligt talt et par uger efter oprettelsen af virksomheden henvendte min bror Vladimir sig til os, som bragte os vores første kunde. Jeg vil ikke kede dig med detaljerne om at arbejde med kunder, det er ikke det, artiklen handler om, jeg vil bare sige, at vi gik til revision, identificerede kritiske områder, og disse områder brød sammen, mens beslutningen blev taget om, hvorvidt samarbejder med os løbende som outsourcere. Herefter blev der straks truffet en positiv beslutning.

Så, hovedsageligt gennem mund til mund gennem venner, begyndte andre servicevirksomheder at dukke op. Helpdesk var i ét system. Forbindelser til netværksudstyr og servere er forskellige eller rettere anderledes. Nogle mennesker gemte genveje, andre brugte RDP-adressebøger. Overvågning er et andet separat system. Det er meget ubelejligt for et team at arbejde i forskellige systemer. Vigtig information er tabt af syne. Nå, for eksempel blev klientens terminalserver utilgængelig. Ansøgninger fra brugere af denne klient modtages straks. Supportspecialisten åbner en anmodning (den blev modtaget via telefon). Hvis hændelser og anmodninger blev registreret i et system, ville supportspecialisten straks se, hvad brugerens problem er og fortælle ham om det, mens han samtidig oprettede forbindelse til det nødvendige objekt for at løse situationen. Alle er opmærksomme på den taktiske situation og arbejder harmonisk. Vi har ikke fundet et system, hvor alt dette er kombineret. Det blev klart, at det var tid til at lave vores eget produkt.

Fortsat arbejde med dit overvågningssystem

Det var tydeligt, at systemet, der blev skrevet tidligere, var fuldstændig uegnet til de aktuelle opgaver. Hverken funktionsmæssigt eller kvalitetsmæssigt. Og det blev besluttet at skrive systemet fra bunden. Grafisk burde det have set helt anderledes ud. Det skulle være et hierarkisk system, så det var muligt hurtigt og bekvemt at åbne det rigtige objekt for den rigtige klient. Ordningen som i den første version var absolut ikke berettiget i den aktuelle sag, pga Kunderne er forskellige, og det var slet ikke ligegyldigt, i hvilke lokaler udstyret var placeret. Dette er allerede overført til dokumentationen.

Så opgaverne:

Hierarkisk struktur;
En slags serverdel, der kan placeres på klientens præmisser i form af en virtuel maskine til at indsamle de metrics, vi har brug for, og sende dem til den centrale server, som vil opsummere alt dette og vise det til os;
Advarsler. Dem der ikke kan gå glip af, fordi... dengang var det ikke muligt for nogen at sidde og bare se på skærmen;
Ansøgningssystem. Kunder begyndte at dukke op, for hvem vi servicerede ikke kun server- og netværksudstyr, men også arbejdsstationer;
Evne til hurtigt at oprette forbindelse til servere og udstyr fra systemet;

Opgaverne er sat, vi begynder at skrive. Undervejs behandler forespørgsler fra kunder. På det tidspunkt var vi allerede 4. Vi begyndte at skrive begge dele på én gang: den centrale server og serveren til installation til klienter. På dette tidspunkt var Linux ikke længere fremmed for os, og det blev besluttet, at de virtuelle maskiner, som klienter ville have, skulle være på Debian. Der vil ikke være nogen installatører, vi laver bare et serverdelprojekt på en specifik virtuel maskine, og så kloner vi det bare til den ønskede klient. Dette var endnu en fejl. Senere blev det klart, at i en sådan ordning var opdateringsmekanismen fuldstændig uudviklet. De der. vi tilføjede en ny funktion, og så var der hele problemet med at distribuere det til alle klientservere, men vi vender tilbage til dette senere, alt i orden.

Vi lavede den første prototype. Han var i stand til at pinge de klientnetværksenheder og servere, vi havde brug for, og sende disse data til vores centrale server. Og han opdaterede til gengæld disse data i bulk på den centrale server. Her vil jeg ikke kun skrive en historie om hvordan og hvad der lykkedes, men også hvilke amatørfejl der blev begået, og hvordan jeg senere skulle betale for det med tiden. Så hele træet af objekter blev gemt i en enkelt fil i form af et serialiseret objekt. Mens vi koblede flere klienter til systemet, var alt mere eller mindre normalt, selvom der nogle gange var nogle artefakter, der var helt uforståelige. Men da vi tilsluttede et dusin servere til systemet, begyndte mirakler at ske. Nogle gange, af en eller anden ukendt årsag, forsvandt alle objekter i systemet simpelthen. Det er her vigtigt at bemærke, at de servere, som klienterne havde, sendte data til den centrale server med få sekunders mellemrum via en POST-anmodning. En opmærksom læser og en erfaren programmør gættede allerede, at der var et problem med flere adgang til selve den fil, hvori det serialiserede objekt blev gemt fra forskellige tråde på samme tid. Og netop da dette skete, skete mirakler med forsvinden af genstande. Filen blev simpelthen tom. Men alt dette blev ikke opdaget med det samme, men kun under drift med flere servere. I løbet af denne tid blev portscanningsfunktionalitet tilføjet (serverne, der blev sendt til centralen, ikke kun information om tilgængeligheden af enheder, men også om de porte, der er åbne på dem). Dette blev gjort ved at kalde kommandoen:

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

resultaterne var ofte forkerte, og scanninger tog lang tid at gennemføre. Jeg glemte fuldstændig ping, det blev gjort via fping:

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

Dette var heller ikke paralleliseret, og derfor var processen meget lang. Senere blev hele listen over IP-adresser, der kræves til verifikation, sendt til fping på én gang, og tilbage modtog vi en færdig liste over dem, der svarede. I modsætning til os var fping i stand til at parallelisere processer.

En anden almindelig rutineopgave var at oprette nogle tjenester via WEB. Nå, for eksempel ECP fra MS Exchange. Dybest set er det bare et link. Og vi besluttede, at vi skal være i stand til at tilføje sådanne links direkte til systemet, for ikke at skulle kigge i dokumentationen eller et andet sted i bogmærker efter, hvordan man får adgang til ECP for en specifik klient. Sådan så konceptet med ressourcelinks til systemet ud, deres funktionalitet er tilgængelig den dag i dag og har ikke ændret sig, ja, næsten.

Sådan fungerer ressourcelinks i Veliam

Fjernforbindelser

Sådan ser det ud i aktion i den nuværende version af Veliam

En af opgaverne var hurtigt og bekvemt at oprette forbindelse til servere, som der allerede var mange af (mere end hundrede), og at sortere gennem millioner af forud gemte RDP-genveje var ekstremt ubelejligt. Der var brug for et værktøj. Der er software på internettet, der ligner en adressebog til sådanne RDP-forbindelser, men de er ikke integreret med overvågningssystemet, og konti kan ikke gemmes. At indtaste konti for forskellige klienter hver gang er et rent helvede, når du forbinder snesevis af gange om dagen til forskellige servere. Med SSH er tingene lidt bedre; der er en masse god software, der giver dig mulighed for at organisere sådanne forbindelser i mapper og huske konti fra dem. Men der er 2 problemer. Den første er, at vi ikke fandt et eneste program til RDP- og SSH-forbindelser. Den anden er, at hvis jeg på et tidspunkt ikke er ved min computer, og jeg skal oprette forbindelse hurtigt, eller jeg lige har geninstalleret systemet, bliver jeg nødt til at gå ind i dokumentationen for at se på kontoen fra denne klient. Det er ubelejligt og spild af tid.

Den hierarkiske struktur, vi havde brug for til klientservere, var allerede tilgængelig i vores interne produkt. Jeg skulle lige finde ud af, hvordan man sætter hurtige forbindelser til det nødvendige udstyr der. Til at begynde med, i hvert fald inden for dit netværk.

Under hensyntagen til det faktum, at klienten i vores system var en browser, der ikke har adgang til de lokale ressourcer på computeren, for blot at starte den applikation, vi havde brug for med en kommando, blev den opfundet til at gøre alt gennem "Windows brugerdefineret url-skema”. Sådan optrådte et bestemt "plugin" til vores system, som blot inkluderede Putty og Remote Desktop Plus og under installationen blot registrerede URI-skemaet i Windows. Nu, da vi ønskede at oprette forbindelse til et objekt via RDP eller SSH, klikkede vi på denne handling på vores system, og den brugerdefinerede URI virkede. Standarden mstsc.exe indbygget i Windows eller kit, som var en del af "plugin", blev lanceret. Jeg sætter ordet plugin i anførselstegn, fordi dette ikke er et browser-plugin i klassisk forstand.

Det var i hvert fald noget. Praktisk adressebog. Desuden var alt i Puttys tilfælde generelt fint; det kunne få IP-forbindelser, login og adgangskode som inputparametre. De der. Vi har allerede oprettet forbindelse til Linux-servere på vores netværk med et enkelt klik uden at indtaste adgangskoder. Men med RDP er det ikke så enkelt. Standard mstsc kan ikke levere legitimationsoplysninger som parametre. Remote Desktop Plus kom til undsætning. Han lod dette ske. Nu kan vi undvære det, men i lang tid var det en trofast assistent i vores system. Med HTTP(S)-websteder er alt enkelt, sådanne objekter åbnes simpelthen i browseren, og det er det. Praktisk og praktisk. Men dette var kun lykke på det interne netværk.

Da vi løste langt de fleste problemer eksternt fra kontoret, var det nemmeste at gøre VPN'er tilgængelige for kunderne. Og så var det muligt at oprette forbindelse til dem fra vores system. Men det var stadig noget ubelejligt. For hver klient var det nødvendigt at holde en masse huskede VPN-forbindelser på hver computer, og før der oprettedes forbindelse til nogen, var det nødvendigt at aktivere den tilsvarende VPN. Vi har brugt denne løsning i ret lang tid. Men antallet af klienter stiger, antallet af VPN'er stiger også, og alt dette begyndte at blive anstrengt, og der måtte gøres noget ved det. Jeg fik især tårer i øjnene efter geninstallation af systemet, da jeg skulle genindtaste snesevis af VPN-forbindelser i en ny Windows-profil. Lad være med at finde ud af det her, sagde jeg og begyndte at tænke på, hvad jeg kunne gøre ved det.

Det skete således, at alle klienter havde enheder fra det kendte firma Mikrotik som routere. De er meget funktionelle og praktiske til at udføre næsten enhver opgave. Ulempen er, at de er "kapret". Vi løste dette problem blot ved at lukke for al adgang udefra. Men det var nødvendigt på en eller anden måde at have adgang til dem uden at komme til kundens sted, fordi... den er lang. Vi lavede simpelthen tunneler til hver sådan Mikrotik og adskilte dem i en separat pool. uden nogen routing, så der ikke er nogen forbindelse mellem dit netværk og klienternes netværk og deres netværk med hinanden.

Ideen blev født for at sikre, at når jeg klikker på det objekt, jeg har brug for i systemet, vil den centrale overvågningsserver, der kender SSH-konti for alle klienter Mikrotik, forbinder til den ønskede, opretter en videresendelsesregel til den ønskede vært med nødvendig havn. Der er flere punkter her. Løsningen er ikke universel - den vil kun fungere for Mikrotik, da kommandosyntaksen er forskellig for alle routere. Sådanne videresendelser skulle også på en eller anden måde slettes, og serverdelen af vores system kunne i det væsentlige ikke spore på nogen måde, om jeg havde afsluttet min RDP-session. Nå, sådan videresendelse er et hul for klienten. Men vi forfulgte ikke universalitet, fordi... produktet blev kun brugt i vores virksomhed, og der var ingen tanker om at frigive det til offentligheden.

Hver af problemerne blev løst på sin egen måde. Da reglen blev oprettet, var denne videresendelse kun tilgængelig for én specifik ekstern IP-adresse (hvorfra forbindelsen blev initialiseret). Så et sikkerhedshul blev undgået. Men med hver sådan forbindelse blev en Mikrotik-regel tilføjet til NAT-siden og blev ikke ryddet. Og alle ved, at jo flere regler der er, jo mere belastes routerens processor. Og generelt kunne jeg ikke acceptere, at jeg en dag ville gå til noget Mikrotik, og der ville være hundredvis af døde, ubrugelige regler.

Da vores server ikke kan spore forbindelsesstatus, lad Mikrotik spore dem selv. Og jeg skrev et script, der konstant overvågede alle videresendelsesregler med en specifik beskrivelse og tjekkede, om TCP-forbindelsen havde en passende regel. Hvis der ikke har været en i nogen tid, er forbindelsen sandsynligvis allerede afsluttet, og denne videresendelse kan slettes. Alt fungerede, manuskriptet fungerede godt.

Her er den forresten:

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

Det kunne sikkert have været gjort smukkere, hurtigere osv., men det virkede, belastede ikke Mikrotik og gjorde et fremragende stykke arbejde. Vi var endelig i stand til at oprette forbindelse til kundernes servere og netværksudstyr med blot et enkelt klik. Uden at åbne en VPN eller indtaste adgangskoder. Systemet er blevet rigtig praktisk at arbejde med. Servicetiden blev reduceret, og vi brugte alle tid på at arbejde frem for at forbinde os til de nødvendige genstande.

Mikrotik backup

Vi konfigurerede backup af alle Mikrotik til FTP. Og generelt var alt fint. Men når du skulle have en sikkerhedskopi, skulle du åbne denne FTP og lede efter den der. Vi har et system, hvor alle routere er forbundet, vi kan kommunikere med enheder via SSH. Hvorfor gør vi det ikke sådan, at systemet selv tager backups fra alle Mikrotik dagligt, tænkte jeg. Og han begyndte at implementere det. Vi oprettede forbindelse, lavede en sikkerhedskopi og tog den til lageret.

Scriptkode i PHP til at tage en sikkerhedskopi fra 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');

?>

Sikkerhedskopien tages i to former - binær og tekstkonfiguration. Det binære hjælper med hurtigt at gendanne den nødvendige konfiguration, og teksten en giver dig mulighed for at forstå, hvad der skal gøres, hvis der er en tvungen udskiftning af udstyr, og det binære materiale ikke kan uploades til det. Som et resultat fik vi endnu en praktisk funktionalitet i systemet. Desuden var der ikke behov for at konfigurere noget, da jeg tilføjede nye Mikrotik, jeg tilføjede blot objektet til systemet og satte en konto til det via SSH. Så sørgede systemet selv for at tage backups. Den nuværende version af SaaS Veliam har endnu ikke denne funktionalitet, men vi overfører den snart.

Skærmbilleder af, hvordan det så ud i det interne system

Overgang til normal databaselagring

Jeg skrev allerede ovenfor, at der dukkede artefakter op. Nogle gange forsvandt hele listen af objekter i systemet simpelthen, nogle gange ved redigering af et objekt blev informationen ikke gemt, og objektet skulle omdøbes tre gange. Dette irriterede alle frygteligt. Forsvinden af objekter forekom sjældent og blev nemt gendannet ved at gendanne netop denne fil, men fejl ved redigering af objekter skete ret ofte. Sandsynligvis gjorde jeg i første omgang ikke dette gennem databasen, fordi det ikke passede ind i mit sind, hvordan det var muligt at holde et træ med alle forbindelserne i en flad tabel. Det er fladt, men træet er hierarkisk. Men en god løsning til multiple access, og efterfølgende (i takt med at systemet bliver mere komplekst) transaktionsmæssigt, er et DBMS. Jeg er nok ikke den første, der støder på dette problem. Jeg begyndte at google. Det viste sig, at alt allerede var opfundet før mig, og der er flere algoritmer, der bygger et træ fra et fladt bord. Efter at have set på hver enkelt implementerede jeg en af dem. Men dette var allerede en ny version af systemet, fordi... Faktisk var jeg på grund af dette nødt til at omskrive ret meget. Resultatet var naturligt, problemerne med systemets tilfældige adfærd forsvandt. Nogle vil måske sige, at fejlene er meget amatøragtige (enkelt-trådede scripts, lagring af information, der blev tilgået flere gange samtidigt fra forskellige tråde i en fil, osv.) inden for softwareudvikling. Måske er det sandt, men mit hovedjob var administration, og programmering var en side-jag for min sjæl, og jeg havde simpelthen ikke erfaring med at arbejde i et team af programmører, hvor sådanne grundlæggende ting straks ville være blevet foreslået mig af min senior kammerater. Derfor udfyldte jeg alle disse buler på egen hånd, men jeg lærte materialet meget godt. Og også, mit job involverer møder med kunder, handlinger rettet mod at forsøge at fremme virksomheden, en masse administrative spørgsmål i virksomheden og meget, meget mere. Men på en eller anden måde var det, der allerede var der, efterspurgt. Fyrene og jeg brugte selv produktet i vores daglige arbejde. Der var ærligt talt mislykkede ideer og løsninger, som tiden blev spildt på, men i sidste ende blev det klart, at dette ikke var et arbejdsredskab, og ingen brugte det, og det endte ikke i Veliam.

Helpdesk - HelpDesk

Det ville ikke være forkert at nævne, hvordan HelpDesk blev dannet. Det er en helt anden historie, fordi... i Veliam er dette allerede den 3. helt nye version, som er forskellig fra alle tidligere. Nu er det et enkelt system, intuitivt uden unødvendige klokker og fløjter, med mulighed for at integrere med et domæne, samt mulighed for at få adgang til den samme brugerprofil fra hvor som helst ved hjælp af et link fra en e-mail. Og vigtigst af alt er det muligt at oprette forbindelse til ansøgeren via VNC fra hvor som helst (hjemme eller på kontoret) direkte fra applikationen uden VPN eller port forwarding. Jeg vil fortælle dig, hvordan vi kom til dette, hvad der skete før, og hvilke forfærdelige beslutninger der blev truffet.

Vi oprettede forbindelse til brugere gennem den velkendte TeamViewer. Alle computere, hvis brugere vi betjener, har tv installeret. Det første, vi gjorde forkert, og efterfølgende fjernede det, var at forbinde hver HD-klient til hardware. Hvordan loggede brugeren på HD-systemet for at efterlade en anmodning? Ud over tv havde alle et særligt værktøj installeret på deres computere, skrevet i Lazarus (mange mennesker her vil rulle med øjnene, og måske endda gå på Google, hvad det er, men det bedste kompilerede sprog, jeg kendte, var Delphi, og Lazarus er næsten det samme, kun gratis). Generelt lancerede brugeren en speciel batch-fil, der lancerede dette værktøj, som igen læste systemets HWID, og derefter blev browseren lanceret og godkendelse skete. Hvorfor blev dette gjort? I nogle virksomheder tælles antallet af servicerede brugere individuelt, og serviceprisen for hver måned er baseret på antallet af personer. Det er forståeligt, siger du, men hvorfor er det bundet til hardware? Det er meget enkelt, nogle enkeltpersoner kom hjem og fremsatte en anmodning fra deres hjemmecomputer i stil med "gør alt smukt for mig her." Ud over at læse systemets HWID trak værktøjet det aktuelle Teamviewer ID fra registreringsdatabasen og sendte det også til os. Teamviewer har en API til integration. Og vi gjorde denne integration. Men der var en fangst. Gennem disse API'er er det umuligt at oprette forbindelse til brugerens computer, når han ikke eksplicit starter denne session, og efter at have forsøgt at oprette forbindelse til den, skal han også klikke på "bekræft". På det tidspunkt virkede det logisk for os, at ingen skulle oprette forbindelse uden brugerens anmodning, og da personen er ved computeren, vil han indlede sessionen og svare bekræftende på anmodningen om fjernforbindelse. Alt viste sig forkert. Ansøgere glemte at trykke på initier sessionen og måtte fortælle dem dette i en telefonsamtale. Dette spildte tid og var frustrerende på begge sider af processen. Desuden er det slet ikke ualmindeligt for sådanne øjeblikke, hvor en person efterlader en anmodning, men kun får lov til at oprette forbindelse, når han går til frokost. Fordi problemet ikke er kritisk, og han ønsker ikke, at hans arbejdsproces bliver afbrudt. Han vil derfor ikke trykke på nogen knapper for at tillade forbindelse. Sådan fremstod yderligere funktionalitet, når du loggede på HelpDesk - læser Teamviewers ID. Vi kendte den permanente adgangskode, der blev brugt ved installation af Teamviewer. Mere præcist var det kun systemet, der kendte det, da det var indbygget i installatøren og i vores system. Derfor var der en forbindelsesknap fra applikationen ved at klikke på, hvor der ikke var behov for at vente på noget, men Teamviewer åbnede straks, og der opstod en forbindelse. Som følge heraf var der to typer mulige forbindelser. Gennem den officielle Teamviewer API og vores selvfremstillede. Til min overraskelse stoppede de med at bruge den første næsten med det samme, selvom der var en instruktion om kun at bruge den i særlige tilfælde, og når brugeren selv giver grønt lys. Alligevel, giv mig sikkerhed nu. Men det viste sig, at ansøgerne ikke havde brug for dette. De har det alle helt fint med at være forbundet til dem uden en bekræftelsesknap.

Skift til multithreading i Linux

Spørgsmålet om at fremskynde passagen af en netværksscanner for åbenheden af en forudbestemt liste over porte og simpel ping af netværksobjekter er længe begyndt at opstå. Her er den første løsning, der kommer til at tænke på, selvfølgelig multithreading. Da den primære tid brugt på ping er at vente på at pakken skal returneres, og den næste ping ikke kan begynde før den forrige pakke er returneret, i virksomheder, der endda havde 20+ servere plus netværksudstyr, fungerede dette allerede ret langsomt. Pointen er, at én pakke kan forsvinde, men ikke med det samme underrette systemadministratoren om det. Han vil simpelthen stoppe med at acceptere sådan spam meget hurtigt. Det betyder, at du skal pinge hvert objekt mere end én gang, før du konkluderer om utilgængelighed. Uden at gå for meget i detaljer er det nødvendigt at parallelisere det, for hvis dette ikke gøres, vil systemadministratoren højst sandsynligt lære om problemet fra klienten og ikke fra overvågningssystemet.

PHP i sig selv understøtter ikke multithreading ud af boksen. I stand til multiprocessing, du kan gaffel. Men faktisk havde jeg allerede skrevet en afstemningsmekanisme, og jeg ville gøre det, så jeg en gang ville tælle alle de noder, jeg havde brug for fra databasen, ping alt på én gang, vente på et svar fra hver og først derefter skrive med det samme dataene. Dette sparer på antallet af læseanmodninger. Multithreading passer perfekt ind i denne idé. Til PHP er der et PThreads-modul, der giver dig mulighed for at lave rigtig multithreading, selvom det krævede en del fifleri at sætte dette op på PHP 7.2, men det blev gjort. Portscanning og ping er nu hurtig. Og i stedet for f.eks. 15 sekunder pr. omgang tidligere, begyndte denne proces at tage 2 sekunder. Det var et godt resultat.

Hurtig revision af nye virksomheder

Hvordan opstod funktionaliteten til at indsamle forskellige metrikker og hardwarekarakteristika? Det er simpelt. Nogle gange bliver vi simpelthen beordret til at revidere den nuværende it-infrastruktur. Nå, det samme er nødvendigt for at fremskynde revisionen af en ny klient. Vi havde brug for noget, der ville give os mulighed for at komme til en mellemstor eller stor virksomhed og hurtigt finde ud af, hvad de har. Efter min mening blokeres ping på det interne netværk kun af dem, der ønsker at komplicere deres eget liv, og efter vores erfaring er der få af dem. Men der er også sådanne mennesker. Derfor kan du hurtigt scanne netværk for tilstedeværelsen af enheder med et simpelt ping. Så kan vi tilføje dem og scanne for åbne porte, der interesserer os. Faktisk eksisterede denne funktionalitet allerede; det var kun nødvendigt at tilføje en kommando fra den centrale server til slaven, så den ville scanne de angivne netværk og tilføje alt, hvad den fandt til listen. Jeg glemte at nævne, det blev antaget, at vi allerede havde et færdigt billede med et konfigureret system (slaveovervågningsserver), som vi blot kunne rulle ud fra klienten under en audit og forbinde det til vores sky.

Men resultatet af en revision omfatter normalt en masse forskellige oplysninger, og en af dem er, hvilken slags enheder der er på netværket. Først og fremmest var vi interesserede i Windows-servere og Windows-arbejdsstationer som en del af et domæne. Da i mellemstore og store virksomheder er manglen på et domæne sandsynligvis en undtagelse fra reglen. For at tale ét sprog er gennemsnittet efter min mening 100+ personer. Det var nødvendigt at finde på en måde at indsamle data fra alle Windows-maskiner og -servere ved at kende deres IP- og domæneadministratorkonto, men uden at installere nogen software på hver af dem. WMI-grænsefladen kommer til undsætning. Windows Management Instrumentation (WMI) betyder bogstaveligt talt Windows-administrationsværktøjer. WMI er en af de grundlæggende teknologier til centraliseret styring og overvågning af driften af forskellige dele af computerinfrastrukturen, der kører Windows-platformen. Taget fra wiki. Dernæst måtte jeg pille igen for at kompilere wmic (dette er en WMI-klient) til Debian. Efter at alt var klar, var der blot tilbage at polle de nødvendige noder gennem wmic for at få den nødvendige information. Gennem WMI kan du få næsten alle informationer fra en Windows-computer, og desuden kan du også styre computeren igennem den, for eksempel sende den til genstart. Sådan så indsamlingen af oplysninger om Windows-stationer og servere i vores system ud. Ud over dette var der aktuel information om aktuelle systembelastningsindikatorer. Vi efterspørger dem oftere, og information om hardware sjældnere. Herefter blev auditeringen lidt sjovere.

Beslutning om softwaredistribution

Vi bruger selv systemet hver dag, og det er altid åbent for enhver teknisk medarbejder. Og vi tænkte, at vi kunne dele med andre, hvad vi allerede har. Systemet var endnu ikke klar til at blive distribueret. Meget skulle omarbejdes, for at den lokale version skulle blive til SaaS. Disse omfatter ændringer i forskellige tekniske aspekter af systemet (fjernforbindelser, supportservice), analyse af moduler til licensering, sønderdeling af kundedatabaser, skalering af hver service og udvikling af auto-opdateringssystemer til alle dele. Men dette bliver anden del af artiklen.

Opdatering

Anden del

Kilde: www.habr.com

Fra outsourcing til udvikling (del 1)