Hola Mi nombre es Pasha Chernyak, soy un desarrollador líder en QIWI y hoy quiero hablar sobre lo inevitable. Sobre el legado.
Comencemos con la pregunta: ¿qué es un servicio heredado? ¿Es un servicio heredado un servicio que el desarrollador no ha tocado durante una semana / mes / año? ¿O es un servicio escrito por un programador menos experimentado, por ejemplo, específicamente por usted, pero hace un año? Y ahora eres más genial y más experimentado. O, después de todo, ¿es un servicio Legacy un servicio que usted decide no volver a comprometer y está preparando lentamente un reemplazo para él? En cualquier caso, dejar este servicio desatendido y no actualizarlo es una bomba de tiempo que puede explotar más tarde.
Antes de pasar a cómo trabajamos con nuestros servicios Legacy en QIWI, le diré cómo ponemos las cosas en orden con los servicios de Wallet. Desde hace dos años soy responsable de su desempeño. Si hay algún problema, siempre me llaman primero. Por lo general, no tengo la audacia de llamar a otra persona a las 11 p.m., así que tuve que sentarme y comprender todos los servicios de nuestro dominio.
Pero a mí, como a cualquier persona, me gusta dormir por la noche, así que traté de lidiar con la operación: "Chicos, ¿por qué me llaman?" A lo que recibió una respuesta bastante concisa de la forma "¿Quién más?" Porque estoy reparando servicios, y los chicos simplemente no saben a quién llamar.
Por lo tanto, en una de las retrospectivas del equipo de back-end de Wallet, decidimos que necesitamos compilar una placa en la que está escrita una lista de nuestros servicios, microservicios y monolitos de la billetera, y los responsables de ellos. Las tabletas son generalmente útiles, en un grado razonable.
Además de la información sobre quién es responsable de qué, hubo respuestas a las preguntas: quién es el propietario del servicio, quién es responsable de su desarrollo, de la arquitectura y del ciclo de vida. Las personas responsables de este servicio son personas que pueden repararlo si sucede algo. El propietario del servicio tiene derecho a dejar +2 en los compromisos, los responsables también deben estar presentes en la revisión antes de que este servicio asuma el nuevo compromiso.
A medida que pasaba el tiempo, comenzaron a aplicarse nuevas prácticas, por ejemplo, la migración a Kubernetes, todo tipo de checkstyle, spotbugs, ktlint, la presencia de registros en kiban, servicios de detección automática en lugar de especificar direcciones directamente y otras cosas útiles. Y en todas partes nuestra mesa nos permitió mantener la relevancia de nuestros servicios. Para nosotros, esta es una lista de verificación que dice que este servicio sabe cómo hacerlo, pero aún no lo ha hecho. Pero fuimos más allá, al darnos cuenta de que carecemos de información sobre nuestros servicios, por lo que hacemos un seguimiento de dónde se encuentran los códigos fuente del servicio. , donde se inician las tareas de ensamblaje en TeamCity, cómo se implementan, dónde se almacenan los códigos fuente de las pruebas de end2end, fotos de los arreglos sobre arquitectura, sobre las decisiones tomadas. Idealmente, quería que toda esta información estuviera en algún lugar y estuviera a mano cuando fuera necesario. Por lo tanto, nuestra placa se ha convertido en un punto de partida para encontrar información.
Pero QIWI, si bien conserva el espíritu de una startup, es una gran empresa. Ya tenemos 12 años y los equipos están cambiando: la gente se va, la gente viene, se están formando nuevos equipos. Y encontramos en nuestro dominio varios servicios que heredamos. Algo ocurrió con los desarrolladores de otros equipos, algo relacionado indirectamente con Wallet, por lo que el servicio ahora está en equilibrio. Tratar con qué y cómo funciona, ¿por qué? El servicio funciona, y tenemos características del producto que deben ser eliminadas.
Como sucede
Pero en algún momento, encontramos que el servicio deja de cumplir su función, algo se ha roto: ¿qué se debe hacer en esta situación? El servicio simplemente dejó de funcionar. Absolutamente Y aprendimos sobre esto, primero, por casualidad, y segundo, seis meses después. Sucede Lo único que sabíamos era en qué máquinas virtuales se desplegó el servicio, dónde se encuentran sus fuentes y eso es todo. Hacemos clon de git y nos sumergimos en los pensamientos de la persona que escribió esto hace varios años, pero ¿qué vemos? No hay Spring Boot familiar para nosotros, aunque estamos acostumbrados a todo, tenemos una pila completa y todo eso. Tal vez hay un marco de primavera? Pero no
El tipo que escribió todo esto fue duro y escribió todo en Java puro. No existen herramientas familiares para el desarrollador, y surge la idea: debemos reescribir todo esto. También tenemos microservicios, y en cada tostadora escuchamos los familiares "¡Chicos, microservicios son lo que necesitan!". Si de repente algo está mal, con calma aprenderás cualquier idioma y todo estará bien.
La cuestión es que ahora no tenemos un cliente responsable de este servicio. ¿Cuáles fueron sus requisitos comerciales, qué debe hacer este servicio en general? Y el servicio está estrechamente integrado en sus procesos comerciales.
Ahora dígame, ¿qué tan fácil es reescribir un servicio sin conocer sus requisitos comerciales? El servicio no está claro cómo se registra; se desconoce si hay métricas. Lo que son, si los hay, es aún más desconocido. Y mientras está en el servicio, una gran cantidad de clases de lógica empresarial oscura. Algo está incluido en algún tipo de base de datos, sobre el cual todavía no sabemos nada.
Por donde empezar
Desde lo más lógico - con la disponibilidad de pruebas. Al menos se escribe allí algún tipo de lógica y se pueden sacar conclusiones sobre lo que está sucediendo. Ahora TDD está de moda, pero vemos que hace 5 años todo era casi igual que ahora: casi no hay pruebas unitarias y no nos dicen absolutamente nada. Bueno, excepto tal vez algún tipo de verificación de cómo se firma algún xml con algún tipo de certificado personalizado.
No podíamos entender nada por el código, y enviamos una mirada para ver qué era la máquina virtual allí. Abrimos los registros del servicio, encontramos un error de cliente http en ellos, un certificado autofirmado que fue cosido a los recursos de la aplicación, sin escrúpulos. Contactamos a nuestros analistas, nos pidieron un nuevo certificado, nos lo emitieron y el servicio funciona nuevamente. Eso parece ser todo. O no? Aún así, el servicio funciona, realiza alguna función que nuestro negocio necesita. Tenemos algunos estándares de desarrollo de aplicaciones que probablemente tenga. Por ejemplo, no almacene los registros en el nodo en la carpeta, sino que los almacene en algún tipo de almacenamiento, como un elástico, mírelos en el kiban. Puedes recordar las métricas doradas. Es decir, la carga en el servicio, la cantidad de solicitudes para el servicio, si está vivo o no, cómo funciona su HealthCheck. Como mínimo, estas métricas lo ayudarán a descubrir cuándo se puede desmantelar y olvidar como un mal sueño con la conciencia tranquila.
Que hacer
Por lo tanto, agregamos un servicio tan antiguo a la tableta, y luego buscamos voluntarios entre los desarrolladores que se encargarán del servicio y lo pondrán en orden: escribirán al menos alguna información sobre el servicio, agregarán enlaces a paneles en graphan, a tareas de ensamblaje, y comprenderán cómo Implemente la aplicación, no cargue archivos usando ftp con sus manos.
Lo principal es cuánto costará todo este voluntariado útil. Un sprint para un desarrollador más o menos experimentado, por ejemplo, durante una deuda técnica del 20%. ¿Y cuánto tiempo se tardó en comprender toda la lógica profundamente arraigada de comunicarse con un determinado sistema de estado y llevarlo a tecnologías más nuevas? No puedo responder por esto, tal vez un mes, o tal vez dos equipos de trabajo. Esto lo digo desde la experiencia de integración en el momento actual con algún servicio nuevo.
Al mismo tiempo, no hay escape de valor comercial. Absolutamente Tomar el servicio de soporte y pasar un poco de tiempo es normal. Pero después de nuestros bailes estándar con el servicio, lo agregamos a la tabla, agregamos información al respecto y, tal vez, algún día lo reescribiremos. Pero ahora cumple con nuestros estándares de servicio.
Como resultado, me gustaría traer a un plan qué hacer con los servicios de Legacy.
Reescribir el legado desde cero es una mala ideaEn serio, ni siquiera tienes que pensarlo. Está claro que nos gustaría, y se ven algunas ventajas, pero generalmente esto no es necesario para nadie, incluido usted.
Libro de referenciaExcava los códigos fuente de tus aplicaciones, crea un directorio que indique qué y dónde se encuentra y cómo funciona, ingresa la descripción del proyecto allí (readme.md condicional) para comprender rápidamente dónde están los registros y las métricas. Un desarrollador que se ocupará de esto después de que solo diga gracias.
Comprender el dominioSi posee un dominio, trate de mantener su pulso. Suena cursi, sí, pero no todos se aseguran de que los servicios estén en una sola clave. Pero trabajar en un estándar es en realidad significativamente más fácil.