De la subcontratación al desarrollo (Parte 1)

Hola a todos, mi nombre es Sergey Emelyanchik. Soy el director de la empresa Audit-Telecom, principal desarrollador y autor del sistema Veliam. Decidí escribir un artículo sobre cómo mi amigo y yo creamos una empresa de subcontratación, escribimos software para nosotros y posteriormente comenzamos a distribuirlo a todos a través del sistema SaaS. Sobre cómo categóricamente no creía que esto fuera posible. El artículo contendrá no sólo una historia, sino también detalles técnicos de cómo se creó el producto Veliam. Incluyendo algunas piezas de código fuente. Te diré qué errores cometimos y cómo los corregimos más tarde. Había dudas sobre si publicar un artículo de este tipo. Pero pensé que era mejor hacerlo, recibir feedback y mejorar, que no publicar el artículo y pensar en qué hubiera pasado si...

Prehistoria

Trabajé en una empresa como empleado de TI. La empresa era bastante grande con una extensa estructura de red. No me detendré en mis responsabilidades laborales, solo diré que definitivamente no incluían el desarrollo de nada.

Tuvimos seguimiento, pero por puro interés académico quería intentar escribir el más simple. La idea era la siguiente: quería que estuviera en la web, para poder entrar fácilmente sin instalar ningún cliente y ver qué estaba pasando con la red desde cualquier dispositivo, incluido un dispositivo móvil a través de Wi-Fi, y también realmente Quería entender rápidamente qué hay equipo en la habitación que se ha vuelto "deprimido" porque... Había requisitos muy estrictos en cuanto al tiempo de respuesta a tales problemas. Como resultado, nació en mi cabeza el plan de escribir una página web simple en la que hubiera un fondo jpeg con un diagrama de red, recortar los dispositivos con sus direcciones IP en esta imagen y mostrar contenido dinámico encima. imagen en las coordenadas requeridas en forma de dirección IP verde o roja parpadeante. La tarea ha sido establecida, comencemos.

Anteriormente estaba programando en Delphi, PHP, JS y muy superficialmente C++. Sé bastante bien cómo funcionan las redes. VLAN, enrutamiento (OSPF, EIGRP, BGP), NAT. Esto fue suficiente para que yo mismo escribiera un prototipo de monitoreo primitivo.

Escribí lo que planeé en PHP. El servidor Apache y PHP estaba en Windows porque... Linux para mí en ese momento era algo incomprensible y muy complejo, como resultó más tarde, estaba muy equivocado y en muchos lugares Linux es mucho más simple que Windows, pero este es un tema aparte y todos sabemos cuántos holívares hay en este tema. El programador de tareas de Windows extraía en un pequeño intervalo (no recuerdo exactamente, pero aproximadamente una vez cada tres segundos) un script PHP que sondeaba todos los objetos con un ping banal y guardaba el estado en un archivo.

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

Sí, sí, trabajar con una base de datos en ese momento tampoco lo dominaba. No sabía que era posible paralelizar procesos, y recorrer todos los nodos de la red tomó mucho tiempo, porque... esto sucedió en un hilo. Los problemas surgían especialmente cuando varios nodos no estaban disponibles, porque cada uno de ellos retrasó el guión 300 ms. En el lado del cliente había una función de bucle simple que, a intervalos de unos segundos, descargaba información actualizada del servidor con una solicitud Ajax y actualizaba la interfaz. Bueno, entonces, después de 3 pings fallidos seguidos, si se abría una página web con monitoreo en la computadora, se reproducía una composición alegre.

Cuando todo salió bien, me inspiré mucho con el resultado y pensé que podía agregarle más (debido a mis conocimientos y capacidades). Pero siempre no me gustaron los sistemas con un millón de gráficos, que entonces pensé, y sigo pensando hasta el día de hoy, son innecesarios en la mayoría de los casos. Quería incluir allí sólo lo que realmente me ayudaría en mi trabajo. Este principio sigue siendo fundamental para el desarrollo de Veliam hasta el día de hoy. Además, me di cuenta de que sería genial si no tuviera que mantener abierto el monitoreo y conocer los problemas, y cuando sucediera, abrir la página y ver dónde se encuentra este nodo de red problemático y qué hacer con él a continuación. . De alguna manera no leía el correo electrónico en aquel entonces, simplemente no lo usaba. Descubrí en Internet que existen pasarelas de SMS a las que puedes enviar una solicitud GET o POST, y enviarán un SMS a mi teléfono móvil con el texto que escribo. Inmediatamente me di cuenta de que realmente quería esto. Y comencé a estudiar la documentación. Después de un tiempo lo logré y ahora recibí en mi teléfono móvil un SMS sobre problemas en la red con el nombre de un “objeto caído”. Aunque el sistema era primitivo, lo escribí yo mismo y lo más importante que me motivó a desarrollarlo fue que era un programa de aplicación que realmente me ayudó en mi trabajo.

