DFK Algotrade
DFK Algotrade desarrolla software financiero y opera sistemas vinculados a la gestión de carteras, el trading, los datos y el riesgo. En ese entorno, la velocidad de despliegue importa, pero importa más que los cambios sean predecibles. Una actualización del plano de control puede afectar al acceso, al enrutamiento, a la entrega de aplicaciones, a las bases de datos y a la capacidad del equipo para diagnosticar todo lo demás.
El incidente que cambió el requisito
Sección titulada «El incidente que cambió el requisito»El equipo había operado antes un entorno en el que una actualización automática de Coolify provocó una caída en producción. La lección fue que la disponibilidad de una versión, su aprobación, el momento del despliegue, la compatibilidad de los datos y las pruebas de recuperación son decisiones distintas.
La caída puso al descubierto una debilidad más amplia del modelo operativo. El equipo podía restablecer el servicio, pero el proceso de actualización no partía de una respuesta compartida a varias preguntas: ¿qué versión exacta está aprobada? ¿Qué estado hay que respaldar? ¿Qué desencadenaría una reversión? ¿Qué rutas de cara al cliente demuestran que la actualización ha funcionado? ¿Qué partes se pueden cambiar de forma independiente?
DFK quería controlar cada cambio en su infraestructura, no solo tener un botón de actualizar.
Adopción en torno a la disciplina de versiones
Sección titulada «Adopción en torno a la disciplina de versiones»DFK pasó a Opfield junto con un procedimiento de actualización acordado por ingeniería y operaciones.
- Separar el descubrimiento de la aprobación. El canal de actualización elegido podía anunciar una versión disponible sin cambiar la instalación en ejecución. Un operador elegía la versión de destino y la ventana de mantenimiento.
- Registrar los datos necesarios para la recuperación. Antes de cada cambio, el equipo registraba las versiones en ejecución y los digests de las imágenes, verificaba las copias de seguridad de PostgreSQL y del estado persistente, y conservaba el material de cifrado y de identidad.
- Actualizar por dominio de fallo. Opfield, los miembros de Relay y los nodos gestionados no se trataban como un único evento simultáneo. Los componentes se podían vaciar, actualizar, verificar y devolver al servicio antes de continuar.
- Verificar el sistema real. Un contenedor en ejecución no se consideraba un éxito. El inicio de sesión, el descifrado, la reconexión de los nodos, las Routes, las vinculaciones de bases de datos, los logs, la automatización y el tráfico externo formaban los criterios de finalización.
Las versiones firmadas y los artefactos de los daemons no dejan dudas sobre lo que está instalado, y los Tasks y los registros de auditoría mantienen visibles todas las decisiones después de que termine la ventana de mantenimiento.
Qué cambió más allá de las actualizaciones
Sección titulada «Qué cambió más allá de las actualizaciones»La misma disciplina mejoró la entrega habitual de aplicaciones. DFK podía conservar un despliegue que sabía que funcionaba, usar despliegues con comprobación de estado cuando correspondía y distinguir la reversión de una aplicación de la recuperación de datos. Los operadores dejaron de eliminar o recrear infraestructura solo porque fallara un despliegue.
Las relaciones de la infraestructura también se volvieron más fáciles de inspeccionar. Los servicios financieros, las conexiones privadas a bases de datos, las Routes, los certificados y el estado de los hosts dejaron de ser fragmentos sueltos en la conversación sobre cada versión. El equipo podía determinar qué capa había cambiado y evitar que un fallo local escalara a un incidente de toda la plataforma.
Resultado
Sección titulada «Resultado»Las actualizaciones pasaron a ser decisiones operativas programadas, con responsables, datos de recuperación y verificación explícitos. DFK mantuvo el control del calendario de versiones y ganó un camino más claro para adoptar nuevas capacidades de Opfield sin que el ritmo de versiones del proveedor dictara los cambios en producción.
«Después de que una actualización de Coolify tumbara un entorno de producción, dejamos de ver las actualizaciones automáticas como una comodidad. Opfield nos da un proceso de actualización que podemos revisar, programar y verificar antes de seguir adelante.»
Continúa con Actualizaciones y copias de seguridad y Ciclo de vida y seguridad para ver los procedimientos detrás de este caso.