De la subcontractació al desenvolupament (part 1)

Hola a tots, em dic Sergey Emelyanchik. Sóc el responsable de l'empresa Audit-Telecom, el principal desenvolupador i autor del sistema Veliam. Vaig decidir escriure un article sobre com el meu amic i jo vam crear una empresa d'externalització, vam escriure programari per a nosaltres mateixos i, posteriorment, vam començar a distribuir-lo a tothom mitjançant el sistema SaaS. Sobre com no vaig creure categòricament que això fos possible. L'article contindrà no només una història, sinó també detalls tècnics de com es va crear el producte Veliam. Incloent alguns fragments de codi font. Més endavant us explicaré quins errors hem comès i com els hem corregit. Hi havia dubtes de publicar un article així. Però vaig pensar que era millor fer-ho, rebre comentaris i millorar, que no publicar l'article i pensar què hauria passat si...

prehistòria

Vaig treballar en una empresa com a empleat informàtic. L'empresa era bastant gran amb una àmplia estructura de xarxa. No em detendré en les meves responsabilitats laborals, només diré que definitivament no incloïen el desenvolupament de res.

Vam tenir un seguiment, però només per interès acadèmic volia intentar escriure el meu més senzill. La idea era aquesta: volia que estigués a la web, per poder entrar fàcilment sense instal·lar cap client i veure què passava amb la xarxa des de qualsevol dispositiu, inclòs un dispositiu mòbil mitjançant Wi-Fi, i també realment volia entendre ràpidament què hi ha un equip a la sala que s'ha convertit en "mopey" perquè... hi havia requisits molt estrictes de temps de resposta a aquests problemes. Com a resultat, va néixer un pla al meu cap per escriure una pàgina web senzilla on hi havia un fons jpeg amb un diagrama de xarxa, retallar els propis dispositius amb les seves adreces IP en aquesta imatge i mostrar contingut dinàmic a la part superior del imatge amb les coordenades requerides en forma d'adreça IP verda o vermella intermitent. La tasca està fixada, comencem.

Anteriorment, estava programant en Delphi, PHP, JS i molt superficialment en C++. Sé molt bé com funcionen les xarxes. VLAN, enrutament (OSPF, EIGRP, BGP), NAT. Això va ser suficient per escriure jo mateix un prototip de monitoratge primitiu.

Vaig escriure el que tenia previst en PHP. El servidor Apache i PHP estava a Windows perquè... Linux per a mi en aquell moment era una cosa incomprensible i molt complexa, com va resultar més tard, em vaig equivocar molt i en molts llocs Linux és molt més senzill que Windows, però aquest és un tema a part i tots sabem quants holivars hi ha. aquest tema. El programador de tasques de Windows va treure a un petit interval (no recordo exactament, però una vegada cada tres segons) un script PHP que va enquestar tots els objectes amb un ping banal i va desar l'estat en un fitxer.

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

Sí, sí, treballar amb una base de dades en aquell moment tampoc no em dominava. No sabia que era possible paral·lelitzar processos, i passar per tots els nodes de la xarxa trigava molt de temps, perquè... això va passar en un fil. Els problemes van sorgir especialment quan diversos nodes no estaven disponibles, perquè cadascun d'ells va retardar l'script durant 300 ms. Al costat del client hi havia una funció de bucle senzilla que, a intervals d'uns segons, baixava informació actualitzada del servidor amb una sol·licitud Ajax i actualitzava la interfície. Bé, doncs, després de 3 pings seguits sense èxit, si una pàgina web amb monitoratge estava oberta a l'ordinador, es reproduïa una composició alegre.

Quan tot va funcionar, em va inspirar molt el resultat i vaig pensar que podria afegir-hi més (pels meus coneixements i capacitats). Però sempre no m'han agradat els sistemes amb un milió de gràfics, que aleshores pensava, i encara avui dia, no són necessaris en la majoria dels casos. Volia posar-hi només allò que realment m'ajudaria en la meva feina. Aquest principi continua sent fonamental per al desenvolupament de Veliam fins avui. A més, em vaig adonar que estaria molt bé si no fos necessari mantenir la supervisió oberta i conèixer els problemes i, quan va passar, obriu la pàgina i veieu on es troba aquest node de xarxa problemàtic i què fer-hi a continuació. D'alguna manera no vaig llegir el correu electrònic aleshores, simplement no el vaig utilitzar. Em vaig trobar a Internet que hi ha passarel·les SMS a les quals pots enviar una sol·licitud GET o POST, i m'enviaran un SMS al meu mòbil amb el text que escric. De seguida em vaig adonar que realment ho volia. I vaig començar a estudiar la documentació. Després d'un temps ho vaig aconseguir, i ara vaig rebre un SMS sobre problemes a la xarxa al meu telèfon mòbil amb el nom d'un "objecte caigut". Tot i que el sistema era primitiu, el vaig escriure jo mateix, i el més important que em va motivar a desenvolupar-lo va ser que era un programa d'aplicació que em va ajudar molt en la meva feina.

