Qu'est-ce qu'un temps d'arrêt ?

Alors que l'adoption du cloud computing continue de stimuler l'innovation dans tous les secteurs, des systèmes performants et résilients sont devenus indispensables pour rester compétitifs et respecter les SLA (contrats de niveau de service) internes et externes. Du point de vue des attentes des clients, une minute d'indisponibilité peut se traduire par des milliers de dollars de pertes d'opportunités et une relation client ternie.

Alors, qu’est-ce qu’un temps d’arrêt exactement ? Temps d'arrêt est mieux décrit comme une période pendant laquelle les services principaux d'un système, d'un appareil ou d'une application, à la fois internes et externes, sont indisponibles ou inactifs pendant un certain temps en raison de mises à jour, de maintenance, de sécurité, de précautions et même de pannes inattendues.

Types de temps d'arrêt

En ce qui concerne les temps d’arrêt, il existe deux types distincts : planifiés et non planifiés.

Prévu Les arrêts (ou planifiés) surviennent au moment le plus opportun et minimisent l'impact négatif pour les utilisateurs. Les arrêts planifiés sont une mesure proactive visant à garantir le fonctionnement optimal des machines et des services. Il existe deux façons de planifier les arrêts planifiés : fixes ou flexibles. Les arrêts fixes suivent un calendrier établi avec des heures de début et de fin spécifiques pour la maintenance. Les arrêts flexibles sont une fenêtre temporelle pendant laquelle l'arrêt aura lieu, bien que l'heure de début exacte soit inconnue.

Imprévu Une interruption de service (ou non planifiée) survient lorsqu'une interruption de service survient en raison d'une erreur machine imprévue, d'une panne d'application ou de serveur, entre autres incidents techniques. Un exemple d'interruption de service imprévue peut aller de la panne d'un ordinateur local à la mise hors ligne soudaine d'un service entier. Une interruption de service imprévue peut survenir de manière sporadique, à toute heure du jour ou de la nuit, et peut avoir des conséquences financières et ternir la réputation de l'entreprise.

Quelles sont les causes des temps d’arrêt ?

Les causes d'indisponibilité sont généralement diverses. L'erreur humaine est l'une des plus fréquentes. Qu'un développeur ait soumis du code défectueux ou qu'un administrateur ait mis à jour un package non testé, le non-respect de la procédure ou l'oubli d'un bug système obscur nuit à la disponibilité du produit. Les pannes de services tiers sont également une cause possible, lorsque l'indisponibilité n'est pas d'origine interne, mais liée à la panne de fournisseurs de services périphériques. Enfin, il existe des événements « cygnes noirs » très imprévisibles, comme les attaques par rançongiciel, qui peuvent également avoir de graves conséquences.

Coûts mesurables

Une fois l'ampleur de l'impact des temps d'arrêt comprise, les entreprises peuvent quantifier les pertes réelles en valeur monétaire. Les coûts mesurables des temps d'arrêt se répartissent en plusieurs catégories. Le premier est celui des coûts salariaux liés à la perte de productivité. Ce calcul se fait en multipliant le nombre d'employés indisponibles par leur coût horaire de main-d'œuvre, puis en multipliant le résultat par le nombre d'heures d'arrêt. D'autres coûts liés au travail, comme l'embauche d'intérimaires ou le paiement d'heures supplémentaires, peuvent également être mesurés.

Les coûts d'exploitation, ou coûts d'opportunité, peuvent également être calculés à partir des pertes de ventes ou de productivité, notamment par comparaison avec la production en temps normal. Enfin, il existe des coûts contractuels et des pénalités, qui prévoient le paiement des clients couverts par un accord de niveau de service (SLA) en cas de panne. Si l'impact de l'interruption de service sur les clients est suffisamment important, les entreprises peuvent même faire l'objet de poursuites judiciaires, notamment dans les secteurs réglementés.

Des coûts non mesurables

Certains des coûts les plus importants sont peut-être ceux qui ne sont pas intrinsèquement mesurables. Par exemple, l'atteinte au moral des employés peut être un facteur, car les temps d'arrêt peuvent faire douter de la viabilité de l'entreprise et empêcher les employés d'accomplir des tâches importantes. Les temps d'arrêt peuvent également engendrer des coûts invisibles en bloquant les projets de développement et informatiques, car l'avancement des travaux est perturbé et la charge cognitive des équipes techniques est accrue. Enfin, il y a la perte irréversible d'opportunités commerciales clés liées aux technologies, car la réputation d'une entreprise dépend de l'efficacité avec laquelle elle maintient ses systèmes en état de fonctionnement.

Quatre méthodes pour éviter les temps d'arrêt

Alors, que peuvent faire les entreprises pour prévenir les pannes et réduire significativement leur durée et leur fréquence ? Ces quatre stratégies deviennent rapidement les meilleures pratiques du secteur pour accroître la fiabilité :

Injecter l'échec pour réussir

