Ahorramos tiempo, nervios y horas de trabajo

Nuestros proyectos suelen ser regionales y los clientes suelen ser ministerios. Pero, además del sector público, también utilizan nuestros sistemas organizaciones privadas. Prácticamente no hay problemas con ellos.

Entonces, los principales proyectos son regionales y, a veces, surgen problemas con ellos. Por ejemplo, con el rendimiento, cuando en las regiones hay más de 20 de nuestros valiosos usuarios durante el período de implementación de nuevas funciones en los servidores del producto. Es un dolor…

Mi nombre es Ruslan y doy soporte a los sistemas de información de BARS Group y desarrollando un robot asesino para DBA en serie violentos. Esta publicación no es para personas débiles de corazón: hay muchas letras e imágenes.

/awr

Algunas de nuestras aplicaciones se ejecutan en Oracle DBMS. También hay proyectos sobre el DBMS PostgreSQL. Oracle tiene algo maravilloso: recopilar estadísticas sobre la carga del DBMS, que resalta los problemas existentes e incluso hace recomendaciones para su eliminación: el repositorio automático de cargas de trabajo (AWR). En un momento (es decir, en el momento doloroso), los desarrolladores pedían constantemente recopilar Informes AWR para análisis de rendimiento. Honestamente, fuimos al servidor DBMS, recopilamos informes, nos los llevamos y los enviamos a producción para su análisis. Después de la quinta vez se volvió molesto... después de la décima vez se volvió irritante...

Uno de mis colegas expresó una vez la idea de que todo lo que se hace más de una vez debería automatizarse. Hasta el momento de la irritación, para ser honesto, no lo pensé y traté de automatizar todo lo que se podía automatizar, pero a menudo no tenía demanda y era más una investigación que una naturaleza aplicada.

Y luego pensé: "No se necesitan administradores para generar un informe...". Después de todo, recopilar un informe significa ejecutar el script sql @$ORACLE_HOME/rdbms/admin/awrrpt.sql y llevar el informe del servidor a su casa... Oh, sí, no permitimos el desarrollo para producción.

Luego busqué en Google la información necesaria, creé la función a partir del artículo en la base de pruebas, ejecuté el script y milagrosamente: el informe se compiló y se puede guardar localmente. Creé funciones donde a menudo se necesitaban informes AWR y les dije a los desarrolladores cómo usarlos.

Por esta época, en mi tiempo libre, después de hablar con @BotFather, creé un bot de Telegram para mí, solo por diversión. Allí introduje una funcionalidad simple: mostrar la hora actual, los tipos de cambio, el clima, le enseñé a enviar cumplidos a mi esposa (entonces novia) según un horario. Quizás, en ese momento, enviar cumplidos era la funcionalidad más popular de mi bot y mi esposa lo apreciaba.

Entonces. Los desarrolladores nos escriben en Telegram, les enviamos un informe en Telegram... ¿Qué pasa si no nos escriben a nosotros, sino a un bot? Después de todo, será mejor para todos, el informe se recibirá más rápido y, lo más importante, sin pasarnos por alto. Así nació la idea de la primera funcionalidad popular para mi bot.

Comencé la implementación. Lo hice lo mejor que pude en PHP (nuestra aplicación en sí está en PHP, estoy más versado en él que en Python). No soy un buen codificador, así que no te mostraré mi código :)

El bot vive en nuestra red corporativa y tiene acceso a ciertos proyectos, incluidas las bases de datos de destino. Para no molestarme con los parámetros en el comando o menú, agregué esta funcionalidad al chat grupal con notificaciones de seguimiento. De esta manera, el bot sabe inmediatamente de qué base de datos recopilar el informe.

Habiendo recibido una orden como /awr ingl., donde N es la cantidad de horas completas para las cuales se necesita un informe (por defecto, 1 hora), incluso durante una semana, si la base de datos no se ha reiniciado, el bot comienza a trabajar inmediatamente, recopila el informe y lo publica como un página web e inmediatamente (casi allí mismo) proporciona un enlace al informe tan necesario.

Siga el enlace y aquí está el informe de AWR:

Como era de esperar, los desarrolladores se las arreglaron con la generación de informes y algunos incluso nos agradecieron.

