¡Hola! Mi nombre es Pasha Chernyak, soy un desarrollador líder en QIWI y hoy quiero hablar de lo inevitable. Sobre el legado.
Comencemos con la pregunta: ¿qué es el servicio Legacy? ¿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 con menos experiencia, por ejemplo, usted específicamente, pero hace un año? Y ahora eres más genial y tienes más experiencia. ¿O es el servicio Legacy un servicio que ha decidido no volver a utilizar nunca más y poco a poco está preparando un reemplazo para él? En cualquier caso, dejar un servicio de este tipo desatendido y sin actualizar es una bomba de tiempo que puede explotar más adelante.
Antes de continuar con cómo trabajamos en QIWI con nuestros servicios Legacy, le diré cómo ordenamos los servicios en Wallet. Desde hace dos años soy responsable de su funcionamiento. Si hay algún problema, siempre me llaman primero. Normalmente no tengo el descaro de llamar a otra persona a las 11 de la noche, así que tuve que sentarme y descubrir 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 explotación: "Chicos, ¿por qué me llaman?". A lo que recibí una respuesta bastante lacónica como “¿Quién más?” Porque arreglo servicios y los muchachos simplemente no saben a quién llamar.
Por lo tanto, en una de las retrospectivas del equipo de backend de Wallet, decidimos que necesitábamos hacer un cartel con una lista de nuestros servicios, microservicios y monolitos de billetera, y sus responsables. Las señales son generalmente útiles, dentro de límites razonables.
Además de 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, arquitectura y ciclo de vida. Los responsables de este servicio son las personas que pueden solucionarlo si pasa algo. El propietario del servicio tiene derecho a dejar +2 en los commits, los responsables también deben estar presentes en la revisión antes de que este servicio acepte un nuevo commit.
Con el paso del tiempo, se empezaron a aplicar nuevas prácticas, por ejemplo, la migración a Kubernetes, todo tipo de checkstyle, spotbugs, ktlint, la presencia de registros en Kibana, servicios de descubrimiento automático 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 especie de lista de verificación que dice que este servicio puede hacer esto, pero aún no lo hace, pero seguimos adelante y nos damos cuenta de que nos falta información sobre nuestros servicios, qué monitoreamos, dónde se encuentran las fuentes del servicio, dónde se lanzan las tareas de ensamblaje en TeamCity, cómo se implementan, dónde se almacenan las fuentes de las pruebas end2end, fotos de las sesiones de preparación sobre la arquitectura, sobre las decisiones tomadas. Idealmente, me gustaría que toda esta información estuviera en algún lugar y estuviera a mano cuando la necesitara. Por tanto, nuestro signo se convirtió en el punto de partida para la búsqueda de información.
Pero QIWI, aunque conserva el espíritu de startup, es una gran empresa. Ya tenemos 12 años y los equipos van cambiando: la gente se va, la gente viene, se forman nuevos equipos. Y descubrimos varios servicios en nuestro dominio que heredamos. Algunos provienen de desarrolladores de otros equipos, otros simplemente están relacionados indirectamente con Wallet, por lo que ahora tenemos el servicio en nuestro balance. Comprender qué y cómo funciona: ¿por qué? El servicio funciona y tenemos características del producto que definitivamente deben mejorarse.
como sucede
Pero en algún momento descubrimos que el servicio deja de realizar su función, algo falla: ¿qué hacer en tal situación? El servicio simplemente dejó de funcionar. En absoluto. Y nos enteramos de esto, en primer lugar, por casualidad y, en segundo lugar, seis meses después. Sucede. Lo único que sabíamos era en qué máquinas virtuales se implementaría el servicio, dónde se ubicarían sus fuentes y eso es todo. Hacemos un clon de git y nos sumergimos en la mente de la persona que escribió esto hace unos años, pero ¿qué vemos? Ninguno de los Spring Boot que nos resultan familiares, aunque estamos acostumbrados a todo, tenemos un full stack y todo eso. ¿Quizás haya un Spring Framework allí? Pero no.
El tipo que escribió todo esto fue duro y escribió todo en Java puro. No existen las herramientas habituales para un desarrollador y surge una idea: tenemos que reescribir todo esto. Tenemos microservicios y de cada tostadora sale el habitual "¡Chicos, los microservicios son lo que necesitan!". Si de repente algo sale mal, puedes tomar tranquilamente cualquier idioma y todo irá bien.
El caso es que ahora no tenemos un cliente que se encargue de este servicio. ¿Qué requisitos comerciales tenía, qué debería hacer este servicio? 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? No está claro cómo se registra el servicio; se desconoce si existen métricas. Cuáles son, si los hay, es aún más desconocido. Y al mismo tiempo, el servicio contiene una gran cantidad de clases de lógica empresarial incomprensible. Algo está incluido en algún tipo de base de datos, de la que tampoco sabemos nada todavía.
¿Con qué comenzar?
Desde el punto de vista más lógico: la disponibilidad de pruebas. Por lo general, allí hay al menos algo de lógica escrita y se pueden sacar conclusiones sobre lo que está sucediendo. Ahora el 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 nada de nada. Bueno, excepto quizás algún tipo de verificación, cómo algún xml está firmado con algún certificado personalizado.
No pudimos entender nada del código, así que fuimos a ver qué había en la máquina virtual. Abrimos los registros de servicio y encontramos un error del cliente http en ellos; el certificado autofirmado que estaba incrustado en los recursos de la aplicación estaba descaradamente podrido. Contactamos con nuestros analistas, nos pidieron un nuevo certificado, nos lo emitieron y el servicio vuelve a funcionar. Parecería que eso es todo. ¿O no? Al fin y al cabo, el servicio funciona, realiza alguna función que nuestro negocio necesita. Tenemos ciertos estándares para el desarrollo de aplicaciones, que probablemente usted también tenga. Por ejemplo, no almacene los registros en el nodo en una carpeta, sino guárdelos en algún tipo de almacenamiento, como un elástico, y mírelos en Kibana. También puedes recordar las métricas doradas. Es decir, la carga del servicio, la cantidad de solicitudes del servicio, si está vivo o no, cómo va su HealthCheck. Como mínimo, estas métricas te ayudarán a saber cuándo puedes sacarlo de servicio con la conciencia tranquila y olvidarlo como un mal sueño.
Qué hacer
Por lo tanto, agregamos un servicio tan antiguo a la mesa y luego buscamos voluntarios entre los desarrolladores que se encargarán del servicio y lo pondrán en orden: escribirán al menos algo de información sobre el servicio, agregarán enlaces a paneles en grafana, hasta tareas de ensamblaje y comprender cómo implementar la aplicación, no cargar archivos manualmente mediante ftp.
Lo principal es ¿cuánto durará toda esta útil actividad voluntaria? Un sprint para un desarrollador más o menos experimentado, por ejemplo, con una deuda técnica del 20%. ¿Cuánto tiempo tomó comprender toda la lógica arraigada de comunicarse con un determinado sistema estatal y adaptarla a tecnologías más nuevas? No puedo dar fe de esto, quizás un mes o quizás dos del trabajo del equipo. Lo digo por experiencia de integración actual con algún servicio nuevo.
Al mismo tiempo, no se libera valor empresarial. En absoluto. Es normal contratar un servicio de soporte y dedicarle un poco de tiempo. 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 reescribimos. Pero ahora cumple con nuestros estándares de servicio.
Como resultado, me gustaría elaborar un plan sobre qué hacer con los servicios Legacy.
Reescribir el legado desde cero es una mala idea
En serio, ni siquiera tienes que pensar en ello. Está claro que me gustaría y tiene algunas ventajas, pero normalmente nadie lo necesita, incluido usted mismo.
Directorio
Busque los códigos fuente de sus aplicaciones, cree un libro de referencia que indique qué es, dónde y cómo funciona, ingrese allí una descripción del proyecto (readme.md condicional) para comprender rápidamente dónde se encuentran los registros y las métricas. El desarrollador que se ocupará de esto después de usted solo le dará las gracias.
entender el dominio
Si posee un dominio, intente mantenerse al tanto. Suena trivial, sí, pero no todo el mundo se asegura de que los servicios estén en una única clave. Pero trabajar con un solo estándar es mucho más fácil.
Solo los usuarios registrados pueden participar en la encuesta. por favor
¿Qué haces con tu legado?
un 31.5%Estoy reescribiendo desde cero, es más correcto 12
un 52.6%Casi lo mismo que tu20
un 10.5%No tenemos legado, somos geniales4
un 5.2%escribiré en los comentarios2
38 usuarios votaron. 20 usuarios se abstuvieron.
Fuente: habr.com
