Van outsourcing naar ontwikkeling (deel 1)

Hallo allemaal, mijn naam is Sergey Emelyanchik. Ik ben het hoofd van het bedrijf Audit-Telecom, de belangrijkste ontwikkelaar en auteur van het Veliam-systeem. Ik besloot een artikel te schrijven over hoe mijn vriend en ik een outsourcingbedrijf hebben opgericht, software voor onszelf hebben geschreven en deze vervolgens via het SaaS-systeem naar iedereen zijn gaan distribueren. Over hoe ik categorisch niet geloofde dat dit mogelijk was. Het artikel bevat niet alleen een verhaal, maar ook technische details over hoe het Veliam-product is gemaakt. Inclusief enkele stukjes broncode. Ik zal je later vertellen welke fouten we hebben gemaakt en hoe we deze hebben gecorrigeerd. Er waren twijfels of een dergelijk artikel zou worden gepubliceerd. Maar ik dacht dat het beter was om het te doen, feedback te krijgen en te verbeteren, dan het artikel niet te publiceren en na te denken over wat er zou zijn gebeurd als...

prehistorie

Ik heb bij een bedrijf gewerkt als IT-medewerker. Het bedrijf was vrij groot met een uitgebreide netwerkstructuur. Ik zal niet stilstaan ​​bij mijn functieverantwoordelijkheden, ik zal alleen zeggen dat ze absoluut niet de ontwikkeling van wat dan ook omvatten.

We hadden monitoring, maar puur uit academische interesse wilde ik proberen mijn eigen eenvoudigste te schrijven. Het idee was dit: ik wilde dat het op internet stond, zodat ik gemakkelijk naar binnen kon gaan zonder clients te installeren en vanaf elk apparaat kon zien wat er met het netwerk gebeurde, inclusief een mobiel apparaat via Wi-Fi. wilde snel begrijpen wat er apparatuur in de kamer is die "mop" is geworden omdat... er waren zeer strenge eisen aan de responstijd bij dergelijke problemen. Het resultaat was dat er in mijn hoofd een plan ontstond om een ​​eenvoudige webpagina te schrijven met een jpeg-achtergrond met een netwerkdiagram, de apparaten zelf met hun IP-adressen in deze afbeelding uit te knippen en dynamische inhoud bovenop de afbeelding in de vereiste coördinaten in de vorm van een groen of knipperend rood IP-adres. De taak is ingesteld, laten we aan de slag gaan.

Voorheen programmeerde ik in Delphi, PHP, JS en heel oppervlakkig C++. Ik weet heel goed hoe netwerken werken. VLAN, routering (OSPF, EIGRP, BGP), NAT. Dit was voor mij genoeg om zelf een primitief monitoring-prototype te schrijven.

Ik schreef wat ik van plan was in PHP. De Apache- en PHP-server stond op Windows omdat... Linux was voor mij op dat moment iets onbegrijpelijks en heel complex, zoals later bleek, ik vergiste me erg en op veel plaatsen is Linux veel eenvoudiger dan Windows, maar dit is een apart onderwerp en we weten allemaal hoeveel holivars er zijn dit onderwerp. De Windows-taakplanner haalde met een klein interval (ik weet het niet precies meer, maar ongeveer eens in de drie seconden) een PHP-script op dat alle objecten met een banale ping ondervroeg en de status in een bestand opsloeg.

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

Ja, ja, het werken met een database was voor mij op dat moment ook nog niet onder de knie. Ik wist niet dat het mogelijk was om processen te parallelliseren, en het doorlopen van alle netwerkknooppunten kostte veel tijd, omdat... dit gebeurde in één draadje. Er ontstonden vooral problemen als meerdere knooppunten niet beschikbaar waren, omdat elk van hen vertraagde het script met 300 ms. Aan de clientzijde was er een eenvoudige lusfunctie die met tussenpozen van een paar seconden bijgewerkte informatie van de server downloadde met een Ajax-verzoek en de interface bijwerkte. Nou, dan, na 3 mislukte pings op rij, als een webpagina met monitoring op de computer geopend was, werd er een vrolijke compositie gespeeld.

Toen alles lukte, was ik erg geïnspireerd door het resultaat en dacht ik er (vanwege mijn kennis en capaciteiten) nog meer aan toe te kunnen voegen. Maar ik heb altijd een hekel gehad aan systemen met een miljoen kaarten, waarvan ik toen dacht, en nog steeds denk, dat ze in de meeste gevallen niet nodig zijn. Ik wilde er alleen in stoppen wat mij echt zou helpen bij mijn werk. Dit principe blijft tot op de dag van vandaag fundamenteel voor de ontwikkeling van Veliam. Verder realiseerde ik me dat het heel gaaf zou zijn als ik niet open hoefde te blijven monitoren en op de hoogte hoefde te zijn van problemen, en als het gebeurde, dan de pagina zou openen en zou zien waar dit problematische netwerkknooppunt zich bevindt en wat ik er vervolgens mee moet doen . Op de een of andere manier las ik destijds geen e-mail, ik gebruikte het gewoon niet. Ik kwam op internet tegen dat er sms-gateways zijn waarnaar je een GET- of POST-verzoek kunt sturen, en zij sturen een sms naar mijn mobiele telefoon met de tekst die ik schrijf. Ik besefte meteen dat ik dit echt wilde. En ik begon de documentatie te bestuderen. Na enige tijd lukte het, en nu ontving ik op mijn mobiele telefoon een sms over problemen op het netwerk met de naam van een “gevallen voorwerp”. Hoewel het systeem primitief was, werd het door mij zelf geschreven, en het belangrijkste dat mij motiveerde om het te ontwikkelen was dat het een toepassingsprogramma was dat mij echt hielp bij mijn werk.