I aleshores va arribar el dia en què un dels canals d'Internet va caure a la feina, i el meu seguiment no m'ho va fer saber. Atès que Google DNS encara va fer ping perfectament. És hora de pensar com es pot controlar que el canal de comunicació estigui viu. Hi havia diferents idees sobre com fer-ho. No tenia accés a tot l'equip. Vam haver d'esbrinar com entendre quin dels canals està en directe, però sense poder veure'l d'alguna manera al propi equip de xarxa. Aleshores, a un company se li va ocórrer la idea que és possible que el traçat de la ruta als servidors públics pugui variar segons quin canal de comunicació s'utilitza actualment per accedir a Internet. Vaig comprovar i va resultar així. Hi havia diferents rutes a l'hora de traçar.

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

Així que va aparèixer un altre script, o millor dit, per alguna raó es va afegir el rastre al final del mateix script, que feia ping a tots els dispositius de la xarxa. Al cap i a la fi, aquest és un altre procés llarg que es va executar en el mateix fil i va alentir el treball de tot l'script. Però aleshores no era tan evident. Però d'una manera o altra, va fer la seva feina, el codi definia estrictament quin tipus de traçat havia de ser per a cadascun dels canals. Així va començar a funcionar el sistema, que ja supervisava (dit en veu alta, perquè no hi havia cap recopilació de mètriques, sinó només ping) dispositius de xarxa (encaminadors, commutadors, wi-fi, etc.) i canals de comunicació amb el món exterior. . Els missatges SMS arribaven regularment i el diagrama sempre mostrava clarament on era el problema.

A més, en el treball quotidià havia de fer creuaments. I em vaig cansar d'anar als commutadors de Cisco cada vegada per veure quina interfície utilitzar. Què bé seria fer clic a un objecte en monitorització i veure una llista de les seves interfícies amb descripcions. M'estalviaria temps. A més, en aquest esquema no caldria executar Putty o SecureCRT per introduir comptes i ordres. Només vaig fer clic al seguiment, vaig veure què calia i vaig anar a fer la meva feina. Vaig començar a buscar maneres d'interactuar amb els interruptors. Immediatament em vaig trobar amb 2 opcions: SNMP o iniciar sessió al commutador mitjançant SSH, introduint les ordres que necessitava i analitzant el resultat. Vaig descartar SNMP per la complexitat de la seva implementació; estava impacient per obtenir el resultat. amb SNMP, hauríeu d'explorar el MIB durant molt de temps i, a partir d'aquestes dades, generar dades sobre les interfícies. Hi ha un equip meravellós a CISCO

show interface status

Mostra exactament el que necessito per encreuaments. Per què molestar-me amb SNMP quan només vull veure la sortida d'aquesta ordre, vaig pensar. Després d'un temps, em vaig adonar d'aquesta oportunitat. S'ha fet clic en un objecte d'una pàgina web. Es va desencadenar un esdeveniment pel qual el client AJAX es va posar en contacte amb el servidor i, al seu torn, es va connectar mitjançant SSH a l'interruptor que necessitava (les credencials estaven codificades en el codi, no hi havia cap desig de refinar-lo, per fer alguns menús separats on seria possible canviar els comptes des de la interfície, necessitava el resultat i ràpidament) vaig introduir l'ordre anterior allà i la vaig enviar de nou al navegador. Així que vaig començar a veure informació sobre les interfícies amb un clic del ratolí. Això va ser extremadament convenient, sobretot quan vau haver de veure aquesta informació en diferents interruptors alhora.

El seguiment del canal basat en traça no va acabar sent la millor idea, perquè... de vegades es treballava a la xarxa, i el traçat podia canviar i el seguiment em va començar a cridar que hi havia problemes amb el canal. Però després de dedicar molt de temps a l'anàlisi, em vaig adonar que tots els canals funcionaven i el meu seguiment m'estava enganyant. Com a resultat, vaig demanar als meus companys que gestionaven els interruptors de formació de canals que simplement m'enviessin syslog quan canviés l'estat de visibilitat dels veïns. En conseqüència, era molt més senzill, més ràpid i més precís que el rastreig. Ha arribat un esdeveniment com un veí perdut i de seguida emet una notificació sobre el canal caigut.

A més, van aparèixer diverses ordres més en fer clic a un objecte i es va afegir SNMP per recollir algunes mètriques, i això és bàsicament. El sistema no es va desenvolupar mai més. Va fer tot el que necessitava, va ser una bona eina. Molts lectors probablement em diran que ja hi ha molt de programari a Internet per resoldre aquests problemes. Però, de fet, no vaig buscar a Google aquests productes gratuïts aleshores i tenia moltes ganes de desenvolupar les meves habilitats de programació, i quina millor manera d'impulsar-ho que un problema real d'aplicació. En aquest punt, es va completar la primera versió del seguiment i ja no es va modificar.