Y luego llegó el día en que uno de los canales de Internet se cayó en el trabajo y mi seguimiento no me avisó. Dado que el DNS de Google todavía hacía ping perfectamente. Es hora de pensar en cómo controlar que el canal de comunicación esté vivo. Hubo diferentes ideas sobre cómo hacer esto. No tuve acceso a todo el equipo. Tuvimos que descubrir cómo entender cuál de los canales está en vivo, pero sin poder verlo de alguna manera en el equipo de red. Entonces a un colega se le ocurrió la idea de que es posible que el seguimiento de la ruta a los servidores públicos difiera según el canal de comunicación que se utilice actualmente para acceder a Internet. Lo revisé y resultó así. Había diferentes rutas a la hora de rastrear.

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

Entonces apareció otro script, o mejor dicho, por alguna razón se agregó un rastro al final del mismo script, que hizo ping a todos los dispositivos en la red. Después de todo, este es otro proceso largo que se ejecutó en el mismo hilo y ralentizó el trabajo de todo el script. Pero entonces no fue tan obvio. Pero de una forma u otra hizo su trabajo, el código definía estrictamente qué tipo de seguimiento debía ser para cada uno de los canales. Así comenzó a funcionar el sistema, que ya monitoreaba (dicho en voz alta, porque no se recopilaban métricas, solo ping) los dispositivos de red (enrutadores, conmutadores, wi-fi, etc.) y los canales de comunicación con el mundo exterior. . Los mensajes SMS llegaban regularmente y el diagrama siempre mostraba claramente dónde estaba el problema.

Además, en el trabajo diario tenía que hacer cruces. Y me cansé de ir cada vez a los conmutadores de Cisco para ver qué interfaz usar. Qué genial sería hacer clic en un objeto en el seguimiento y ver una lista de sus interfaces con descripciones. Me ahorraría tiempo. Además, en este esquema no habría necesidad de ejecutar Putty o SecureCRT para ingresar cuentas y comandos. Simplemente hice clic en el monitoreo, vi lo que necesitaba y fui a hacer mi trabajo. Empecé a buscar formas de interactuar con los interruptores. Inmediatamente encontré 2 opciones: SNMP o iniciar sesión en el conmutador a través de SSH, ingresar los comandos que necesitaba y analizar el resultado. Descarté SNMP debido a la complejidad de su implementación; estaba impaciente por obtener el resultado. con SNMP, habría que profundizar mucho tiempo en la MIB y, basándose en estos datos, generar datos sobre las interfaces. Hay un equipo maravilloso en CISCO

show interface status

Muestra exactamente lo que necesito para los cruces. ¿Por qué molestarme con SNMP cuando sólo quiero ver el resultado de este comando?, pensé. Después de un tiempo, me di cuenta de esta oportunidad. Se hizo clic en un objeto en una página web. Se desencadenó un evento mediante el cual el cliente AJAX se puso en contacto con el servidor y este, a su vez, se conectó a través de SSH al conmutador que necesitaba (las credenciales estaban codificadas en el código, no había ningún deseo de refinarlo, de crear algunos menús separados donde sería posible cambiar de cuenta desde la interfaz, necesitaba el resultado y rápidamente) Ingresé el comando anterior allí y lo envié de regreso al navegador. Entonces comencé a ver información sobre interfaces con un clic del mouse. Esto fue extremadamente conveniente, especialmente cuando tenía que ver esta información en diferentes conmutadores a la vez.

La monitorización de canales basada en seguimiento acabó no siendo la mejor idea, porque... A veces se trabajaba en la red, y el rastreo podía cambiar y el seguimiento empezó a gritarme que había problemas con el canal. Pero después de dedicar mucho tiempo al análisis, me di cuenta de que todos los canales estaban funcionando y mi seguimiento me engañaba. Como resultado, les pedí a mis colegas que administraban conmutadores de formación de canales que simplemente me enviaran syslog cuando cambiara el estado de visibilidad de los vecinos. En consecuencia, era mucho más sencillo, rápido y preciso que el rastreo. Ha llegado un evento como vecino perdido e inmediatamente envío una notificación sobre el canal inactivo.

Además, aparecieron varios comandos más al hacer clic en un objeto y se agregó SNMP para recopilar algunas métricas, y eso es básicamente todo. El sistema nunca se desarrolló más. Hizo todo lo que necesitaba, fue una buena herramienta. Probablemente muchos lectores me dirán que ya existe mucho software en Internet para solucionar estos problemas. Pero, de hecho, en ese entonces no buscaba en Google este tipo de productos gratuitos y tenía muchas ganas de desarrollar mis habilidades de programación, y qué mejor manera de impulsar esto que con un problema de aplicación real. En este punto, la primera versión del monitoreo se completó y ya no se modificó.

