El problema que resuelve
Un buen sistema puede fallar por razones que no tienen que ver con su código: un servidor sin espacio en disco, un certificado vencido, un respaldo que nunca se probó o un despliegue manual en el que se olvidó un paso. La infraestructura es lo que permite que el software esté disponible, sea seguro y pueda recuperarse cuando algo sale mal.
Esta solución está pensada para la infraestructura que necesitan las soluciones que desarrollamos e integramos: dónde se ejecutan, cómo se publican, cómo se vigilan y cómo se recuperan.
Situaciones en las que resulta útil
- Un sistema nuevo que necesita un entorno de producción definido desde el inicio.
- Una aplicación que hoy se publica copiando archivos a mano y con pasos que solo conoce una persona.
- Sistemas sin monitoreo, donde los problemas se descubren por reclamos de usuarios.
- Servicios sin respaldos verificados o sin un procedimiento de recuperación documentado.
- Costos de infraestructura que crecieron sin una revisión de lo que realmente se usa.
Cómo lo abordamos
- Requisitos de operaciónDisponibilidad esperada, volumen, datos y presupuesto.
- Diseño de entornosDesarrollo, pruebas y producción separados.
- Despliegue automatizadoPublicar de forma repetible y reversible.
- Monitoreo y alertasDetectar problemas antes que los usuarios.
- Respaldo y recuperaciónCopias verificadas y procedimiento probado.
La elección del tipo de infraestructura —servicios en la nube, servidores virtuales o infraestructura del cliente— se hace por proyecto según los requisitos de disponibilidad, los datos involucrados, las capacidades del equipo que operará el sistema y el presupuesto. No existe una opción correcta para todos los casos.
| Modelo | Ventajas | Puntos de atención |
|---|---|---|
| Servicios administrados en la nube | Menos mantenimiento de sistema operativo, escalado sencillo, respaldos integrados. | Costos variables que deben vigilarse; dependencia de servicios específicos del proveedor. |
| Servidores virtuales (VPS / máquinas virtuales) | Costo predecible y control total del entorno. | La actualización, seguridad y respaldo del sistema operativo quedan a cargo del equipo. |
| Infraestructura propia del cliente | Control físico de los datos y aprovechamiento de inversiones existentes. | Requiere personal, redundancia y procedimientos propios de continuidad. |
Componentes habituales
- Entornos separados con credenciales y datos distintos para desarrollo, pruebas y producción.
- Integración y despliegue continuos (CI/CD): cada cambio se construye, se prueba y se publica de la misma manera.
- Configuración como código, para poder reconstruir un entorno sin depender de la memoria de alguien.
- Gestión de secretos fuera del repositorio de código.
- Monitoreo de disponibilidad, errores, tiempos de respuesta y recursos, con alertas accionables.
- Health checks que indiquen si cada servicio está vivo y listo para recibir tráfico (ver health checks útiles).
- Respaldos automáticos con pruebas periódicas de restauración.
- Certificados TLS con renovación automática y dominios correctamente configurados.
Consideraciones técnicas
Despliegues reversibles
Todo despliegue debería poder deshacerse rápidamente. Mantener la versión anterior disponible y aplicar cambios de base de datos compatibles hacia atrás permite volver atrás sin pérdida de datos si una versión presenta problemas.
Respaldos que se prueban
Un respaldo que nunca se restauró es una suposición. Conviene definir cuánta información se puede perder como máximo (punto de recuperación) y en cuánto tiempo debe volver el servicio (tiempo de recuperación), y probar periódicamente que esos objetivos se cumplen.
Monitoreo orientado a síntomas
Las alertas más útiles describen lo que siente el usuario —errores, lentitud, indisponibilidad— y no solo el uso de CPU. Demasiadas alertas irrelevantes hacen que se ignoren las importantes.
Seguridad
Aplicamos el principio de mínimo privilegio en accesos y credenciales, exposición pública solo de los servicios necesarios, actualizaciones de seguridad periódicas, cifrado en tránsito, registros de acceso y separación de los datos de producción. Los accesos administrativos deben ser nominales y revocables, nunca compartidos.
Escalabilidad y costos
Escalar no siempre significa más servidores. Antes de ampliar recursos conviene revisar consultas lentas, ausencia de caché o procesos que podrían ejecutarse en segundo plano. Cuando sí se necesita más capacidad, una aplicación sin estado en memoria permite agregar instancias detrás de un balanceador. En la nube, revisar periódicamente el consumo evita pagar por recursos que nadie usa.
Operación y mantenimiento
La operación continua incluye aplicar actualizaciones, revisar alertas, renovar certificados, verificar respaldos, ajustar capacidad y documentar los procedimientos de recuperación. Lo recomendable es que esta documentación exista y esté accesible para el cliente, de modo que la continuidad no dependa de una sola persona.
Relación con los productos de INTEDI
Los productos de INTEDI, como Fidelio o Paybridge, necesitan esta misma base para operar: entornos separados, monitoreo y procedimientos de recuperación.
Preguntas frecuentes
¿Con qué proveedor de nube trabajan?
La elección se hace según los requisitos de cada proyecto. Lo importante es que la decisión considere costos, ubicación de los datos, servicios necesarios y la capacidad de quien operará el sistema.
¿Pueden trabajar con la infraestructura que ya tengo?
Sí es posible evaluarlo. Se revisa qué existe, cómo se administra y si cumple los requisitos de la solución antes de proponer cambios.
¿Cada cuánto deben probarse los respaldos?
Depende de la criticidad del sistema, pero debe ser una tarea programada, no una reacción ante un incidente. Lo importante es que la restauración se haya probado antes de necesitarla.