Fra outsourcing til utvikling (del 1)

Hei alle sammen, mitt navn er Sergey Emelyanchik. Jeg er leder for Audit-Telecom-selskapet, hovedutvikleren og forfatteren av Veliam-systemet. Jeg bestemte meg for å skrive en artikkel om hvordan vennen min og jeg opprettet et outsourcingselskap, skrev programvare for oss selv og begynte deretter å distribuere det til alle via SaaS-systemet. Om hvordan jeg kategorisk ikke trodde at dette var mulig. Artikkelen vil inneholde ikke bare en historie, men også tekniske detaljer om hvordan Veliam-produktet ble laget. Inkludert noen deler av kildekoden. Jeg skal fortelle deg hvilke feil vi gjorde og hvordan vi rettet dem senere. Det var tvil om å publisere en slik artikkel. Men jeg tenkte det var bedre å gjøre det, få tilbakemeldinger og forbedre, enn å ikke publisere artikkelen og tenke på hva som ville ha skjedd hvis...

forhistorie

Jeg jobbet i ett selskap som IT-medarbeider. Selskapet var ganske stort med en omfattende nettverksstruktur. Jeg vil ikke dvele ved jobbansvaret mitt, jeg vil bare si at de definitivt ikke inkluderte utviklingen av noe.

Vi hadde overvåking, men av rent akademisk interesse ville jeg prøve å skrive min egen enkleste. Tanken var denne: Jeg ville at den skulle være på nettet, slik at jeg enkelt kunne gå inn uten å installere noen klienter og se hva som skjedde med nettverket fra en hvilken som helst enhet, inkludert en mobil enhet via Wi-Fi, og jeg virkelig ønsket å raskt forstå hva Det er utstyr i rommet som har blitt "mopey" fordi... det var svært strenge krav til responstid på slike problemer. Som et resultat ble det født en plan i hodet mitt om å skrive en enkel nettside der det var en jpeg-bakgrunn med et nettverksdiagram, kutte ut selve enhetene med deres IP-adresser på dette bildet, og vise dynamisk innhold på toppen av bilde i de nødvendige koordinatene i form av en grønn eller blinkende rød IP-adresse. Oppgaven er satt, la oss komme i gang.

Tidligere programmerte jeg i Delphi, PHP, JS og veldig overfladisk C++. Jeg vet ganske godt hvordan nettverk fungerer. VLAN, Ruting (OSPF, EIGRP, BGP), NAT. Dette var nok til at jeg kunne skrive en primitiv overvåkingsprototype selv.

Jeg skrev det jeg planla i PHP. Apache- og PHP-serveren var på Windows fordi... Linux for meg i det øyeblikket var noe uforståelig og veldig komplekst, som det viste seg senere, tok jeg veldig feil og mange steder er Linux mye enklere enn Windows, men dette er et eget emne og vi vet alle hvor mange holivarer det er på dette emnet. Windows-oppgaveplanleggeren trakk med et lite intervall (jeg husker ikke nøyaktig, men noe sånt som en gang hvert tredje sekund) et PHP-skript som pollet alle objekter med en banal ping og lagret tilstanden til en fil.

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

Ja, ja, det å jobbe med en database på det tidspunktet var heller ikke mestret for meg. Jeg visste ikke at det var mulig å parallellisere prosesser, og det tok lang tid å gå gjennom alle nettverksnodene, fordi... dette skjedde i en tråd. Problemer oppsto spesielt når flere noder var utilgjengelige, pga hver av dem forsinket manuset med 300 ms. På klientsiden var det en enkel looping-funksjon som med noen sekunders mellomrom lastet ned oppdatert informasjon fra serveren med en Ajax-forespørsel og oppdaterte grensesnittet. Vel, da, etter 3 mislykkede ping på rad, hvis en nettside med overvåking var åpen på datamaskinen, spilte en munter komposisjon.

Da alt ordnet seg ble jeg veldig inspirert av resultatet og tenkte at jeg kunne tilføre det mer (på grunn av min kunnskap og evner). Men jeg har alltid ikke likt systemer med en million diagrammer, som jeg trodde den gang, og fortsatt tror den dag i dag, er unødvendig i de fleste tilfeller. Jeg ville bare legge inn det som virkelig ville hjelpe meg i arbeidet mitt. Dette prinsippet er fortsatt grunnleggende for utviklingen av Veliam til i dag. Videre innså jeg at det ville være veldig kult om jeg ikke måtte holde overvåking åpen og vite om problemer, og når det skjedde, åpne siden og se hvor denne problematiske nettverksnoden er og hva jeg skal gjøre med den neste . På en eller annen måte leste jeg ikke e-post den gang, jeg brukte den rett og slett ikke. Jeg kom over på Internett at det finnes SMS-gatewayer som du kan sende en GET eller POST-forespørsel til, og de vil sende en SMS til mobilen min med teksten som jeg skriver. Jeg skjønte umiddelbart at dette ville jeg virkelig. Og jeg begynte å studere dokumentasjonen. Etter en tid lyktes jeg, og nå fikk jeg en SMS om problemer på nettverket på mobiltelefonen min med navnet på en "falt gjenstand". Selv om systemet var primitivt, var det skrevet av meg selv, og det viktigste som motiverte meg til å utvikle det var at det var et applikasjonsprogram som virkelig hjalp meg i arbeidet mitt.

