Indisponibilité d’un site web

Lorsqu’un site web ou un service web n’est pas disponible en ligne ou ne fonctionne pas assez bien pour que les utilisateurs puissent y réaliser une tâche, le site est considéré comme étant indisponible.

Bien que la plupart des sites web et des services web visent une indisponibilité de niveau zéro, des moments d’indisponibilité sont inévitables. Même les géants comme Google et Facebook connaissent occasionnellement des indisponibilités. La technologie s’est améliorée et les fournisseurs ont mis en place des systèmes pour aider à éliminer les indisponibilités, mais des circonstances imprévisibles peuvent toujours causer des indisponibilités.

Qu’est-ce qu’une indisponibilité ?

L’indisponibilité (ou “downtime”) est un terme subjectif, tout comme son contraire la disponibilité (ou “uptime”). Aux prémices d’Internet, l’indisponibilité signifiait généralement qu’un site était inaccessible pour ses utilisateurs finaux. Aujourd’hui, la notion d’indisponibilité est plus complexe. On considère généralement qu’un site ou un service est indisponible si les utilisateurs finaux ne peuvent pas réaliser leur tâche. Par exemple, un site de commerce électronique est indisponible si les utilisateurs finaux ne peuvent pas mettre un article dans leur panier d’achats. En réalité, les visiteurs pardonnent davantage à un site qui subit une panne complète qu’à un site qui est disponible, mais qui ne fonctionne pas bien. Des performances médiocres peuvent également tomber dans la catégorie des indisponibilités si elles empêchent les utilisateurs finaux d’atteindre leur objectif.

Qu’est-ce qui produit les indisponibilités ?

Pour un fournisseur, beaucoup de choses peuvent être à l’origine d’une indisponibilité. Certaines causes sont sous son contrôle, telles que la maintenance planifiée, mais d’autres ne le sont pas. Chaque situation est unique, mais la plupart des causes tombent dans les catégories suivantes.

Erreur humaine

Comme toujours, quand quelque chose ne va pas, la cause profonde mène généralement à une seule erreur commise par un individu ou une équipe. Un changement de code apparemment bénin peut affecter quelque chose qui n’apparaît pas lors des tests de régression, un système peut être déconnecté alors qu’il n’aurait pas dû l’être, ou une entrée DNS peut être mise à jour incorrectement. Et ce ne sont là que quelques exemples d’erreurs humaines pouvant causer l’indisponibilité d’un site. L’énorme panne qui a frappé AWS début 2017 est un exemple concret de la façon dont quelque chose d’aussi simple qu’une faute de frappe peut provoquer des indisponibilités qui ont non seulement affecté Amazon Web Services, mais également causé des pannes sur de nombreux sites web importants.

Panne d’équipement

L’équipement s’use et tombe en panne, et même les équipements neufs peuvent cesser de fonctionner sans prévenir. Une bonne maintenance et la redondance matérielle sont les seuls moyens de minimiser les indisponibilités dues au matériel. Un autre exemple en provenance d’Amazon : en 2010, le géant du commerce électronique a subi une panne qui a touché la plupart des pays en Europe. On a d’abord soupçonné que des pirates avaient cassé le site, mais Amazon a révélé ultérieurement que l’indisponibilité était due à une panne matérielle dans leur centre de données.

Attaque malveillante

Les hackers découvrent constamment de nouvelles façons intelligentes d’infiltrer et de perturber les entreprises. Une méthode courante est l’attaque DDoS (Distributed Denial-of-Service). Les attaques par déni de service tentent de submerger les serveurs avec des requêtes. Les requêtes proviennent simultanément et de manière répétée de plusieurs emplacements provoquant une surcharge des serveurs web de la cible. Le déluge de requêtes a comme effet de bloquer les requêtes légitimes, ce qui fait échouer le site. Un autre type d’attaque est l’empoisonnement du cache DNS où les pirates infiltrent le cache du DNS (Domain Name System) et modifient l’adresse IP de façon à pouvoir exploiter les utilisateurs du site. Le résultat est que le site cible n’est plus disponible. D’autres attaques impliquent des certificats SSL et des logiciels malveillants.

Comment les sites web évitent-ils les indisponibilités ?

En ce qui concerne le matériel, les entreprises utilisent la redondance pour s’assurer que les systèmes de sauvegarde restent prêts en cas de panne, et les équilibreurs de charge et les centres de données contribuent à maintenir les performances. Les services de monitoring synthétique surveillent les sites web, les serveurs, les API et les applications web pour détecter les pannes, les performances et les problèmes de fonctionnement. Le service de surveillance alerte les équipes de support lorsque les choses ne fonctionnent pas correctement.