Creación de la empresa Audit-Telecom

Con el paso del tiempo comencé a trabajar a tiempo parcial en otras empresas, afortunadamente mi horario de trabajo me lo permitió. Cuando trabajas en diferentes empresas, tus habilidades en diversas áreas crecen muy rápidamente y tus horizontes se desarrollan bien. Hay empresas en las que, como dicen, eres sueco, segador y trompetista. Por un lado, es difícil, por otro lado, si no eres vago, te vuelves generalista y esto te permite resolver problemas de manera más rápida y eficiente porque sabes cómo funciona el campo relacionado.

Mi amigo Pavel (también informático) intentaba constantemente animarme a iniciar su propio negocio. Había innumerables ideas con diferentes variaciones de lo que estaban haciendo. Esto se ha discutido durante años. Y al final no debería haber llegado a nada porque yo soy un escéptico y Pavel es un soñador. Cada vez que me proponía una idea, yo no creía en ella y me negaba a participar. Pero realmente queríamos abrir nuestro propio negocio.

Finalmente pudimos encontrar una opción que nos convenía a ambos y hacer lo que sabemos hacer. En 2016, decidimos crear una empresa de TI que ayudaría a las empresas a resolver problemas de TI. Se trata del despliegue de sistemas informáticos (1C, servidor de terminal, servidor de correo, etc.), su mantenimiento, el clásico HelpDesk para usuarios y administración de redes.

Francamente, en el momento de crear la empresa, no creía en ella en un 99,9%. Pero de alguna manera Pavel logró que lo intentara y, mirando hacia el futuro, resultó que tenía razón. Pavel y yo aportamos 300 rublos cada uno, registramos una nueva LLC "Audit-Telecom", alquilamos una pequeña oficina, hicimos tarjetas de presentación geniales, bueno, en general, como probablemente la mayoría de los empresarios novatos e inexpertos, y comenzamos a buscar clientes. Encontrar clientes es una historia completamente diferente. Quizás escribamos un artículo aparte como parte del blog corporativo si alguien está interesado. Llamadas en frío, folletos, etc. Esto no dio ningún resultado. Como leo ahora en muchas historias sobre negocios, de una forma u otra, mucho depende de la suerte. Fuimos suertudos. Y literalmente, un par de semanas después de la creación de la empresa, se nos acercó mi hermano Vladimir, quien nos trajo el primer cliente. No los aburriré con los detalles del trabajo con clientes, de eso no se trata el artículo, solo diré que fuimos a una auditoría, identificamos áreas críticas y estas áreas fallaron mientras se tomaba la decisión sobre si cooperan con nosotros de forma continua como subcontratistas. Después de esto, inmediatamente se tomó una decisión positiva.

Luego, principalmente a través del boca a boca a través de amigos, comenzaron a aparecer otras empresas de servicios. El servicio de asistencia técnica estaba en un solo sistema. Las conexiones a equipos y servidores de red son diferentes, o más bien diferentes. Algunas personas guardaron accesos directos, otras usaron libretas de direcciones RDP. El seguimiento es otro sistema independiente. Es muy inconveniente para un equipo trabajar en sistemas dispares. Se pierde de vista información importante. Bueno, por ejemplo, el servidor terminal del cliente dejó de estar disponible. Las solicitudes de los usuarios de este cliente se reciben inmediatamente. El especialista de soporte abre una solicitud (se recibió por teléfono). Si los incidentes y solicitudes se registraran en un sistema, el especialista de soporte vería inmediatamente cuál es el problema del usuario y se lo informaría, al mismo tiempo que se conectaría al objeto requerido para resolver la situación. Todos conocen la situación táctica y trabajan en armonía. No hemos encontrado un sistema donde se combine todo esto. Quedó claro que había llegado el momento de fabricar nuestro propio producto.

Trabajo continuo en su sistema de monitoreo

Estaba claro que el sistema escrito anteriormente era completamente inadecuado para las tareas actuales. Ni en términos de funcionalidad ni en términos de calidad. Y se decidió escribir el sistema desde cero. Gráficamente debería haberse visto completamente diferente. Tenía que ser un sistema jerárquico para que fuera posible abrir rápida y cómodamente el objeto adecuado para el cliente adecuado. El esquema, como en la primera versión, no estaba en absoluto justificado en el caso actual, porque Los clientes son diferentes y no importa en absoluto en qué local se encuentre el equipo. Esto ya ha sido transferido a la documentación.

Entonces las tareas son:

