Tiempo de Actividad Garantizado
En Kinsta, aunque no ofrecemos alojamiento de alta disponibilidad (HA, high availability), sí ofrecemos una garantía de tiempo de actividad respaldada por un Acuerdo de Nivel de Servicio (SLA, Service Level Agreement). En Kinsta, cada sitio de nuestra plataforma se ejecuta en un único contenedor Linux, y la base de datos del sitio se ejecuta como un servicio dentro del contenedor del sitio, todo ello basado en Google Cloud Platform (GCP) y Cloudflare. No ejecutamos múltiples instancias de carga equilibrada de la infraestructura de cada sitio.
Para más detalles sobre nuestra infraestructura y arquitectura, consulta:
- Infraestructura de Alojamiento de Aplicaciones y Bases de Datos
- Infraestructura de Alojamiento de Sitios Estáticos
- Infraestructura de Alojamiento de WordPress
Gracias a la flexibilidad que nos proporciona el uso de una infraestructura basada en contenedores, la gestión proactiva de la carga por parte de nuestro equipo de Ingeniería y el uso de un proveedor de nube de primera clase en Google Cloud Platform, podemos ofrecer una garantía de tiempo de actividad respaldada por SLA del 99,9%.
Circunstancias que Bloquean el Control del Tiempo de Actividad
Para asegurarnos de que cumplimos nuestra garantía de tiempo de actividad, supervisamos el tiempo de actividad de todos los sitios de nuestra plataforma. Cuando falla uno de nuestros monitores de tiempo de actividad, nuestros ingenieros responden inmediatamente y trabajan para restablecer el servicio del sitio. Sin embargo, hay algunas situaciones en las que nuestra capacidad para controlar el tiempo de actividad puede verse limitada:
- Si tienes activada la autenticación básica, se mostrará un error 401 a todas las solicitudes no autorizadas.
- El modo Estoy siendo atacado (I’m under attack) de Cloudflare tiene un tiempo de espera de 5 segundos para evitar ataques DDoS. Esto no se aplica a las solicitudes HEAD, ya que éstas responderán con un error 503.
- Sitios de proxy inverso en los que el dominio principal no redirige a la URL de destino.
- Ciertos casos de caché personalizada pueden causar problemas. Por ejemplo, si almacenas en caché la petición HEAD de cadena de consulta de Kinsta. Los servicios proxy como Sucuri y Cloudflare también pueden causar a veces problemas con el almacenamiento en caché, dependiendo de la configuración.
- Servicio de bloqueo de bots: Nuestro monitor de tiempo de actividad utiliza el
kinsta-bot
como agente de usuario, por lo que si lo bloqueas con un plugin o servicio (user-agent deny), esto puede hacer que nuestro monitor de tiempo de actividad falle (esto suele dar como resultado un código de respuesta 406). - Bloquear la(s) dirección(es) IP de nuestro monitor de tiempo de actividad o el país de origen (Geo-block) afectará a nuestra monitorización. Si configuras estas funciones en los servidores de Kinsta, no es un problema, ya que añadimos excepciones.
- Si el dominio principal no se resuelve en la instalación donde se ha añadido o tiene una redirección a otro dominio (que aparece en la lista de dominios del mismo sitio).
- Cuando un sitio está en modo de mantenimiento, puede devolver una respuesta 503.