Os nosos proxectos adoitan ser rexionais, e os clientes adoitan ser ministerios. Pero, ademais do sector público, as organizacións privadas tamén usan os nosos sistemas. Practicamente non hai problemas con eles.
Entón, os principais proxectos son rexionais, e ás veces hai problemas con eles. Por exemplo, co rendemento, cando nas rexións hai máis de 20k dos nosos preciosos usuarios durante o período de implementación de novas funcionalidades nos servidores de produtos. É unha dor...
Chámome Ruslan e apoio os sistemas de información do Grupo BARS e desenvolvendo un bot asasino para DBA en serie violentos. Esta publicación non é para os débiles de corazón: hai moitas cartas e imaxes.
/awr
Algunhas das nosas aplicacións execútanse en Oracle DBMS. Tamén hai proxectos no DBMS PostgreSQL. Oracle ten unha cousa marabillosa: recoller estatísticas sobre a carga do DBMS, que destacan os problemas existentes e incluso fai recomendacións para a súa eliminación: o repositorio automático de carga de traballo (AWR). Nun momento dado (nomeadamente no momento da dor), os desenvolvedores pedían constantemente recoller Informes AWR para análise de rendemento. Sinceramente, fomos ao servidor DBMS, recompilamos informes, levámolos e enviámolos á produción para a súa análise. Despois da 5a vez volveuse molesto... despois da 10a volveuse irritante...
Un dos meus compañeiros expresou unha vez a idea de que todo o que se fai máis dunha vez debería ser automatizado. Ata o momento da irritación, para ser sincero, non pensei niso e tentei automatizar todo o que se podía automatizar, pero moitas veces non era demandado e era máis unha investigación que unha natureza aplicada.
E entón pensei: "Non son necesarios administradores para xerar un informe...". Despois de todo, recoller un informe significa executar o script sql @$ORACLE_HOME/rdbms/admin/awrrpt.sql e levar o informe do servidor ao teu lugar... Ah, si, non permitimos o desenvolvemento para a produción.
Despois busquei en Google a información necesaria, creei a función a partir do artigo sobre a base de probas, executei o guión e o milagre: o informe recompilouse e pódese gardar localmente. Creou funcións nas que a miúdo se necesitaban informes AWR e dixéronlles aos desenvolvedores como usalos.
Por esta época, no meu tempo libre, despois de falar con @BotFather, creei un bot de Telegram para min, só por diversión. Alí atornillei unha funcionalidade sinxela: mostrar a hora actual, os tipos de cambio, o tempo, ensineille a enviarlle eloxios á miña muller (daquela noiva) nun horario. Quizais, naquel momento, o envío de eloxios era a funcionalidade máis popular do meu bot, e a miña muller apreciouno.
Entón. Os desenvolvedores escríbenos en Telegram, enviámoslles un informe en Telegram... E se non nos escriben a nós, senón a un bot? Despois de todo, será mellor para todos, o informe será recibido máis rápido e, o máis importante, pasando por nós. Así naceu a idea da primeira funcionalidade popular para o meu bot.
Comecei a implementar. Fíxeno, como puiden, en PHP (a nosa aplicación en si está en PHP, estou máis versado niso que en Python). Non son un bo programador, así que non che mostrarei o meu código :)
O bot vive na nosa rede corporativa e ten acceso a certos proxectos, incluídas bases de datos de destino. Para non molestar cos parámetros do equipo ou do menú, adxuntei esta funcionalidade ao chat grupal con notificacións de seguimento. Deste xeito, o bot sabe inmediatamente de que base de datos recoller o informe.
Recibindo un comando como /awr N, onde N é o número de horas completas para as que se necesita un informe (por defecto - 1 hora), mesmo durante unha semana, se a base de datos non se reiniciou, o bot comeza a traballar inmediatamente, recolle o informe e publícao como un páxina web e inmediatamente (case alí mesmo) ofrece unha ligazón ao informe tan necesario.
Siga a ligazón e aquí está o informe AWR:
Como era de esperar, os desenvolvedores afrontaron esa xeración de informes, e algúns ata nos agradeceron.
Despois de apreciar a comodidade do equipo, os xestores de proxectos doutras rexións querían o mesmo, xa que reciben o máximo do cliente e están preocupados polo rendemento e a dispoñibilidade dos sistemas. Engadín o bot a outros chats. Aínda o usan, e estou feliz con iso.
Máis tarde, os compañeiros do CIT decatáronse de como recollemos os informes e tamén quixeron facelo. Non os engadín aos nosos chats, creei un chat separado coa xeración de informes nun horario e baixo petición.
/pgBadger
Tamén temos outras aplicacións en PHP en conxunto con PostgreSQL. Implementei a colección de informes pgBadger para os necesitados usando o mesmo principio: nos chats de grupo. Ao principio usárono, pero despois pararon. A funcionalidade foi cortada como innecesaria.
/deber
O noso departamento ten quendas nocturnas e, en consecuencia, ten un horario. Está en Follas de cálculo de Google. Non sempre é conveniente buscar unha ligazón, abrir un gráfico, buscar por ti mesmo... Un dos meus antigos compañeiros tamén xogou co seu bot de Telegram e introduciuno no chat do noso departamento. notificacións sobre o inicio da quenda de servizo para os empregados do departamento. O bot analiza o horario, determina a persoa de servizo pola data actual e, segundo o horario ou previa solicitude, informa quen está de servizo hoxe. Resultou xenial e cómodo. É certo, non me gustou moito o formato das mensaxes. Ademais, para os empregados doutro departamento (por exemplo, BC "Medicina"), a información sobre os que están de servizo noutras direccións non é realmente necesaria, pero cómpre saber quen está de servizo en "Medicina" en caso de problemas. Decidín "tomar prestada" a funcionalidade, pero cambiar o que non me gustaba. Fixen un formato de mensaxe conveniente para min e para os demais, eliminando información innecesaria.
/tnls
Despois de probar a automatización usando un bot de Telegram, apareceron moitas ideas diferentes, pero quería facer cousas estrictamente necesarias. Decidín dirixir estatísticas de solicitudes. Para acceder aos proxectos dos nosos clientes, implantamos o chamado "servidor de salto" ou servidor de reenvío. As conexións VPN érguense nel, entón os portos de aplicacións, bases de datos e outros reenvíos auxiliares envíanse á nosa rede local a través de ssh, para acceder facilmente aos proxectos dos nosos empregados, sen problemas coas conexións VPN. Todo o que tes que facer é configurar unha conexión VPN á nosa rede corporativa.
As estatísticas de solicitudes demostraron que moitas veces, despois de que un dos túneles falla (no caso de problemas de rede, por un tempo de espera, por exemplo), a xente se pon en contacto connosco para restablecer o acceso ao proxecto. Na maioría dos casos, basta con reiniciar a conexión e todo está ben. Imos facelo vostede mesmo. Aquí está o comando:
"Cae" no elemento do menú desexado, selecciona o teu proxecto, espera un minuto e todos estarán felices e satisfeitos...
Ao recibir un comando, cun pequeno movemento dos bytes e bits, o bot conéctase ao servidor de reenvío, sabendo de antemán que reenvío debe reiniciarse e fai o seu traballo: restablece a conexión co proxecto. Escribín instrucións para que poidas resolver tales problemas ti mesmo. E a xente só contactaba connosco se a ferramenta proporcionada non funcionaba...
/ecp_to_pem
Outras estatísticas mostraron que moitas veces é necesario converter EDS Crypto Pro en formato pem() para varias integracións, e temos moitas delas. Tarefa: colle un contedor, cópiao nun ordenador Windows coa utilidade P12FromGostCSP instalada (de pago, por certo), convérteo a pfx e despois converte pfx usando OpenSSL (con soporte para o cifrado GOST) a pem. Non é moi cómodo, pero queres cun chasquido dos dedos.
Google veu ao rescate de novo. Atopado . Munteino como está escrito no README - funcionou. Ensineille ao bot a traballar coa utilidade e obtiven unha conversión case instantánea.
No momento da implementación final, emitiuse unha orde para cambiar a un novo formato de cifrado: gost-2012. Polo que recordo, a utilidade nese momento só funcionaba co antigo GOST (2001), quizais fose outra utilidade semellante doutra persoa amable, non lembro exactamente.
Despois da transición ao novo GOST, a funcionalidade do bot foi eliminada por motivos de seguridade. Implementouno nun contedor docker.
Dockerfile, por se alguén o 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.shPara converter, cómpre colocar o contedor orixinal (directorio como xxx.000) no directorio /srv/in e levar o pem rematado a /srv/out.
Para converter:
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 e /emstart
Un día, un DBA de Oracle moi xenial, con moita experiencia en administración e desenvolvemento de DBMS, conseguiu un traballo na nosa empresa. E inmediatamente tivo problemas para conectarse aos servidores do DBMS con ssh: non sabe onde nin como conectarse, o acceso non está claramente descrito ou non pode reenviar algo que necesita. Ben, estamos encantados de axudar, dixémoslle como conectarse e reenviámoslle Enterprise Manager. Pero as cousas aínda non funcionaron con ssh. Un dos meus colegas explicouno de forma sinxela: un DBA de raza pura :) Decidimos que se necesitamos modificar algo no servidor, farémolo nós mesmos.
EM ás veces falla baixo unha carga pesada, e para reinicialo... cómpre conectarse mediante ssh e reiniciar a través do terminal. "Os administradores son bos nisto", decidiu o noso novo compañeiro. As cargas pesadas no DBMS non son infrecuentes para nós, e tamén son frecuentes as solicitudes de reinicio de EM. Despois o mesmo escenario: tensión, irritación e procura dunha solución ao problema. Entón, nos mesmos chats de grupo apareceron os seguintes comandos: /emstop e /emstart.
/matar
Se hai unha forte competencia na base de datos, e isto ocorre ás veces, é necesario descargar rapidamente a base de datos. O xeito máis rápido é matar o proceso problemático... Para iso, conéctate a través de ssh, mata -9... O bot axudaralle!
Alexey apreciou o equipo e púxolle un nome cariñoso. "Kilyalka" ou unha pistola.
Un día, despois de ver como Alexey intentou e sufriu, ingresando /kill xxx cada vez para cada un dos procesos, decidín engadir "multi-barrel" á nosa arma:
Iso está mellor! Todo é para ti, Alexey, só traballa, querida!
Por suposto, un equipo tan importante era limitado acceso por user_id - "infalible". Ao ver como Lesha mata con habilidade os procesos no servidor de base de datos, varias persoas intentaron introducir un comando cun número de proceso aleatorio, pero non podes enganar ao meu bot intelixente, rexeitou inmediatamente.
/alertlog
Ben, por se acaso, fixen o comando:
/alertlog — obter o número especificado de liñas de rexistro de alertas
O bot tira un rexistro de alertas e envíao ao noso servizo, como pastebin, chamado pyste, e envía unha ligazón ao pegar ao chat de solicitude.
/cheques
A continuación veu unha solicitude de supervisando o rendemento real da nosa aplicación. Ata agora, o soporte técnico do proxecto recollía estes datos manualmente. Non importa! Os nosos valientes probadores desenvolveron casos de proba para iso. O rexistro de proba resultante non é moi cómodo de ler; un usuario inexperto tardará moito en entender e non está seguro de que resalte a información necesaria. E non nos gusta facer coas nosas mans o que non podemos facer coas nosas mans... Unha nova tarefa para o bot!
O comando /checks mostra un menú sinxelo e inequívoco; esta vez os nosos rapaces aprenderon a usar este comando sen instrucións.
Cando selecciona o elemento desexado, en lugar dun menú, aparece unha notificación sobre o inicio da proba, para que os usuarios impacientes non executen a nosa proba 100500 veces:
Dependendo do elemento de menú seleccionado, lánzase desde a nosa rede unha proba específica, concretamente desde a máquina onde vive o bot (alí está preconfigurado jmeter, sitúanse as probas necesarias...) ou directamente desde o centro de datos (desde un máquina preparada xunto á aplicación), para excluír as conexións de rede ao probar os atrasos ou reducilos ao mínimo.
Despois de completar a proba e recibir o rexistro, o bot analízao e produce o resultado nun formulario "lexible por humanos":
Colección de métricas
A funcionalidade chegou e os xestores de proxectos interesados recibiron tal función para as súas rexións. E un director de proxecto compasivo dixo: "Quero ter estatísticas de tempo!" Alguén do CIT díxolle que sería conveniente supervisar todo isto en Zabbix. Zabbix, entón Zabbix...
Pensei que necesitaba prepararme para a necesidade de replicar a solución... Puxen a idea nun contedor docker. No contedor, jmeter lánzase nunha programación (unha vez cada 10 minutos), coloca o rexistro nun lugar determinado, php analízao e mostra os datos necesarios en forma de páxina web. Zabbix, mediante a clave web.page.get, recibe esta páxina, selecciona regularmente os datos necesarios para determinados elementos dependentes e constrúe un gráfico.
Creo que non resultou mal. Observando a gráfica, vemos, en primeiro lugar, a velocidade aproximada da aplicación e, se se detectan picos na gráfica, sabemos aproximadamente onde está o "enchufe". É sinxelo. Ata agora resultou ser demandado só para unha rexión, pero estou preparado para replicalo para os interesados.
Desenvolvemento de aplicacións
As estatísticas sobre tarefas semellantes deron lugar recentemente a máis ideas para simplificar e facilitar o traballo. Nalgúns proxectos, en servidores de aplicacións, hai que instalar contedores clave Crypto Pro, hai moitos deles e a sinatura dixital caduca co paso do tempo. Ás veces chegan 2 tarefas ao día. Pero considerei que non era seguro usar un bot para estes fins e decidín que crearía a funcionalidade directamente na aplicación. Por suposto con autorización e comprobación dos dereitos de acceso. Se tes os privilexios necesarios, estará dispoñible un elemento de menú adicional para traballar con sinaturas dixitais, instalación, eliminación, visualización de información, etc. A funcionalidade está actualmente en desenvolvemento. Como se viu, isto non é moi difícil, só tes que ler un pouco as instrucións existentes, mirar exemplos de código, preguntar a compañeiros con máis experiencia no desenvolvemento e despois facelo. Durante o proceso de investigación, xurdiron ideas para engadir á aplicación. Non farei plans napoleónicos: hai desenvolvemento, que cada un se ocupe dos seus asuntos. Pero aínda que é interesante, fágoo eu.
Plans
Como dixen, naceron moitas ideas diferentes para usar o noso bot e non só, en xeral, digamos, ideas para "puntos de automatización", moitas delas foron esquecidas, xa que non tiven tempo para anotalas. Agora intento anotar todo o que se ocorra, e recoméndolles que outros fagan o mesmo.
Pero Alexey non esquece dar os seus desexos. Do último:
/kill_sql SQL_ID — mata todas as sesións con esta solicitude SQL_ID
/kill_block - matar a sesión de bloqueo de raíz
/mostralos — mostrar unha imaxe do rendemento EM
É un tipo astuto, quere coser DBA desde o seu teléfono =)
Así traballamos en beneficio da Patria!
Como te libras de tarefas rutineiras e pouco interesantes?
Espero que a lectura resultou interesante, e quizais mesmo útil para alguén, e non tiven tempo de aburrir ao lector... Sorte a todos.
Fonte: www.habr.com