1. Estructura jerarquica;
2. Una especie de parte del servidor que se puede colocar en las instalaciones del cliente en forma de máquina virtual para recopilar las métricas que necesitamos y enviarlas al servidor central, que resumirá todo esto y nos lo mostrará;
3. Alertas. Esas que no pueden faltar, porque... en ese momento no era posible que alguien se sentara y simplemente mirara el monitor;
4. Sistema de aplicación. Comenzaron a aparecer clientes a quienes atendíamos no solo servidores y equipos de red, sino también estaciones de trabajo;
5. Capacidad para conectarse rápidamente a servidores y equipos del sistema;

Se han planteado las tareas, comenzamos a escribir. En el camino, procesando solicitudes de clientes. En ese momento ya éramos 4. Empezamos a escribir ambas partes a la vez: el servidor central y el servidor para la instalación en los clientes. En este punto, Linux ya no era un extraño para nosotros y se decidió que las máquinas virtuales que tendrían los clientes estarían en Debian. No habrá instaladores, simplemente crearemos un proyecto de parte del servidor en una máquina virtual específica y luego lo clonaremos en el cliente deseado. Este fue otro error. Más tarde quedó claro que en tal esquema el mecanismo de actualización estaba completamente subdesarrollado. Aquellos. Estábamos agregando alguna característica nueva y luego estaba todo el problema de distribuirla a todos los servidores del cliente, pero volveremos a esto más adelante, todo en orden.

Hicimos el primer prototipo. Pudo hacer ping a los dispositivos y servidores de red del cliente que necesitábamos y enviar estos datos a nuestro servidor central. Y él, a su vez, actualizó estos datos de forma masiva en el servidor central. Aquí escribiré no sólo una historia sobre cómo y qué tuvo éxito, sino también qué errores de aficionado se cometieron y cómo luego tuve que pagar por ello con el tiempo. Entonces, todo el árbol de objetos se almacenó en un solo archivo en forma de objeto serializado. Mientras conectamos varios clientes al sistema, todo fue más o menos normal, aunque en ocasiones había algunos artefactos que eran completamente incomprensibles. Pero cuando conectamos una docena de servidores al sistema, empezaron a ocurrir milagros. A veces, por alguna razón desconocida, todos los objetos del sistema simplemente desaparecían. Es importante tener en cuenta aquí que los servidores que tenían los clientes enviaban datos al servidor central cada pocos segundos a través de una solicitud POST. Un lector atento y un programador experimentado ya han adivinado que existe un problema de acceso múltiple al mismo archivo en el que se almacena el objeto serializado desde diferentes subprocesos al mismo tiempo. Y justo cuando esto sucedía, se produjo el milagro con la desaparición de objetos. El archivo simplemente quedó vacío. Pero todo esto no se descubrió de inmediato, sino sólo durante el funcionamiento con varios servidores. Durante este tiempo, se agregó la funcionalidad de escaneo de puertos (los servidores enviaban a la central no solo información sobre la disponibilidad de los dispositivos, sino también sobre los puertos abiertos en ellos). Esto se hizo llamando al comando:

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

los resultados a menudo eran incorrectos y los escaneos tardaban mucho en completarse. Me olvidé por completo del ping, se hizo mediante fping:

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

Esto tampoco fue paralelizado y por lo tanto el proceso fue muy largo. Más tarde, la lista completa de direcciones IP requeridas para la verificación se envió a fping de inmediato, y de regreso recibimos una lista preparada de quienes respondieron. A diferencia de nosotros, fping pudo paralelizar procesos.

Otro trabajo rutinario común era configurar algunos servicios vía WEB. Bueno, por ejemplo, ECP de MS Exchange. Básicamente es sólo un enlace. Y decidimos que necesitamos poder agregar dichos enlaces directamente al sistema, para no tener que buscar en la documentación o en algún otro lugar de los marcadores cómo acceder al ECP de un cliente específico. Así surgió el concepto de enlaces de recursos para el sistema, su funcionalidad está disponible hasta el día de hoy y no ha cambiado, bueno, casi.

Cómo funcionan los enlaces de recursos en Veliam

Conexiones remotas

Así es como se ve en acción en la versión actual de Veliam

Una de las tareas era conectarse rápida y cómodamente a servidores, de los cuales ya había muchos (más de cien) y clasificar millones de accesos directos RDP guardados previamente era extremadamente inconveniente. Se necesitaba una herramienta. Hay software en Internet que es algo así como una libreta de direcciones para este tipo de conexiones RDP, pero no están integrados con el sistema de monitoreo y las cuentas no se pueden guardar. Ingresar cuentas para diferentes clientes cada vez es un infierno cuando te conectas decenas de veces al día a diferentes servidores. Con SSH las cosas van un poco mejor, hay muchos buenos programas que te permiten organizar dichas conexiones en carpetas y recordar las cuentas de ellas. Pero hay 2 problemas. La primera es que no encontramos ni un solo programa para conexiones RDP y SSH. La segunda es que si en algún momento no estoy en mi computadora y necesito conectarme rápidamente, o simplemente reinstalé el sistema, tendré que entrar en la documentación para mirar la cuenta de este cliente. Es un inconveniente y una pérdida de tiempo.