En toen kwam de dag dat een van de internetkanalen op het werk uitviel, en mijn monitoring liet me daar niets van weten. Omdat Google DNS nog steeds perfect pingde. Het is tijd om na te denken over hoe u kunt controleren of het communicatiekanaal leeft. Er waren verschillende ideeën over hoe dit te doen. Ik had geen toegang tot alle apparatuur. We moesten uitzoeken hoe we konden begrijpen welke van de kanalen live was, maar zonder dat we het op de een of andere manier op de netwerkapparatuur zelf konden bekijken. Toen kwam een ​​collega op het idee dat het mogelijk is dat de routetracering naar openbare servers kan verschillen, afhankelijk van welk communicatiekanaal momenteel wordt gebruikt om toegang te krijgen tot internet. Ik heb het gecontroleerd en het bleek zo te zijn. Bij het traceren waren er verschillende routes.

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

Er verscheen dus een ander script, of beter gezegd, om de een of andere reden werd de trace toegevoegd aan het einde van hetzelfde script, dat alle apparaten op het netwerk pingde. Dit is tenslotte weer een lang proces dat in dezelfde thread werd uitgevoerd en het werk van het hele script vertraagde. Maar toen was het nog niet zo vanzelfsprekend. Maar op de een of andere manier deed hij zijn werk: de code definieerde strikt wat voor soort tracering voor elk van de kanalen zou moeten zijn. Dit is hoe het systeem begon te werken, dat al toezicht hield (luid gezegd, omdat er geen verzameling van statistieken was, maar alleen ping) netwerkapparaten (routers, switches, wifi, enz.) en communicatiekanalen met de buitenwereld . Er kwamen regelmatig sms-berichten binnen en in het schema was altijd duidelijk te zien waar het probleem zat.

Verder moest ik in het dagelijkse werk cross-crossing doen. En ik werd het beu om elke keer naar Cisco-switches te gaan om te zien welke interface ik moest gebruiken. Hoe cool zou het zijn om op een object in monitoring te klikken en een lijst met interfaces met beschrijvingen te zien. Het zou mij tijd besparen. Bovendien zou het in dit schema niet nodig zijn om Putty of SecureCRT uit te voeren om accounts en opdrachten in te voeren. Ik klikte gewoon op de monitoring, zag wat er nodig was en ging aan de slag. Ik begon te zoeken naar manieren om met schakelaars te communiceren. Ik kwam meteen 2 opties tegen: SNMP of inloggen op de switch via SSH, de commando's invoeren die ik nodig had en het resultaat parseren. Ik heb SNMP afgewezen vanwege de complexiteit van de implementatie ervan; ik was ongeduldig om het resultaat te krijgen. bij SNMP zou je lang in de MIB moeten graven en op basis van deze gegevens gegevens over de interfaces moeten genereren. Er is een geweldig team bij CISCO

show interface status

