Usa esta lista de verificación lista para producción para empaquetar entornos, secretos, monitorización, backups y runbooks para que operaciones pueda desplegar y hacerse cargo de tu app.
Una entrega lista para producción significa que ops puede ejecutar la app sin suponer cosas. Pueden desplegar una versión conocida, confirmar que está sana, responder a alertas y recuperarse de una mala versión o un fallo. Si cualquiera de esas tareas depende de la memoria de un desarrollador, la entrega no está terminada.
Trata la entrega como un paquete que responde a una pregunta: si los constructores originales desaparecen durante una semana, ¿puede ops mantener el sistema seguro y disponible?
Un paquete sólido suele cubrir qué hace la app, qué significa que esté “sana”, cómo funcionan las versiones (desplegar, verificar, revertir), dónde vive la configuración, cómo se manejan los secretos y cómo monitorizar, hacer backups y responder a incidentes.
Igualmente importante es lo que no cubre. Una entrega no es una promesa de añadir funciones, refactorizar, rediseñar pantallas o “limpiar las cosas después”. Esos son proyectos separados con su propio alcance.
Antes de darla por completa, acordad la propiedad y los tiempos de respuesta. Por ejemplo: ops es responsable del uptime y despliega; el equipo de producto es responsable del roadmap; el equipo de desarrollo ofrece una ventana definida de soporte post-entrega para arreglos y preguntas.
Ops solo puede gestionar lo que puede ver. Un inventario de una página evita conjeturas durante despliegues, incidentes y auditorías. Mantenlo en lenguaje llano y específico.
Lista cada parte en ejecución y dónde vive: la API backend, la app web, los workers, trabajos programados y cómo se conectan las apps móviles. Aunque iOS/Android se distribuyan por tiendas, siguen dependiendo del mismo backend.
Incluye servicios externos sin los que la app no puede funcionar. Si usas PostgreSQL, una cola, almacenamiento de objetos o APIs de terceros (pagos como Stripe, mensajería, email/SMS, Telegram), escribe el nombre exacto del servicio y para qué se usa.
Captura requisitos de red para que el hosting no sea prueba y error: dominios necesarios (app, api, admin), puertos y protocolos, quién renueva los certificados TLS, dónde se gestiona DNS y cualquier allowlist entrante/saliente.
Finalmente, anota la carga esperada con números reales: peticiones pico por minuto, usuarios activos, tamaños típicos de payload, tamaño actual de la base de datos y crecimiento esperado. Incluso rangos aproximados ayudan a ops a fijar límites y alertas.
Si has construido con AppMaster, inventaría el backend generado, la app web y las integraciones para que ops sepa qué debe desplegarse junto.
Los entornos de producción suelen fallar en la parte aburrida: la config que solo vive en la cabeza de alguien. Trata la configuración como un entregable. Ops debe poder ver qué ajustes existen, qué difiere por entorno y cómo cambiarlos de forma segura.
Empieza por nombrar cada entorno que exista hoy, aunque pienses que es temporal. La mayoría de equipos tiene dev, staging y production, más copias como “production-eu” o “staging-us”. Indica qué entorno se usa para pruebas de release, migraciones de datos y simulacros de incidentes.
Proporciona una referencia única de config que liste nombres de variables y valores de ejemplo seguros (nunca credenciales reales). Haz los placeholders evidentes.
Tu paquete de entrega debería incluir:
Añade un proceso simple de cambio. Por ejemplo: pedir mediante ticket, revisión por el responsable del servicio, aplicar primero en staging y luego promover a producción en una ventana programada con un plan de rollback si suben las tasas de error.
Si exportas y autoalojas una app de AppMaster, aplica la misma regla: envía un conjunto limpio y documentado de claves de configuración junto con el código generado para que ops pueda ejecutarlo de forma consistente entre entornos.
Los secretos son la vía más rápida para que una entrega limpia se convierta en un incidente de seguridad. El objetivo es sencillo: ops debe conocer cada secreto que la app necesita, dónde está almacenado, quién puede leerlo y cómo cambiarlo sin tiempo de inactividad.
Empieza con una lista corta de secretos que ops pueda revisar en un minuto. Para cada elemento, anota qué desbloquea (base de datos, SMTP, Stripe, clave de firma JWT), dónde está (vault, secret store de la nube, Kubernetes Secret, archivo cifrado) y quién tiene a cargo la rotación.
Escribe los pasos de rotación como una receta, no como una política. Incluye el orden exacto, cuánto debe permanecer válido el secreto viejo y la verificación única que demuestre que funcionó.
Usa este patrón para cada secreto:
Sé explícito sobre expectativas de cifrado. Los secretos deben estar cifrados en reposo en el gestor y protegidos en tránsito (TLS) entre la app y sus dependencias. Nunca pongas secretos en control de código, artefactos de build o documentos compartidos.
Define el acceso de emergencia (break-glass). Si un fallo bloquea el acceso normal, especifica quién puede aprobar el acceso de emergencia, cuánto dura y qué debe auditarse después.
Ops solo puede gestionar lo que puede reproducir. Un buen paquete de despliegue facilita tres preguntas: qué exactamente estamos ejecutando, cómo desplegarlo de nuevo y cómo volver rápido si algo falla.
Incluye una “lista de materiales” clara para la build. Nombra el tipo de artefacto y cómo verificarlo, no solo dónde está:
Añade un ejemplo pequeño y concreto. Por ejemplo: “Desplegar v1.8.2 actualizando la etiqueta de la imagen, ejecutar migraciones y luego reiniciar los workers web. Si los health checks fallan en 10 minutos, revertir a v1.8.1 y detener el job de migración.”
Un plan de rollback debe leerse como instrucciones que puedas seguir a las 2 a. m. Debe indicar:
Si la app se construyó con AppMaster y se exportó como código fuente para autoalojamiento, incluye la versión del código generado, instrucciones de build y las expectativas de runtime para que ops pueda reconstruir la misma release más tarde.
Una entrega no está completa hasta que ops puede ver qué hace la app y recibe avisos antes de que los usuarios se quejen.
Acordad qué logs deben existir y dónde van (archivo, syslog, plataforma de logs). Aseguraos de que los logs estén sincronizados en tiempo e incluyan un ID de petición o correlación para que los incidentes sean trazables de extremo a extremo.
Normalmente querrás logs de aplicación (eventos clave y fallos), logs de errores (stack traces y jobs fallidos), logs de acceso (peticiones y códigos de estado), logs de auditoría (acciones admin y exportaciones) y logs de infraestructura (reinicios, presión de nodos, problemas de disco).
Después, define un conjunto pequeño de métricas que reflejen la salud y el impacto al usuario. Si solo escoges cinco: latencia (p95/p99), tasa de errores, saturación (CPU/memoria/disco), profundidad de colas y comprobaciones de disponibilidad desde fuera de tu red.
Las reglas de alerta deben ser inequívocas: qué las activa, severidad (pagar vs ticket), quién está on-call y cuándo escalar. Añade una captura de pantalla del dashboard “bueno” y una nota corta describiendo qué es lo normal (rango típico de latencia, tasa de error esperada, profundidad usual de colas). Ese contexto evita alertas ruidosas y ayuda a nuevos respondedores a actuar rápido.
Los backups no son algo que “tienes”. Son algo desde lo que puedes restaurar, bajo demanda.
Escribe el alcance exacto: base de datos, almacenamiento de archivos (uploads, informes, facturas) y las piezas que la gente olvida, como la config que no está en código y las claves de cifrado necesarias para leer datos protegidos.
Mantén los objetivos en términos simples. RPO es cuánto dato puedes perder (por ejemplo, 15 minutos). RTO es cuánto tiempo puedes estar caído (por ejemplo, 1 hora). Elige números con los que el negocio esté de acuerdo, porque determinan coste y esfuerzo.
Incluye:
Si exportas y autoalojas una app construida con AppMaster, incluye pasos de restauración de PostgreSQL además de cualquier bucket de almacenamiento externo y las claves usadas para campos cifrados.
Programa un ejercicio de restauración. Registra el tiempo, qué falló y qué cambiaste para que la próxima vez la restauración sea más rápida y menos estresante.
Una entrega no es real hasta que alguien puede recibir una página a las 2 a. m. y arreglar el problema sin adivinar. Los runbooks convierten conocimiento tribal en pasos que una persona on-call puede seguir.
Empieza por los incidentes que esperas que ocurran primero: caída total, peticiones lentas y un despliegue que rompe algo. Mantén cada runbook corto. Pon las comprobaciones más rápidas al principio para que los respondedores obtengan señal en minutos.
Mantén la estructura consistente para que sea fácil de escanear bajo presión:
Si la app fue exportada o autoalojada desde AppMaster, incluye dónde corren los servicios generados, cómo reiniciarlos con seguridad y qué valores de config se esperan por entorno.
Mantén una checklist corta post-incidente. Registra la línea de tiempo, qué cambió último, los mensajes de error exactos, usuarios afectados y qué acción lo solucionó. Luego actualiza el runbook mientras los detalles siguen frescos.
Ops solo puede asumir la propiedad de un sistema si está claro quién puede tocar qué y cómo se rastrea el acceso.
Escribe los roles que realmente usáis. Para muchos equipos, estos son suficientes:
Documenta la “política de puertas” en pasos sencillos: quién concede acceso, dónde se concede (SSO, cloud IAM, usuarios de base de datos, CI/CD, paneles admin), quién puede revocarlo y cómo confirmar que se eliminó durante el offboarding.
No olvides los accesos no humanos. Lista cada cuenta de servicio y token usados por jobs, integraciones y monitorización, con una nota de privilegio mínimo para cada una (por ejemplo, “puede leer solo del bucket X”). Si exportas código fuente de AppMaster para autoalojar, incluye qué env vars o archivos de config definen estas identidades, pero nunca pegues valores secretos en el documento de entrega.
También fija expectativas de logs de auditoría: qué debe registrarse (login, deploy, cambio de config, acciones de admin BD), quién puede leer logs, retención, dónde se almacenan y cómo solicitar logs durante un incidente o revisión.
Las notas de seguridad deben ser legibles por no especialistas, pero lo suficientemente específicas para que ops pueda actuar. Añade una página que responda: qué datos almacenamos, dónde viven y quién puede acceder.
Empieza por tipos de datos: perfiles de clientes, tickets de soporte, metadata de pagos, archivos. Señala categorías sensibles como PII (nombres, emails, teléfonos), credenciales y cualquier dato regulado que importe a la empresa. Si exportaste código fuente para autoalojar (incluyendo desde AppMaster), indica dónde acaba esa información en la base de datos y qué servicios pueden leerla.
Luego escribe reglas de retención y eliminación en términos prácticos. Di qué conservas, por cuánto tiempo y cómo funciona la eliminación (soft delete vs borrado permanente, purga retrasada, backups). Si hay retenciones legales o necesidades de auditoría, anota quién aprueba excepciones.
Los logs a menudo filtran más que las bases de datos. Sé claro sobre dónde puede aparecer PII (logs de acceso, logs de error, eventos de analytics) y cómo reducirlo o enmascararlo. Si un campo nunca debe registrarse, dilo explícitamente.
Mantén las aprobaciones explícitas:
Si puedes añadir solo una cosa más, añade una nota de evidencia: dónde están los logs de auditoría y cómo exportarlos cuando alguien pida pruebas.
Ops asume el control de un portal de clientes construido por un pequeño equipo de producto y lo traslada a nueva infraestructura autoalojada. El objetivo no es solo “que funcione”, sino “ops puede gestionarlo sin llamar a los creadores”.
Día 1: Ops hace un primer despliegue limpio en un entorno nuevo usando solo el paquete de entrega. La app arranca, pero el login falla porque falta una variable de entorno para el proveedor de email. Eso se añade a la plantilla de env y el despliegue se repite hasta que funcione desde cero.
Día 2: Se provoca a propósito la primera alerta. Ops induce una falla controlada (detener un servicio o bloquear el envío de email) y confirma: las métricas muestran el problema, las alertas llegan al canal correcto y el mensaje indica qué hacer a continuación.
Día 3: Un token expira en el sandbox de pagos. Como la ubicación de credenciales y los pasos de rotación están documentados, ops lo reemplaza sin adivinar ni exponer secretos.
Día 4: Corte de DNS. Un registro erróneo apunta a la IP antigua y el portal parece caído para algunos usuarios. Ops usa el runbook para verificar DNS, TLS y health checks en el orden correcto.
Día 5: Primera prueba de restauración de backup. Ops restaura a una base de datos nueva y demuestra que el portal carga datos reales.
La app ha estado funcionando durante 7 días sin arreglos misteriosos, con una restauración exitosa, alertas claras y un despliegue repetible que ops puede hacer solo.
La forma más rápida de convertir una entrega tranquila en un incendio a las 2 a. m. es asumir que “les dijimos todo a ops” es igual a “ops puede gestionar sin nosotros”.
Patrones de fallo comunes tras una entrega para autoalojar incluyen secretos compartidos en hojas de cálculo o chat, rollbacks que dependen de un desarrollador, backups que existen pero nunca se probó la restauración, alertas que suenan todo el día porque los umbrales no se ajustaron y detalles de entorno que solo viven en la cabeza de alguien (puertos, nombres DNS, cron, permisos en la nube).
Ejemplo: exportas código fuente desde AppMaster para autoalojar y el primer despliegue funciona. Dos semanas después un cambio de config rompe logins. Si los secretos se pasaron por chat y el rollback necesita al creador original, ops pierde horas solo para volver a “lo que funcionaba ayer”.
Antes de cerrar el ticket, ejecuta un pequeño drill de inicio desde cero. Da el paquete de entrega a un ingeniero de ops y un entorno limpio (VM nueva, namespace de Kubernetes nuevo o un proyecto en la nube en blanco). Si puede desplegar, observar y recuperar la app dentro de un tiempo establecido (por ejemplo, 2 horas), estás cerca.
Usa estas comprobaciones:
Si exportas código fuente generado para autoalojar, confirma también que ops sabe dónde están registrados los inputs de build, versiones y tags de release para que futuras releases sigan siendo repetibles.
Haz un walkthrough final con las personas que cargarán con el pager. Trátalo como un ensayo. Demuestra que el despliegue, rollback, restauración y alertas funcionan con el paquete exacto que estás entregando.
Un walkthrough final suele cubrir: desplegar a test y luego a producción usando los mismos pasos, revertir a la versión anterior y verificar que la app sigue funcionando, restaurar desde backup en un entorno limpio y validar una comprobación real (login, crear un registro, enviar un mensaje), provocar una alerta segura y confirmar dónde encontrar logs y dashboards durante un incidente.
Haz explícita la propiedad. Asigna un responsable nombrado para cada runbook (despliegue, incidente, restauración) y para cada ruta de alerta (on-call primaria, backup, comportamiento fuera de horas). Si nadie posee una alerta, será ignorada o despertará a la persona equivocada.
Escribe un plan corto de Day 2 para que ops sepa qué mejorar tras la primera semana: ajustar umbrales, revisar costes, limpiar artefactos antiguos y revisar accesos. Manténlo pequeño y con tiempo limitado.
Si has construido con AppMaster (appmaster.io), incluye el código fuente exportado o los detalles exactos del destino de despliegue (nube, regiones, settings de build, servicios requeridos) para que ops pueda reproducir la app sin depender del workspace del proyecto original. Establece una cadencia simple para actualizar el paquete cuando cambien los requisitos, de modo que los runbooks no se desalineen de la realidad.
¿Qué significa realmente “handoff listo para producción”?Un handoff listo para producción significa que ops puede desplegar una versión conocida, confirmar que está sana, responder a alertas y recuperar de fallos sin depender de la memoria de un desarrollador específico. Si una semana sin los creadores pondría en riesgo la disponibilidad, la entrega no está completa.
¿Qué debe incluir un inventario básico del sistema?Empieza con un inventario de una página que liste cada componente en ejecución y dónde vive: API, app web, workers, tareas programadas, base de datos, almacenamiento y servicios de terceros necesarios. Añade dominios, puertos, quién gestiona DNS/TLS y una estimación de carga para que ops pueda operar sin adivinar.
¿Cómo entregamos la configuración de entornos sin filtrar secretos?Proporciona una referencia única de configuración que liste cada clave de configuración, su tipo y un valor de ejemplo seguro, además de lo que difiere entre dev/staging/prod. Mantén fuera las credenciales reales y documenta dónde se guarda la config y cómo se aplica durante los despliegues para que los cambios sean repetibles.
¿Cuál es lo mínimo que debemos documentar sobre secretos y rotación de credenciales?Crea una lista corta de secretos que indique para qué sirve cada uno, dónde está guardado, quién puede leerlo y quién es responsable de su rotación. Escribe los pasos de rotación como una checklist con una verificación clara y añade un proceso de acceso de emergencia (break-glass) con expectativas de auditoría.
¿Qué hace que un paquete de despliegue sea “reproducible” para ops?Ops necesita saber exactamente qué está corriendo y cómo reproducirlo: nombre/etiqueta del artefacto, versión, fecha de build, checksum y la referencia de origen usada para construirlo. Incluye el objetivo de despliegue recomendado, el orden del despliegue, el tiempo esperado y cómo se ejecutan y verifican las migraciones de base de datos.
¿Qué debe incluir un plan de rollback para ser útil a las 2 a. m.?Define las señales que disparan el rollback (como checks de salud fallidos o aumento de errores), la última versión conocida buena y los pasos exactos para revertir rápidamente. Indica si los cambios de base de datos son reversibles y cuál es la alternativa segura si no lo son, para que el rollback no sea improvisado.
¿Qué señales de monitorización debemos priorizar durante el handoff?Elige un conjunto pequeño de métricas que reflejen el impacto al usuario: latencia (p95/p99), tasa de errores, saturación (CPU/memoria/disco), profundidad de colas y una comprobación de disponibilidad externa. Haz las reglas de alerta explícitas sobre severidad, quién recibe la página y qué significa “normal” y asegúrate de que los logs estén sincronizados en tiempo y sean trazables con un ID de correlación.
¿Cómo hacemos que backups y restores sean realmente fiables?Documenta qué se respalda, dónde se guarda, la retención y quién puede ejecutar restores. Incluye un procedimiento paso a paso para restaurar con una verificación, y programa un ejercicio de restauración; los backups solo importan si puedes restaurar a demanda en un entorno limpio.
¿Cómo debe ser un runbook para on-call ante incidentes comunes?Mantén los runbooks cortos y consistentes: síntomas, primeras comprobaciones, siguientes pasos, puntos de decisión y escalamiento. Céntrate en los incidentes más probables (caída total, lentitud, despliegue que rompe) y actualiza el runbook justo después del incidente para que el conocimiento no se difumine.
¿Cómo documentamos control de acceso y permisos para que ops pueda asumir la propiedad?Escribe los roles reales que usáis (deployer, admin BD, solo lectura, comandante de incidentes), cómo se concede y revoca el acceso, y qué debe registrarse para auditoría. No olvides las cuentas de servicio y tokens; lista a qué pueden acceder y dónde se configuran sus identidades sin incluir valores secretos.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