La estructura jerárquica que necesitábamos para los servidores del cliente ya estaba disponible en nuestro producto interno. Sólo tenía que descubrir cómo conectar conexiones rápidas al equipo necesario allí. Para empezar, al menos dentro de su red.

Teniendo en cuenta que el cliente en nuestro sistema era un navegador que no tiene acceso a los recursos locales de la computadora, para simplemente ejecutar la aplicación que necesitábamos con algún comando, se inventó hacer todo a través del menú "Windows". esquema de URL personalizado”. Así apareció un determinado "complemento" para nuestro sistema, que simplemente incluía Putty y Remote Desktop Plus y, durante la instalación, simplemente registraba el esquema URI en Windows. Ahora, cuando queríamos conectarnos a un objeto a través de RDP o SSH, hacíamos clic en esta acción en nuestro sistema y el URI personalizado funcionó. Se lanzó el estándar mstsc.exe integrado en Windows o PuTTY, que formaba parte del "complemento". Puse la palabra complemento entre comillas porque no es un complemento de navegador en el sentido clásico.

Al menos eso era algo. Cómoda libreta de direcciones. Además, en el caso de Putty, en general, todo estaba bien; se le podían dar conexiones IP, nombre de usuario y contraseña como parámetros de entrada. Aquellos. Ya nos hemos conectado a servidores Linux de nuestra red con un clic sin introducir contraseñas. Pero con RDP no es tan sencillo. El mstsc estándar no puede proporcionar credenciales como parámetros. Remote Desktop Plus vino al rescate. Él permitió que esto sucediera. Ahora podemos prescindir de él, pero durante mucho tiempo fue un fiel asistente en nuestro sistema. Con los sitios HTTP(S) todo es sencillo, dichos objetos simplemente se abren en el navegador y listo. Cómodo y práctico. Pero ésta era la felicidad sólo en la red interna.

Dado que resolvimos la gran mayoría de los problemas de forma remota desde la oficina, lo más fácil fue poner las VPN a disposición de los clientes. Y luego fue posible conectarse a ellos desde nuestro sistema. Pero todavía era algo inconveniente. Para cada cliente, era necesario mantener un montón de conexiones VPN recordadas en cada computadora, y antes de conectarse a cualquiera, era necesario habilitar la VPN correspondiente. Usamos esta solución durante bastante tiempo. Pero el número de clientes está aumentando, el número de VPN también está aumentando, y todo esto empezó a ser tenso y había que hacer algo al respecto. Se me llenaron los ojos de lágrimas especialmente después de reinstalar el sistema, cuando tuve que volver a ingresar docenas de conexiones VPN en un nuevo perfil de Windows. Deja de soportar esto, dije, y comencé a pensar en qué podía hacer al respecto.

Dio la casualidad de que todos los clientes tenían como enrutadores dispositivos de la conocida empresa Mikrotik. Son muy funcionales y convenientes para realizar casi cualquier tarea. La desventaja es que están “secuestrados”. Solucionamos este problema simplemente cerrando todo acceso desde el exterior. Pero era necesario de alguna manera tener acceso a ellos sin tener que ir a casa del cliente, porque... es largo. Simplemente hicimos túneles para cada Mikrotik y los separamos en un grupo separado. sin ningún enrutamiento, de modo que no haya conexión de su red con las redes de los clientes y sus redes entre sí.

La idea nació para asegurar que cuando hago clic en el objeto que necesito en el sistema, el servidor de monitoreo central, conociendo las cuentas SSH de todos los clientes Mikrotik, se conecta al objeto deseado, crea una regla de reenvío al host deseado con el puerto requerido. Hay varios puntos aquí. La solución no es universal: solo funcionará para Mikrotik, ya que la sintaxis del comando es diferente para todos los enrutadores. Además, dichos reenvíos tenían que eliminarse de alguna manera, y la parte del servidor de nuestro sistema esencialmente no podía rastrear de ninguna manera si había terminado mi sesión RDP. Bueno, ese reenvío es un agujero para el cliente. Pero no perseguimos la universalidad, porque... El producto se utilizó únicamente dentro de nuestra empresa y no se pensó en lanzarlo al público.

Cada uno de los problemas se resolvió a su manera. Cuando se creó la regla, este reenvío estaba disponible solo para una dirección IP externa específica (desde la cual se inicializó la conexión). Así se evitó un agujero de seguridad. Pero con cada conexión de este tipo, se agregaba una regla de Mikrotik a la página NAT y no se borraba. Y todo el mundo sabe que cuantas más reglas haya, más se cargará el procesador del router. Y, en general, no podía aceptar que algún día iría a algún Mikrotik y habría cientos de reglas muertas e inútiles.