Al apreciar la conveniencia del equipo, los gerentes de proyectos de otras regiones querían lo mismo, ya que reciben lo máximo del cliente y se preocupan por el rendimiento y la disponibilidad de los sistemas. Agregué el bot a otros chats. Todavía lo usan y me alegro.

Más tarde, los compañeros de CIT descubrieron cómo recopilamos informes y quisieron hacerlo también. No los agregué a nuestros chats, creé un chat separado con la generación de informes de forma programada y previa solicitud.

/pgTejón

También disponemos de otras aplicaciones en PHP en conjunto con PostgreSQL. Implementé la recopilación de informes de pgBadger para quienes los necesitaban utilizando el mismo principio: en chats grupales. Al principio lo usaron, pero luego dejaron de hacerlo. La funcionalidad se eliminó por ser innecesaria.

/deber

Nuestro departamento tiene turnos de noche y, en consecuencia, tiene un horario. Está en Google Sheets. No siempre es cómodo buscar un enlace, abrir un gráfico, buscarlo uno mismo... Uno de mis antiguos compañeros también jugó con su bot de Telegram y lo introdujo en el chat de nuestro departamento. notificaciones sobre el inicio del turno de trabajo para los empleados del departamento. El robot analiza el cronograma, determina la persona de servicio en la fecha actual y, según el cronograma o previa solicitud, informa quién está de servicio hoy. Resultó genial y conveniente. Es cierto que no me gustó mucho el formato de los mensajes. Además, para los empleados de otro departamento (por ejemplo, BC "Medicina"), la información sobre aquellos que están de servicio en otras direcciones no es realmente necesaria, pero es necesario saber quién está de servicio en "Medicina" en caso de problemas. Decidí "tomar prestada" la funcionalidad, pero cambié lo que no me gustaba. Creé un formato de mensaje conveniente para mí y para los demás, eliminando información innecesaria.

/tnls

Después de probar la automatización usando un bot de Telegram, surgieron muchas ideas diferentes, pero quería hacer cosas estrictamente necesarias. decidí liderar estadísticas sobre solicitudes. Para acceder a los proyectos de nuestros clientes, hemos implementado el llamado "servidor de salto" o servidor de reenvío. En él se levantan conexiones VPN, luego los puertos de aplicaciones, bases de datos y otros reenvíos auxiliares se reenvían a nuestra red local vía ssh, para acceder fácilmente a los proyectos de nuestros empleados, sin problemas con las conexiones VPN. Todo lo que necesita hacer es configurar una conexión VPN a nuestra red corporativa.

Las estadísticas de solicitudes han demostrado que, a menudo, después de que uno de los túneles falla (en el caso de problemas de red, por ejemplo, debido a un tiempo de espera), la gente se pone en contacto con nosotros para restaurar el acceso al proyecto. En la mayoría de los casos, basta con reiniciar la conexión y todo estará bien. Hagámoslo tú mismo. Aquí está el comando:


Usted "cae" en el elemento del menú deseado, selecciona su proyecto, espera un minuto y todos están felices y satisfechos...

Al recibir un comando, con un ligero movimiento de bytes y bits, el bot se conecta al servidor de reenvío, sabiendo de antemano qué reenvío debe reiniciarse y hace su trabajo: restablece la conexión con el proyecto. Escribí instrucciones para que usted mismo pueda resolver estos problemas. Y la gente se comunicaba con nosotros sólo si la herramienta proporcionada no funcionaba...

/ecp_to_pem

Otras estadísticas mostraron que a menudo es necesario convertir EDS Crypto Pro en formato pem(Basexnumx) para varias integraciones, y tenemos bastantes. Tarea: tome un contenedor, cópielo a una computadora con Windows con la utilidad P12FromGostCSP instalada (de pago, por cierto), conviértalo a pfx y luego convierta pfx usando OpenSSL (con soporte para cifrado GOST) a pem. No es muy conveniente, pero lo desea con solo chasquear los dedos.

Google ha vuelto al rescate. Encontró la utilidad de alguna persona amable. Lo monté como está escrito en el archivo README y funcionó. Le enseñé al bot a trabajar con la utilidad y obtuve una conversión casi instantánea.


En el momento de la implementación final, se emitió una orden para cambiar a un nuevo formato de cifrado: gost-2012. Por lo que recuerdo, la utilidad en ese momento solo funcionaba con el antiguo GOST (2001), tal vez fuera otra utilidad similar de otra amable persona, no recuerdo exactamente.
Después de la transición al nuevo GOST, la funcionalidad del bot se eliminó por razones de seguridad. Lo implementé en un contenedor acoplable.

