Garantie de disponibilité

Chez Kinsta, bien que nous ne proposions pas d’hébergement à haute disponibilité (HA), nous offrons une garantie de temps de fonctionnement soutenue par un accord de niveau de service (SLA). Chez Kinsta, chaque site sur notre plateforme fonctionne dans un seul conteneur Linux, et la base de données du site fonctionne comme un service dans le conteneur du site, le tout construit sur des serveurs haute performance de niveau entreprise. Nous n’exécutons pas d’instances multiples à charge équilibrée pour chaque infrastructure de site.

Pour plus de détails sur notre infrastructure et notre architecture, voir :

• Infrastructure d’hébergement d’applications et de bases de données
• Infrastructure d’hébergement de sites statiques
• Infrastructure d’hébergement WordPress

Grâce à la flexibilité offerte par l’utilisation d’une infrastructure basée sur des conteneurs, à la gestion proactive de la charge par notre équipe d’ingénieurs et à l’utilisation de plateformes cloud de premier plan, nous sommes en mesure d’offrir une garantie de temps de fonctionnement (SLA) allant jusqu’à 99,9 %. Pour les plans personnalisés, nous pouvons offrir une garantie de temps de fonctionnement améliorée allant jusqu’à 99,99 %. Pour plus d’informations à ce sujet, veuillez contacter notre équipe commerciale.

Période de maintenance

La période de maintenance de Kinsta a lieu chaque jour, du lundi au dimanche, de 2h à 5h du matin, heure locale, en fonction du fuseau horaire du centre de données dans lequel chaque application est hébergée. Nous n’envoyons pas de notifications de surveillance si une maintenance est effectuée pendant cette période. Pour plus d’informations, reportez-vous à l’accord de niveau de service de Kinsta.

Circonstances qui bloquent la surveillance du temps de fonctionnement

Afin de nous assurer que nous respectons notre garantie de temps de fonctionnement, nous surveillons chaque site sur notre plateforme pour le temps de fonctionnement. Lorsque l’un de nos moniteurs de temps de fonctionnement tombe en panne, nos ingénieurs réagissent immédiatement et s’efforcent de rétablir le service sur le site. Cependant, il existe quelques scénarios dans lesquels notre capacité à surveiller le temps de fonctionnement peut être limitée :

• Si l’authentification de base est activée, toutes les requêtes non autorisées recevront une erreur 401.
• Le mode « Je suis attaqué » de Cloudflare a un temps d’attente de 5 secondes pour prévenir les attaques DDoS. Ce délai ne s’applique pas aux requêtes HEAD, qui recevront une erreur 503.
• Les sites à proxy inversé dont le domaine principal ne redirige pas vers l’URL cible.
• Certains cas de mise en cache personnalisée peuvent poser problème. Par exemple, si vous mettez en cache la chaîne de requête HEAD de Kinsta. Les services de proxy tels que Sucuri et Cloudflare peuvent aussi parfois causer des problèmes de mise en cache, en fonction de la configuration.
• Service de blocage des robots : Notre moniteur de temps de fonctionnement utilise kinsta-bot comme user-agent, donc si vous le bloquez avec une extension ou un service (user-agent deny), cela peut faire échouer notre moniteur de temps de fonctionnement (cela se traduit généralement par un code de réponse 406).
• Le blocage de l’adresse IP ou du pays d’origine de notre moniteur de temps de fonctionnement (Geo-block) aura un impact sur notre surveillance. Si vous configurez ces fonctionnalités sur les serveurs de Kinsta, ce n’est pas un problème puisque nous ajoutons des exceptions.
• Si le domaine primaire ne se résout pas à l’installation où il est ajouté ou s’il a une redirection vers un autre domaine (listé dans la liste des domaines du même site).
• Lorsqu’un site est en mode maintenance, il peut renvoyer une réponse 503.