Dado que nuestro servidor no puede rastrear el estado de la conexión, deje que Mikrotik los rastree él mismo. Y escribí un script que monitoreaba constantemente todas las reglas de reenvío con una descripción específica y verificaba si la conexión TCP tenía una regla adecuada. Si hace algún tiempo que no hay ninguna, probablemente la conexión ya se haya completado y este reenvío se pueda eliminar. Todo salió bien, el guión funcionó bien.

Por cierto, 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
	}
}

Seguramente se podría haber hecho más bonito, más rápido, etc., pero funcionó, no cargó Mikrotik e hizo un excelente trabajo. Finalmente pudimos conectarnos a los servidores y equipos de red de los clientes con solo un clic. Sin abrir una VPN ni ingresar contraseñas. Se ha vuelto realmente cómodo trabajar con el sistema. El tiempo de servicio se redujo y todos pasamos tiempo trabajando en lugar de conectarnos a los objetos necesarios.

Copia de seguridad de Microtik

Configuramos la copia de seguridad de todos los Mikrotik a FTP. Y en general todo estuvo bien. Pero cuando necesitabas obtener una copia de seguridad, tenías que abrir este FTP y buscarla allí. Tenemos un sistema donde están conectados todos los routers, podemos comunicarnos con los dispositivos vía SSH. ¿Por qué no hacemos que el propio sistema realice copias de seguridad de todos los Mikrotik diariamente?, pensé. Y comenzó a implementarlo. Nos conectamos, hicimos una copia de seguridad y la guardamos.

Código de script en PHP para realizar una copia de seguridad 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 copia de seguridad se realiza de dos formas: configuración binaria y de texto. El binario ayuda a restaurar rápidamente la configuración requerida, y el de texto le permite comprender qué se debe hacer si hay un reemplazo forzado del equipo y no se puede cargar el binario. Como resultado, obtuvimos otra funcionalidad conveniente en el sistema. Además, al agregar un nuevo Mikrotik, no hubo necesidad de configurar nada; simplemente agregué el objeto al sistema y configuré una cuenta para él a través de SSH. Luego, el propio sistema se encargó de realizar las copias de seguridad. La versión actual de SaaS Veliam aún no tiene esta funcionalidad, pero la adaptaremos pronto.

Capturas de pantalla de cómo se veía en el sistema interno.

Transición al almacenamiento de base de datos normal

Ya escribí arriba que aparecieron artefactos. A veces, la lista completa de objetos en el sistema simplemente desaparecía, a veces, al editar un objeto, la información no se guardaba y era necesario cambiar el nombre del objeto tres veces. Esto irritó terriblemente a todos. La desaparición de objetos ocurría raramente y se recuperaba fácilmente restaurando este mismo archivo, pero los fallos al editar objetos ocurrían con bastante frecuencia. Probablemente, inicialmente no hice esto a través de la base de datos porque no entendía cómo era posible mantener un árbol con todas las conexiones en una mesa plana. Es plano, pero el árbol es jerárquico. Pero una buena solución para el acceso múltiple y posteriormente (a medida que el sistema se vuelve más complejo) transaccional es un DBMS. Probablemente no soy el primero en encontrar este problema. Empecé a buscar en Google. Resultó que todo ya estaba inventado antes que yo y hay varios algoritmos que construyen un árbol a partir de una mesa plana. Después de mirar cada uno, implementé uno de ellos. Pero esta ya era una nueva versión del sistema, porque... De hecho, debido a esto, tuve que reescribir bastante. El resultado fue natural, los problemas de comportamiento aleatorio del sistema desaparecieron. Algunos podrían decir que los errores son muy amateurs (scripts de un solo subproceso, almacenamiento de información a la que se accedió varias veces simultáneamente desde diferentes subprocesos en un archivo, etc.) en el campo del desarrollo de software. Tal vez esto sea cierto, pero mi trabajo principal era la administración, y la programación era una actividad secundaria para mi alma, y ​​​​simplemente no tenía experiencia trabajando en un equipo de programadores, donde mi superior me habría sugerido de inmediato cosas tan básicas. camaradas. Por lo tanto, llené todos estos baches por mi cuenta, pero aprendí muy bien el material. Y además mi trabajo implica reuniones con clientes, acciones encaminadas a intentar promocionar la empresa, un montón de cuestiones administrativas dentro de la empresa y mucho, mucho más. Pero de una forma u otra, lo que ya existía tenía demanda. Los chicos y yo utilizamos el producto en nuestro trabajo diario. Hubo ideas y soluciones francamente fallidas en las que se perdió el tiempo, pero al final quedó claro que no era una herramienta de trabajo y nadie la utilizó y no acabó en Veliam.