Dockerfile, por si alguien lo necesita:

FROM ubuntu:16.04                                                                                                                                                                        
RUN apt update && apt -y install git sudo wget unzip gcc g++ make &&                        
   cd /srv/ && git clone https://github.com/kov-serg/get-cpcert.git &&                     
   cd get-cpcert && chmod +x *.sh && ./prepare.sh && ./build.sh &&                         
   mkdir -p /srv/{in,out} &&                                                               
   echo '#!/bin/bash' > /srv/getpem.sh &&                                                  
   echo 'cd /srv/get-cpcert' >> /srv/getpem.sh &&                                          
   echo './get-cpcert /srv/in/$CONT.000 $PASS > /srv/out/$CONT.pem' >> /srv/getpem.sh &&   
   chmod +x /srv/getpem.sh                                                                  ENTRYPOINT /srv/getpem.sh

Para convertir, debe colocar el contenedor original (directorio como xxx.000) en el directorio /srv/in y llevar el pem terminado a /srv/out.

Para convertir:

 docker run -t -i -e CONT='<имя директории с контейнером(без ".000")>' -e PASS='<пароль для контейнера>' -v /srv/in:/srv/in -v /srv/out:/srv/out --name ecptopem <адрес нашего репозитория>/med/ecptopem:latest 

/emstop y /emstart

Un día, un DBA de Oracle genial, con mucha experiencia en administración y desarrollo de DBMS, consiguió trabajo en nuestra empresa. E inmediatamente tuvo problemas para conectarse a los servidores DBMS con ssh: no sabe dónde ni cómo conectarse, el acceso no está claramente descrito o no puede reenviarse algo que necesita. Bueno, estaremos encantados de poder ayudarle, le dijimos cómo conectarse y le enviamos Enterprise Manager. Pero las cosas todavía no funcionaron con ssh. Uno de mis colegas lo explicó simplemente: un DBA de pura raza :) Decidimos que si necesitamos modificar algo en el servidor, lo haremos nosotros mismos.

EM a veces falla bajo carga pesada, y para reiniciarlo... necesitas conectarte vía ssh y reiniciar a través de la terminal. "Los administradores son buenos en esto", decidió nuestro nuevo colega. Las cargas pesadas en el DBMS no son infrecuentes para nosotros, y las solicitudes para reiniciar EM también lo son. Luego el mismo escenario: tensión, irritación y búsqueda de una solución al problema. Entonces en los mismos chats grupales aparecieron los siguientes comandos: /emstop y /emstart.

/matar

Si hay una fuerte competencia en la base de datos, y esto sucede a veces, es necesario descargar rápidamente la base de datos. La forma más rápida es matar el proceso problemático... Para hacer esto, conéctese a través de ssh, mate -9... ¡El bot te ayudará!

Alexey apreció al equipo y le puso un nombre cariñoso: "Kilialka" o un arma.
Un día, después de ver cómo Alexey lo intentó y sufrió, ingresando /kill xxx cada vez para cada uno de los procesos, decidí agregar "multi-barrel" a nuestra arma:

¡Eso es mejor! Todo es para ti, Alexey, ¡solo trabaja, querido!

Naturalmente, un equipo tan importante era limitado. acceso por user_id - "infalible". Al ver cómo Lesha mata hábilmente procesos en el servidor de la base de datos, varias personas intentaron ingresar un comando con un número de proceso aleatorio, pero no puedes engañar a mi robot inteligente, él se negó de inmediato.

/registro de alertas

Bueno, por si acaso, hice el comando:
/alertlog <número de líneas> — obtener el número especificado de líneas de registro de alertas
El bot extrae un registro de alertas y lo envía a nuestro servicio, como Pastebin, llamado pyste, y envía un enlace para pegar al chat de solicitud.

/cheques

Luego vino una solicitud de monitorizando el rendimiento real de nuestra aplicación. Hasta ahora, el soporte técnico del proyecto recopilaba estos datos manualmente. ¡No importa! Nuestros valientes evaluadores han desarrollado casos de prueba para esto. El registro de prueba resultante no es muy cómodo de leer, un usuario inexperto tardará mucho en comprenderlo y no está seguro de resaltar la información necesaria. Y no nos gusta hacer con las manos lo que no podemos hacer con las manos... ¡Una nueva tarea para el bot!