Og så kom dagen da en av internettkanalene gikk ned på jobb, og overvåkingen min ga meg ikke beskjed om det. Siden Google DNS fortsatt pinget perfekt. Det er på tide å tenke på hvordan du kan overvåke at kommunikasjonskanalen er i live. Det var forskjellige ideer om hvordan dette skulle gjøres. Jeg hadde ikke tilgang til alt utstyret. Vi måtte finne ut hvordan vi skulle forstå hvilken av kanalene som er live, men uten å kunne se det på en eller annen måte på selve nettverksutstyret. Så kom en kollega på ideen om at det er mulig at rutesporingen til offentlige servere kan variere avhengig av hvilken kommunikasjonskanal som for øyeblikket brukes for å få tilgang til Internett. Jeg sjekket og det ble sånn. Det var forskjellige ruter ved sporing.

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

Så et annet skript dukket opp, eller rettere sagt, av en eller annen grunn ble sporet lagt til på slutten av det samme skriptet, som pinget alle enheter på nettverket. Tross alt er dette nok en lang prosess som ble utført i samme tråd og bremset arbeidet med hele manuset. Men så var det ikke så åpenbart. Men på en eller annen måte gjorde han jobben sin, koden definerte strengt hva slags sporing skulle være for hver av kanalene. Dette er hvordan systemet begynte å fungere, som allerede overvåket (høyt sagt, fordi det ikke var noen samling av noen beregninger, men bare ping) nettverksenheter (rutere, brytere, wi-fi, etc.) og kommunikasjonskanaler med omverdenen . SMS-meldinger kom jevnlig og diagrammet viste alltid tydelig hvor problemet var.

Videre, i det daglige arbeidet måtte jeg krysse. Og jeg ble lei av å gå til Cisco-svitsjer hver gang for å se hvilket grensesnitt jeg skulle bruke. Hvor kult det ville være å klikke på et objekt i overvåking og se en liste over grensesnittene med beskrivelser. Det ville spare meg tid. Dessuten ville det i denne ordningen ikke være nødvendig å kjøre Putty eller SecureCRT for å legge inn kontoer og kommandoer. Jeg bare klikket på overvåkingen, så hva som var nødvendig og gikk for å gjøre jobben min. Jeg begynte å se etter måter å samhandle med brytere. Jeg kom umiddelbart over 2 alternativer: SNMP eller logge på bryteren via SSH, skrive inn kommandoene jeg trengte og analysere resultatet. Jeg avskjediget SNMP på grunn av kompleksiteten i implementeringen; jeg var utålmodig etter å få resultatet. med SNMP, ville du måtte grave i MIB i lang tid og, basert på disse dataene, generere data om grensesnittene. Det er et fantastisk team på CISCO

show interface status

Den viser akkurat hva jeg trenger for kryssinger. Hvorfor bry meg med SNMP når jeg bare vil se utdataene til denne kommandoen, tenkte jeg. Etter en tid innså jeg denne muligheten. Klikket på et objekt på en nettside. En hendelse ble utløst av at AJAX-klienten kontaktet serveren, og den koblet på sin side via SSH til bryteren jeg trengte (legitimasjonen ble hardkodet inn i koden, det var ikke noe ønske om å avgrense den, for å lage noen separate menyer der det ville være mulig å endre kontoer fra grensesnittet, jeg trengte resultatet og raskt) Jeg skrev inn kommandoen ovenfor der og sendte den tilbake til nettleseren. Så jeg begynte å se informasjon om grensesnitt med ett museklikk. Dette var ekstremt praktisk, spesielt når du måtte se denne informasjonen på forskjellige brytere samtidig.

Sporbasert kanalovervåking endte opp med å ikke være den beste ideen, fordi... noen ganger ble det utført arbeid på nettverket, og sporingen kunne endre seg og overvåkingen begynte å skrike til meg at det var problemer med kanalen. Men etter å ha brukt mye tid på analyser, innså jeg at alle kanaler fungerte, og overvåkingen min lurte meg. Som et resultat ba jeg kollegene mine som administrerte kanaldannende brytere om å sende meg syslog når synlighetsstatusen til naboer endret seg. Følgelig var det mye enklere, raskere og mer nøyaktig enn sporing. En hendelse som nabo tapt har kommet, og jeg gir umiddelbart en melding om kanalen nede.

