Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Réduire MTTR

Après la découverte d'une défaillance, le reste du MTTR temps est consacré à la réparation effective ou à l'atténuation de l'impact. Pour réparer ou atténuer une panne, vous devez savoir ce qui ne va pas. Deux groupes clés de mesures fournissent des informations au cours de cette phase : 1/ les métriques d'évaluation d'impact et 2/ les métriques de santé opérationnelle. Le premier groupe indique l'ampleur de l'impact en cas de panne, en mesurant le nombre ou le pourcentage de clients, de ressources ou de charges de travail affectés. Le deuxième groupe aide à déterminer pourquoi il y a un impact. Une fois le pourquoi découvert, les opérateurs et l'automatisation peuvent réagir et résoudre la panne. Reportez-vous à l'annexe 1 MTTD et MTTR aux mesures critiques pour plus d'informations sur ces mesures.

Parcours pour contourner l'échec

L'approche la plus rapide pour atténuer l'impact consiste à utiliser des sous-systèmes rapides qui contournent les défaillances. Cette approche utilise la redondance pour réduire la charge de travail en MTTR transférant rapidement le travail d'un sous-système défaillant vers un sous-système de rechange. La redondance peut aller des processus logiciels aux EC2 instances, en passant par plusieurs ou plusieurs AZs régions.

Les sous-systèmes de rechange peuvent les MTTR réduire à presque zéro. Le temps de reprise correspond uniquement à ce qu'il faut pour réacheminer le travail vers le serveur de réserve. Cela se produit souvent avec une latence minimale et permet au travail de se terminer dans les délais définisSLA, tout en maintenant la disponibilité du système. MTTRsCela se traduit par des retards légers, voire imperceptibles, plutôt que par des périodes d'indisponibilité prolongées.

Par exemple, si votre service utilise des EC2 instances situées derrière un Application Load Balancer ALB (), vous pouvez configurer des contrôles de santé à un intervalle de cinq secondes seulement et n'exiger que deux tests de santé ayant échoué avant qu'une cible ne soit marquée comme non saine. Cela signifie qu'en 10 secondes, vous pouvez détecter une panne et arrêter d'envoyer du trafic vers l'hôte défaillant. Dans ce cas, MTTR c'est effectivement le même que le cas MTTD puisque dès que la panne est détectée, elle est également atténuée.

C'est ce que cherchent à atteindre les charges de travail à haute disponibilité ou à disponibilité continue. Nous voulons contourner rapidement les défaillances de la charge de travail en détectant rapidement les sous-systèmes défaillants, en les marquant comme défaillants, en cessant de leur envoyer du trafic et en envoyant le trafic vers un sous-système redondant.

Notez que l'utilisation de ce type de mécanisme de rapidité rend votre charge de travail très sensible aux erreurs transitoires. Dans l'exemple fourni, assurez-vous que les vérifications de l'état de votre équilibreur de charge ne portent que sur des vérifications superficielles ou locales de l'instance, et non sur les dépendances ou les flux de travail (souvent appelées vérifications de santé approfondies). Cela permettra d'éviter le remplacement inutile d'instances lors d'erreurs transitoires affectant la charge de travail.

L'observabilité et la capacité à détecter les défaillances dans les sous-systèmes sont essentielles à la réussite du contournement des défaillances. Vous devez connaître l'ampleur de l'impact afin que les ressources affectées puissent être signalées comme étant défectueuses ou défaillantes et mises hors service afin de pouvoir être réacheminées. Par exemple, si le service d'une seule zone de disponibilité est partiellement perturbé, votre instrumentation devra être en mesure d'identifier l'existence d'un problème localisé dans la zone AZ pour acheminer toutes les ressources de cette zone jusqu'à ce qu'elle soit rétablie.

La capacité à contourner les défaillances peut également nécessiter un outillage supplémentaire en fonction de l'environnement. En utilisant l'exemple précédent avec des EC2 instances situées derrière unALB, imaginez que les instances d'une zone géographique passent avec succès les tests de santé locaux, mais qu'une déficience isolée de la zone Z les empêche de se connecter à leur base de données dans une autre zone. Dans ce cas, les contrôles de santé de l'équilibrage de charge ne mettront pas ces instances hors service. Un mécanisme automatisé différent serait nécessaire pour supprimer l'AZ de l'équilibreur de charge ou forcer les instances à échouer à leurs tests de santé, ce qui dépend de l'identification du fait que l'étendue de l'impact est une AZ. Pour les charges de travail qui n'utilisent pas d'équilibreur de charge, une méthode similaire serait nécessaire pour empêcher les ressources d'une zone de travail spécifique d'accepter des unités de travail ou de supprimer complètement de la capacité de la zone de gestion.

Dans certains cas, le transfert du travail vers un sous-système redondant ne peut pas être automatisé, comme le basculement d'une base de données principale vers une base de données secondaire lorsque la technologie ne fournit pas sa propre élection de leader. Il s'agit d'un scénario courant pour les architectures AWS multirégionales. Étant donné que ces types de basculement nécessitent un certain temps d'arrêt, ne peuvent pas être annulés immédiatement et laissent la charge de travail sans redondance pendant un certain temps, il est important de faire participer un humain au processus décisionnel.

Les charges de travail qui peuvent adopter un modèle de cohérence moins strict peuvent être réduites MTTRs en utilisant l'automatisation du basculement multirégional pour contourner les défaillances. Des fonctionnalités telles que la réplication entre régions Amazon S3 ou les tables globales Amazon DynamoDB fournissent des fonctionnalités multirégionales grâce à une réplication finalement cohérente. De plus, l'utilisation d'un modèle de cohérence assoupli est bénéfique lorsque l'on considère le CAP théorème. Lors de pannes réseau qui ont un impact sur la connectivité aux sous-systèmes dynamiques, si la charge de travail choisit la disponibilité plutôt que la cohérence, elle peut toujours fournir des réponses sans erreur, ce qui constitue un autre moyen de contourner les défaillances.