El comando /checks muestra un menú simple e inequívoco; ¡esta vez nuestros muchachos aprendieron a usar este comando sin instrucciones!

Cuando selecciona el elemento deseado, en lugar de un menú, aparece una notificación sobre el inicio de la prueba, para que los usuarios impacientes no ejecuten nuestra prueba 100500 veces:

Dependiendo del elemento del menú seleccionado, se lanza una prueba específica desde nuestra red, es decir, desde la máquina donde reside el bot (allí está preconfigurado jmeter, se encuentran las pruebas necesarias...) o directamente desde el centro de datos (desde un máquina preparada al lado de la aplicación), para excluir conexiones de red al probar retrasos, o reducirlos al mínimo.

Después de completar la prueba y recibir el registro, el robot lo analiza y produce el resultado en un formato "legible por humanos":

Colección de métricas

La funcionalidad ha llegado y los directores de proyectos interesados ​​han recibido dicha función para sus regiones. Y un compasivo director de proyecto dijo: “¡Quiero tener estadísticas de tiempo!” Alguien del CIT le dijo que sería conveniente monitorear todo esto en Zabbix. Zabbix, entonces Zabbix...

Pensé que necesitaba prepararme para la necesidad de replicar la solución... Puse la idea en un contenedor acoplable. En el contenedor, jmeter se inicia según un cronograma (una vez cada 10 minutos), coloca el registro en un lugar determinado, php lo analiza y muestra los datos necesarios en forma de página web. Zabbix, utilizando la clave web.page.get, recibe esta página, selecciona periódicamente los datos necesarios para ciertos elementos dependientes y construye un gráfico.

Creo que no quedó nada mal. Al observar el gráfico, primero vemos la velocidad aproximada de la aplicación, y si se detectan picos en el gráfico, sabemos aproximadamente dónde está el "tapón". Es sencillo. Hasta ahora ha resultado tener demanda solo en una región, pero estoy listo para replicarlo para aquellos interesados.

Desarrollo de aplicaciones

Las estadísticas sobre tareas similares han dado lugar últimamente a más ideas para simplificar y facilitar el trabajo. En algunos proyectos, en los servidores de aplicaciones, es necesario instalar contenedores clave Crypto Pro, hay muchos y la firma digital caduca con el tiempo. A veces llegan 2 tareas al día. Pero consideré que no era seguro utilizar un bot para estos fines y decidí crear la funcionalidad directamente en la aplicación. Naturalmente con autorización y comprobando los derechos de acceso. Si tiene los privilegios necesarios, estará disponible un elemento de menú adicional para trabajar con firmas digitales, instalación, eliminación, visualización de información, etc. La funcionalidad está actualmente en desarrollo. Al final resultó que, esto no es muy difícil, solo necesita leer un poco las instrucciones existentes, mirar ejemplos de código, preguntar a colegas con más experiencia en desarrollo y luego hacerlo. Durante el proceso de investigación surgieron ideas para agregar a la aplicación. No haré planes napoleónicos: hay desarrollo, que cada uno se ocupe de sus propios asuntos. Pero si bien es interesante, lo hago yo mismo.

Planes

Como dije, nacieron muchas ideas diferentes para usar nuestro bot y no solo, en general, digamos, ideas para "puntos de automatización", muchas de ellas fueron olvidadas, ya que no tuve tiempo de escribirlas. Ahora intento anotar todo lo que se me viene a la cabeza y recomiendo a los demás que hagan lo mismo.

Pero Alexey no se olvida de expresar sus deseos. De lo último:
/kill_sql SQL_ID — mata todas las sesiones con esta solicitud SQL_ID
/kill_block - matar la sesión de bloqueo de raíz
/Muestrales — mostrar una imagen del desempeño de los mercados emergentes
Es un tipo astuto, quiere coser DBA desde su teléfono =)

¡Así trabajamos en beneficio de la Patria!

¿Cómo deshacerse de las tareas rutinarias y poco interesantes?

Espero que la lectura haya resultado interesante, y tal vez incluso útil para alguien, y no tuve tiempo de aburrir al lector... Buena suerte a todos.

Fuente: habr.com