Videre dukket det opp flere kommandoer når du klikket på et objekt, og SNMP ble lagt til for å samle noen beregninger, og det er i grunnen det. Systemet har aldri utviklet seg videre. Den gjorde alt jeg trengte, det var et godt verktøy. Mange lesere vil nok fortelle meg at det allerede finnes mye programvare på Internett for å løse disse problemene. Men faktisk googlet jeg ikke slike gratisprodukter den gang, og jeg ønsket virkelig å utvikle programmeringsferdighetene mine, og hvilken bedre måte å presse på for dette enn et ekte applikasjonsproblem. På dette tidspunktet ble den første versjonen av overvåking fullført og ble ikke lenger endret.

Opprettelse av Audit-Telecom-selskapet

Ettersom tiden gikk begynte jeg å jobbe deltid i andre bedrifter, heldigvis tillot arbeidsplanen meg å gjøre dette. Når du jobber i forskjellige selskaper, vokser ferdighetene dine på ulike områder veldig raskt, og horisonten din utvikler seg godt. Det er selskaper der du, som de sier, er en svenske, en reaper og en trompetist. På den ene siden er det vanskelig, på den andre siden, hvis du ikke er lat, blir du en generalist og dette lar deg løse problemer raskere og mer effektivt fordi du vet hvordan det relaterte feltet fungerer.

Min venn Pavel (også IT-spesialist) prøvde hele tiden å oppmuntre meg til å starte sin egen virksomhet. Det var utallige ideer med ulike varianter av hva de holdt på med. Dette har vært diskutert i årevis. Og til slutt burde det ikke ha blitt til noe fordi jeg er en skeptiker, og Pavel er en drømmer. Hver gang han foreslo en idé, trodde jeg alltid ikke på den og nektet å delta. Men vi ønsket virkelig å åpne vår egen virksomhet.

Til slutt klarte vi å finne et alternativ som passet oss begge og gjøre det vi vet hvordan vi skal gjøre. I 2016 bestemte vi oss for å opprette et IT-selskap som skulle hjelpe bedrifter med å løse IT-problemer. Dette er utrulling av IT-systemer (1C, terminalserver, mailserver, etc.), vedlikehold av dem, klassisk HelpDesk for brukere og nettverksadministrasjon.

Ærlig talt, da jeg opprettet selskapet, trodde jeg ikke på det omtrent 99,9%. Men Pavel klarte på en eller annen måte å få meg til å prøve, og så framover viste han seg å ha rett. Pavel og jeg chippet inn 300 000 rubler hver, registrerte en ny LLC "Audit-Telecom", leide et lite kontor, laget kule visittkort, vel, generelt, som sannsynligvis de fleste uerfarne, nybegynnere forretningsmenn, og begynte å lete etter kunder. Å finne kunder er en helt annen historie. Kanskje vi skriver en egen artikkel som en del av bedriftsbloggen hvis noen er interessert. Cold calls, flyers, etc. Dette ga ingen resultater. Som jeg nå leser fra mange historier om business, på en eller annen måte, avhenger mye av flaks. Vi var heldige. og bokstavelig talt et par uker etter etableringen av selskapet, henvendte broren min Vladimir seg til oss, som ga oss den første klienten. Jeg skal ikke kjede deg med detaljene om å jobbe med kunder, det er ikke det artikkelen handler om, jeg vil bare si at vi gikk til en revisjon, identifiserte kritiske områder og disse områdene brøt sammen mens beslutningen ble tatt om vi skulle samarbeide med oss ​​fortløpende som outsourcer. Etter dette ble det umiddelbart tatt en positiv beslutning.

Så, hovedsakelig gjennom jungeltelegrafen gjennom venner, begynte andre tjenesteselskaper å dukke opp. Helpdesk var i ett system. Tilkoblinger til nettverksutstyr og servere er forskjellige, eller snarere forskjellige. Noen lagret snarveier, andre brukte RDP-adressebøker. Overvåking er et annet eget system. Det er veldig upraktisk for et team å jobbe i ulike systemer. Viktig informasjon er tapt av syne. Vel, for eksempel ble klientens terminalserver utilgjengelig. Søknader fra brukere av denne klienten mottas umiddelbart. Støttespesialisten åpner en forespørsel (den ble mottatt på telefon). Hvis hendelser og forespørsler ble registrert i ett system, ville støttespesialisten umiddelbart se hva brukerens problem er og fortelle ham om det, samtidig som han koblet til det nødvendige objektet for å løse situasjonen. Alle er klar over den taktiske situasjonen og jobber harmonisk. Vi har ikke funnet et system hvor alt dette er kombinert. Det ble klart at det var på tide å lage vårt eget produkt.

Fortsatt arbeid med overvåkingssystemet ditt

Det var tydelig at systemet som ble skrevet tidligere var helt uegnet for dagens oppgaver. Verken med tanke på funksjonalitet eller kvalitet. Og det ble besluttet å skrive systemet fra bunnen av. Grafisk burde det sett helt annerledes ut. Det måtte være et hierarkisk system slik at det skulle være mulig å raskt og enkelt åpne rett objekt for rett klient. Ordningen som i første versjon var absolutt ikke berettiget i den aktuelle saken, pga Kundene er forskjellige og det spilte ingen rolle i hvilke lokaler utstyret var plassert. Dette er allerede overført til dokumentasjonen.

