El runbook que debe incluir una entrega de software

La entrega de software debe incluir un runbook probado para las tareas que el equipo receptor necesita realizar sin el desarrollador original. Acceder al repositorio y conocer la arquitectura aporta contexto, pero no explica cómo recuperar una tarea detenida ni cómo comprobar que un despliegue funcionó.

La prueba de aceptación es práctica: ¿alguien con los permisos previstos puede seguir el procedimiento y obtener el resultado esperado?

Organizá procedimientos por trabajo, no por componentes

Empezá con tareas operativas recurrentes: desplegar una versión, investigar una integración fallida, restaurar datos en un entorno seguro y revocar accesos. Cada una necesita un procedimiento con una condición de entrada clara. Un capítulo llamado “Base de datos” no dice cuándo utilizarlo.

La guía de runbooks de AWS pide herramientas y permisos necesarios, manejo de errores, escalamiento y validación por otra persona. Son criterios de entrega útiles sin importar dónde se aloje el sistema.

Vinculá los procedimientos con su responsable y su proceso de cambios. Si modificar el despliegue vuelve incorrecta una instrucción, actualizarla forma parte del mismo trabajo. Revisarla solo cuando se renueva el contrato permite que se desactualice.

Definí el alcance operativo de cada procedimiento

Revisá esta lista en las tareas importantes:

• Resultado esperado y situaciones donde el procedimiento no aplica.
• Entorno, rol de acceso, herramientas y requisitos previos.
• Pasos con marcadores seguros y observaciones esperadas.
• Condiciones para detenerse antes de acciones destructivas o ambiguas.
• Recuperación, comprobación y escalamiento si el resultado difiere.
• Responsable y fecha del último ensayo exitoso.

Enlazá la ubicación aprobada de los secretos en vez de copiar credenciales al documento. Diferenciá claramente pruebas y producción. Si volver a la versión anterior no revierte una migración de datos, explicá la decisión real de recuperación. “Desplegar lo anterior” no resuelve ese caso por sí solo.

Ejemplo hipotético: una exportación detenida

El equipo receptor necesita recuperar una exportación que quedó pendiente tras un timeout del proveedor. “Reiniciar el trabajador” es insuficiente: el destino podría haber aceptado la operación.

El procedimiento pide localizar el identificador e inspeccionar el estado persistido. Luego explica cómo consultar la referencia externa. Un registro existente confirmado se concilia localmente; un reintento seguro confirmado conserva la misma identidad. Si el resultado externo sigue siendo desconocido, corresponde escalar, no enviar otra solicitud independiente.

La verificación incluye registro de destino, estado final local y ausencia de acciones duplicadas. También indica qué puede comunicar soporte mientras la conciliación continúa pendiente. Son pasos hipotéticos para adaptar al sistema, no instrucciones para ejecutar a ciegas en una plataforma desconocida.

Ensayá antes de dar por terminada la entrega

Pedile a quien recibe que haga un ejercicio acotado en un entorno seguro, mientras el autor observa sin tomar el control. Los permisos faltantes y supuestos sin explicar van a la lista de pendientes, aunque el desarrollador original pudiera resolverlos rápidamente.

Si equipos de Costa Rica y Estados Unidos comparten operación, documentá horarios de cobertura y siguiente responsable. Coincidir en horario laboral no define atención fuera de horario. Acordá también el idioma de las instrucciones para que puedan leerse bajo presión.

Antes de firmar la próxima entrega, elegí un procedimiento de recuperación para un ensayo independiente. Incluí sus vacíos en el alcance de entrega de software a la medida. Una vez corregidos, repetí los pasos bloqueados con la persona que recibirá la operación.