Creació de l'empresa Audit-Telecom

Amb el pas del temps vaig començar a treballar a temps parcial en altres empreses, sortosament el meu horari laboral em va permetre fer-ho. Quan treballes en diferents empreses, les teves habilitats en diferents àmbits creixen molt ràpidament i els teus horitzons es desenvolupen bé. Hi ha empreses en què, com diuen, ets suec, segador i trompetista. D'una banda, és difícil, de l'altra, si no ets mandrós, et converteixes en generalista i això et permet resoldre problemes de manera més ràpida i eficient perquè saps com funciona l'àmbit relacionat.

El meu amic Pavel (també especialista en informàtica) intentava constantment animar-me a iniciar el seu propi negoci. Hi havia innombrables idees amb diferents variacions del que estaven fent. Això fa anys que es parla. I al final, no hauria d'haver arribat a res perquè sóc un escèptic, i el Pavel és un somiador. Cada cop que proposava una idea, jo sempre no hi creia i em vaig negar a participar. Però teníem moltes ganes d'obrir el nostre propi negoci.

Finalment, vam poder trobar una opció que ens convingués a tots dos i fer el que sabem fer. El 2016 vam decidir crear una empresa informàtica que ajudés les empreses a resoldre problemes informàtics. Es tracta del desplegament de sistemes informàtics (1C, servidor de terminal, servidor de correu, etc.), el seu manteniment, el clàssic HelpDesk per a usuaris i administració de xarxes.

Francament, en el moment de crear l'empresa, no hi creia al voltant del 99,9%. Però d'alguna manera Pavel va poder fer-me que ho intentés i, mirant endavant, va resultar que tenia raó. Pavel i jo vam pagar 300 rubles cadascun, vam registrar una nova LLC "Audit-Telecom", vam llogar una petita oficina, vam fer targetes de visita fantàstiques, bé, en general, com probablement la majoria dels empresaris novells i sense experiència, i vam començar a buscar clients. Trobar clients és una història completament diferent. Potser escriurem un article separat com a part del bloc corporatiu si algú està interessat. Trucades en fred, volants, etc. Això no va donar cap resultat. Com ara llegeixo moltes històries sobre negocis, d'una manera o una altra, depèn molt de la sort. Vam tenir sort. i literalment un parell de setmanes després de la creació de l'empresa, es va acostar a nosaltres el meu germà Vladimir, que ens va portar el nostre primer client. No us avorriré amb els detalls de treballar amb clients, no és del que tracta l'article, només diré que vam fer una auditoria, vam identificar àrees crítiques i aquestes es van trencar mentre es va prendre la decisió de si col·laboreu amb nosaltres de manera continuada com a contractistes. Després d'això, immediatament es va prendre una decisió positiva.