Så, oppgavene:

1. Hierarkisk struktur;
2. En slags serverdel som kan plasseres på klientens premisser i form av en virtuell maskin for å samle inn beregningene vi trenger og sende den til den sentrale serveren, som vil oppsummere alt dette og vise det til oss;
3. Varsler. De som ikke kan gå glipp av, fordi... på den tiden var det ikke mulig for noen å sitte og bare se på skjermen;
4. Søknadssystem. Det begynte å dukke opp klienter som vi betjente ikke bare server- og nettverksutstyr for, men også arbeidsstasjoner;
5. Evne til raskt å koble til servere og utstyr fra systemet;

Oppgavene er satt, begynner vi å skrive. Underveis behandler forespørsler fra kunder. På den tiden var vi allerede 4. Vi begynte å skrive begge deler på en gang: den sentrale serveren og serveren for installasjon til klienter. På dette tidspunktet var Linux ikke lenger fremmed for oss, og det ble bestemt at de virtuelle maskinene som klienter ville ha skulle være på Debian. Det vil ikke være noen installatører, vi lager bare et serverdelprosjekt på en spesifikk virtuell maskin, og så kloner vi den til ønsket klient. Dette var nok en feil. Senere ble det klart at i en slik ordning var oppdateringsmekanismen fullstendig uutviklet. De. vi la til en ny funksjon, og så var det hele problemet med å distribuere det til alle klientservere, men vi kommer tilbake til dette senere, alt i orden.

Vi laget den første prototypen. Han var i stand til å pinge klientnettverksenhetene og serverne vi trengte og sende disse dataene til vår sentrale server. Og han oppdaterte på sin side disse dataene i bulk på den sentrale serveren. Her vil jeg ikke bare skrive en historie om hvordan og hva som var vellykket, men også hvilke amatørfeil som ble gjort og hvordan jeg senere måtte betale for det med tiden. Så hele treet av objekter ble lagret i en enkelt fil i form av et serialisert objekt. Mens vi koblet flere klienter til systemet, var alt mer eller mindre normalt, selv om det noen ganger var noen artefakter som var helt uforståelige. Men da vi koblet et dusin servere til systemet, begynte mirakler å skje. Noen ganger, av en eller annen ukjent grunn, forsvant alle objekter i systemet rett og slett. Det er viktig å merke seg her at serverne som klientene hadde sendte data til den sentrale serveren med noen sekunders mellomrom via en POST-forespørsel. En oppmerksom leser og en erfaren programmerer har allerede gjettet at det var et problem med flere tilganger til selve filen der det serialiserte objektet ble lagret fra forskjellige tråder samtidig. Og akkurat da dette skjedde, skjedde mirakler med forsvinningen av gjenstander. Filen ble rett og slett tom. Men alt dette ble ikke oppdaget umiddelbart, men bare under drift med flere servere. I løpet av denne tiden ble portskanningsfunksjonalitet lagt til (serverne som ble sendt til sentralen, ikke bare informasjon om tilgjengeligheten til enheter, men også om portene som er åpne på dem). Dette ble gjort ved å ringe kommandoen:

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

resultatene var ofte feil og skanninger tok lang tid å fullføre. Jeg glemte helt ping, det ble gjort via fping:

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

Dette var heller ikke parallellisert og derfor var prosessen veldig lang. Senere ble hele listen over IP-adresser som kreves for verifisering sendt til fping på en gang, og tilbake fikk vi en ferdig liste over de som svarte. I motsetning til oss, var fping i stand til å parallellisere prosesser.

En annen vanlig rutinejobb var å sette opp noen tjenester via WEB. Vel, for eksempel ECP fra MS Exchange. I utgangspunktet er det bare en lenke. Og vi bestemte at vi må kunne legge til slike lenker direkte til systemet, for ikke å måtte lete i dokumentasjonen eller andre steder i bokmerker for å få tilgang til ECP til en spesifikk klient. Dette er hvordan konseptet med ressurskoblinger for systemet dukket opp, funksjonaliteten deres er tilgjengelig til i dag og har ikke endret seg, vel, nesten.

Hvordan ressurskoblinger fungerer i Veliam

Eksterne tilkoblinger

Slik ser det ut i aksjon i den nåværende versjonen av Veliam

En av oppgavene var å raskt og enkelt koble til servere, som det allerede var mange av (mer enn hundre), og å sortere gjennom millioner av forhåndslagrede RDP-snarveier var ekstremt upraktisk. Et verktøy var nødvendig. Det finnes programvare på Internett som er noe som en adressebok for slike RDP-forbindelser, men de er ikke integrert med overvåkingssystemet, og kontoer kan ikke lagres. Å legge inn kontoer for forskjellige klienter hver gang er et rent helvete når du kobler dusinvis av ganger om dagen til forskjellige servere. Med SSH er ting litt bedre; det er mye god programvare som lar deg organisere slike koblinger i mapper og huske kontoene fra dem. Men det er 2 problemer. Den første er at vi ikke fant et eneste program for RDP- og SSH-forbindelser. Det andre er at hvis jeg på et tidspunkt ikke er ved datamaskinen min og må koble til raskt, eller jeg bare har installert systemet på nytt, må jeg gå inn i dokumentasjonen for å se på kontoen fra denne klienten. Det er upraktisk og bortkastet tid.

