Cambiar sistemas críticos mientras la operación sigue en marcha

En logística y operaciones de campo, el software no es una herramienta administrativa. Decide qué camión sale primero, qué cuadrilla va a dónde y si un cliente recibe la entrega en la ventana que se le prometió. Cuando ese software se detiene, la operación se detiene con él, a menudo en cuestión de minutos.

Eso crea una tensión que todo líder de operaciones conoce. El negocio necesita nuevas capacidades: una integración con un nuevo transportador, mejores reglas de despacho, un portal para clientes, seguimiento en tiempo real. Pero cada cambio a un sistema que funciona 24/7 tiene riesgo, y el costo de un incidente se mide en envíos perdidos y horas extra, no solo en tickets de bugs.

Este artículo trata de cómo resolver esa tensión. Se basa en más de 20 años construyendo y operando software para empresas cuyos sistemas no pueden apagarse, incluidas plataformas de logística y operaciones en EE. UU.

Trata cada release como un evento operativo

En la mayoría de empresas de producto, un release es un evento de ingeniería. En operaciones críticas es un evento operativo, y debe planearse con las personas que dirigen la operación.

Eso implica algunas disciplinas sencillas:

• Ventanas de release acordadas con operaciones, no elegidas por el calendario de desarrollo. Los cambios de turno y las horas pico de despacho son el peor momento para desplegar.
• Un responsable nombrado en cada lado para todo release importante: un ingeniero y un líder de operaciones que pueden decidir el rollback.
• Una lista de verificación breve antes del release que incluya las preguntas operativas (quién debe saberlo, qué cambia para los despachadores, cómo se ve una falla en la operación) y no solo las técnicas.

Nada de esto frena la entrega. Elimina las sorpresas que hacen que los equipos teman publicar, que es lo que de verdad frena la entrega.

Cambios pequeños y reversibles

El cambio más seguro es el que puedes deshacer en minutos. Para sistemas que funcionan todo el día, ese principio debe definir cómo se construyen las funcionalidades, no solo cómo se despliegan.

• Feature flags: permiten que una nueva regla de despacho o integración salga apagada, se active para una sola bodega o región y se desactive al instante si algo no se ve bien.
• Cambios de datos compatibles hacia atrás: primero se agregan campos y tablas nuevas, los datos se migran en segundo plano y la estructura vieja se elimina solo cuando la nueva está probada en producción.
• Ejecuciones en paralelo para la lógica crítica: correr la nueva lógica de rutas o asignación junto a la existente, comparar resultados y cambiar solo cuando se entienden las diferencias.

Estos patrones agregan algo de trabajo al inicio y eliminan la mayor parte del riesgo en el momento que importa, cuando la operación real depende del cambio.

Observabilidad en el idioma de la operación

El monitoreo técnico (CPU, memoria, tasa de errores) es necesario, pero rara vez dice si la operación está sana. Un sistema puede estar en verde en todos los dashboards de infraestructura mientras las órdenes esperan sin asignar en una cola.

Instrumenta el flujo del negocio, no solo los servidores:

• Órdenes recibidas frente a órdenes asignadas, por hora.
• Tiempo entre la creación de la orden y el despacho.
• Retraso de las integraciones con transportadores, telemática o sistemas de bodega.
• Excepciones que esperan una decisión humana.

Cuando estas señales tienen umbrales y alertas, el equipo ve el problema antes de que llamen los despachadores. Además, ingeniería y operaciones comparten un vocabulario para los incidentes, lo que acorta cada conversación posterior.

Runbooks y guardias que la gente sí usa

Un runbook que nadie ha abierto desde que se escribió no es un runbook. En sistemas críticos, la respuesta a las fallas más probables debe estar escrita, ser breve y estar probada.

Los buenos runbooks para plataformas de operaciones suelen cubrir:

• Cómo identificar qué integración o servicio está fallando.
• Cómo pasar a un modo manual o degradado para que la operación siga funcionando.
• A quién llamar del lado de operaciones y qué decirle.
• Cómo hacer rollback del último release.

Revísalos después de cada incidente y de cada release importante. El objetivo es que un ingeniero mid-level de guardia a las 2 a. m. pueda estabilizar la situación y escalar con el contexto correcto, sin adivinar.

Moderniza por partes, nunca todo a la vez

Muchas plataformas de logística cargan años de lógica acumulada: reglas por transportador, excepciones por cliente, casos especiales de precios. Reescribirla en un solo proyecto es tentador y casi siempre más riesgoso de lo que parece. Nuestro artículo sobre modernizar un monolito sin detener la entrega explica en detalle el enfoque incremental.

En operaciones, elige las partes según límites operativos: una bodega, una región, un transportador, un segmento de clientes. Cada parte es lo bastante pequeña para revertirla y lo bastante real para probar el nuevo sistema en condiciones en vivo.

El equipo detrás de una operación estable

La estabilidad en producción depende tanto del equipo como de la arquitectura. El patrón que vemos funcionar en entornos con alta carga operativa:

• Ingenieros mid-level y junior integrados al equipo del cliente, en horario de EE. UU., que conocen bien el sistema y se encargan del flujo continuo de cambios, integraciones y correcciones.
• Ingenieros senior y tech leads que intervienen a medida que crece la complejidad: desbloquear al equipo durante un incidente, revisar una migración de datos riesgosa o asumir horas on-demand para trabajo de arquitectura, como un nuevo pipeline de eventos.
• Baja rotación, porque en operaciones el conocimiento más valioso no está documentado: por qué existe una regla, para qué cliente se creó, qué se rompió la última vez que alguien la cambió.

La alineación horaria importa más aquí que en casi cualquier industria. Cuando un incidente empieza en el turno de la mañana en EE. UU., las personas que pueden resolverlo tienen que estar conectadas en ese momento, no horas después.

Lista de verificación para tu próximo release importante

Antes del próximo cambio que toque despacho, rutas o una integración crítica:

1. ¿La ventana de release está acordada con operaciones?
2. ¿Se puede apagar sin volver a desplegar?
3. ¿Los cambios de datos son compatibles hacia atrás?
4. ¿Sabemos qué métrica de negocio mostrará primero un problema?
5. ¿El runbook está actualizado y el ingeniero de guardia sabe que existe?
6. ¿Hay un líder de operaciones que sabe que el cambio viene?

Si alguna respuesta es no, resuelve eso primero. Suele ser poco trabajo comparado con el costo de un incidente.

En resumen

Las operaciones críticas no necesitan menos cambios. Necesitan cambios planeados con operaciones, lo bastante pequeños para revertirlos, visibles en términos de negocio y hechos por un equipo que se queda el tiempo suficiente para entender el sistema. Puedes ver cómo se ve esto en la práctica en nuestros casos de estudio, incluido nuestro trabajo en logística y operaciones.

Si tu operación depende de software que no puede detenerse, hablemos.