Le routage en cas de défaillance peut être mis en œuvre à l'aide de deux stratégies différentes. La première stratégie consiste à implémenter la stabilité statique en préprovisionnant suffisamment de ressources pour gérer la charge complète du sous-système défaillant. Il peut s'agir d'une EC2 instance unique ou d'une capacité totale d'AZ. Tenter de provisionner de nouvelles ressources en cas de panne augmente le plan de contrôle MTTR et ajoute une dépendance à celui-ci dans votre chemin de restauration. Cependant, cela entraîne des frais supplémentaires.

La deuxième stratégie consiste à acheminer une partie du trafic du sous-système défaillant vers d'autres sous-systèmes et à éliminer le trafic excédentaire qui ne peut pas être traité par la capacité restante. Au cours de cette période de dégradation, vous pouvez augmenter le volume de nouvelles ressources pour remplacer la capacité défaillante. Cette approche est plus longue MTTR et crée une dépendance à l'égard d'un plan de contrôle, mais elle coûte moins cher en réserve et en capacité de réserve.

Retour à un état connu en bon état

Une autre approche courante pour atténuer les risques pendant la réparation consiste à remettre la charge de travail dans un état normal connu auparavant. Si une modification récente est susceptible d'être à l'origine de l'échec, l'annulation de cette modification est un moyen de revenir à l'état précédent.

Dans d'autres cas, des conditions transitoires peuvent être à l'origine de l'échec, auquel cas le redémarrage de la charge de travail peut atténuer l'impact. Examinons ces deux scénarios.

Lors d'un déploiement, la minimisation de la MTTD terre MTTR repose sur l'observabilité et l'automatisation. Votre processus de déploiement doit surveiller en permanence la charge de travail pour détecter toute augmentation des taux d'erreur, une latence accrue ou des anomalies. Une fois ceux-ci reconnus, le processus de déploiement doit être interrompu.

Il existe différentes stratégies de déploiement, telles que les déploiements sur place, les déploiements bleu/vert et les déploiements progressifs. Chacun d'entre eux peut utiliser un mécanisme différent pour revenir à un état dont le fonctionnement a été vérifié. Il peut revenir automatiquement à l'état précédent, ramener le trafic vers l'environnement bleu ou nécessiter une intervention manuelle.

CloudFormation offre la possibilité de revenir en arrière automatiquement dans le cadre de ses opérations de création et de mise à jour de la pile, comme le fait AWS CodeDeploy. CodeDeploy prend également en charge les déploiements bleu/vert et les déploiements progressifs.

Pour tirer parti de ces fonctionnalités et minimiser les vôtresMTTR, envisagez d'automatiser l'ensemble de votre infrastructure et de vos déploiements de code par le biais de ces services. Dans les scénarios où vous ne pouvez pas utiliser ces services, envisagez d'implémenter le modèle Saga AWS Step Functions pour annuler les déploiements ayant échoué.

Lorsque l'on envisage le redémarrage, il existe plusieurs approches différentes. Cela va du redémarrage d'un serveur, la tâche la plus longue, au redémarrage d'un thread, la tâche la plus courte. Voici un tableau qui décrit certaines des approches de redémarrage et les durées approximatives d'exécution (représentatives de la différence d'ordres de grandeur, elles ne sont pas exactes).

MTTREn examinant le tableau, l'utilisation de conteneurs et de fonctions sans serveur (comme AWS Lambda) présente des avantages évidents. Ils MTTR sont bien plus rapides que le redémarrage d'une machine virtuelle ou le lancement d'une nouvelle machine. Cependant, l'utilisation de l'isolation des défauts par le biais de la modularité logicielle est également avantageuse. Si vous pouvez contenir l'échec d'un seul processus ou thread, la reprise après cette défaillance est beaucoup plus rapide que le redémarrage d'un conteneur ou d'un serveur.

Comme approche générale de la restauration, vous pouvez passer de bas en haut : 1/Restart, 2/Reboot, 3/RE-image/Redeploy, 4/Replace. Cependant, une fois que vous avez atteint l'étape de redémarrage, le routage en cas d'échec est généralement une approche plus rapide (cela prend généralement 3 à 4 minutes au maximum). Ainsi, pour atténuer le plus rapidement possible l'impact d'une tentative de redémarrage, contournez la panne puis, en arrière-plan, poursuivez le processus de restauration pour rétablir la capacité de votre charge de travail.

Diagnostic des défaillances

Une partie du processus de réparation après la détection est la période de diagnostic. Il s'agit de la période pendant laquelle les opérateurs tentent de déterminer ce qui ne va pas. Ce processus peut impliquer d'interroger les journaux, de passer en revue les indicateurs de santé opérationnelle ou de se connecter aux hôtes pour résoudre les problèmes. Toutes ces actions prennent du temps. La création d'outils et de runbooks pour accélérer ces actions peut également contribuer à MTTR les réduire.

Runbooks et automatisation

De même, une fois que vous avez déterminé ce qui ne va pas et quel plan d'action permettra de réparer la charge de travail, les opérateurs doivent généralement suivre un ensemble d'étapes pour y parvenir. Par exemple, après une panne, le moyen le plus rapide de réparer la charge de travail peut être de la redémarrer, ce qui peut impliquer plusieurs étapes ordonnées. L'utilisation d'un manuel qui automatise ces étapes ou fournit des instructions spécifiques à un opérateur accélérera le processus et contribuera à réduire le risque d'action involontaire.