Mesa de ayuda - Mesa de ayuda

No estaría de más mencionar cómo se formó HelpDesk. Esta es una historia completamente diferente, porque... En Veliam esta ya es la tercera versión completamente nueva, que se diferencia de todas las anteriores. Ahora es un sistema simple, intuitivo y sin lujos innecesarios, con la capacidad de integrarse con un dominio, así como la capacidad de acceder al mismo perfil de usuario desde cualquier lugar mediante un enlace de un correo electrónico. Y lo más importante, es posible conectarse con el solicitante a través de VNC desde cualquier lugar (en casa o en la oficina) directamente desde la aplicación sin VPN ni reenvío de puertos. Te diré cómo llegamos a esto, qué pasó antes y qué terribles decisiones se tomaron.

Nos conectamos con los usuarios a través del conocido TeamViewer. Todas las computadoras a cuyos usuarios atendemos tienen TV instalada. Lo primero que hicimos mal, y posteriormente lo eliminamos, fue vincular cada cliente HD al hardware. ¿Cómo inició sesión el usuario en el sistema HD para dejar una solicitud? Además de la televisión, todos tenían una utilidad especial instalada en sus computadoras, escrita en Lazarus (muchas personas aquí pondrán los ojos en blanco y tal vez incluso buscarán en Google qué es, pero el mejor lenguaje compilado que conocía era Delphi, y Lazarus es casi lo mismo, solo que gratis). En general, el usuario inicia un archivo por lotes especial que inicia esta utilidad, que a su vez lee el HWID del sistema y luego se inicia el navegador y se produce la autorización. ¿Por qué se hizo esto? En algunas empresas, la cantidad de usuarios atendidos se cuenta individualmente y el precio del servicio para cada mes se basa en la cantidad de personas. Esto es comprensible, dirás, pero ¿por qué está ligado al hardware? Muy simple, algunas personas llegaron a casa e hicieron una solicitud desde la computadora portátil de su casa al estilo de "haz que todo sea hermoso para mí aquí". Además de leer el HWID del sistema, la utilidad extrajo el ID actual de Teamviewer del registro y también nos lo transmitió. Teamviewer tiene una API para la integración. Y hicimos esta integración. Pero había un inconveniente. A través de estas API, es imposible conectarse a la computadora del usuario cuando este no inicia explícitamente esta sesión y luego de intentar conectarse a ella, también debe hacer clic en “confirmar”. En ese momento nos parecía lógico que nadie se conectara sin la petición del usuario, y como la persona está frente al ordenador, iniciará la sesión y responderá afirmativamente a la petición de conexión remota. Todo salió mal. Los solicitantes olvidaron presionar iniciar sesión y tuvieron que comunicárselo en una conversación telefónica. Esto fue una pérdida de tiempo y fue frustrante para ambos lados del proceso. Además, no es nada raro que en esos momentos una persona deje una solicitud, pero solo se le permite conectarse cuando sale a almorzar. Porque el problema no es crítico y no quiere que se interrumpa su proceso de trabajo. En consecuencia, no presionará ningún botón para permitir la conexión. Así es como apareció una funcionalidad adicional al iniciar sesión en HelpDesk: leer el ID de Teamviwer. Sabíamos la contraseña permanente que se utilizó al instalar Teamviwer. Más precisamente, sólo el sistema lo sabía, ya que estaba integrado en el instalador y en nuestro sistema. En consecuencia, había un botón de conexión de la aplicación, al hacer clic en el cual no era necesario esperar nada, pero Teamviewer se abrió inmediatamente y se produjo una conexión. Como resultado, había dos tipos de conexiones posibles. A través de la API oficial de Teamviewer y la nuestra propia. Para mi sorpresa, dejaron de utilizar el primero casi de inmediato, aunque había una instrucción de utilizarlo sólo en casos especiales y cuando el propio usuario dé el visto bueno. Aún así, dame seguridad ahora. Pero resultó que los solicitantes no lo necesitaban. Todos están absolutamente bien con estar conectados a ellos sin un botón de confirmación.

Cambiar a subprocesos múltiples en Linux

Hace tiempo que ha comenzado a surgir la cuestión de acelerar el paso de un escáner de red para abrir una lista predeterminada de puertos y realizar un simple ping a los objetos de la red. Aquí, por supuesto, la primera solución que me viene a la mente es el subproceso múltiple. Dado que el tiempo principal dedicado al ping es esperar a que se devuelva el paquete, y el siguiente ping no puede comenzar hasta que se devuelva el paquete anterior, en empresas que incluso tenían más de 20 servidores más equipos de red, esto ya funcionaba con bastante lentitud. El punto es que un paquete puede desaparecer, pero no notifique inmediatamente al administrador del sistema. Simplemente dejará de aceptar ese tipo de spam muy rápidamente. Esto significa que debe hacer ping a cada objeto más de una vez antes de llegar a una conclusión sobre la inaccesibilidad. Sin entrar en demasiados detalles, es necesario paralelizarlo porque si no se hace esto, lo más probable es que el administrador del sistema se entere del problema a través del cliente y no del sistema de monitoreo.

