Problema frecuente
¿No podéis permitiros una caída del sistema?
Cuando la operación se detiene si falla un servidor, la infraestructura no es un detalle técnico: es la continuidad del negocio. Diseñamos y operamos sistemas con alta disponibilidad real, backups que se prueban y monitorización que alguien atiende.
- 01 Redundancia y plan de fallo por componente
- 02 Backups que se restauran, no solo se programan
- 03 Alertas que llegan a una persona concreta
- 04 Plan de contingencia ya ejecutado en simulacro
El diagnóstico
"La alta disponibilidad que no se ha probado no existe. Un clúster redundante sobre el que nunca se ha simulado un fallo es una hipótesis, no una garantía."
Solvent · Infraestructura crítica
Síntomas
Señales de que estáis expuestos
Casi ninguna empresa descubre estos huecos en una auditoría. Los descubre el día que algo falla, que es el peor momento posible.
-
01
Un único punto de fallo
Si cae ese servidor, esa base de datos o ese servicio, todo se para. Y nadie lo ha nombrado.
-
02
Los backups nunca se han probado
Se programan y se ejecutan, pero nadie ha intentado restaurarlos. Hasta que hace falta, no se sabe si sirven.
-
03
Las alertas saltan y nadie las mira
O saltan demasiado y se ignoran, o no existen y el primer aviso lo da el usuario.
-
04
El procedimiento está en una cabeza
Solo una persona sabe qué hacer si el sistema cae. Y no siempre está disponible.
-
05
Nadie sabe cuánto se puede perder
Sin RPO ni RTO definidos, no hay forma de saber si la inversión en infraestructura es suficiente.
- 24/7
- Monitorización activa de sistemas críticos
- +25
- Fuentes integradas en el ecosistema portuario
- 12 años
- Operando infraestructura en producción
- 0
- Restauraciones sin probar antes de darlas por buenas
Alertas con dueño
Oracle, AS400, EDI
Desde 2013
Política interna
// Cifras de nuestra operativa real con la comunidad portuaria de Bilbao
Qué evitamos
De la falsa sensación de seguridad a la continuidad real
La diferencia no está en el hardware. Está en si alguien ha comprobado que el plan funciona.
Falsa sensación de seguridad
- Alta disponibilidad teórica que nunca se probó bajo fallo real
- Cloud contratado sin control de coste ni de acceso
- Procedimientos que solo existen en la cabeza de una persona
- Servidores sin inventario real ni endurecer
- Backups programados que nadie ha restaurado nunca
Operación estable
- Redundancia y balanceo con plan por componente
- Monitorización con logs, métricas y alertas con dueño
- Restauraciones de prueba periódicas y documentadas
- Plan de contingencia ejecutado al menos una vez
- Servidores inventariados y endurecidos
Ya lo hemos hecho antes
Sistemas críticos que mantenemos en producción
Arquitectura HA, monitorización y procedimientos de contingencia para operaciones que no pueden parar.
Alta disponibilidad y desarrollo para operaciones críticas del Puerto de Bilbao
Arquitectura de alta disponibilidad, monitorización y desarrollo de las aplicaciones que dan servicio a la comunidad portuaria de Bilbao.
Leer el caso
Intranet operativa para la terminal de contenedores CSP Iberian Bilbao
Dos intranets operativas que cubren el día a día de la terminal: tránsitos aduaneros, alertas de reefers, inspecciones, EDI, trenes, llamamientos de buques y un historial de contenedor que agrega eventos de más de 25 fuentes.
Leer el casoDudas habituales
Preguntas frecuentes
Si tu duda no está aquí, escríbenos: respondemos con criterio técnico, no con un folleto.
¿La alta disponibilidad obliga a pasarlo todo al cloud?
No. Hay cargas que rinden mejor on-premise y otras que encajan en cloud. Decidimos por componente, con criterio técnico y de coste. Lo que no es opcional es eliminar los puntos únicos de fallo, estén donde estén.
¿Cómo se comprueba que un backup sirve?
Restaurándolo. Programamos restauraciones de prueba periódicas y documentadas: se saca una copia, se levanta en un entorno aislado y se verifica que los datos y los servicios arrancan. Un backup que nunca se restauró es una hipótesis.
¿Qué son RPO y RTO?
RPO es cuántos datos podéis perder como máximo (por ejemplo, 15 minutos de facturación). RTO es cuánto podéis estar parados hasta recuperar el servicio. Definirlos es lo que permite dimensionar infraestructura con criterio, ni por exceso ni por defecto.
¿Tu infraestructura aguantaría un incidente grave?
Revisamos tu arquitectura, backups y procedimientos. Te decimos dónde estás expuesto y cómo cerrar los huecos.