Ce document du framework d'architecture Google Cloud fournit les bonnes pratiques pour gérer les services et définir des processus de réponse aux incidents. Les incidents se produisent dans tous les services. Vous devez donc disposer d'un processus bien documenté pour réagir efficacement à ces problèmes et les atténuer.
Présentation de la gestion des incidents
Il est inévitable que votre système bien conçu ne parvienne pas à atteindre ses objectifs de niveau de service. En l'absence de SLO, vos clients définissent de manière approximative le niveau de service acceptable à partir de leur expérience passée. Les clients font remonter votre demande à l'assistance technique ou à un groupe similaire, quel que soit le contenu de votre contrat de niveau de service.
Pour répondre correctement à vos clients, établissez et testez régulièrement un plan de gestion des incidents. Le plan peut être aussi court qu'une simple liste d'une page comportant dix éléments. Ce processus aide votre équipe à réduire le temps de détection (Time to detect, TTD) et le temps d'atténuation des risques (Time to mitigate, TTM).
Le TTM est préférable au TTR, où le R pour la réparation ou la récupération est souvent utilisé pour désigner une correction complète par rapport à l'atténuation des risques. Le système TTM met l'accent sur la résolution rapide pour limiter rapidement l'impact pour le client d'une panne, puis lance un processus souvent beaucoup plus long pour résoudre complètement le problème.
Un système bien conçu avec des opérations d'excellente qualité augmente le délai entre les défaillances (Time between failures, TBF). En d'autres termes, les principes de fiabilité opérationnels, y compris la bonne gestion des incidents, ont pour but de rendre les défaillances moins fréquentes.
Pour exécuter des services fiables, appliquez les bonnes pratiques suivantes dans votre processus de gestion des incidents.
Attribuer une propriété de service claire
Tous les services et leurs dépendances critiques doivent avoir des propriétaires clairs responsables du respect de leurs SLO. En cas de réorganisations ou de départs d'équipe, les responsables ingénieurs doivent s'assurer que la propriété est explicitement transférée à une nouvelle équipe, ainsi que la documentation et la formation nécessaires. Les propriétaires d'un service doivent être facilement détectables par d'autres équipes.
Réduisez le temps de détection grâce à des alertes bien réglées.
Avant de pouvoir réduire le TTD, examinez et mettez en œuvre les recommandations figurant dans les sections Intégrer l'observabilité dans votre infrastructure et vos applications et Définir vos objectifs de fiabilité de la catégorie de fiabilité du framework d'architecture. Par exemple, faites la distinction entre les problèmes d'application et les problèmes liés au cloud.
Un ensemble de SLI bien défini prévient votre équipe au bon moment, tout en évitant la surabondance d'alertes. Pour plus d'informations, consultez la section Créer des alertes efficaces du pilier "Architecture Framework" ou "Affiner vos métriques SLI : blog CRE Life Lessons".
Réduisez le temps nécessaire à la résolution avec des plans de gestion des incidents et des formations.
Pour réduire le TTM, définissez un plan de gestion des incidents documenté et correctement testé. disposer de données aisément accessibles documentant les changements apportés à l'environnement ; Assurez-vous que les équipes connaissent les atténuations génériques qu'elles peuvent appliquer rapidement pour minimiser le TTM. Ces techniques d'atténuation incluent le drainage, le rollback, le redimensionnement des ressources et la dégradation de la qualité de service.
Comme indiqué dans un autre document clé lié à la catégorie de fiabilité du framework Architecture, créez des processus et des outils opérationnels fiables pour pouvoir effectuer un rollback rapide et sécurisé des modifications.
Concevez des dispositions et du contenu de tableau de bord de façon à minimiser le temps nécessaire à la résolution.
Organisez la mise en page de votre tableau de bord et la navigation de votre service afin qu'un opérateur puisse déterminer en une minute ou deux si le service, ainsi que toutes ses dépendances critiques, sont en cours d'exécution. Pour identifier rapidement les causes potentielles des problèmes, les opérateurs doivent pouvoir analyser tous les graphiques du tableau de bord afin de rechercher rapidement des graphiques qui changent de manière significative au moment de l'alerte.
La liste suivante d'exemples de graphiques peut se trouver sur votre tableau de bord pour vous aider à résoudre des problèmes. Le personnel chargé de répondre aux incidents doit pouvoir les consulter sur un même écran.
- Les indicateurs de niveau de service, tels que le nombre de requêtes ayant réussi, divisés par le nombre total de requêtes valides
- Configuration et déploiements binaires
- Requêtes par seconde envoyées au système
- Réponses d'erreurs par seconde provenant du système
- Requêtes par seconde depuis le système vers ses dépendances
- Réponses d'erreur par seconde au système à partir de ses dépendances
D'autres graphiques courants permettant de résoudre les problèmes incluent la latence, la saturation, la taille de la requête, la taille de la réponse, le coût des requêtes, l'utilisation du pool de threads et les métriques de machine virtuelle Java (JVM) (le cas échéant). La saturation fait référence à l'exhaustivité en fonction d'une certaine limite, telle que le quota ou la taille de la mémoire système. L'utilisation du pool de threads recherche les régressions dues à l'épuisement du pool.
Testez l'emplacement de ces graphiques sur quelques scénarios de panne pour vous assurer que les graphiques les plus importants sont proches du haut et que l'ordre des graphiques correspond à votre workflow de diagnostic standard. Vous pouvez également appliquer le machine learning et la détection d'anomalies statistiques pour faire apparaître le sous-ensemble approprié de ces graphiques.
Documenter les procédures de diagnostic et l'atténuation des risques de défaillances connues
Rédigez des guides et des liens vers ces derniers à partir des notifications d'alerte. Si ces documents sont accessibles à partir des notifications d'alerte, les opérateurs peuvent obtenir rapidement les informations dont ils ont besoin pour résoudre les problèmes.
Utilisez les analyses post-mortem irréprochables pour tirer des leçons des interruptions de service et éviter les récurrences
Établir une culture post-mortem irréprochable et un processus d'examen des incidents. Sans reproches signifie que votre équipe évalue et documente les erreurs de manière objective, sans qu'il soit nécessaire d'attribuer le problème.
Les erreurs sont des opportunités d'apprentissage, et non des critiques. Veillez à toujours améliorer la résilience du système pour qu'il puisse récupérer rapidement d'une erreur humaine, ou mieux, pour qu'il soit capable de détecter et d'éviter les erreurs humaines. Extrayez le plus d'apprentissage possible de chaque post-mortem et effectuez un suivi minutieux de chaque action post-mortem afin de réduire les fréquences d'interruption, ce qui aura pour effet d'augmenter le TBF.
Exemple de plan de gestion des incidents
Des problèmes de production ont été détectés, par exemple via une alerte ou une page, ou s'ils m'ont été signalés :
- Dois-je déléguer cette tâche à une autre personne ?
- Oui, si vous et votre équipe ne parvenez pas à résoudre le problème.
- S'agit-il d'une atteinte à la vie privée ou d'une violation de la sécurité ?
- Si oui, déléguez cette tâche à l'équipe chargée de la confidentialité ou de la sécurité.
- S'agit-il d'une urgence ou des SLO sont-ils menacés ?
- En cas de doute, traitez le problème comme s'il s'agissait d'une urgence.
- Dois-je impliquer davantage de personnes ?
- Oui, si cela concerne plus de X% des clients ou si la résolution du problème prend plus de Y minutes. En cas de doute, impliquez toujours plus de personnes, en particulier pendant les heures de travail.
- Définissez un canal de communication principal, tel que IRC, Hangouts Chat ou Slack.
- Déléguez des rôles précédemment définis, tels que les suivants :
- Responsable des incidents chargé de la coordination générale.
- Responsable de la communication chargé des communications internes et externes.
- Responsable des opérations chargé d'atténuer le problème.
- Déterminez quand l'incident est terminé. Vous aurez peut-être d'abord à vous adresser à un conseiller de l'équipe d'assistance ou à d'autres équipes similaires.
- Collaborez sur le post-mortem irréprochable.
- Participez à une réunion dédiée à l'examen des incidents post-mortem au cours de laquelle vous pourrez discuter des points à traiter et des tâches à effectuer.
Recommandations
Pour appliquer les instructions du framework d'architecture à votre propre environnement, suivez les recommandations ci-dessous :
- Mettez en place un plan de gestion des incidents et formez vos équipes à son utilisation.
- Pour réduire le TTD, mettez en œuvre les recommandations permettant de créer une observabilité dans votre infrastructure et vos applications.
- Créer un tableau de bord "Qu'est-ce qui a changé ?" que vous pouvez consulter en cas d'incident.
- Documentez les extraits de requête ou créez un tableau de bord Looker Studio avec des requêtes de journal fréquentes.
- Évaluez Firebase Remote Config pour limiter les problèmes de déploiement des applications mobiles.
- Testez la reprise après échec, y compris la restauration des données à partir de sauvegardes, afin de réduire le TTM pour un sous-ensemble de vos incidents.
- Concevez des solutions adaptées aux rollbacks de la configuration et des binaires et effectuez des tests.
- Répliquez les données dans plusieurs régions pour la reprise après sinistre et utilisez des tests de reprise après sinistre pour réduire le TTM après les pannes régionales.
- Concevez une architecture multirégionale pour la résilience aux pannes régionales si les besoins de haute disponibilité justifient le coût, ce qui augmente le TBF.
Étape suivante
Découvrez comment créer un processus collaboratif de gestion des incidents à l'aide des ressources suivantes :
- Google Cloud Status Dashboard
- Gestion des incidents chez Google
- Processus de gestion des incidents liés aux données
- Chapitre sur la gestion des incidents dans le livre sur l'ingénierie SRE
Découvrez d'autres catégories du framework d'architecture, telles que la conception du système, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.