PHP en sí no admite subprocesos múltiples de fábrica. Capaz de multiprocesamiento, puede bifurcarse. Pero, de hecho, ya tenía un mecanismo de sondeo escrito y quería hacerlo de modo que una vez contara todos los nodos que necesitaba de la base de datos, hiciera ping a todo a la vez, esperara una respuesta de cada uno y solo después de eso escribiera inmediatamente. los datos. Esto ahorra en la cantidad de solicitudes de lectura. El multiproceso encaja perfectamente en esta idea. Para PHP hay un módulo PThreads que le permite realizar subprocesos múltiples reales, aunque tomó bastantes retoques para configurar esto en PHP 7.2, pero ya estaba hecho. El escaneo de puertos y el ping ahora son rápidos. Y en lugar de, por ejemplo, 15 segundos por vuelta antes, este proceso empezó a tardar 2 segundos. Fue un buen resultado.

Auditoría rápida de nuevas empresas.

¿Cómo surgió la funcionalidad para recopilar diversas métricas y características de hardware? Es sencillo. A veces simplemente nos ordenan auditar la infraestructura de TI actual. Pues lo mismo es necesario para acelerar la auditoría de un nuevo cliente. Necesitábamos algo que nos permitiera llegar a una empresa mediana o grande y descubrir rápidamente lo que tienen. En mi opinión, el ping en la red interna lo bloquean sólo aquellos que quieren complicarse la vida, y según nuestra experiencia, son pocos. Pero también existen personas así. En consecuencia, puede escanear rápidamente las redes en busca de dispositivos con un simple ping. Luego podremos agregarlos y buscar puertos abiertos que nos interesen. De hecho, esta funcionalidad ya existía, sólo era necesario añadir un comando desde el servidor central al esclavo para que escaneara las redes especificadas y añadiera todo lo que encontrara a la lista. Olvidé mencionar que se suponía que ya teníamos una imagen lista para usar con un sistema configurado (servidor de monitoreo esclavo) que simplemente podíamos implementar desde el cliente durante una auditoría y conectarlo a nuestra nube.

Pero el resultado de una auditoría suele incluir mucha información diferente, y una de ellas es qué tipo de dispositivos hay en la red. En primer lugar, estábamos interesados ​​en los servidores y estaciones de trabajo Windows como parte de un dominio. Ya que en las medianas y grandes empresas la falta de un dominio probablemente sea una excepción a la regla. Para hablar un idioma, la media, en mi opinión, es de más de 100 personas. Era necesario idear una forma de recopilar datos de todas las máquinas y servidores Windows, conociendo su IP y cuenta de administrador de dominio, pero sin instalar ningún software en cada uno de ellos. La interfaz WMI viene al rescate. Instrumental de administración de Windows (WMI) significa literalmente herramientas de administración de Windows. WMI es una de las tecnologías básicas para la gestión centralizada y el monitoreo del funcionamiento de varias partes de la infraestructura informática que ejecuta la plataforma Windows. Tomado de wiki. Luego tuve que retocar nuevamente para compilar wmic (este es un cliente WMI) para Debian. Una vez que todo estuvo listo, todo lo que quedaba era simplemente sondear los nodos necesarios a través de wmic para obtener la información necesaria. A través de WMI puede obtener casi cualquier información de una computadora con Windows y, además, también puede controlar la computadora a través de él, por ejemplo, enviarla para que se reinicie. Así apareció la recopilación de información sobre estaciones y servidores Windows en nuestro sistema. Además de esto, había información actualizada sobre los indicadores actuales de carga del sistema. Los solicitamos con más frecuencia y la información sobre hardware con menos frecuencia. Después de esto, la auditación se volvió un poco más placentera.

Decisión de distribución de software

Nosotros mismos utilizamos el sistema todos los días y siempre está abierto para todos los empleados técnicos. Y pensamos que podríamos compartir con otros lo que ya tenemos. El sistema aún no estaba listo para ser distribuido. Hubo que reelaborar muchas cosas para que la versión local se convirtiera en SaaS. Estos incluyen cambios en varios aspectos técnicos del sistema (conexiones remotas, servicio de soporte), análisis de módulos para licencias, fragmentación de bases de datos de clientes, escalamiento de cada servicio y desarrollo de sistemas de actualización automática para todas las partes. Pero esta será la segunda parte del artículo.

Actualizar

Segunda parte

Fuente: habr.com