Surveillance de la disponibilité

Aussi appelée surveillance de site web la surveillance de la disponibilité (ou monitoring uptime) est un type de surveillance synthétique qui utilise un réseau d’ordinateurs (les checkpoints) pour envoyer des requêtes, des pings et des connexions à des sites web et des serveurs. Ces moniteurs de base vérifient les codes de réponse et les temps de réponse et envoient les résultats au service de surveillance. Si une erreur se produit ou si la réponse prend plus de temps que prévu, le service de surveillance peut émettre une alerte ou valider l’erreur à partir d’un autre checkpoint avant de déclencher les alarmes.

Surveillance avancée de la disponibilité

La surveillance avancée de la disponibilité utilise des types de surveillance spécialisés pour vérifier la disponibilité en fonction de serveurs ou de fonctions spécifiques. Les entreprises utilisent cette surveillance avancée afin de :

• vérifier le contenu et la date d’expiration des certificats TLS/SSL ;
• vérifier l’intégrité du DNS en contrôlant les champs clés sur un enregistrement DNS ;
• communiquer avec les serveurs de messagerie POP3, SMTP, et IMAP ;
• interroger et vérifier les bases de données MySQL et SQL Server ; et
• vérifier la disponibilité et les téléchargements pour FTP et SFTP.

Surveillance des performances et des fonctionnalités

La surveillance de disponibilité et la surveillance avancée sont utiles pour vérifier les pannes du système, mais elles sont moins adaptées pour vérifier les performances et les fonctionnalités. Avec la surveillance des performances, la surveillance des applications web, et le monitoring d’API, la surveillance de la disponibilité atteint un niveau supérieur.

Surveillance des performances web

Les moniteurs de performance font plus qu’émettre et recevoir une requête : ils utilisent des navigateurs réels comme Chrome et Edge pour envoyer la requête et recevoir la réponse. Les checkpoints font plus que vérifier le retour des messages d’erreur : ils chargent la réponse dans un navigateur. Le chargement du contenu permet aux requêtes suivantes de s’exécuter et les scripts et contenus de la page de se charger dans le navigateur. Le moniteur vérifie les performances de chaque élément de page. Un service de surveillance génère un rapport visuel sous la forme d’un graphique en cascade pour un examen plus facile. Les graphiques en cascade facilitent l’analyse des causes premières en identifiant un contenu peu performant (tiers ou natif) et en signalant les performances côté client et côté serveur (front-end et back-end) de chaque élément.

Surveillance des applications web

Un site peut être disponible mais ne pas fonctionner correctement et subir une forme d’indisponibilité. La surveillance des applications web (aussi appelée surveillance des transactions) aide les entreprises à maintenir le bon fonctionnement de leur site web. Les checkpoints utilisent des scripts qui agissent comme le feraient des utilisateurs réels pour tester les formulaires de connexion, les paniers d’achats, les formulaires web et les processus de paiement. Les moniteurs surveillent également la réactivité du serveur et vérifient le contenu de la page en cours de route.

Monitoring d’API

Les entreprises SaaS et les sites web communiquent continuellement entre eux et avec les utilisateurs finaux en utilisant leurs API orientées vers le public. Lorsqu’une API tombe en panne, elle n’est pas la seule victime. Les applications mobiles cessent de fonctionner, les fonctions et le contenu web dépendants échouent, et les processus back-end s’arrêtent. Tester les fonctionnalités de l’API à l’aide de l’API Monitoring permet de réduire considérablement les indisponibilités en détectant rapidement les défaillances et les tendances. La détection précoce des problèmes d’API peut empêcher les problèmes d’API d’affecter les utilisateurs de l’API.

Conclusion

Les problèmes d’indisponibilité sont difficiles à éviter, mais vous pouvez les contrer un maximum en vous dotant de solutions de surveillance et de systèmes de support adéquats. Les fournisseurs visent une haute disponibilité (99,99 %) et nombre d’entre eux atteignent et maintiennent cet objectif. Une autre solution utilisée par les fournisseurs pour surveiller leur présence sur le web est le Real User Monitoring (RUM). Le RUM permet à un fournisseur de suivre l’expérience réelle de ses utilisateurs (Digital Experience Monitoring ou DEM). Bien que le RUM ne soit pas la bonne solution pour la surveillance de la disponibilité, il peut fournir des détails sur la performance en fonction de l’emplacement de l’utilisateur, du type et de la version du navigateur, du système d’exploitation et de la version, du type d’appareil et de la page visionnée.