Den hierarkiske strukturen vi trengte for klientservere var allerede tilgjengelig i vårt interne produkt. Jeg måtte bare finne ut hvordan jeg skulle feste hurtigkoblinger til nødvendig utstyr der. For det første, i det minste innenfor nettverket ditt.

Tatt i betraktning at klienten i systemet vårt var en nettleser som ikke har tilgang til de lokale ressursene til datamaskinen, for ganske enkelt å starte applikasjonen vi trengte med en kommando, ble den oppfunnet for å gjøre alt gjennom "Windows tilpasset url-skjema". Dette er hvordan en viss "plugin" dukket opp for systemet vårt, som ganske enkelt inkluderte Putty og Remote Desktop Plus og, under installasjonen, ganske enkelt registrerte URI-skjemaet i Windows. Nå, når vi ønsket å koble til et objekt via RDP eller SSH, klikket vi denne handlingen på systemet vårt og den tilpassede URIen fungerte. Standard mstsc.exe innebygd i Windows eller kitt, som var en del av "plugin", ble lansert. Jeg setter ordet plugin i anførselstegn fordi dette ikke er en nettleserplugin i klassisk forstand.

Det var i hvert fall noe. Praktisk adressebok. Dessuten, i tilfellet med Putty, var alt generelt bra; det kunne gis IP-tilkoblinger, pålogging og passord som inngangsparametere. De. Vi har allerede koblet til Linux-servere på nettverket vårt med ett klikk uten å angi passord. Men med RDP er det ikke så enkelt. Standard mstsc kan ikke oppgi legitimasjon som parametere. Remote Desktop Plus kom til unnsetning. Han lot dette skje. Nå kan vi klare oss uten, men lenge var det en trofast assistent i systemet vårt. Med HTTP(S)-sider er alt enkelt, slike objekter åpnes ganske enkelt i nettleseren og det er det. Praktisk og praktisk. Men dette var lykke bare på det interne nettverket.

Siden vi løste de aller fleste problemene eksternt fra kontoret, var det enkleste å gjøre VPN-er tilgjengelige for klienter. Og så var det mulig å koble til dem fra systemet vårt. Men det var fortsatt noe upraktisk. For hver klient var det nødvendig å ha en haug med huskede VPN-tilkoblinger på hver datamaskin, og før du koblet til noen, var det nødvendig å aktivere den tilsvarende VPN-en. Vi brukte denne løsningen ganske lenge. Men antallet klienter øker, antallet VPN-er øker også, og alt dette begynte å bli anstrengt og noe måtte gjøres med det. Tårene kom spesielt i øynene etter å ha installert systemet på nytt, da jeg måtte legge inn dusinvis av VPN-tilkoblinger på nytt i en ny Windows-profil. Slutt å tåle dette, sa jeg og begynte å tenke på hva jeg kunne gjøre med det.

Det hadde seg slik at alle klienter hadde enheter fra det kjente selskapet Mikrotik som rutere. De er svært funksjonelle og praktiske for å utføre nesten alle oppgaver. Ulempen er at de er "kapret". Vi løste dette problemet ganske enkelt ved å stenge all tilgang fra utsiden. Men det var nødvendig å på en eller annen måte ha tilgang til dem uten å komme til klientens sted, fordi... den er lang. Vi lagde ganske enkelt tunneler for hver slik Mikrotik og skilte dem i et eget basseng. uten ruting, slik at det ikke er noen forbindelse mellom nettverket ditt og nettverkene til klienter og deres nettverk med hverandre.

Ideen ble født for å sørge for at når jeg klikker på objektet jeg trenger i systemet, kobler den sentrale overvåkingsserveren, som kjenner SSH-kontoene til alle klient Mikrotik, til den ønskede, oppretter en videresendingsregel til ønsket vert med nødvendig port. Det er flere punkter her. Løsningen er ikke universell - den vil bare fungere for Mikrotik, siden kommandosyntaksen er forskjellig for alle rutere. Dessuten måtte slike videresendinger på en eller annen måte slettes, og serverdelen av systemet vårt kunne i hovedsak ikke spore på noen måte om jeg hadde fullført RDP-økten min. Vel, slik videresending er et hull for klienten. Men vi forfulgte ikke universalitet, fordi... produktet ble kun brukt i vårt selskap, og det var ingen tanker om å gi det ut til offentligheten.