Aleshores, principalment pel boca-orella a través dels amics, van començar a aparèixer altres empreses de serveis. Helpdesk estava en un sistema. Les connexions als equips de xarxa i als servidors són diferents, o més aviat diferents. Algunes persones van desar dreceres, d'altres van utilitzar llibretes d'adreces RDP. El seguiment és un altre sistema independent. És molt inconvenient per a un equip treballar en sistemes diferents. La informació important es perd de vista. Bé, per exemple, el servidor de terminal del client no va estar disponible. Les sol·licituds dels usuaris d'aquest client es reben immediatament. L'especialista de suport obre una sol·licitud (s'ha rebut per telèfon). Si les incidències i les sol·licituds es registressin en un sistema, l'especialista de suport veuria immediatament quin és el problema de l'usuari i li explicaria al respecte, alhora que es connectava a l'objecte necessari per resoldre la situació. Tothom és conscient de la situació tàctica i treballa harmoniosament. No hem trobat un sistema on tot això es combini. Va quedar clar que era el moment de fer el nostre propi producte.

Continueu treballant en el vostre sistema de monitorització

Era evident que el sistema que es va escriure abans era completament inadequat per a les tasques actuals. Ni pel que fa a la funcionalitat ni pel que fa a la qualitat. I es va decidir escriure el sistema des de zero. Gràficament hauria d'haver semblat completament diferent. Havia de ser un sistema jeràrquic perquè fos possible obrir de manera ràpida i còmoda l'objecte adequat per al client adequat. L'esquema com en la primera versió no estava absolutament justificat en el cas actual, perquè Els clients són diferents i no importava gens en quin local es trobava l'equip. Això ja s'ha traslladat a la documentació.

Així doncs, les tasques:

1. Estructura jeràrquica;
2. Una mena de part de servidor que es pot col·locar a les instal·lacions del client en forma de màquina virtual per recollir les mètriques que necessitem i enviar-la al servidor central, que resumirà tot això i ens ho mostrarà;
3. Alertes. Els que no es poden perdre, perquè... en aquell moment no era possible que algú s'assegués i només mirés el monitor;
4. Sistema d'aplicació. Van començar a aparèixer clients als quals vam donar servei no només a equips de servidors i de xarxa, sinó també a estacions de treball;
5. Capacitat de connectar-se ràpidament a servidors i equips des del sistema;

Les tasques s'han fixat, comencem a escriure. Al llarg del camí, processant les sol·licituds dels clients. En aquell moment ja érem 4. Vam començar a escriure les dues parts alhora: el servidor central i el servidor per a la instal·lació als clients. En aquest moment, Linux ja no era un estrany per a nosaltres i es va decidir que les màquines virtuals que tindrien els clients estarien a Debian. No hi haurà instal·ladors, només farem un projecte de part del servidor en una màquina virtual específica i després només el clonarem al client desitjat. Aquest va ser un altre error. Més tard va quedar clar que en aquest esquema el mecanisme d'actualització estava completament sense desenvolupar. Aquells. estàvem afegint alguna característica nova, i després va haver-hi tot el problema de distribuir-la a tots els servidors de clients, però hi tornarem més endavant, tot en ordre.

Hem fet el primer prototip. Va poder fer ping als dispositius de la xarxa client i als servidors que necessitàvem i enviar aquestes dades al nostre servidor central. I ell, al seu torn, va actualitzar aquestes dades de manera massiva al servidor central. Aquí escriuré no només una història sobre com i què va tenir èxit, sinó també quins errors d'aficionat es van cometre i com més tard vaig haver de pagar-ho amb el temps. Així, tot l'arbre d'objectes es va emmagatzemar en un sol fitxer en forma d'objecte serialitzat. Mentre connectàvem diversos clients al sistema, tot era més o menys normal, encara que de vegades hi havia alguns artefactes que eren del tot incomprensibles. Però quan vam connectar una dotzena de servidors al sistema, van començar a produir-se miracles. De vegades, per algun motiu desconegut, tots els objectes del sistema simplement desaparegueren. És important tenir en compte aquí que els servidors que els clients havien enviat dades al servidor central cada pocs segons mitjançant una sol·licitud POST. Un lector atent i un programador experimentat ja van endevinar que hi havia un problema d'accés múltiple al mateix fitxer en què s'emmagatzemava l'objecte serialitzat des de diferents fils alhora. I just quan això passava, es van produir miracles amb la desaparició dels objectes. El fitxer simplement es va quedar buit. Però tot això no es va descobrir immediatament, sinó només durant el funcionament amb diversos servidors. Durant aquest temps, es va afegir la funcionalitat d'escaneig de ports (els servidors enviaven a la central no només informació sobre la disponibilitat dels dispositius, sinó també sobre els ports oberts en ells). Això es va fer cridant l'ordre:

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

els resultats sovint eren incorrectes i les exploracions trigaven molt de temps a completar-se. Em vaig oblidar completament del ping, es va fer mitjançant fping:

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

Això tampoc va ser paral·lelitzat i, per tant, el procés va ser molt llarg. Més tard, tota la llista d'adreces IP necessàries per a la verificació es va enviar a fping alhora i vam rebre una llista ja feta dels que van respondre. A diferència de nosaltres, fping va ser capaç de paral·lelitzar processos.

Una altra tasca habitual era configurar alguns serveis via WEB. Bé, per exemple, ECP de MS Exchange. Bàsicament només és un enllaç. I vam decidir que hem de ser capaços d'afegir aquests enllaços directament al sistema, per no haver de buscar a la documentació o en algun altre lloc als marcadors com accedir a l'ECP d'un client concret. Així va aparèixer el concepte d'enllaços de recursos per al sistema, la seva funcionalitat està disponible fins avui i no ha canviat, bé, gairebé.

Com funcionen els enllaços de recursos a Veliam

Connexions remotes

Així es veu en acció a la versió actual de Veliam

Una de les tasques era connectar-se ràpidament i còmodament als servidors, dels quals ja n'hi havia molts (més d'un centenar) i ordenar milions de dreceres RDP desades prèviament era extremadament inconvenient. Calia una eina. Hi ha programari a Internet que s'assembla a una llibreta d'adreces per a aquestes connexions RDP, però no estan integrats amb el sistema de monitorització i els comptes no es poden desar. Introduir comptes per a clients diferents cada vegada és un pur infern quan connecteu desenes de vegades al dia a diferents servidors. Amb SSH, les coses són una mica millors; hi ha molt bon programari que us permet organitzar aquestes connexions en carpetes i recordar-ne els comptes. Però hi ha 2 problemes. El primer és que no hem trobat un sol programa per a connexions RDP i SSH. La segona és que si en algun moment no estic al meu ordinador i necessito connectar-me ràpidament, o simplement he reinstal·lat el sistema, hauré d'entrar a la documentació per veure el compte d'aquest client. És incòmode i és una pèrdua de temps.

