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 · operación remota desde Rute
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. No simula una sede, un 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 · ENTREGA
Arquitectura, migración, hardening, copias verificables, monitorización y procedimiento de recuperación.
03 · 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.
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: 23/07/2026. Los datos variables se vuelven a validar antes de cada propuesta.
No. El servicio se presta en remoto desde Rute, Córdoba. Un desplazamiento a Granada solo se incluye si se acuerda en el alcance.
Arquitectura, migración, hardening, copias verificables, monitorización y procedimiento de recuperación. El presupuesto concreta qué entregables aplican y cómo se aceptan.
No. Definimos una línea base, cambios medibles y criterios de aceptación, pero no prometemos ventas, posiciones ni indexación permanente.