Lorsqu’une agence gère un ou deux sites clients, la rapidité avec laquelle vous réagissez à un incident est l’indicateur qui importe le plus. Si vous connaissez bien l’environnement, la solution est généralement à portée de main. Un problème résolu et bien géré peut renforcer la relation avec le client ; une réaction rapide est donc une compétence que vous développez et une source de fierté sur laquelle vous vous appuyez.
Cependant, le volume d’incidents au sein d’un portefeuille augmente parallèlement à ce dernier. Si vous ne mettez pas l’accent sur les bons éléments, vous risquez de gagner en rapidité pour résoudre les problèmes sans pour autant réduire leur fréquence. C’est dans la distinction entre la rapidité d’intervention et la fréquence des incidents que réside le véritable coût d’une agence réactive.
Pourquoi la rapidité de réponse aux incidents n’est pas l’indicateur de réussite à privilégier
Les configurations à site unique peuvent se permettre une culture de résolution rapide, car les incidents y sont rares et isolés. Une connaissance approfondie de l’environnement et une procédure de résolution bien rodée font de votre vitesse de réponse un indicateur de performance pertinent. C’est ce qu’on appelle le temps moyen de rétablissement ou de réparation (MTTR): le temps moyen nécessaire pour résoudre une panne une fois qu’elle s’est produite.
Cependant, le temps moyen entre deux pannes (MTBF) devient un meilleur indicateur de la santé opérationnelle à mesure que votre activité se développe. Alors que le MTTR mesure la vitesse de rétablissement, le MTBF mesure la durée pendant laquelle un système fonctionne avant la prochaine panne. Un MTBF élevé signifie que les pannes sont peu fréquentes, mais un MTBF faible indique que votre équipe est en mode de reprise quasi permanent, quelle que soit la rapidité de chaque reprise individuelle.
En résumé, si vous vous contentez d’optimiser le MTTR, vous vous concentrez sur l’atelier de réparation alors que le véhicule continue de tomber en panne. Vous devez au contraire vous appuyer sur le MTTR pour évaluer l’efficacité de la reprise et sur le MTBF pour déterminer si l’environnement génère des incidents en premier lieu.
Le coût d’un MTBF faible dans un portefeuille en pleine expansion
Dans un vaste portefeuille, un MTBF faible par site engendre une file d’attente de support que la seule rapidité de réponse ne suffit pas à gérer. Les types d’incidents courants se recoupent régulièrement entre plusieurs sites :
- Les conflits liés aux mises à jour d’extensions touchent simultanément plusieurs installations lorsqu’une mise à jour est déployée sur une extension partagée utilisée dans l’ensemble du portefeuille.
- Une dégradation des performances due à des robots peut affecter plusieurs sites à la fois lorsque le trafic automatisé contourne la mise en cache et consomme des threads PHP sans limite.
- Les erreurs de déploiement introduisent des erreurs de configuration dans les environnements de production lorsque les workflows de préproduction ne sont pas systématiquement respectés.
- Les incidents liés à l’infrastructure partagée sur des plateformes qui n’isolent pas les sites peuvent se propager en cascade d’un site à l’autre sur le même serveur.
Bon nombre de ces incidents ne sont pas imputables à votre équipe et celle-ci ne peut les prévenir au sein de l’environnement. Par conséquent, résoudre plus rapidement tous ces incidents ne revient pas à en réduire le nombre.
Hall est un client de Kinsta qui possède plusieurs décennies d’expérience en tant qu’agence web. Chez son hébergeur précédent, les interruptions récurrentes du site lors des pics de trafic avaient un impact direct sur le chiffre d’affaires d’un client WooCommerce et mobilisaient des ressources de l’équipe qui auraient dû être consacrées au travail pour les clients :
Kinsta fonctionne comme nous fonctionnons. Nous avons besoin d’excellentes performances pour éviter toute mauvaise surprise, et d’un support de qualité au cas où un problème surviendrait. Kinsta nous permet de réduire les distractions liées au support et d’augmenter notre productivité.
Les coûts qui n’apparaissent pas sur les tickets d’incident
La plupart des agences suivent le coût direct d’un incident, généralement les heures qu’un développeur ou un chargé de compte passe à diagnostiquer et à résoudre le problème. Ce chiffre est réel mais incomplet, en raison de certains coûts cachés :
- Le changement de contexte oblige un développeur à quitter un projet de développement pour gérer un incident sur un site en production, mais le développement ne s’interrompt pas pour autant. Des études indiquent qu’il faut entre 15 et 25 minutes pour retrouver pleinement sa concentration après une interruption, ce qui signifie qu’un seul incident en milieu de matinée peut discrètement anéantir la majeure partie d’une période de travail concentrée. Ce coût n’apparaît jamais sur le ticket d’incident, mais il s’accumule sur l’ensemble des sites du portefeuille.
- La confiance du client est solide si vous gérez et résolvez un incident isolé en toute transparence. En revanche, une succession d’incidents récurrents sème le doute quant à la fiabilité de l’environnement. La fréquence à elle seule détermine la confiance du client au fil du temps.
- Une agence fondée sur des interventions réactives place les développeurs seniors en première ligne de défense permanente. En tant que mode de fonctionnement standard pour un portefeuille en pleine croissance, cela entraîne un roulement de personnel et des contraintes de capacité, et aggrave encore davantage la situation.
Les efforts continus d’une équipe pour faire barrage entre un portefeuille et des défaillances récurrentes relèvent davantage d’un problème de plateforme que d’une question de personnel. La solution réside dans une infrastructure qui ne nécessite pas d’intervention constante pour rester stable. L’agence de marketing numérique primée Paramark décrit un modèle similaire à celui de Kinsta :
Cela nécessitait une administration système excessive pour empêcher les sites web de tomber en panne. Parmi les problèmes récurrents figuraient la gestion des ressources serveur et le nettoyage des fichiers journaux. Ne pas s’en occuper entraînait une instabilité des sites web.
La solution (suivre le nombre d’incidents par site et par mois plutôt que le délai de résolution) vous permet de déterminer si l’environnement s’améliore réellement ou si votre équipe devient simplement plus efficace dans la gestion d’un problème persistant.
À quoi ressemble la prévention des incidents
L’infrastructure et la plateforme globale de Kinsta s’articulent autour de cette philosophie, qui vise à réduire la probabilité d’incidents plutôt que de se contenter de réduire leur délai de résolution.
Tout d’abord, chaque site fonctionne dans son propre conteneur Linux isolé, doté d’une pile logicielle dédiée. Les ressources ne peuvent pas franchir les limites des conteneurs, et cela s’applique même entre des sites appartenant au même compte d’entreprise.
Dans le cas d’un portefeuille d’agence, les incidents survenant dans un environnement donné n’ont aucune incidence sur les performances ou la disponibilité des autres sites que vous gérez. En revanche, sur les plateformes d’hébergement mutualisé, un pic de consommation de ressources sur un site dégrade les performances des autres sites hébergés sur le même serveur.
Sauvegardes automatiques et restauration en un clic
Kinsta effectue des sauvegardes quotidiennes complètes de chaque site et les conserve pendant au moins 14 jours. Vous pouvez accéder aux sauvegardes et les restaurer depuis l’écran Sauvegardes de MyKinsta, où vous avez également accès à deux autres types de sauvegardes pertinentes :
- Les sauvegardes générées par le système se déclenchent automatiquement avant certaines opérations clés, telles que la restauration à partir d’une sauvegarde existante. Un point de restauration est toujours créé avant l’exécution d’une opération.
- Les sauvegardes manuelles vous permettent de créer jusqu’à cinq instantanés supplémentaires à tout moment, que vous pouvez également nommer pour les identifier.
Le bouton Restaurer vers associé à chaque sauvegarde vous permet de revenir à un état connu en quelques clics seulement. Pour les agences utilisant les mises à jour automatiques de Kinsta sur l’ensemble de leur portefeuille, chaque mise à jour planifiée s’exécute avec un point de restauration généré par le système déjà en place. Le processus est désormais « restaurer puis analyser », ce qui est prévisible quel que soit le site concerné.
Environnements de staging et déploiement sélectif
Les environnements de staging de Kinsta fournissent une copie distincte du site en production afin de tester les modifications avant qu’aucune d’entre elles ne parvienne aux clients. Chaque formule Kinsta comprend un environnement de staging standard gratuit par site. Lorsqu’une modification est prête à être déployée, le déploiement sélectif vous permet de contrôler précisément ce qui est transféré vers l’environnement de production.
Pour utiliser le déploiement sélectif, sélectionnez votre environnement de staging dans MyKinsta, cliquez sur Déployer l’environnement, puis choisissez une portée de déploiement (Fichiers ou Base de données). Chaque portée dispose également d’un menu déroulant qui vous permet d’affiner les éléments à déployer :
Kinsta effectue une sauvegarde automatique de l’environnement cible avant chaque déploiement. Les erreurs de déploiement qui affectent les sites en production sont souvent à l’origine d’incidents ; c’est pourquoi une configuration multi-environnements recourant à des déploiements sélectifs et à des sauvegardes automatiques préalables au déploiement constitue un moyen d’éviter toute intervention urgente sur le site en production.
La protection contre les bots : une couche de protection contre les incidents de performance
La protection contre les robots de Kinsta filtre le trafic avant que WordPress ne traite une requête, afin de réduire la charge automatisée au niveau de l’infrastructure avant qu’elle n’affecte les performances du serveur. Par défaut, Kinsta bloque le trafic classé comme malveillant sur l’ensemble de la plateforme.
Pour configurer la protection d’un site, rendez-vous sur l’écran « Protection contre les robots » dans MyKinsta et cliquez sur « Modifier » dans le panneau « Niveau de protection » :
Quatre niveaux sont disponibles, et l’option « Bloquer le trafic malveillant » est sélectionnée par défaut pour tous les sites. Ce paramètre bloque les tentatives de DDoS et les requêtes provenant d’adresses IP associées à des sources d’attaque connues. Cependant, vous pouvez également étendre cette protection pour bloquer le trafic automatisé confirmé, soumettre des défis aux requêtes susceptibles de provenir de robots et aux requêtes non classifiées, et même soumettre à un défi tout le trafic non vérifié, y compris les visiteurs susceptibles d’être des utilisateurs humains.
Si vous sélectionnez plusieurs sites dans MyKinsta et que vous cliquez sur Actions > Modifier la protection contre les robots, vous pouvez également appliquer un niveau de protection à plusieurs sites à la fois. La charge générée par les robots peut contourner entièrement la mise en cache et monopoliser des threads PHP à chaque requête, en particulier pour la gestion de sites WooCommerce ou de sites d’adhésion. Disposer de cette fonctionnalité devient de plus en plus indispensable au fil du temps.
L’analyse comme couche d’alerte précoce
La suite d’analyses de MyKinsta vous offre une visibilité sur les conditions avant qu’elles ne se transforment en problèmes pour vos clients. Depuis l’écran « Analytics », l’onglet « Performance » suit les temps de réponse PHP et l’utilisation des threads PHP au fil du temps. Une tendance à l’augmentation des temps de réponse sans augmentation correspondante du trafic humain est souvent un signe précoce indiquant une charge due aux bots ou une requête de base de données inefficace :
L’examen conjoint des graphiques d’analyse ne prend que quelques minutes par site et permet de repérer des tendances que la surveillance réactive ne détecte pas. Par exemple, en consultant le graphique « Visites » sous « Utilisation du plan », vous pouvez obtenir des données sur des aspects tels que le trafic humain facturable. Si vous comparez ces données au rapport « Top des requêtes par vues » (qui couvre l’ensemble du trafic, y compris les requêtes automatisées), vous obtenez un aperçu des endroits où la charge générée par les bots affecte les performances du serveur, alors que le nombre de visites semble normal.
Réorienter le modèle opérationnel de votre agence vers la prévention
La réduction du nombre d’incidents repose davantage sur le choix de la plateforme et des fonctionnalités que sur des modes de travail différents.
Par exemple, commencez à consigner les facteurs individuels propres à chaque site ainsi que les étapes de résolution lorsqu’un incident se produit. L’objectif n’est pas la documentation en soi, mais de déterminer si les incidents se reproduisent pour les mêmes raisons sous-jacentes. Les journaux disponibles dans MyKinsta peuvent vous y aider :
Un journal indiquant trois incidents sur le même site, causés par des conflits liés à la mise à jour d’extensions, met en évidence une lacune dans le workflow de staging. Sans cet enregistrement, ce schéma reste invisible et les incidents se poursuivent.
Une liste de contrôle préalable au déploiement constitue le moyen idéal pour intégrer les décisions que vous avez déjà prises dans un processus reproductible. Les points ci-dessous permettent d’éviter les catégories d’incidents évitables les plus courantes :
- Testez chaque modification dans un environnement de staging Kinsta par rapport à un état représentatif de la production avant de la déployer.
- Utilisez le déploiement sélectif pour adapter la portée du déploiement à la modification.
- Vérifiez la protection contre les robots après tout déploiement ajoutant des fonctionnalités dynamiques accessibles au public, en particulier les formulaires, les processus de paiement ou les points de connexion.
- Vérifiez le graphique de performances dans la section « Analyses » après le déploiement pour vous assurer que les temps de réponse restent dans les limites acceptables.
Une fois que vous suivez régulièrement les incidents par site, vous pouvez rendre compte de manière proactive des tendances en matière de fiabilité, plutôt que d’expliquer les problèmes a posteriori. Un client qui reçoit un résumé trimestriel montrant une baisse de la fréquence des incidents et une disponibilité constante a une perception différente du service par rapport à celui qui reçoit un appel après chaque événement.
Une infrastructure axée sur la prévention est la clé d’une croissance durable pour une agence
Une réponse rapide aux incidents est une capacité fondamentale pour toute agence. C’est l’infrastructure qui réduit la fréquence des incidents qui détermine si cette capacité est constamment sollicitée ou rarement nécessaire. À l’échelle d’une agence, c’est l’écart entre ces deux situations qui détermine la rentabilité et la stabilité de l’équipe.
Les outils et l’infrastructure de Kinsta (tels que l’isolation par conteneurs, le système de sauvegarde automatique et la protection contre les robots) traitent les catégories d’incidents auxquelles vous consacrez le plus de temps. À partir de là, les processus que vous mettez en place, tels qu’un journal des incidents ou une liste de contrôle préalable au déploiement, permettent d’assurer une réduction constante du nombre d’incidents sur tous les sites que vous gérez.
Pour les agences gérant les sites de leurs clients sur Kinsta, le programme de partenariat pour les agences offre une assistance dédiée, des ressources de co-vente et des outils conçus pour la gestion de WordPress à grande échelle.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