L'estructura jeràrquica que necessitàvem per als servidors de clients ja estava disponible al nostre producte intern. Només vaig haver d'esbrinar com connectar-hi connexions ràpides a l'equip necessari. Per començar, almenys dins de la vostra xarxa.

Tenint en compte que el client del nostre sistema era un navegador que no té accés als recursos locals de l'ordinador, per tal d'engegar simplement l'aplicació que necessitàvem amb algun comandament, es va inventar per fer-ho tot a través del "Windows". esquema d'URL personalitzat". Així és com va aparèixer un cert "connector" per al nostre sistema, que simplement incloïa Putty i Remote Desktop Plus i, durant la instal·lació, simplement registrava l'esquema URI a Windows. Ara, quan volíem connectar-nos a un objecte mitjançant RDP o SSH, vam fer clic en aquesta acció al nostre sistema i l'URI personalitzat va funcionar. Es va llançar el mstsc.exe estàndard integrat a Windows o putty, que formava part del "connector". He posat la paraula connector entre cometes perquè no és un connector de navegador en el sentit clàssic.

Almenys això era alguna cosa. Llibreta d'adreces convenient. A més, en el cas de Putty, generalment tot estava bé; se'ls podia donar connexions IP, inici de sessió i contrasenya com a paràmetres d'entrada. Aquells. Ja ens hem connectat als servidors Linux de la nostra xarxa amb un sol clic sense introduir contrasenyes. Però amb RDP no és tan senzill. El mstsc estàndard no pot proporcionar credencials com a paràmetres. Remote Desktop Plus va venir al rescat. Va permetre que això passés. Ara podem prescindir-ne, però durant molt de temps va ser un assistent fidel al nostre sistema. Amb els llocs HTTP(S) tot és senzill, aquests objectes simplement s'obren al navegador i ja està. Convenient i pràctic. Però aquesta era la felicitat només a la xarxa interna.

Com que vam resoldre la gran majoria dels problemes de forma remota des de l'oficina, el més fàcil va ser posar VPN disponibles per als clients. I després va ser possible connectar-s'hi des del nostre sistema. Però encara era una mica incòmode. Per a cada client, era necessari mantenir un munt de connexions VPN recordades a cada ordinador i abans de connectar-se a qualsevol, calia habilitar la VPN corresponent. Hem utilitzat aquesta solució durant força temps. Però el nombre de clients augmenta, el nombre de VPN també augmenta, i tot això va començar a esforçar-se i calia fer-hi alguna cosa. Les llàgrimes em van sortir especialment als ulls després de reinstal·lar el sistema, quan vaig haver de tornar a introduir desenes de connexions VPN en un nou perfil de Windows. Deixa de suportar això, vaig dir, i vaig començar a pensar què hi podia fer.

Va passar que tots els clients tenien dispositius de la coneguda empresa Mikrotik com a encaminadors. Són molt funcionals i còmodes per realitzar gairebé qualsevol tasca. L'inconvenient és que són "segrestats". Hem resolt aquest problema simplement tancant tots els accessos des de l'exterior. Però calia tenir-hi accés d'alguna manera sense venir al lloc del client, perquè... és llarg. Simplement vam fer túnels per a cada Mikrotik i els vam separar en una piscina separada. sense cap enrutament, de manera que no hi hagi connexió de la vostra xarxa amb les xarxes de clients i les seves xarxes entre si.

La idea va néixer per assegurar-me que quan faig clic a l'objecte que necessito al sistema, el servidor central de monitorització, coneixent els comptes SSH de tots els clients Mikrotik, es connecta al desitjat, crea una regla de reenviament a l'amfitrió desitjat amb el port requerit. Aquí hi ha diversos punts. La solució no és universal: només funcionarà per a Mikrotik, ja que la sintaxi de l'ordre és diferent per a tots els encaminadors. A més, aquests reenviaments s'havien d'eliminar d'alguna manera i la part del servidor del nostre sistema essencialment no podia rastrejar de cap manera si havia acabat la meva sessió RDP. Bé, aquest reenviament és un forat per al client. Però no perseguim la universalitat, perquè... el producte s'utilitzava només a la nostra empresa i no hi havia cap idea de llançar-lo al públic.

Cadascun dels problemes es va resoldre a la seva manera. Quan es va crear la regla, aquest reenviament només estava disponible per a una adreça IP externa específica (des de la qual es va inicialitzar la connexió). Així que es va evitar un forat de seguretat. Però amb cada connexió d'aquest tipus, es va afegir una regla Mikrotik a la pàgina NAT i no es va esborrar. I tothom sap que com més regles hi ha, més es carrega el processador de l'encaminador. I, en general, no podia acceptar que algun dia aniria a algun Mikrotik, i hi hauria centenars de regles mortes i inútils.