Hvert av problemene ble løst på sin egen måte. Da regelen ble opprettet, var denne videresendingen kun tilgjengelig for én spesifikk ekstern IP-adresse (hvorfra tilkoblingen ble initialisert). Så et sikkerhetshull ble unngått. Men med hver slik tilkobling ble en Mikrotik-regel lagt til NAT-siden og ble ikke slettet. Og alle vet at jo flere regler det er, jo mer lastes ruterens prosessor. Og generelt sett kunne jeg ikke akseptere at jeg en dag ville gå til noe Mikrotik, og det ville være hundrevis av døde, ubrukelige regler.

Siden vår server ikke kan spore tilkoblingsstatusen, la Mikrotik spore dem selv. Og jeg skrev et script som hele tiden overvåket alle videresendingsregler med en spesifikk beskrivelse og sjekket om TCP-tilkoblingen hadde en passende regel. Hvis det ikke har vært en på en stund, er tilkoblingen sannsynligvis allerede fullført og denne videresendingen kan slettes. Alt ordnet seg, manuset fungerte bra.

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 vært gjort vakrere, raskere osv., men det fungerte, lastet ikke Mikrotik og gjorde en utmerket jobb. Vi var endelig i stand til å koble til klientenes servere og nettverksutstyr med bare ett klikk. Uten å åpne en VPN eller skrive inn passord. Systemet har blitt veldig praktisk å jobbe med. Servicetiden ble redusert, og vi brukte alle tid på å jobbe i stedet for å koble oss til de nødvendige objektene.

Mikrotik Backup

Vi konfigurerte sikkerhetskopiering av alle Mikrotik til FTP. Og totalt sett var alt bra. Men når du trengte å få en sikkerhetskopi, måtte du åpne denne FTP-en og se etter den der. Vi har et system der alle ruterne er tilkoblet, vi kan kommunisere med enheter via SSH. Hvorfor gjør vi det ikke slik at selve systemet tar sikkerhetskopier fra alle Mikrotik daglig, tenkte jeg. Og han begynte å implementere det. Vi koblet til, laget en sikkerhetskopi og tok den til lagring.

Skriptkode i PHP for å ta sikkerhetskopi 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');

?>

Sikkerhetskopien er tatt i to former - binær og tekstkonfigurasjon. Binæren hjelper til med å raskt gjenopprette den nødvendige konfigurasjonen, og teksten en lar deg forstå hva som må gjøres hvis det er en tvungen utskifting av utstyr og binæren ikke kan lastes opp til den. Som et resultat fikk vi en annen praktisk funksjonalitet i systemet. Dessuten, når du la til ny Mikrotik, var det ikke nødvendig å konfigurere noe; jeg la bare objektet til systemet og satte en konto for det via SSH. Da tok systemet selv seg av å ta sikkerhetskopier. Den nåværende versjonen av SaaS Veliam har ennå ikke denne funksjonaliteten, men vi vil portere den snart.

Skjermbilder av hvordan det så ut i det interne systemet

Overgang til vanlig databaselagring

Jeg skrev allerede ovenfor at det dukket opp gjenstander. Noen ganger forsvant hele listen over objekter i systemet, noen ganger ved redigering av et objekt ble ikke informasjonen lagret og objektet måtte gis nytt navn tre ganger. Dette irriterte alle fryktelig. Forsvinningen av objekter skjedde sjelden, og ble enkelt gjenopprettet ved å gjenopprette denne filen, men feil ved redigering av objekter skjedde ganske ofte. Sannsynligvis gjorde jeg i utgangspunktet ikke dette gjennom databasen fordi det ikke passet inn i tankene mine hvordan det var mulig å holde et tre med alle tilkoblingene i en flat tabell. Det er flatt, men treet er hierarkisk. Men en god løsning for flertilgang, og deretter (etter hvert som systemet blir mer komplekst) transaksjonelle, er et DBMS. Jeg er nok ikke den første som møter dette problemet. Jeg begynte å google. Det viste seg at alt allerede var oppfunnet før meg, og det er flere algoritmer som bygger et tre fra et flatt bord. Etter å ha sett på hver enkelt, implementerte jeg en av dem. Men dette var allerede en ny versjon av systemet, fordi... På grunn av dette måtte jeg faktisk skrive om ganske mye. Resultatet var naturlig, problemene med tilfeldig oppførsel av systemet forsvant. Noen vil kanskje si at feilene er veldig amatørmessige (entrådede skript, lagring av informasjon som ble åpnet flere ganger samtidig fra forskjellige tråder i en fil, etc.) innen programvareutvikling. Kanskje dette er sant, men hovedjobben min var administrasjon, og programmering var et mas for sjelen min, og jeg hadde rett og slett ikke erfaring med å jobbe i et team med programmerere, hvor slike grunnleggende ting umiddelbart ville blitt foreslått for meg av min senior kamerater. Derfor fylte jeg alle disse ujevnhetene på egenhånd, men jeg lærte stoffet veldig godt. Og også, jobben min innebærer møter med kunder, handlinger rettet mot å prøve å promotere selskapet, en haug med administrative spørsmål i selskapet, og mye, mye mer. Men på en eller annen måte var det etterspurt det som allerede var der. Gutta og jeg brukte selv produktet i vårt daglige arbeid. Det var ærlig talt mislykkede ideer og løsninger som tid ble kastet bort på, men til slutt ble det klart at dette ikke var et fungerende verktøy og ingen brukte det og det endte ikke opp i Veliam.

