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

L'adoption du cloud computing encourageant l'innovation dans tous les secteurs, des systèmes performants et résilients sont devenus une nécessité pour rester en phase avec la concurrence et respecter les SLA (accords de niveau de service) internes/externes. En termes d'attentes des clients, une minute d'indisponibilité peut se traduire par des milliers de dollars d'opportunités perdues et une relation client entachée.

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 temps d'arrêt (ou planifiés) se produisent au moment le plus pratique et minimisent l'impact négatif pour les utilisateurs. Les temps d'arrêt planifiés sont un exercice proactif visant à garantir une fonctionnalité optimale des machines et des services. Il existe deux façons de planifier les temps d'arrêt planifiés : fixes ou flexibles. Les temps d'arrêt fixes adhèrent à un calendrier défini avec une heure de début et de fin spécifique pour la maintenance. Les temps d'arrêt flexibles sont une fenêtre de temps pendant laquelle les temps d'arrêt se produiront, bien que l'heure de début exacte soit inconnue.

Imprévu (ou non planifié) : un arrêt de service survient lorsqu'une interruption de service survient en raison d'une erreur machine imprévue ou d'une panne d'application/serveur, entre autres incidents techniques. Un exemple d'arrêt de service imprévu peut aller d'un plantage d'ordinateur local à la mise hors ligne inattendue d'un service entier. Un arrêt de service imprévu peut survenir de manière sporadique à tout moment du jour ou de la nuit et peut être coûteux en termes financiers et de réputation pour l'entreprise.

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

Les causes des temps d'arrêt sont généralement classées en plusieurs catégories. L'erreur humaine est l'une des plus courantes. Qu'un développeur ait soumis un code défectueux ou qu'un administrateur ait mis à jour un package non testé, lorsque la procédure n'est pas suivie ou qu'un bug système obscur n'est pas pris en compte, la disponibilité du produit en pâtit. Une autre cause est la panne de services tiers, lorsque les temps d'arrêt ne sont pas causés en interne mais par la panne de fournisseurs de services périphériques. Enfin, il existe des événements « cygnes noirs » très imprévisibles, comme les attaques de ransomware, qui peuvent également avoir de graves conséquences.

Des coûts mesurables

Une fois que l'ampleur de l'impact des temps d'arrêt est 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é. On peut le calculer en multipliant le nombre d'employés qui ne peuvent pas travailler 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 de travailleurs temporaires ou le paiement d'heures supplémentaires aux travailleurs, peuvent également être mesurés.

Les coûts d’entreprise ou coûts d’opportunité peuvent également être calculés à partir des ventes perdues ou de la perte de productivité, en particulier lorsqu’ils sont comparés à la production dans des circonstances normales. Enfin, il existe des coûts contractuels et des pénalités, dans le cadre desquels les clients couverts par un accord de niveau de service (SLA) doivent être payés en cas de panne. Si l’impact de la panne sur les clients est suffisamment grave, les entreprises peuvent même faire face à des poursuites judiciaires, en particulier dans les secteurs réglementés.

Des coûts non mesurables

Les coûts les plus importants sont peut-être ceux qui ne sont pas intrinsèquement mesurables. Citons par exemple le moral des employés, car les temps d'arrêt peuvent faire douter de la viabilité de l'entreprise et empêcher les employés d'accomplir leur travail important. Les temps d'arrêt peuvent également engendrer des coûts invisibles en bloquant les projets de développement et informatiques, car la progression des travaux est perturbée et la charge cognitive des équipes techniques est accrue. Enfin, il y a la perte irréversible d'opportunités commerciales clés basées sur la technologie, car la réputation d'une entreprise dépend de l'efficacité avec laquelle elle peut faire fonctionner ses systèmes.

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

Alors, que peuvent faire les entreprises pour prévenir les pannes et réduire considérablement la durée et la fréquence de celles qui se produisent ? 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. Les 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 gros budgets 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. Mais les petites entreprises peuvent simplement planifier des heures régulières pour effectuer ces opérations manuellement.

Chez PagerDuty, nous appelons cette bonne pratique « le vendredi des échecs ». L’injection d’échecs par le biais d’attaques planifiées permet aux entreprises de détecter de manière proactive les vulnérabilités des systèmes et de devenir expertes en matière de réponse aux incidents, allant au-delà de la résolution des problèmes pour les empêcher de se produire. Lors de l’exécution de cet exercice, les entreprises lancent des attaques pendant une courte durée et ramènent les services à un état entièrement fonctionnel entre les attaques. Les équipes doivent également utiliser des tableaux de bord pour mieux comprendre quelles mesures indiquent des problèmes et comment cela affecte les systèmes.

Pratiques d'intégration continue

L'intégration continue (CI) est une pratique de développement logiciel dans laquelle les membres de l'équipe fusionnent leurs tâches pour réduire les problèmes et les conflits. En substance, elle vérifie la qualité du code pour s'assurer qu'aucun bug n'est introduit. Dans de nombreux cas, des tests automatisés et répétitifs sont utilisés, de sorte qu'une fois qu'un bug est détecté, de nouveaux tests sont créés pour empêcher que ce bug ne soit introduit dans les futures révisions de code. En utilisant l'intégration continue, les organisations créeront une qualité de base du logiciel qui réduira le risque de chaque version.

Il existe cinq types de tests à prendre en compte. Le premier est celui des tests sémantiques, qui étudient la relation 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 que tout fonctionne lorsqu'il est combiné avec tous les autres services, y compris les services tiers. Enfin, les tests de charge permettent de déterminer les capacités de volume et les endroits où des goulots d'étranglement des performances peuvent se produire.

Ne faites jamais face au même incident deux fois

L'exploitation des données de performances historiques, l'analyse de la cause profonde des problèmes et la mise en place d'un système d'alerte et de réponse contribueront à empêcher que les causes de temps d'arrêt passées ne se reproduisent. Suivez ce processus en cinq étapes pour réussir.

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

2. Tirez parti 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 individuels.

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ée lorsque les objectifs ont été dépassés.

5. Regroupez les alertes exploitables et associées dans les incidents pour faire remonter automatiquement les notifications d'incident si aucune mesure n'est prise. Le bon outil de gestion permettra aux organisations de gérer toutes les données d'événement en un seul endroit, d'interagir avec des experts supplémentaires et de tenir toutes les parties prenantes informées.

Tester les services tiers

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

En matière de tests de bout en bout des fournisseurs de SMS, il existe quelques bonnes pratiques spécifiques à 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, les alertes internes doivent être envoyées tout au long de la journée en utilisant chacun des fournisseurs d'une organisation. Les organisations doivent également mesurer le temps nécessaire à la réception du message pour déterminer si un fournisseur est disponible et ses performances. Les fournisseurs dont la latence de livraison des SMS est supérieure à trois minutes doivent être dégradés et remplacés. Enfin, les organisations doivent supprimer les alertes non exploitables et les alertes liées aux groupes. Cela réduit le nombre de pages que reçoivent les ingénieurs d'astreinte, ce qui minimise la fatigue 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 faire face aux inévitables temps d’arrêt, les entreprises peuvent réaliser des milliers, voire des millions, de dollars 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.