Com que el nostre servidor no pot fer un seguiment de l'estat de la connexió, deixeu que Mikrotik els faci el seguiment. I vaig escriure un script que supervisava constantment totes les regles de reenviament amb una descripció específica i verificava si la connexió TCP tenia una regla adequada. Si fa temps que no n'hi ha cap, és probable que la connexió ja s'hagi completat i aquest reenviament es pot suprimir. Tot va funcionar, el guió va funcionar bé.

Per cert, aquí està:

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

Segurament es podria haver fet més bonic, més ràpid, etc., però va funcionar, no va carregar Mikrotik i va fer un treball excel·lent. Finalment vam poder connectar-nos als servidors i equips de xarxa dels clients amb un sol clic. Sense obrir una VPN ni introduir contrasenyes. El sistema s'ha tornat molt còmode de treballar. El temps de servei es va reduir i tots vam passar temps treballant en lloc de connectar-nos als objectes necessaris.

Còpia de seguretat de Mikrotik

Hem configurat una còpia de seguretat de tots els Mikrotik a FTP. I en general tot estava bé. Però quan calia fer una còpia de seguretat, calia obrir aquest FTP i buscar-lo allà. Tenim un sistema on tots els encaminadors estan connectats; ens podem comunicar amb dispositius mitjançant SSH. Per què no fem que el propi sistema faci còpies de seguretat de tots els Mikrotik diàriament, vaig pensar. I va començar a aplicar-ho. Ens vam connectar, vam fer una còpia de seguretat i la vam portar a l'emmagatzematge.

Codi d'script en PHP per fer una còpia de seguretat de 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');

?>

La còpia de seguretat es pren de dues formes: configuració binària i de text. El binari ajuda a restaurar ràpidament la configuració necessària, i el de text us permet entendre què cal fer si hi ha una substitució forçada d'equips i el binari no es pot carregar-hi. Com a resultat, vam obtenir una altra funcionalitat convenient al sistema. A més, en afegir un nou Mikrotik, no calia configurar res; simplement vaig afegir l'objecte al sistema i vaig establir-hi un compte mitjançant SSH. Aleshores, el propi sistema es va encarregar de fer còpies de seguretat. La versió actual de SaaS Veliam encara no té aquesta funcionalitat, però aviat la portarem.

Captures de pantalla del que semblava al sistema intern

Transició a l'emmagatzematge normal de la base de dades

Ja vaig escriure més amunt que van aparèixer artefactes. De vegades, la llista sencera d'objectes del sistema simplement desapareixia, de vegades, en editar un objecte, la informació no es guardava i s'havia de canviar el nom de l'objecte tres vegades. Això va irritar terriblement a tothom. La desaparició d'objectes es va produir poques vegades, i es va restaurar fàcilment mitjançant la restauració d'aquest mateix fitxer, però els errors en l'edició d'objectes passaven amb força freqüència. Probablement, inicialment no ho vaig fer a través de la base de dades perquè no em pensava com era possible mantenir un arbre amb totes les connexions en una taula plana. És pla, però l'arbre és jeràrquic. Però una bona solució per a l'accés múltiple i, posteriorment (a mesura que el sistema es fa més complex) transaccional, és un SGBD. Probablement no sóc el primer a trobar aquest problema. Vaig començar a googlear. Va resultar que tot ja s'havia inventat abans que jo i hi ha diversos algorismes que construeixen un arbre a partir d'una taula plana. Després de mirar cadascuna d'elles, n'he implementat una. Però aquesta ja era una nova versió del sistema, perquè... De fet, per això, vaig haver de reescriure bastant. El resultat va ser natural, els problemes de comportament aleatori del sistema van desaparèixer. Alguns podrien dir que els errors són molt afeccionats (scripts d'un sol fil, emmagatzemar informació a la qual s'ha accedit diverses vegades simultàniament des de diferents fils en un fitxer, etc.) en l'àmbit del desenvolupament de programari. Potser això és cert, però la meva feina principal era l'administració, i la programació era un enrenou secundari per a la meva ànima, i simplement no tenia experiència treballant en un equip de programadors, on coses tan bàsiques m'haurien suggerit immediatament el meu sènior. camarades. Per tant, vaig omplir tots aquests cops pel meu compte, però vaig aprendre molt bé el material. I també, la meva feina passa per reunions amb clients, accions encaminades a intentar promocionar l'empresa, un munt de qüestions administratives dins de l'empresa, i molt, molt més. Però d'una manera o una altra, el que ja hi havia era demanat. Els nois i jo mateix vam utilitzar el producte en el nostre treball diari. Hi havia idees i solucions francament infructuoses en les quals es va perdre el temps, però al final es va veure clar que no era una eina de treball i ningú no la feia servir i no va acabar a Veliam.