Helpdesk - HelpDesk

Det ville ikke være galt å nevne hvordan HelpDesk ble dannet. Dette er en helt annen historie, fordi... i Veliam er dette allerede den tredje helt nye versjonen, som er forskjellig fra alle tidligere. Nå er det et enkelt system, intuitivt uten unødvendige bjeller og plystre, med muligheten til å integrere med et domene, samt muligheten til å få tilgang til samme brukerprofil fra hvor som helst ved hjelp av en lenke fra en e-post. Og viktigst av alt, det er mulig å koble til søkeren via VNC fra hvor som helst (hjemme eller på kontoret) direkte fra applikasjonen uten VPN eller portvideresending. Jeg skal fortelle deg hvordan vi kom til dette, hva som skjedde før og hvilke forferdelige avgjørelser som ble tatt.

Vi koblet til brukere gjennom den velkjente TeamViewer. Alle datamaskiner med brukere vi betjener har TV installert. Det første vi gjorde feil, og deretter fjernet det, var å koble hver HD-klient til maskinvare. Hvordan logget brukeren på HD-systemet for å legge igjen en forespørsel? I tillegg til TV hadde alle et spesielt verktøy installert på datamaskinene sine, skrevet i Lazarus (mange mennesker her vil himle med øynene, og kanskje til og med gå på Google hva det er, men det beste kompilerte språket jeg visste var Delphi, og Lazarus er nesten det samme, bare gratis). Generelt lanserte brukeren en spesiell batchfil som lanserte dette verktøyet, som igjen leste systemets HWID og etter det ble nettleseren startet og autorisasjon skjedde. Hvorfor ble dette gjort? I enkelte bedrifter telles antall betjente brukere individuelt, og tjenesteprisen for hver måned er basert på antall personer. Dette er forståelig, sier du, men hvorfor er det knyttet til maskinvare? Det er veldig enkelt, noen enkeltpersoner kom hjem og kom med en forespørsel fra den bærbare hjemmemaskinen sin i stilen med "lag alt vakkert for meg her." I tillegg til å lese systemets HWID, trakk verktøyet den gjeldende Teamviewer-IDen fra registeret og sendte den også til oss. Teamviewer har et API for integrasjon. Og vi gjorde denne integrasjonen. Men det var en hake. Gjennom disse API-ene er det umulig å koble til brukerens datamaskin når han ikke eksplisitt starter denne økten, og etter å ha prøvd å koble til den, må han også klikke på "bekreft". På det tidspunktet virket det logisk for oss at ingen skulle koble til uten brukerens forespørsel, og siden personen er ved datamaskinen, vil han starte økten og svare bekreftende på forespørselen om ekstern tilkobling. Alt ble feil. Søkere glemte å trykke på initier økten, og måtte fortelle dem dette i en telefonsamtale. Dette kastet bort tid og var frustrerende på begge sider av prosessen. Dessuten er det slett ikke uvanlig for slike øyeblikk når en person legger igjen en forespørsel, men får bare koble seg når han drar til lunsj. Fordi problemet ikke er kritisk og han vil ikke at arbeidsprosessen hans skal avbrytes. Følgelig vil han ikke trykke på noen knapper for å tillate tilkobling. Slik dukket tilleggsfunksjonalitet opp ved innlogging på HelpDesk - lesing av Teamviewers ID. Vi kjente det permanente passordet som ble brukt ved installasjon av Teamviewer. Mer presist var det bare systemet som visste det, siden det var innebygd i installatøren og i systemet vårt. Følgelig var det en tilkoblingsknapp fra applikasjonen ved å klikke på som det ikke var nødvendig å vente på noe, men Teamviewer åpnet umiddelbart og en tilkobling oppstod. Som et resultat var det to typer mulige forbindelser. Gjennom den offisielle Teamviewer API og vår selvlagde. Til min overraskelse sluttet de å bruke den første nesten umiddelbart, selv om det var en instruks om å bruke den kun i spesielle tilfeller og når brukeren selv gir klarsignal. Likevel, gi meg trygghet nå. Men det viste seg at søkerne ikke trengte dette. De er alle helt fine med å være koblet til dem uten en bekreftelsesknapp.

Bytter til multithreading i Linux

Spørsmålet om å fremskynde passasjen av en nettverksskanner for åpenheten til en forhåndsbestemt liste over porter og enkel pinging av nettverksobjekter har lenge begynt å dukke opp. Her er selvfølgelig den første løsningen som dukker opp, multithreading. Siden hovedtiden brukt på ping er å vente på at pakken skal returneres, og neste ping ikke kan begynne før den forrige pakken er returnert, i selskaper som til og med hadde 20+ servere pluss nettverksutstyr, fungerte dette allerede ganske sakte. Poenget er at én pakke kan forsvinne, men ikke umiddelbart gi systemadministrator beskjed om det. Han vil ganske enkelt slutte å godta slik spam veldig raskt. Dette betyr at du må pinge hvert objekt mer enn én gang før du konkluderer om utilgjengelighet. Uten å gå i for mye detaljer, er det nødvendig å parallellisere det, fordi hvis dette ikke gjøres, vil systemadministratoren mest sannsynlig lære om problemet fra klienten, og ikke fra overvåkingssystemet.