Disposer de sauvegardes de sauvegardes et d'une conception tolérante aux pannes est une bonne chose, mais ce n'est pas suffisant. Des sauvegardes qui ne se déclenchent qu'en cas de panne peuvent masquer du code qui échoue lorsqu'il est exposé à des charges de travail de production réelles. Les grandes entreprises disposant de budgets importants résolvent les problèmes en créant des outils automatisés qui testent la résilience des applications aux pannes, introduisent une latence artificielle ou ferment des zones de disponibilité entières. Les petites entreprises, quant à elles, peuvent simplement programmer des plages horaires régulières pour effectuer ces opérations manuellement.

Chez PagerDuty, nous appelons cette bonne pratique « Failure Friday ». Injecter des pannes via des attaques planifiées permet aux entreprises d'identifier proactivement les vulnérabilités des systèmes et de maîtriser la réponse aux incidents, allant au-delà de la simple résolution des problèmes pour les empêcher complètement. Lors de cet exercice, les entreprises lancent des attaques de courte durée et rétablissent les services à un état pleinement fonctionnel entre les attaques. Les équipes doivent également utiliser des tableaux de bord pour mieux comprendre les indicateurs qui pointent vers des problèmes et leur impact sur les systèmes.

Pratiques d'intégration continue

L'intégration continue (IC) est une pratique de développement logiciel qui consiste à fusionner les tâches des équipes afin de réduire les problèmes et les conflits. Concrètement, elle vérifie la qualité du code pour garantir l'absence de bugs. Dans de nombreux cas, des tests automatisés et répétitifs sont utilisés. Ainsi, dès qu'un bug est détecté, de nouveaux tests sont créés pour éviter sa réapparition lors des futures revues de code. Grâce à l'intégration continue, les organisations établissent une qualité logicielle de référence qui réduit les risques liés à chaque version.

Il existe cinq types de tests à prendre en compte. Les premiers sont les tests sémantiques, qui étudient les relations entre les données. Les tests unitaires étudient la conception et la flexibilité du code. Les tests fonctionnels vérifient la lisibilité humaine. Les tests d'intégration garantissent le bon fonctionnement de l'ensemble lorsqu'il est combiné avec d'autres services, y compris des services tiers. Enfin, les tests de charge permettent de déterminer les capacités de volume et d'identifier les goulots d'étranglement potentiels en termes de performances.

Ne faites jamais face au même incident deux fois

L'exploitation des données de performance historiques, l'analyse des causes profondes des problèmes et la mise en place d'un système d'alerte et de réponse contribueront à prévenir la réapparition des causes d'interruption passées. Suivez ce processus en cinq étapes pour réussir.

1. Examinez les informations historiques pour connaître les tendances de performance et approfondissez les problèmes spécifiques, en créant une plate-forme solide pour prévenir les problèmes futurs.

2. Exploitez des outils de surveillance tiers et centralisez toutes les informations sur les indicateurs de performance. Cela permet aux entreprises d'analyser en détail les performances et les dépendances entre les serveurs, les sites web et les applications.

3. Fixez des objectifs en fonction des besoins de l’entreprise, des performances passées et de la manière dont ces performances se sont traduites en termes d’accessibilité des opérations commerciales.

4. Transformez les objectifs en seuils de notification afin que les organisations soient averties dès qu'un problème survient, plutôt que d'attendre simplement d'être alertées lorsque les objectifs ont été dépassés.

5. Regroupez les alertes exploitables et connexes en incidents afin de les faire remonter automatiquement si aucune mesure n'est prise. Un outil de gestion adapté permettra aux organisations de centraliser toutes les données d'événements, de collaborer avec des experts supplémentaires et de tenir informées toutes les parties prenantes.

Tester les services tiers

De nombreuses entreprises font appel à des tiers pour fournir des produits et services à leurs clients. Lorsqu'une panne frappe Amazon Web Services, par exemple, de nombreux autres sites web sont également impactés. Il est donc crucial d'assurer la redondance afin d'éviter les points de défaillance uniques.

Pour tester les fournisseurs SMS de bout en bout, quelques bonnes pratiques spécifiques sont à prendre en compte. Pour les codes courts, les tests SMS doivent être envoyés toutes les deux minutes, la fréquence variant pour les codes longs moins courants. De plus, des alertes internes doivent être envoyées tout au long de la journée via chaque fournisseur de l'organisation. Les organisations doivent également mesurer le temps de réception des messages afin de déterminer la disponibilité d'un fournisseur et ses performances. Les fournisseurs dont la latence de livraison des SMS est supérieure à trois minutes doivent être déclassés et remplacés. Enfin, les organisations doivent supprimer les alertes non exploitables et les alertes de groupe. Cela réduit le nombre de messages reçus par les ingénieurs d'astreinte, ce qui minimise la lassitude liée aux alertes et leur permet de se concentrer sur la résolution des problèmes et l'amélioration des processus.

Préparez-vous à une panne

En prenant le temps de mettre en œuvre un plan pour gérer les inévitables temps d'arrêt, les organisations peuvent réaliser des milliers, voire des millions, d'économies quantifiables. Elles peuvent également garantir la santé de facteurs qualitatifs encore plus cruciaux, tels que le moral des employés, la réputation de la marque et la fidélité des clients.

Pour découvrir comment PagerDuty peut aider votre organisation à gérer les pannes et les temps d'arrêt, inscrivez-vous pour un essai gratuit de 14 jours.