Helpdesk - HelpDesk

No seria dolent esmentar com es va formar HelpDesk. Aquesta és una història completament diferent, perquè... a Veliam aquesta ja és la 3a versió completament nova, que és diferent de totes les anteriors. Ara és un sistema senzill, intuïtiu sense campanes i xiulets innecessaris, amb la possibilitat d'integrar-se amb un domini, així com la possibilitat d'accedir al mateix perfil d'usuari des de qualsevol lloc mitjançant un enllaç d'un correu electrònic. I el més important, és possible connectar-se amb el sol·licitant mitjançant VNC des de qualsevol lloc (a casa o a l'oficina) directament des de l'aplicació sense VPN ni reenviament de ports. Us explicaré com hem arribat a això, què va passar abans i quines terribles decisions es van prendre.

Ens vam connectar amb els usuaris a través del conegut TeamViewer. Tots els ordinadors als usuaris dels quals servim tenen TV instal·lada. El primer que vam fer malament, i després el vam eliminar, va ser enllaçar cada client HD al maquinari. Com va iniciar la sessió l'usuari al sistema HD per deixar una sol·licitud? A més de la televisió, tothom tenia instal·lada una utilitat especial als seus ordinadors, escrita en Lazarus (molta gent aquí posarà els ulls en blanc, i potser fins i tot va a Google què és, però el millor llenguatge compilat que coneixia era Delphi, i Lazarus és gairebé el mateix, només gratuït). En general, l'usuari va llançar un fitxer per lots especial que va iniciar aquesta utilitat, que al seu torn va llegir l'HWID del sistema i després es va iniciar el navegador i es va produir l'autorització. Per què es va fer això? En algunes empreses, el nombre d'usuaris atesos es compta de manera individual i el preu del servei per a cada mes es basa en el nombre de persones. Això és comprensible, dius, però per què està lligat al maquinari? És molt senzill, algunes persones van tornar a casa i van fer una sol·licitud des del seu ordinador portàtil de casa amb l'estil de "Fes que tot sigui bonic per a mi aquí". A més de llegir l'HWID del sistema, la utilitat va treure l'identificador de Teamviewer actual del registre i també ens el va transmetre. Teamviewer té una API per a la integració. I vam fer aquesta integració. Però hi havia una captura. Mitjançant aquestes API és impossible connectar-se a l'ordinador de l'usuari quan no inicia explícitament aquesta sessió i després d'intentar connectar-s'hi, també ha de fer clic a "confirmar". En aquell moment, ens va semblar lògic que ningú es connectés sense la petició de l'usuari, i com que la persona està a l'ordinador, iniciarà la sessió i respondrà afirmativament a la petició de connexió remota. Tot va sortir malament. Els sol·licitants es van oblidar de prémer per iniciar la sessió i ho van haver de dir en una conversa telefònica. Això va perdre temps i va ser frustrant per ambdues parts del procés. A més, no és gens estrany en aquests moments en què una persona deixa una sol·licitud, però només se li permet connectar-se quan surt a dinar. Perquè el problema no és crític i no vol que el seu procés laboral s'interrompi. En conseqüència, no prem cap botó per permetre la connexió. Així és com va aparèixer una funcionalitat addicional en iniciar sessió a HelpDesk: llegir l'identificador de Teamviwer. Sabíem la contrasenya permanent que s'utilitzava en instal·lar Teamviwer. Més precisament, només el sistema ho sabia, ja que estava integrat a l'instal·lador i al nostre sistema. En conseqüència, hi havia un botó de connexió de l'aplicació fent clic en el qual no calia esperar res, però Teamviewer es va obrir immediatament i es va produir una connexió. Com a resultat, hi havia dos tipus de connexions possibles. A través de l'API oficial de Teamviewer i la nostra pròpia. Per a la meva sorpresa, van deixar d'utilitzar el primer gairebé immediatament, tot i que hi havia una instrucció per utilitzar-lo només en casos especials i quan el propi usuari donava el vistiplau. Tot i així, dona'm seguretat ara. Però va resultar que els sol·licitants no ho necessitaven. Tots estan perfectament connectats amb ells sense un botó de confirmació.

Canviar a multithreading a Linux

La qüestió d'accelerar el pas d'un escàner de xarxa per a l'obertura d'una llista predeterminada de ports i un simple ping als objectes de xarxa fa temps que comença a sorgir. Aquí, per descomptat, la primera solució que em ve al cap és el multithreading. Com que el temps principal dedicat al ping és esperar que es torni el paquet i el següent ping no pot començar fins que no es retorni el paquet anterior, a les empreses que fins i tot tenen més de 20 servidors més equips de xarxa això ja funcionava bastant lentament. La qüestió és que un paquet pot desaparèixer, però no ho notifiqueu immediatament a l'administrador del sistema. Simplement deixarà d'acceptar aquest correu brossa molt ràpidament. Això vol dir que heu de fer ping a cada objecte més d'una vegada abans de treure una conclusió sobre la inaccessibilitat. Sense entrar en massa detalls, cal paral·lelitzar-lo perquè, si no es fa, el més probable és que l'administrador del sistema s'assabentarà del problema del client i no del sistema de supervisió.

PHP en si no admet multithreading des de la caixa. Capaç de multiprocessament, podeu bifurcar. Però, de fet, ja tenia escrit un mecanisme d'enquesta i volia fer-ho de manera que una vegada comptaria tots els nodes que necessitava de la base de dades, fer ping tot alhora, esperar una resposta de cadascun i només després escriure immediatament. les dades. Això estalvia el nombre de sol·licituds de lectura. El multithreading encaixa perfectament en aquesta idea. Per a PHP hi ha un mòdul PThreads que us permet fer multithreading real, tot i que va necessitar una bona quantitat de retocs per configurar-ho a PHP 7.2, però es va fer. L'exploració de ports i el ping ara són ràpids. I en comptes de, per exemple, 15 segons per volta abans, aquest procés va començar a trigar 2 segons. Va ser un bon resultat.

Auditoria ràpida de noves empreses

Com va sorgir la funcionalitat per recopilar diverses mètriques i característiques de maquinari? És fàcil. De vegades, simplement se'ns demana auditar la infraestructura informàtica actual. Bé, el mateix és necessari per accelerar l'auditoria d'un nou client. Necessitàvem alguna cosa que ens permetés arribar a una empresa mitjana o gran i esbrinar ràpidament què tenen. Al meu entendre, el ping a la xarxa interna només està bloquejat per aquells que volen complicar-se la vida, i segons la nostra experiència n'hi ha pocs. Però també hi ha gent així. En conseqüència, podeu escanejar ràpidament les xarxes per detectar la presència de dispositius amb un simple ping. Després els podem afegir i buscar els ports oberts que ens interessin. De fet, aquesta funcionalitat ja existia; només calia afegir una ordre del servidor central a l'esclau perquè escanegés les xarxes especificades i afegeixi tot el que trobés a la llista. Em vaig oblidar d'esmentar, es va suposar que ja teníem una imatge preparada amb un sistema configurat (servidor de monitorització esclau) que podríem simplement desplegar des del client durant una auditoria i connectar-la al nostre núvol.

Però el resultat d'una auditoria sol incloure un munt d'informació diferent, i una d'elles és quin tipus de dispositius hi ha a la xarxa. En primer lloc, ens interessaven els servidors i les estacions de treball Windows com a part d'un domini. Ja que a les mitjanes i grans empreses la manca de domini és probablement una excepció a la regla. Per parlar una llengua, la mitjana, al meu entendre, és de més de 100 persones. Va ser necessari trobar una manera de recollir dades de totes les màquines i servidors Windows, coneixent la seva IP i el compte d'administrador del domini, però sense instal·lar cap programari en cadascun d'ells. La interfície WMI ve al rescat. Windows Management Instrumentation (WMI) significa literalment eines de gestió de Windows. WMI és una de les tecnologies bàsiques per a la gestió centralitzada i el seguiment del funcionament de diverses parts de la infraestructura informàtica que executa la plataforma Windows. Tret de la wiki. A continuació, vaig haver de tornar a retocar per compilar wmic (aquest és un client WMI) per a Debian. Després que tot estigués a punt, només quedava enquestar els nodes necessaris mitjançant wmic per obtenir la informació necessària. Mitjançant WMI podeu obtenir gairebé qualsevol informació d'un ordinador Windows i, a més, també podeu controlar l'ordinador a través d'ell, per exemple, enviar-lo per reiniciar-lo. Així va aparèixer la recopilació d'informació sobre estacions i servidors Windows del nostre sistema. A més d'això, hi havia informació actual sobre els indicadors actuals de càrrega del sistema. Els demanem més sovint, i la informació sobre el maquinari amb menys freqüència. Després d'això, l'auditoria es va fer una mica més agradable.

Decisió de distribució de programari

Nosaltres mateixos utilitzem el sistema cada dia, i sempre està obert per a tots els empleats tècnics. I vam pensar que podríem compartir amb els altres allò que ja tenim. El sistema encara no estava preparat per ser distribuït. Es va haver de reelaborar molt perquè la versió local es convertís en SaaS. Aquests inclouen canvis en diversos aspectes tècnics del sistema (connexions remotes, servei de suport), anàlisi de mòduls per a la concessió de llicències, fragmentació de bases de dades de clients, escalat de cada servei i desenvolupament de sistemes d'actualització automàtica per a totes les parts. Però aquesta serà la segona part de l'article.

Actualitzar

Segona part

Font: www.habr.com