Pourquoi votre site a besoin d'une surveillance d'uptime

Ce qui met un site en panne

Un site peut cesser de répondre pour des raisons qui n'ont rien à voir entre elles. La liste habituelle :

• Du mauvais code, y compris un déploiement qui a passé la revue et échoué en production
• Des pannes de l'hébergeur, d'une seule machine à tout un centre de données
• Des limites d'hébergement atteintes : bande passante, connexions, quota CPU, disque
• Des tentatives de piratage contre l'application ou le serveur
• Des attaques DDoS, qui submergent l'hébergeur jusqu'à ce qu'il cesse de répondre à toute requête, bonne ou mauvaise
• Un enregistrement de domaine expiré
• Un certificat TLS expiré, qui fait refuser la connexion par tous les navigateurs

La plupart de ces cas sont sous votre contrôle. Vous pouvez relire le code, dimensionner l'hébergement au trafic, et renouveler un domaine et un certificat à temps. Les tentatives de piratage et le trafic DDoS ne le sont pas : vous ne pouvez que les limiter et les absorber. Ce que ces sept cas ont en commun, c'est que le serveur vous prévient rarement. Une machine qui ne peut pas joindre internet ne peut pas vous envoyer un message pour le dire, et un certificat expiré à minuit n'ouvre pas de ticket.

Ce que coûte une panne pendant que vous l'ignorez

Un visiteur qui tombe sur « Serveur introuvable » actualise une fois, vérifie que l'adresse a été correctement saisie, puis cherche un site qui fonctionne. La fenêtre pendant laquelle vous gardez cette personne est courte, et elle se referme sans que personne ne vous prévienne.

Le calcul est facile à faire pour votre propre site. Prenez une valeur moyenne de commande de 25 $ et 50 visiteurs par heure qui convertissent : cette heure vaut environ 1 250 $, et une heure d'indisponibilité coûte ces mêmes 1 250 $. Rien dans vos statistiques n'enregistre cette heure comme une perte : les commandes qui n'ont pas eu lieu ne laissent qu'un creux que vous attribuerez à autre chose la semaine suivante. Des pages lentes font des dégâts similaires, en plus discret. Le site répond, la vérification passe, et les visiteurs partent quand même.

Comment la surveillance change la séquence

La surveillance remplace « un client nous a prévenus » par « la vérification a échoué à 03h14 depuis quatre emplacements ».

1. Elle démarre le chronomètre plus tôt. Le temps de réparation se mesure à partir du moment où vous savez, donc tout ce qui raccourcit le délai de détection raccourcit la panne.
2. Elle vous donne des preuves. Quelle vérification a échoué, depuis quels emplacements, avec quel code de statut ou délai dépassé, et quand était le dernier bon résultat. C'est déjà l'essentiel d'un diagnostic avant même d'avoir ouvert un terminal.
3. Elle vous dit la différence entre « en panne pour tout le monde » et « en panne depuis un seul réseau », car les vérifications s'exécutent depuis de nombreux endroits à la fois plutôt que depuis un serveur unique.

La vérification externe est la partie qu'un journal côté serveur ne peut pas remplacer. Si le problème vient du chemin réseau, de l'enregistrement DNS ou du certificat, le serveur ne voit strictement rien d'anormal. Exécuter la même requête depuis de nombreux pays, l'idée derrière la surveillance de disponibilité distribuée, est ce qui rend une panne régionale visible comme une panne régionale plutôt que comme un mystère.

Que surveiller au-delà du simple actif/en panne

Une vérification de disponibilité répond à une seule question. Ce qui casse un site est en général visible ailleurs en premier :

• L'uptime et les temps d'arrêt du serveur, la vérification de base
• Le temps de réponse, qui se dégrade avant d'échouer complètement
• La pression CPU, RAM et disque sur le serveur
• La charge de la base de données et la latence des requêtes
• L'expiration du domaine
• L'expiration du certificat
• Le contenu de la page, afin qu'un site qui renvoie 200 avec une page d'erreur soit quand même détecté

L'expiration du domaine et du certificat mérite une remarque à part, car ce sont les deux seules pannes dont on connaît la date à l'avance. Toutes deux sont entièrement évitables grâce à une alerte réglée des semaines en amont.

Réduire l'indisponibilité une fois qu'on peut la voir

1. Placez un moniteur sur le site, depuis l'extérieur, avec un intervalle assez court pour qu'une panne se mesure en minutes plutôt qu'en heures. Lancez d'abord une vérification HTTP ponctuelle depuis plusieurs emplacements pour voir comment le site répond aujourd'hui.
2. Choisissez un hébergeur avec une marge de capacité et des antécédents que vous avez vérifiés vous-même plutôt qu'on vous les a rapportés. Une offre « illimitée » ne l'est pas.
3. Gardez l'application, le logiciel serveur et les extensions à jour. Un site compromis perd plus que sa disponibilité : il perd sa crédibilité auprès des clients et des moteurs de recherche.
4. Réglez des alertes d'expiration pour le domaine et chaque certificat, avec assez de marge pour renouveler.

Vérifier une fois versus savoir quand ça casse

Une vérification lancée à la main répond pour l'instant où vous l'avez lancée. Un moniteur répond en continu et vous dit quand la réponse change. HostTracker surveille des sites web depuis 2004 et observe aujourd'hui plus de 500 000 sites depuis plus de 300 points de contrôle répartis dans 158 villes, sur 13 types de moniteurs, avec des alertes par e-mail, SMS, appel vocal, Slack, Telegram et bien d'autres canaux. Consultez l'ensemble des fonctionnalités pour ce que ces vérifications couvrent, le guide de la vérification HTTP pour celle par laquelle la plupart des sites commencent, et le reste de la section des concepts de surveillance pour les termes qui s'y rattachent.