01 · CRITERIO
Cómo decidimos
No prometemos una latencia universal: medimos la aplicación, definimos el SLO y diseñamos copias y alertas según el riesgo.
Cobertura en Granada
La infraestructura debe dimensionarse con datos de tráfico, tolerancia a fallos, recuperación y mantenimiento.
Esta URL se restaura por las consultas de infraestructura de Granada —«hosting granada», «servidores en granada», «empresa de hosting granada»—. Las consultas de continuidad y cuidado del sitio pertenecen a la página de mantenimiento de Granada, no a esta, y se enlazan desde aquí para no competir por la misma intención. Trabajamos en remoto desde Rute y no simulamos sede, equipo ni casos de cliente en Granada.
El supuesto es una web con crecimiento estacional que necesita saber si su alojamiento aguanta un pico. Se revisa caché, base de datos y límites del plan, y se prueba el comportamiento bajo carga antes de la campaña, no durante.
01 · CRITERIO
No prometemos una latencia universal: medimos la aplicación, definimos el SLO y diseñamos copias y alertas según el riesgo.
02 · VALIDACIÓN
Esta página no cubre el mantenimiento correctivo ni las actualizaciones periódicas: eso corresponde al servicio de mantenimiento. Aquí se decide la infraestructura.
Territorio
Granada vive en buena medida de la universidad y del turismo. La Alhambra atrae visitantes todo el año, y alrededor de ella hay hoteles, guías, restaurantes y comercios que dependen de reservas online. A la vez, la Universidad y el Parque Tecnológico de la Salud han generado empresas biotecnológicas y de software que manejan datos sensibles.
Esas dos caras piden cosas distintas a la infraestructura. El turismo necesita velocidad y disponibilidad cuando se abren las entradas o llega un puente; la biotecnología y la salud necesitan saber dónde residen los datos, quién los trata y cómo se protegen, porque la normativa de protección de datos es más exigente con la información sanitaria.
La provincia añade la Costa Tropical, con Almuñécar y Motril, y la estación de Sierra Nevada, que concentran temporada en verano e invierno respectivamente. Un mismo proveedor granadino puede tener clientes con picos opuestos, y la capacidad debe seguirlos en lugar de estar dimensionada siempre para el máximo.
Encargos habituales
Escenarios, no casos de cliente.
Servidor para una plataforma que trata datos clínicos de investigación: alojamiento en la Unión Europea, cifrado, accesos registrados, contrato de encargo de tratamiento y copias restaurables documentadas.
Web de reservas que se satura cuando se liberan entradas. Se cachea todo lo informativo, se aísla el proceso de compra y se prueba la carga antes de las fechas fuertes.
Capacidad que crece en invierno y se reduce en verano, con copias diarias y una alerta que llega al responsable, no a un buzón genérico, cuando la web deja de responder.
Contexto
Esta página cubre las consultas de infraestructura de Granada. La distinción importa porque la provincia genera también búsquedas de continuidad y cuidado del sitio, y esas pertenecen a la página de mantenimiento: si ambas intentaran responder a lo mismo competirían entre sí en lugar de con la competencia.
El caso que se repite en negocios con estacionalidad marcada es el de una infraestructura dimensionada para el día normal que se descubre insuficiente el día de la campaña. El techo no se manifiesta como una caída limpia sino como lentitud creciente, que es peor: el visitante se va sin que ningún sistema registre un error.
Averiguar dónde está ese techo requiere provocarlo en un entorno controlado. Es la parte del trabajo que más se salta y la única que da una respuesta fiable antes de que la dé el tráfico real.
Alcance
Qué picos previsibles tiene el negocio a lo largo del año y qué multiplicador sobre el tráfico normal representan.
Qué porcentaje de peticiones se resuelve sin llegar al servidor y cuál debería resolverse, con la configuración necesaria para conseguirlo.
Ensayo controlado que localiza el límite real antes de la campaña, con el informe de qué componente cede primero.
Dictamen sobre si conviene separar base de datos y aplicación, con el coste y la complejidad añadida de hacerlo.
Qué se puede escalar temporalmente durante la campaña y qué requiere decisión con antelación.
Se empieza midiendo el comportamiento actual con datos de campo y no con una prueba sintética puntual: qué tiempos ven los usuarios reales, en qué momentos del día y desde qué dispositivos. Esa medición determina si el problema es de infraestructura o de aplicación, y con frecuencia resulta ser lo segundo, en cuyo caso ampliar el servidor solo habría trasladado el gasto.
Checklist previo
Fuentes primarias
Conceptos técnicos de CDN, caché, latencia y rendimiento.
Controles verificables para seguridad de aplicaciones.
Revisión editorial: 28/09/2026.
Preferiblemente en la Unión Europea, con cifrado, control de accesos y un contrato que regule el tratamiento. Los datos de salud tienen protección reforzada y conviene poder demostrar dónde están y quién los toca.
Separando lo informativo, que va a caché, del proceso de reserva, que se dimensiona y se prueba con carga antes. La mayoría de caídas en esas fechas son previsibles.