PHP i seg selv støtter ikke multithreading ut av esken. I stand til multiprosessering, kan du gaffel. Men faktisk hadde jeg allerede skrevet en avstemningsmekanisme, og jeg ønsket å gjøre det slik at jeg en gang skulle telle alle nodene jeg trengte fra databasen, pinge alt på en gang, vente på svar fra hver og først etter det umiddelbart skrive dataen. Dette sparer på antall leseforespørsler. Multithreading passet perfekt inn i denne ideen. For PHP er det en PThreads-modul som lar deg gjøre ekte multithreading, selv om det tok en del triksing for å sette opp dette på PHP 7.2, men det ble gjort. Portskanning og ping er nå rask. Og i stedet for for eksempel 15 sekunder per runde tidligere, begynte denne prosessen å ta 2 sekunder. Det ble et godt resultat.

Rask revisjon av nye selskaper

Hvordan oppsto funksjonaliteten for å samle ulike beregninger og maskinvareegenskaper? Det er enkelt. Noen ganger blir vi rett og slett beordret til å revidere dagens IT-infrastruktur. Vel, det samme er nødvendig for å fremskynde revisjonen av en ny klient. Vi trengte noe som ville tillate oss å komme til et mellomstort eller stort selskap og raskt finne ut hva de har. Etter min mening blokkeres ping på det interne nettverket bare av de som ønsker å komplisere sine egne liv, og etter vår erfaring er det få av dem. Men det finnes også slike mennesker. Følgelig kan du raskt skanne nettverk for tilstedeværelse av enheter med en enkel ping. Så kan vi legge dem til og skanne etter åpne porter som interesserer oss. Faktisk eksisterte denne funksjonaliteten allerede; det var bare nødvendig å legge til en kommando fra den sentrale serveren til slaven slik at den ville skanne de spesifiserte nettverkene og legge til alt den fant til listen. Jeg glemte å nevne, det ble antatt at vi allerede hadde et ferdig bilde med et konfigurert system (slaveovervåkingsserver) som vi ganske enkelt kunne rulle ut fra klienten under en revisjon og koble det til skyen vår.

Men resultatet av en revisjon inkluderer vanligvis en haug med forskjellig informasjon, og en av dem er hva slags enheter som er på nettverket. Først av alt var vi interessert i Windows-servere og Windows-arbeidsstasjoner som en del av et domene. Siden i mellomstore og store selskaper er mangelen på et domene sannsynligvis et unntak fra regelen. For å snakke ett språk er gjennomsnittet, etter min mening, 100+ personer. Det var nødvendig å komme opp med en måte å samle inn data fra alle Windows-maskiner og -servere, kjenne til deres IP- og domeneadministratorkonto, men uten å installere noen programvare på hver av dem. WMI-grensesnittet kommer til unnsetning. Windows Management Instrumentation (WMI) betyr bokstavelig talt Windows-administrasjonsverktøy. WMI er en av de grunnleggende teknologiene for sentralisert styring og overvåking av driften av ulike deler av datamaskininfrastrukturen som kjører Windows-plattformen. Hentet fra wiki. Deretter måtte jeg tukle igjen for å kompilere wmic (dette er en WMI-klient) for Debian. Etter at alt var klart, gjensto det bare å spørre de nødvendige nodene gjennom wmic for nødvendig informasjon. Gjennom WMI kan du få nesten all informasjon fra en Windows-datamaskin, og dessuten kan du også kontrollere datamaskinen gjennom den, for eksempel sende den til omstart. Slik så innsamlingen av informasjon om Windows-stasjoner og servere i systemet vårt ut. I tillegg til dette var det aktuell informasjon om gjeldende systembelastningsindikatorer. Vi ber om dem oftere, og informasjon om maskinvare sjeldnere. Etter dette ble revisjonen litt morsommere.

Beslutning om programvaredistribusjon

Selv bruker vi systemet hver dag, og det er alltid åpent for hver teknisk medarbeider. Og vi tenkte at vi kunne dele med andre det vi allerede har. Systemet var ennå ikke klart til å distribueres. Mye måtte omarbeides for at den lokale versjonen skulle bli til SaaS. Disse inkluderer endringer i ulike tekniske aspekter ved systemet (fjerntilkoblinger, støttetjeneste), analyse av moduler for lisensiering, sønderdeling av kundedatabaser, skalering av hver tjeneste, og utvikling av autooppdateringssystemer for alle deler. Men dette blir den andre delen av artikkelen.

Oppdater

Den andre delen

Kilde: www.habr.com