Het laat precies zien wat ik nodig heb voor kruisingen. Waarom zou ik me druk maken over SNMP als ik alleen maar de uitvoer van dit commando wil zien, dacht ik. Na enige tijd besefte ik deze kans. Er is op een object op een webpagina geklikt. Er werd een gebeurtenis geactiveerd waardoor de AJAX-client contact opnam met de server, en deze maakte op zijn beurt via SSH verbinding met de switch die ik nodig had (de inloggegevens waren hardgecodeerd in de code, er was geen wens om deze te verfijnen, om een ​​aantal aparte menu's te maken waar het zou mogelijk zijn om accounts te veranderen vanuit de interface, ik had het resultaat nodig en snel) Ik voerde daar de bovenstaande opdracht in en stuurde het terug naar de browser. Dus begon ik met één muisklik informatie over interfaces te zien. Dit was erg handig, vooral als je deze informatie op verschillende schakelaars tegelijk moest bekijken.

Op tracering gebaseerde kanaalmonitoring bleek uiteindelijk niet het beste idee, omdat... soms werd er aan het netwerk gewerkt en kon de tracering veranderen en begon de monitoring tegen me te schreeuwen dat er problemen waren met het kanaal. Maar nadat ik veel tijd aan analyse had besteed, realiseerde ik me dat alle kanalen werkten en dat mijn monitoring me bedroog. Als gevolg hiervan vroeg ik mijn collega's die kanaalvormende schakelaars beheerden om mij eenvoudigweg een syslog te sturen wanneer de zichtbaarheidsstatus van buren veranderde. Dienovereenkomstig was het veel eenvoudiger, sneller en nauwkeuriger dan tracering. Een evenement als buurman verloren is gearriveerd en ik geef onmiddellijk een melding over het kanaal naar beneden.

Verder verschenen er nog een aantal commando's wanneer je op een object klikte, en SNMP werd toegevoegd om wat statistieken te verzamelen, en dat is het eigenlijk. Het systeem heeft zich nooit verder ontwikkeld. Het deed alles wat ik nodig had, het was een goed hulpmiddel. Veel lezers zullen mij waarschijnlijk vertellen dat er al veel software op internet te vinden is om deze problemen op te lossen. Maar in feite heb ik dergelijke gratis producten destijds niet gegoogled en ik wilde heel graag mijn programmeervaardigheden ontwikkelen, en wat is een betere manier om dit te bereiken dan een echt applicatieprobleem. Op dit punt was de eerste versie van de monitoring voltooid en niet langer gewijzigd.

Oprichting van het bedrijf Audit-Telecom

Naarmate de tijd verstreek, begon ik parttime bij andere bedrijven te werken, gelukkig liet mijn werkschema mij dit toe. Als je in verschillende bedrijven werkt, groeien je vaardigheden op verschillende gebieden heel snel en ontwikkelt je horizon zich goed. Er zijn bedrijven waarin je, zoals ze zeggen, een Zweed, een maaier en een trompettist bent. Aan de ene kant is dat lastig, aan de andere kant: als je niet lui bent, word je een generalist en hierdoor kun je problemen sneller en efficiënter oplossen omdat je weet hoe het vakgebied in elkaar zit.

Mijn vriend Pavel (ook een IT-specialist) probeerde mij voortdurend aan te moedigen om zijn eigen bedrijf te starten. Er waren talloze ideeën met verschillende variaties op wat ze deden. Hier wordt al jaren over gesproken. En uiteindelijk had het niets moeten opleveren, want ik ben een scepticus en Pavel een dromer. Elke keer dat hij een idee voorstelde, geloofde ik er altijd niet in en weigerde ik mee te doen. Maar we wilden heel graag een eigen bedrijf openen.

Eindelijk hebben we een optie kunnen vinden die bij ons allebei paste en waar we verstand van hebben. In 2016 besloten we een IT-bedrijf op te richten dat bedrijven zou helpen IT-problemen op te lossen. Dit betreft de inzet van IT-systemen (1C, terminalserver, mailserver, etc.), het onderhoud ervan, de klassieke HelpDesk voor gebruikers en het netwerkbeheer.

Eerlijk gezegd geloofde ik er op het moment dat ik het bedrijf oprichtte er voor 99,9% niet in. Maar op de een of andere manier kreeg Pavel het voor elkaar om het te proberen, en vooruitkijkend bleek dat hij gelijk had. Pavel en ik verdienden elk 300 roebel, registreerden een nieuwe LLC "Audit-Telecom", huurden een klein kantoor, maakten coole visitekaartjes, nou ja, in het algemeen, zoals waarschijnlijk de meest onervaren, beginnende zakenmensen, en gingen op zoek naar klanten. Klanten vinden is een heel ander verhaal. Misschien zullen we een apart artikel schrijven als onderdeel van de bedrijfsblog als iemand geïnteresseerd is. Koude oproepen, flyers, enz. Dit leverde geen resultaat op. Zoals ik nu uit veel verhalen over zaken lees, hangt veel af van geluk. We hadden geluk. en letterlijk een paar weken na de oprichting van het bedrijf benaderde mijn broer Vladimir ons, die ons de eerste klant bracht. Ik zal je niet vervelen met de details van het werken met klanten, daar gaat het artikel niet over. Ik wil alleen zeggen dat we een audit hebben uitgevoerd, kritieke gebieden hebben geïdentificeerd en dat deze gebieden zijn afgebroken terwijl de beslissing werd genomen over de vraag of we dat zouden doen. werken voortdurend met ons samen als outsourcer. Hierna werd direct een positief besluit genomen.

Toen begonnen er, voornamelijk via mond-tot-mondreclame via vrienden, andere dienstverlenende bedrijven te verschijnen. De helpdesk zat in één systeem. Verbindingen met netwerkapparatuur en servers zijn anders, of liever anders. Sommige mensen bewaarden snelkoppelingen, anderen gebruikten RDP-adresboeken. Monitoring is een ander afzonderlijk systeem. Het is erg lastig voor een team om in verschillende systemen te werken. Belangrijke informatie wordt uit het oog verloren. De terminalserver van de klant was bijvoorbeeld niet meer beschikbaar. Aanvragen van gebruikers van deze opdrachtgever worden direct ontvangen. De ondersteuningsspecialist opent een verzoek (deze is telefonisch ontvangen). Als incidenten en verzoeken in één systeem zouden worden geregistreerd, zou de supportspecialist onmiddellijk zien wat het probleem van de gebruiker is en hem hierover vertellen, terwijl hij tegelijkertijd verbinding maakt met het benodigde object om de situatie uit te werken. Iedereen is zich bewust van de tactische situatie en werkt harmonieus samen. Wij hebben geen systeem gevonden waarin dit allemaal gecombineerd wordt. Het werd duidelijk dat het tijd was om ons eigen product te maken.

Verder werken aan uw monitoringsysteem

Het was duidelijk dat het eerder geschreven systeem totaal ongeschikt was voor de huidige taken. Noch qua functionaliteit, noch qua kwaliteit. En er werd besloten om het systeem helemaal opnieuw te schrijven. Grafisch had het er heel anders uit moeten zien. Het moest een hiërarchisch systeem zijn, zodat het mogelijk zou zijn om snel en gemakkelijk het juiste object voor de juiste klant te openen. Het schema zoals in de eerste versie was in het huidige geval absoluut niet gerechtvaardigd, omdat De klanten zijn verschillend en het maakte helemaal niet uit in welk pand de apparatuur zich bevond. Dit is al overgebracht naar de documentatie.

De taken zijn dus:

1. Hiërarchische structuur;
2. Een soort serveronderdeel dat bij de klant kan worden geplaatst in de vorm van een virtuele machine om de statistieken te verzamelen die we nodig hebben en deze naar de centrale server te sturen, die dit allemaal zal samenvatten en aan ons zal laten zien;
3. Waarschuwingen. Die je niet mag missen, want... in die tijd was het niet mogelijk dat iemand alleen maar naar de monitor keek;
4. Applicatiesysteem. Er begonnen klanten te verschijnen voor wie we niet alleen server- en netwerkapparatuur onderhoudden, maar ook werkstations;
5. Mogelijkheid om snel verbinding te maken met servers en apparatuur vanuit het systeem;

De taken zijn vastgesteld, we beginnen te schrijven. Onderweg verwerken van verzoeken van klanten. We waren toen al met z’n vieren. We zijn begonnen met het schrijven van beide delen in één keer: de centrale server en de server voor installatie op clients. Op dat moment was Linux geen onbekende meer voor ons en werd besloten dat de virtuele machines waarover klanten zouden beschikken, op Debian zouden staan. Er zullen geen installatieprogramma's zijn, we maken gewoon een serverdeelproject op één specifieke virtuele machine, en dan klonen we het gewoon naar de gewenste client. Dit was weer een fout. Later werd duidelijk dat in een dergelijk schema het updatemechanisme volledig onontwikkeld was. Die. we waren een nieuwe functie aan het toevoegen, en toen was er het hele probleem van het distribueren ervan naar alle clientservers, maar we komen hier later op terug, alles in orde.

We hebben het eerste prototype gemaakt. Hij kon de clientnetwerkapparaten en -servers die we nodig hadden pingen en deze gegevens naar onze centrale server sturen. En hij heeft deze gegevens op zijn beurt in bulk bijgewerkt op de centrale server. Hier zal ik niet alleen een verhaal schrijven over hoe en wat succesvol was, maar ook welke amateuristische fouten er zijn gemaakt en hoe ik daar later met de tijd voor moest boeten. De hele boom van objecten werd dus opgeslagen in één enkel bestand in de vorm van een geserialiseerd object. Hoewel we verschillende clients op het systeem hadden aangesloten, was alles min of meer normaal, hoewel er soms enkele artefacten waren die volkomen onbegrijpelijk waren. Maar toen we een tiental servers op het systeem aansloten, begonnen er wonderen te gebeuren. Soms verdwenen om een ​​onbekende reden alle objecten in het systeem gewoon. Belangrijk hierbij is dat de servers waarop de clients stonden elke paar seconden gegevens naar de centrale server stuurden via een POST-verzoek. Een oplettende lezer en een ervaren programmeur vermoedden al dat er een probleem was met meervoudige toegang tot het bestand waarin het geserialiseerde object tegelijkertijd vanuit verschillende threads was opgeslagen. En net toen dit gebeurde, vonden er wonderen plaats met het verdwijnen van objecten. Het bestand werd gewoon leeg. Maar dit alles werd niet onmiddellijk ontdekt, maar alleen tijdens het gebruik van meerdere servers. Gedurende deze tijd werd poortscanfunctionaliteit toegevoegd (de servers stuurden niet alleen informatie over de beschikbaarheid van apparaten naar de centrale, maar ook over de poorten die daarop open stonden). Dit werd gedaan door het commando aan te roepen:

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

de resultaten waren vaak onjuist en het duurde lang voordat de scans waren voltooid. Ik was ping helemaal vergeten, het gebeurde via fping:

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

Ook dit verliep niet parallel en daarom duurde het proces erg lang. Later werd de volledige lijst met IP-adressen die nodig waren voor verificatie in één keer naar fping gestuurd, en terug ontvingen we een kant-en-klare lijst van degenen die reageerden. In tegenstelling tot ons was fping in staat processen te parallelliseren.

Een andere veel voorkomende routineklus was het opzetten van een aantal diensten via WEB. Nou ja, bijvoorbeeld ECP van MS Exchange. Eigenlijk is het gewoon een link. En we hebben besloten dat we dergelijke links rechtstreeks aan het systeem moeten kunnen toevoegen, zodat we niet in de documentatie of ergens anders in bladwijzers hoeven te zoeken hoe we toegang kunnen krijgen tot het ECP van een specifieke klant. Dit is hoe het concept van bronkoppelingen voor het systeem verscheen, hun functionaliteit is tot op de dag van vandaag beschikbaar en is bijna niet veranderd.

Hoe bronkoppelingen werken in Veliam

Verbindingen op afstand

Zo ziet het er in actie uit in de huidige versie van Veliam

Een van de taken was om snel en gemakkelijk verbinding te maken met servers, waarvan er al veel waren (meer dan honderd), en het doorzoeken van miljoenen vooraf opgeslagen RDP-snelkoppelingen was buitengewoon lastig. Er was een hulpmiddel nodig. Er is software op internet die zoiets als een adresboek is voor dergelijke RDP-verbindingen, maar deze zijn niet geïntegreerd met het monitoringsysteem en accounts kunnen niet worden opgeslagen. Elke keer accounts voor verschillende klanten invoeren is een hel als je tientallen keren per dag verbinding maakt met verschillende servers. Met SSH gaat het iets beter; er is veel goede software waarmee je dergelijke verbindingen in mappen kunt ordenen en de accounts daaruit kunt onthouden. Maar er zijn 2 problemen. De eerste is dat we geen enkel programma voor RDP- en SSH-verbindingen hebben gevonden. De tweede is dat als ik op een gegeven moment niet achter mijn computer zit en snel verbinding moet maken, of als ik het systeem zojuist opnieuw heb geïnstalleerd, ik de documentatie moet raadplegen om het account van deze klant te bekijken. Het is lastig en tijdverspilling.

De hiërarchische structuur die we nodig hadden voor clientservers was al beschikbaar in ons interne product. Ik moest alleen nog uitzoeken hoe ik daar snelle verbindingen kon maken met de benodigde apparatuur. Om te beginnen, in ieder geval binnen jouw netwerk.

Rekening houdend met het feit dat de client in ons systeem een ​​browser was die geen toegang heeft tot de lokale bronnen van de computer, om eenvoudigweg de applicatie te starten die we nodig hadden met een of ander commando, werd deze uitgevonden om alles via de “Windows aangepast URL-schema”. Zo verscheen er een bepaalde “plug-in” voor ons systeem, die eenvoudigweg Putty en Remote Desktop Plus bevatte en tijdens de installatie eenvoudigweg het URI-schema in Windows registreerde. Toen we nu verbinding wilden maken met een object via RDP of SSH, klikten we op deze actie op ons systeem en de aangepaste URI werkte. De standaard mstsc.exe ingebouwd in Windows of putty, die deel uitmaakte van de “plug-in”, werd gelanceerd. Ik heb het woord plug-in tussen aanhalingstekens gezet omdat dit geen browserplug-in in de klassieke zin is.

Dat was tenminste iets. Handig adresboek. Bovendien was in het geval van Putty over het algemeen alles in orde; het kon IP-verbindingen, login en wachtwoord als invoerparameters krijgen. Die. We hebben al met één klik verbinding gemaakt met Linux-servers op ons netwerk zonder wachtwoorden in te voeren. Maar met RDP is het niet zo eenvoudig. Standaard mstsc kan geen referenties als parameters opgeven. Remote Desktop Plus kwam te hulp. Hij liet dit gebeuren. Nu kunnen we het zonder, maar het was lange tijd een trouwe assistent in ons systeem. Met HTTP(S)-sites is alles eenvoudig: dergelijke objecten worden eenvoudigweg in de browser geopend en dat is alles. Handig en praktisch. Maar dit was alleen geluk op het interne netwerk.

Omdat we de overgrote meerderheid van de problemen op afstand vanaf kantoor hebben opgelost, was het het gemakkelijkst om VPN's beschikbaar te stellen aan klanten. En toen was het mogelijk om vanuit ons systeem verbinding met hen te maken. Maar het was nog steeds enigszins lastig. Voor elke client was het nodig om een ​​aantal onthouden VPN-verbindingen op elke computer bij te houden, en voordat er verbinding mee kon worden gemaakt, was het noodzakelijk om de bijbehorende VPN in te schakelen. Wij hebben deze oplossing al geruime tijd gebruikt. Maar het aantal klanten neemt toe, het aantal VPN's neemt ook toe, en dit alles begon onder druk te staan ​​en er moest iets aan gedaan worden. De tranen sprongen mij vooral in de ogen na het opnieuw installeren van het systeem, toen ik tientallen VPN-verbindingen opnieuw moest invoeren in een nieuw Windows-profiel. Verdraag dit niet langer, zei ik, en begon na te denken over wat ik eraan kon doen.

Het gebeurde zo dat alle klanten apparaten van het bekende bedrijf Mikrotik als routers hadden. Ze zijn zeer functioneel en handig voor het uitvoeren van vrijwel elke taak. Het nadeel is dat ze worden “gekaapt”. We hebben dit probleem eenvoudig opgelost door alle toegang van buitenaf af te sluiten. Maar het was nodig om er op de een of andere manier toegang toe te hebben zonder naar de klant te komen, omdat... het is lang. We hebben eenvoudigweg tunnels gemaakt voor elke Mikrotik en deze in een apart zwembad gescheiden. zonder enige routing, zodat er geen verbinding is van uw netwerk met de netwerken van klanten en hun netwerken met elkaar.

Het idee werd geboren om ervoor te zorgen dat wanneer ik op het object klik dat ik nodig heb in het systeem, de centrale monitoringserver, die de SSH-accounts van alle Mikrotik-clients kent, verbinding maakt met het gewenste object, een doorstuurregel creëert naar de gewenste host met de vereiste poort. Er zijn hier verschillende punten. De oplossing is niet universeel: deze werkt alleen voor Mikrotik, omdat de syntaxis van de opdrachten voor alle routers anders is. Bovendien moesten dergelijke doorzendingen op de een of andere manier worden verwijderd, en het servergedeelte van ons systeem kon in wezen op geen enkele manier volgen of ik mijn RDP-sessie had beëindigd. Welnu, zo'n doorzending is een gat voor de klant. Maar we streefden niet naar universaliteit, omdat... het product werd alleen binnen ons bedrijf gebruikt en er waren geen gedachten om het aan het publiek vrij te geven.

Elk van de problemen werd op zijn eigen manier opgelost. Toen de regel werd aangemaakt, was deze doorsturing alleen beschikbaar voor één specifiek extern IP-adres (van waaruit de verbinding werd geïnitialiseerd). Zo werd een veiligheidslek vermeden. Maar bij elke dergelijke verbinding werd een Mikrotik-regel aan de NAT-pagina toegevoegd, die niet werd gewist. En iedereen weet dat hoe meer regels er zijn, hoe meer de processor van de router wordt belast. En over het algemeen kon ik niet accepteren dat ik op een dag naar een of andere Mikrotik zou gaan, en dat er honderden dode, nutteloze regels zouden zijn.

Omdat onze server de verbindingsstatus niet kan volgen, kunt u Mikrotik deze zelf laten volgen. En ik schreef een script dat voortdurend alle doorstuurregels met een specifieke beschrijving in de gaten hield en controleerde of de TCP-verbinding een geschikte regel had. Als er al enige tijd geen verbinding meer is, is de verbinding waarschijnlijk al tot stand gebracht en kan deze doorzending worden verwijderd. Alles is gelukt, het script werkte goed.

Trouwens, hier is het:

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

Het had zeker mooier, sneller etc. gemaakt kunnen worden, maar het werkte, laadde Mikrotik niet en deed uitstekend werk. Eindelijk konden we met slechts één klik verbinding maken met de servers en netwerkapparatuur van klanten. Zonder een VPN te openen of wachtwoorden in te voeren. Het systeem is erg handig geworden om mee te werken. De servicetijd werd verkort en we brachten allemaal tijd door met werken in plaats van verbinding te maken met de noodzakelijke objecten.

Mikrotik-back-up

We hebben een back-up van alle Mikrotik naar FTP geconfigureerd. En over het algemeen was alles prima. Maar als je een back-up nodig had, moest je deze FTP openen en daar naar zoeken. We hebben een systeem waar alle routers op zijn aangesloten; we kunnen via SSH met apparaten communiceren. Waarom zorgen we er niet voor dat het systeem zelf dagelijks back-ups maakt van alle Mikrotiks, dacht ik. En hij begon het te implementeren. We maakten verbinding, maakten een back-up en brachten deze naar de opslag.

Scriptcode in PHP voor het maken van een back-up van 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');

?>

De back-up wordt in twee vormen gemaakt: binair en tekstconfiguratie. Het binaire bestand helpt om de vereiste configuratie snel te herstellen, en de tekst laat u begrijpen wat er moet gebeuren als er een gedwongen vervanging van apparatuur plaatsvindt en het binaire bestand er niet naartoe kan worden geüpload. Als gevolg hiervan kregen we nog een handige functionaliteit in het systeem. Bovendien hoefde ik bij het toevoegen van de nieuwe Mikrotik niets te configureren; ik voegde het object eenvoudigweg toe aan het systeem en stelde er een account voor in via SSH. Vervolgens zorgde het systeem zelf voor het maken van back-ups. De huidige versie van SaaS Veliam beschikt nog niet over deze functionaliteit, maar we zullen deze binnenkort porteren.

Screenshots van hoe het eruit zag in het interne systeem

Overgang naar normale databaseopslag

Ik schreef hierboven al dat er artefacten verschenen. Soms verdween gewoon de hele lijst met objecten in het systeem, soms werd bij het bewerken van een object de informatie niet opgeslagen en moest het object drie keer hernoemd worden. Dit irriteerde iedereen vreselijk. Het verdwijnen van objecten kwam zelden voor en kon gemakkelijk worden hersteld door dit bestand te herstellen, maar fouten bij het bewerken van objecten kwamen vrij vaak voor. Waarschijnlijk heb ik dit in eerste instantie niet via de database gedaan, omdat het niet in mijn gedachten paste hoe het mogelijk was om een ​​boom met alle verbindingen in een platte tabel bij te houden. Het is plat, maar de boom is hiërarchisch. Maar een goede oplossing voor meervoudige toegang, en vervolgens (naarmate het systeem complexer wordt) transactioneel, is een DBMS. Ik ben waarschijnlijk niet de eerste die dit probleem tegenkomt. Ik begon te googlen. Het bleek dat alles al vóór mij was uitgevonden en dat er verschillende algoritmen zijn die een boom bouwen vanuit een platte tafel. Nadat ik ze allemaal had bekeken, heb ik er een geïmplementeerd. Maar dit was al een nieuwe versie van het systeem, omdat... Hierdoor moest ik eigenlijk heel veel herschrijven. Het resultaat was natuurlijk: de problemen van willekeurig gedrag van het systeem verdwenen. Sommigen zullen misschien zeggen dat de fouten erg amateuristisch zijn (scripts met één thread, het opslaan van informatie die meerdere keren tegelijk vanuit verschillende threads in een bestand is benaderd, enz.) op het gebied van softwareontwikkeling. Misschien is dit waar, maar mijn hoofdtaak was administratie, en programmeren was een bijzaak voor mijn ziel, en ik had simpelweg geen ervaring met het werken in een team van programmeurs, waar zulke basiszaken mij onmiddellijk zouden zijn voorgesteld door mijn senior. kameraden. Daarom heb ik al deze hobbels zelf opgevuld, maar ik heb de stof heel goed geleerd. En mijn werk omvat ook ontmoetingen met klanten, acties gericht op het promoten van het bedrijf, een heleboel administratieve kwesties binnen het bedrijf, en nog veel, veel meer. Maar op de een of andere manier was er vraag naar wat er al was. De jongens en ikzelf gebruikten het product in ons dagelijks werk. Er waren ronduit mislukte ideeën en oplossingen waaraan tijd werd verspild, maar uiteindelijk werd duidelijk dat dit geen werkinstrument was en dat niemand het gebruikte en dat het niet bij Veliam terechtkwam.

Helpdesk - Helpdesk

Het zou niet verkeerd zijn om te vermelden hoe HelpDesk is ontstaan. Dit is een heel ander verhaal, want... in Veliam is dit al de 3e volledig nieuwe versie, die anders is dan alle voorgaande. Nu is het een eenvoudig systeem, intuïtief zonder onnodige toeters en bellen, met de mogelijkheid om te integreren met een domein, en de mogelijkheid om overal toegang te krijgen tot hetzelfde gebruikersprofiel via een link uit een e-mail. En het allerbelangrijkste: het is mogelijk om overal (thuis of op kantoor) via VNC rechtstreeks vanuit de applicatie verbinding te maken met de aanvrager zonder VPN of port forwarding. Ik zal je vertellen hoe we hiertoe zijn gekomen, wat er daarvoor is gebeurd en welke vreselijke beslissingen er zijn genomen.

Via de bekende TeamViewer kwamen we in contact met gebruikers. Op alle computers waarvan wij de gebruikers bedienen, is een tv geïnstalleerd. Het eerste dat we verkeerd deden en vervolgens verwijderden, was het koppelen van elke HD-client aan hardware. Hoe heeft de gebruiker ingelogd op het HD-systeem om een ​​verzoek achter te laten? Naast TV had iedereen een speciaal hulpprogramma op zijn computer geïnstalleerd, geschreven in Lazarus (veel mensen hier zullen met hun ogen rollen en misschien zelfs op Google gaan zoeken wat het is, maar de beste gecompileerde taal die ik kende was Delphi, en Lazarus is bijna hetzelfde, alleen gratis). Over het algemeen lanceerde de gebruiker een speciaal batchbestand dat dit hulpprogramma startte, dat op zijn beurt de HWID van het systeem las, waarna de browser werd gestart en autorisatie plaatsvond. Waarom werd dit gedaan? In sommige bedrijven wordt het aantal ondersteunde gebruikers individueel geteld en is de serviceprijs voor elke maand gebaseerd op het aantal personen. Dit is begrijpelijk, zegt u, maar waarom is dit gebonden aan hardware? Het is heel eenvoudig: sommige mensen kwamen thuis en deden vanaf hun thuislaptop een verzoek in de stijl van 'maak hier alles mooi voor mij'. Naast het lezen van de HWID van het systeem, haalde het hulpprogramma de huidige Teamviewer-ID uit het register en stuurde deze ook naar ons. Teamviewer heeft een API voor integratie. En we hebben deze integratie gedaan. Maar er was één addertje onder het gras. Via deze API's is het onmogelijk om verbinding te maken met de computer van de gebruiker wanneer hij deze sessie niet expliciet initieert en nadat hij geprobeerd heeft verbinding te maken, moet hij ook op "bevestigen" klikken. Op dat moment leek het ons logisch dat niemand verbinding zou maken zonder het verzoek van de gebruiker, en aangezien de persoon achter de computer zit, zal hij de sessie starten en bevestigend reageren op het verzoek om verbinding op afstand. Alles pakte verkeerd uit. Aanvragers vergaten de sessie te starten en moesten dit in een telefoongesprek vertellen. Dit verspilde tijd en was frustrerend voor beide kanten van het proces. Bovendien is het op zulke momenten helemaal niet ongebruikelijk dat iemand een verzoek achterlaat, maar alleen verbinding mag maken als hij vertrekt voor de lunch. Omdat het probleem niet kritiek is en hij niet wil dat zijn werkproces wordt onderbroken. Dienovereenkomstig zal hij op geen enkele knop drukken om verbinding mogelijk te maken. Zo verscheen er extra functionaliteit bij het inloggen op HelpDesk - het lezen van de ID van Teamviwer. We kenden het permanente wachtwoord dat werd gebruikt bij het installeren van Teamviwer. Om precies te zijn: alleen het systeem wist dit, omdat het in het installatieprogramma en in ons systeem was ingebouwd. Dienovereenkomstig was er een verbindingsknop vanuit de applicatie door erop te klikken, waarop u nergens op hoefde te wachten, maar Teamviewer werd onmiddellijk geopend en er vond een verbinding plaats. Als gevolg hiervan waren er twee soorten mogelijke verbindingen. Via de officiële Teamviewer API en onze zelfgemaakte. Tot mijn verbazing stopten ze vrijwel onmiddellijk met het gebruik van de eerste, hoewel er een instructie was om deze alleen in speciale gevallen te gebruiken en wanneer de gebruiker zelf toestemming geeft. Toch, geef mij nu zekerheid. Maar het bleek dat de aanvragers dit niet nodig hadden. Ze vinden het allemaal prima om met hen verbonden te zijn zonder een bevestigingsknop.

Overstappen naar multithreading in Linux

De kwestie van het versnellen van de doorgang van een netwerkscanner voor de openheid van een vooraf bepaalde lijst met poorten en het eenvoudig pingen van netwerkobjecten is al lang begonnen op te komen. Hier is uiteraard de eerste oplossing die in je opkomt multithreading. Omdat de belangrijkste tijd die aan ping wordt besteed, bestaat uit het wachten op het terugsturen van het pakket, en de volgende ping pas kan beginnen als het vorige pakket is teruggestuurd, werkte dit in bedrijven die zelfs meer dan 20 servers plus netwerkapparatuur hadden, al vrij langzaam. Het punt is dat één pakket kan verdwijnen, maar stel de systeembeheerder er niet onmiddellijk van op de hoogte. Hij zal gewoon heel snel stoppen met het accepteren van dergelijke spam. Dit betekent dat u elk object meerdere keren moet pingen voordat u een conclusie trekt over de ontoegankelijkheid. Zonder al te veel in detail te treden, is het noodzakelijk om dit te parallelliseren, want als dit niet gebeurt, zal de systeembeheerder hoogstwaarschijnlijk via de client over het probleem te weten komen, en niet via het monitoringsysteem.

PHP zelf ondersteunt geen out-of-the-box multithreading. Geschikt voor multiprocessing, u kunt vorken. Maar in feite had ik al een polling-mechanisme geschreven en ik wilde het zo maken dat ik ooit alle knooppunten uit de database zou tellen die ik nodig had, alles in één keer zou pingen, op een antwoord van elk zou wachten en pas daarna onmiddellijk zou schrijven de data. Dit scheelt in het aantal leesverzoeken. Multithreading past perfect in dit idee. Voor PHP is er een PThreads-module waarmee je echte multithreading kunt doen, hoewel het behoorlijk wat sleutelwerk kostte om dit op PHP 7.2 in te stellen, maar het was klaar. Poortscannen en ping zijn nu snel. En in plaats van bijvoorbeeld 15 seconden per ronde eerder, begon dit proces 2 seconden te duren. Het was een goed resultaat.

Snelle audit van nieuwe bedrijven

Hoe is de functionaliteit voor het verzamelen van verschillende statistieken en hardwarekenmerken tot stand gekomen? Het is makkelijk. Soms krijgen we simpelweg de opdracht om de huidige IT-infrastructuur te auditen. Hetzelfde is nodig om de audit van een nieuwe klant te versnellen. We hadden iets nodig waarmee we naar een middelgroot of groot bedrijf konden gaan en snel konden achterhalen wat ze te bieden hadden. Naar mijn mening wordt ping op het interne netwerk alleen geblokkeerd door degenen die hun eigen leven willen compliceren, en naar onze ervaring zijn dat er maar weinig. Maar er zijn ook zulke mensen. Zo kunt u netwerken snel scannen op de aanwezigheid van apparaten met een simpele ping. Dan kunnen we ze toevoegen en zoeken naar open poorten die ons interesseren. In feite bestond deze functionaliteit al; het was alleen nodig om een ​​commando van de centrale server aan de slave-server toe te voegen, zodat deze de gespecificeerde netwerken zou scannen en alles wat hij vond aan de lijst zou toevoegen. Ik vergat nog te vermelden dat er vanuit werd gegaan dat we al een kant-en-klaar image hadden met een geconfigureerd systeem (slave monitoring server) dat we tijdens een audit eenvoudig vanuit de klant konden uitrollen en verbinden met onze cloud.

Maar het resultaat van een audit bevat meestal een heleboel verschillende informatie, en een daarvan is wat voor soort apparaten er op het netwerk zijn aangesloten. Allereerst waren we geïnteresseerd in Windows-servers en Windows-werkstations als onderdeel van een domein. Omdat bij middelgrote en grote bedrijven het ontbreken van een domein waarschijnlijk een uitzondering op de regel is. Om één taal te spreken, is het gemiddelde naar mijn mening meer dan 100 mensen. Er moest een manier worden bedacht om gegevens van alle Windows-machines en -servers te verzamelen, waarbij we hun IP-adres en domeinbeheerderaccount kenden, maar zonder op elk ervan software te installeren. De WMI-interface komt te hulp. Windows Management Instrumentation (WMI) betekent letterlijk Windows-beheertools. WMI is een van de basistechnologieën voor gecentraliseerd beheer en monitoring van de werking van verschillende delen van de computerinfrastructuur waarop het Windows-platform draait. Van wiki gehaald. Vervolgens moest ik opnieuw sleutelen om wmic (dit is een WMI-client) voor Debian te compileren. Nadat alles klaar was, hoefde je alleen nog maar via wmic de benodigde knooppunten te ondervragen voor de benodigde informatie. Via WMI kun je vrijwel alle informatie van een Windows-computer krijgen, en bovendien kun je er ook de computer mee besturen, bijvoorbeeld sturen om opnieuw op te starten. Dit is hoe de verzameling informatie over Windows-stations en servers in ons systeem verscheen. Daarnaast was er actuele informatie over de huidige systeembelastingsindicatoren. We vragen ze vaker op, en informatie over hardware minder vaak. Hierna werd het auditeren iets leuker.

Beslissing over softwaredistributie

Zelf gebruiken wij het systeem dagelijks en staat het altijd open voor iedere technische medewerker. En we dachten dat we met anderen konden delen wat we al hebben. Het systeem was nog niet klaar om gedistribueerd te worden. Er moest veel herwerkt worden zodat de lokale versie SaaS zou worden. Deze omvatten veranderingen in verschillende technische aspecten van het systeem (verbindingen op afstand, ondersteunende service), analyse van modules voor licentieverlening, sharding van klantendatabases, schaalvergroting van elke service en de ontwikkeling van automatische updatesystemen voor alle onderdelen. Maar dit zal het tweede deel van het artikel zijn.

bijwerken

Het tweede deel

Bron: www.habr.com