Fiabilité

Cette section du framework d'architecture explique comment appliquer des exigences techniques et procédurales concernant la conception et l'exploitation de services fiables sur Google Cloud.

Le framework comprend les articles suivants :

La fiabilité représente la fonctionnalité la plus importante d'une application. Si l'application n'est pas fiable, les utilisateurs finiront par la quitter, qu'importent les autres fonctionnalités.

  • Une application doit avoir des objectifs de fiabilité mesurables, et les écarts doivent être rapidement corrigés.
  • La conception de l'application doit inclure l'évolutivité, la haute disponibilité et la gestion automatisée des modifications.
  • L'application doit être autoréparable dans la mesure du possible, et elle doit être instrumentée pour l'observabilité.
  • Les procédures opérationnelles permettant d'exécuter l'application doivent imposer un minimum de travail manuel et de charge intellectuelle aux opérateurs, tout en garantissant une atténuation rapide des défaillances.

Stratégies

Utilisez les stratégies ci-dessous pour atteindre la fiabilité.

La fiabilité est définie par l'utilisateur. Pour les charges de travail destinées aux utilisateurs, mesurez l'expérience utilisateur, par exemple le taux de réussite des requêtes, plutôt que les métriques du serveur (telles que l'utilisation du processeur). Pour les charges de travail par lot et par flux, vous aurez peut-être besoin de mesurer des indicateurs clés de performance (KPI), tels que le nombre de lignes en cours d'analyse par fenêtre temporelle, pour vous assurer que le rapport trimestriel sera terminé à temps, plutôt que de simplement mesurer des métriques de serveur (telles que l'utilisation du disque).

Utilisez un niveau de fiabilité suffisant. Vos systèmes doivent être suffisamment fiables pour que les utilisateurs en soient satisfaits. Toutefois, veillez à ne pas dépasser le niveau de fiabilité requis, car cela pourrait entraîner des coûts injustifiés. Définissez des objectifs de niveau de service (SLO) qui déterminent le seuil de fiabilité et utilisez des marges d'erreurs pour gérer le taux de variation. N'appliquez les principes supplémentaires répertoriés ci-dessous que si le SLO en justifie les coûts.

Mettez en place des mécanismes de redondance. Les systèmes nécessitant des niveaux de fiabilité élevés ne doivent présenter aucun point de défaillance unique et leurs ressources doivent être répliquées sur plusieurs domaines de défaillance. Un domaine de défaillance est un pool de ressources pouvant échouer indépendamment, telles qu'une VM, une zone ou une région.

Incluez l'évolutivité horizontale. Assurez-vous que chaque composant de votre système peut s'adapter à la croissance du trafic ou des données par l'ajout ressources.

Garantissez la tolérance aux surcharges. Concevez les services pour qu'ils se dégradent de manière concertée en cas de charge élevée.

Incluez une fonctionnalité de rollback. Toute modification apportée à un service par un opérateur doit être associée à une méthode bien définie pour être annulée (c'est-à-dire, pour effectuer un rollback de la modification).

Anticipez les pics de trafic. Ne synchronisez pas les requêtes entre les clients. Lorsqu'un nombre trop élevé de clients envoient du trafic au même moment, cela peut entraîner des pics de trafic qui, dans le pire des cas, génèrent des défaillances en cascade.

Testez la reprise après échec. Si vous n'avez pas testé récemment vos procédures opérationnelles de reprise après échec, les procédures ne fonctionneront probablement pas lorsque vous en aurez besoin. Les éléments à tester régulièrement incluent le basculement régional, le rollback d'une version et la restauration des données à partir de sauvegardes.

Détectez les défaillances. Il existe un compromis entre un envoi d'alertes trop rapide qui pourrait alourdir la charge de travail de l'équipe de développement, et un envoi d'alertes trop tardif qui pourrait entraîner des interruptions de service prolongées. Le délai avant de notifier les opérateurs en cas de panne (également appelé "délai de détection") doit être adapté à ce compromis.

Apportez des modifications incrémentielles. Les modifications globales instantanées apportées aux binaires ou à la configuration des services sont fondamentalement risquées. Nous vous recommandons de déployer les modifications progressivement, en effectuant des "tests en version Canary" afin de détecter les bugs ayant un impact minimal sur les utilisateurs au cours des premières étapes du déploiement.

Mettez en place une procédure d'urgence coordonnée. Concevez des pratiques opérationnelles afin de minimiser la durée des interruptions (également appelée "temps nécessaire à la résolution") tout en tenant compte de l'expérience client et du bien-être des opérateurs. Cette approche nécessite une formalisation préalable des procédures d'urgence avec des rôles et des canaux de communication bien définis.

Instrumentez les systèmes pour l'observabilité. Les systèmes doivent être suffisamment bien instrumentés pour permettre la rapidité des opérations de catégorisation, de dépannage et de diagnostic des problèmes et ainsi minimiser le temps nécessaire à la résolution.

Documentez et automatisez les procédures d'urgence. En cas d'urgence, les utilisateurs ont du mal à définir la procédure à suivre et à effectuer des tâches complexes. Par conséquent, planifiez des actions d'urgence, documentez-les et, dans l'idéal, automatisez-les.

Effectuez la gestion de la capacité. Prévoyez le trafic et provisionnez les ressources avant les pics de trafic

Réduisez les tâches laborieuses. Les tâches laborieuses constituent un travail manuel et répétitif sans valeur durable, qui augmentent à mesure que le service se développe. Essayez constamment de réduire ou d'éliminer les tâches laborieuses. Sinon, le travail opérationnel finira par surcharger les opérateurs, tout en laissant peu de place à la croissance.

Bonnes pratiques

Suivez ces bonnes pratiques pour améliorer la fiabilité.

  • Définir vos objectifs de fiabilité à l'aide des objectifs de niveau de service (SLO) et des marges d'erreurs.
  • Intégrer l'observabilité dans votre infrastructure et vos applications.
  • Concevoir des solutions évolutives et à haute disponibilité
  • Créer des fonctionnalités de déploiement flexibles et automatisées.
  • Créer des alertes efficaces.
  • Créer un processus collaboratif pour la gestion des incidents.

Définir vos objectifs de fiabilité

Nous vous recommandons de mesurer l'expérience actuelle de vos clients, ainsi que leur tolérance aux erreurs, tout en établissant des objectifs de fiabilité basés sur ces événements. Par exemple, un objectif de disponibilité du système global de 100 % sur une durée illimitée ne peut pas être atteint et n'est pas pertinent si les données attendues par l'utilisateur ne sont pas présentes.

Définissez des SLO en fonction de l'expérience utilisateur. Mesurez les métriques de fiabilité en vous rapprochant autant que possible de l'utilisateur. Si possible, instrumentez le client mobile ou Web. Si cela n'est pas possible, instrumentez l'équilibreur de charge. La mesure de la fiabilité sur le serveur ne doit être utilisée qu'en dernier recours. Définissez un niveau de SLO suffisamment élevé pour que l'utilisateur ne soit pas mécontent, mais pas au-delà.

En raison de problèmes de connectivité réseau ou d'autres problèmes temporaires côté client, vos clients ne percevront peut-être pas certains problèmes de fiabilité causés par votre application pendant de courtes périodes.

Nous vous recommandons vivement de viser un objectif proche mais inférieur à 100 % pour la disponibilité et d'autres métriques essentielles. Cette cible permet à quiconque de livrer des logiciels plus rapidement et dans des conditions de qualité élevées. Dans de nombreux cas, avec un système bien conçu, vous pouvez obtenir une disponibilité plus haute en réduisant le rythme et le volume des modifications.

En d'autres termes, les objectifs de fiabilité réalisables qui sont adaptés à l'expérience client ont tendance à définir le rythme et le champ d'application des modifications (c'est-à-dire la vitesse d'exécution) au stade maximal de tolérance des clients.

Si vous ne parvenez pas à mesurer l'expérience client existante et à en définir les objectifs, nous vous recommandons d'effectuer une analyse comparative de la concurrence. En l'absence de concurrence comparable, mesurez l'expérience client même si vous ne pouvez pas encore définir d'objectifs (par exemple, la disponibilité du système ou le taux de transactions significatives et réussies vers le client). Vous pouvez établir une corrélation avec les métriques commerciales ou les indicateurs clés de performance, tels que le volume de commandes (commerce), le volume d'appels au service client et de demandes d'assistance et leur gravité, etc. Après un certain temps, vous serez en mesure d'utiliser ces exercices de corrélation pour établir un seuil raisonnable de satisfaction client, soit un SLO.

Indicateurs de niveau de service (SLI), objectif de niveau de service (SLO) et contrat de niveau de service

Un indicateur de niveau de service (SLI) est une mesure quantitative d'un aspect du niveau de service fourni. Il s'agit d'une métrique, et non d'une cible.

Les objectifs de niveau de service (SLO) spécifient un niveau cible pour la fiabilité de votre service. Étant donné que les SLO sont essentiels pour prendre des décisions basées sur les données en ce qui concerne la fiabilité, ils sont au cœur des pratiques de l'ingénierie SRE. Le SLO correspond à une valeur pour un SLI. Lorsque le SLI est égal ou supérieur à cette valeur, le service est considéré comme étant "suffisamment fiable".

Les marges d'erreurs sont calculées sur la base de (100 % - SLO) sur une période donnée. Ils vous indiquent si votre système est plus ou moins fiable que nécessaire sur une période donnée. Nous vous recommandons généralement d'utiliser une période de 30 jours.

Les contrats de niveau de service sont des contrats explicites ou implicites avec vos utilisateurs, qui incluent les conséquences de la conformité (ou de la non-conformité) aux SLO qu'ils contiennent.

Il est recommandé de définir des SLO internes plus stricts que les contrats de niveau de service externes. Cette approche repose sur le fait que le non-respect du contrat de niveau de service entraîne généralement un crédit financier ou un remboursement des clients. Nous partons du principe que vous souhaitez résoudre les problèmes bien avant qu'ils aient un impact financier. Nous vous recommandons d'associer des SLO internes plus stricts à un processus post-mortel irréprochable avec des examens d'incidents.

Si l'application possède une architecture mutualisée, typique des applications SaaS utilisées par plusieurs clients indépendants, veillez à capturer les SLI au niveau de chaque locataire. Si vous ne mesurez les SLI qu'au niveau global, votre surveillance ne sera pas en mesure de signaler les problèmes critiques qui affectent des clients individuels ou une partie d'entre eux. Concevez l'application de manière à inclure un identifiant de locataire dans chaque requête utilisateur et à le propager à travers chaque couche de la pile. La propagation de cet identifiant permet à votre système de surveillance d'agréger des statistiques au niveau de chaque locataire sur chaque couche ou microservice qui se trouve sur le chemin de la requête.

Marges d'erreur

Gérez la vitesse de développement à l'aide des marges d'erreur. Lorsque la marge d'erreur n'est pas encore épuisée, continuez à lancer rapidement de nouvelles fonctionnalités. Lorsque la marge d'erreur est proche de zéro, figez ou ralentissez les modifications de service et consacrez des ressources techniques aux fonctionnalités de fiabilité.

Google Cloud minimise les efforts de configuration des SLO et des marges d'erreurs grâce à Service Monitoring. Ce produit offre une interface utilisateur pour la configuration manuelle des SLO, une API pour la configuration automatisée des SLO et des tableaux de bord intégrés pour le suivi du taux d'utilisation de la marge d'erreur.

Exemples de SLI

Pour les systèmes de diffusion, il est courant de rencontrer les SLI suivants :

  • La disponibilité, qui indique la durée pendant laquelle un service est utilisable. Elle correspond souvent au nombre de requêtes correctement formulées qui aboutissent (par exemple, 99 %).
  • La latence, qui indique la rapidité avec laquelle un certain pourcentage de requêtes peut être traité. Elle correspond souvent à un centile autre que le 50e (par exemple, 99e centile à 300 ms).
  • La qualité, qui vous indique la qualité d'une réponse donnée. La définition de la qualité est souvent spécifique au service, révélant dans quelle mesure le contenu de la réponse à une requête diffère du contenu de la réponse idéale. Sa valeur peut être binaire (bonne ou mauvaise) ou exprimée sur une échelle de 0 à 100 %.

Pour les systèmes de traitement de données, il est courant de rencontrer les SLI suivants :

  • La couverture, qui indique la fraction des données ayant été traitées (par exemple, 99,9 %).
  • L'exactitude, qui indique la fraction des réponses considérées comme étant correctes (par exemple, 99,99 %).
  • La fraîcheur, qui indique la fraîcheur des données sources ou des réponses agrégées, en gardant souvent la meilleure de ces deux valeurs (par exemple, 20 minutes).
  • Le débit, qui indique la quantité de données en cours de traitement (par exemple, 500 Mio/s, voire 1 000 RPS).

Pour les systèmes de stockage, il est courant de rencontrer les SLI suivants :

  • La durabilité, qui indique la probabilité que les données écrites dans le système puissent être récupérées à l'avenir (par exemple, 99,9999 %). Tout incident de perte définitive de données réduit la métrique de durabilité.
  • Le débit et la latence (comme décrit précédemment).

Questions concernant la conception

  • Mesurez-vous l'expérience utilisateur en ce qui concerne la fiabilité des applications ?
  • Les applications clientes sont-elles conçues pour capturer des métriques de fiabilité et générer des rapports les concernant ?
  • L'architecture du système est-elle conçue en tenant compte d'objectifs de fiabilité et d'évolutivité spécifiques ?
  • Pour les systèmes mutualisés, les requêtes des utilisateurs incluent-elles un identifiant de locataire, et celui-ci est-il propagé vers chaque couche de la pile logicielle ?

Recommandations

  • Définissez et mesurez des SLI centrés sur le client.
  • Définissez une marge d'erreur centrée sur le client plus stricte que votre contrat de niveau de service externe, avec des conséquences en cas de non-respect des règles (par exemple, l'arrêt de la production).
  • Configurez des SLI de latence pour capturer les valeurs aberrantes (90e ou 99e centile) afin de détecter les réponses les plus lentes.
  • Vérifiez les SLO au moins une fois par an.

Ressources

Intégrer l'observabilité dans votre infrastructure et vos applications

L'observabilité inclut la surveillance, la journalisation, le traçage, le profilage, le débogage et d'autres systèmes semblables.

Optimisez l'observabilité en instrumentant votre code. Écrivez des entrées de journal et de trace, et exportez des métriques de surveillance axées sur le débogage et le dépannage, en privilégiant les modes de défaillance les plus probables ou les plus fréquents du système. Afin d'éviter tout encombrement, auditez et affinez régulièrement votre système de surveillance, en supprimant les tableaux de bord, les alertes, et les opérations de traçage et de journalisation inutilisés ou inutiles.

La surveillance constitue la base de la hiérarchie en termes de fiabilité du service. Sans système de surveillance approprié, vous ne pouvez même pas savoir si une application fonctionne correctement.

Un système bien conçu vise à garantir un bon niveau d'observabilité dès la phase de développement. N'attendez pas qu'une application soit en production pour commencer à la surveiller.

La suite des opérations Google Cloud offre une surveillance et une journalisation en temps réel (Google Cloud et AWS, ainsi que le traçage, le profilage et le débogage). Elle peut également surveiller un maillage de services à l'aide d'Istio et des services App Engine (Cloud Monitoring).

La surconception de la surveillance et la surabondance d'alertes constituent des antimodèles courants. Évitez ces antimodèles en supprimant de manière proactive les séries temporelles, les tableaux de bord et les alertes qui ne sont jamais consultés ou qui se déclenchent rarement lors des premières étapes de lancement externe. C'est également valable pour les entrées de journal qui sont rarement analysées.

Évaluez l'envoi de tout ou partie des événements d'application à un entrepôt de données cloud tel que BigQuery. Cette fonctionnalité vous permet d'exécuter des requêtes arbitraires à moindre coût plutôt que de concevoir votre système surveillance dès le départ. Elle permet également de dissocier les rapports de la surveillance. Tous les utilisateurs de Google Data Studio ou de Looker peuvent générer des rapports.

Questions concernant la conception

  • Le processus de vérification de la conception et du code comporte-t-il des normes d'observabilité à suivre ?
  • Les métriques exportées par l'application sont-elles suffisantes pour résoudre les pannes ?
  • Les entrées de journal d'application sont-elles suffisamment détaillées et pertinentes pour le débogage ?

Recommandations

  • Mettez en œuvre un système de surveillance bien avant d'effectuer une migration ou, lors de la création d'une application, avant son premier déploiement en production.
  • Faites la distinction entre les problèmes d'application et les problèmes liés au cloud sous-jacents (par exemple, utilisez le SLI transparent et le tableau de bord d'état de Google Cloud).
  • Définissez une stratégie d'observabilité au-delà du profilage incluant le traçage, le profilage et le débogage.
  • Nettoyez régulièrement les artefacts d'observabilité inutilisés ou inutiles, y compris les alertes inexploitables.
  • Envoyez des événements d'application (soit des métriques à cardinalité élevée) à un système d'entrepôt de données tel que BigQuery.

Concevoir des solutions évolutives et à haute disponibilité

Concevoir une architecture multirégionale avec basculement

Si votre service doit être opérationnel même lorsqu'une région entière est inactive, concevez-le de manière à ce qu'il utilise des pools de ressources de calcul répartis sur différentes régions, avec basculement automatique en cas de panne d'une région. Éliminez les points de défaillance uniques, tels qu'une base de données maître à région unique qui, en cas d'inaccessibilité, pourrait entraîner une panne globale.

Éliminer les goulots d'étranglement liés à l'évolutivité

Identifiez les composants système qui ne peuvent pas dépasser les limites de ressources d'une seule VM ou d'une seule zone. Certaines applications sont conçues pour le scaling vertical, qui nécessite davantage de cœurs de processeur, de quantité de mémoire ou de bande passante réseau sur une seule VM pour pouvoir gérer une charge accrue. Ces applications possèdent des limites strictes en matière d'évolutivité et nécessitent souvent une reconfiguration manuelle pour gérer la croissance. Redéfinissez ces composants de manière à pouvoir les faire évoluer horizontalement à l'aide de la segmentation (partitionnement entre les VM ou les zones). L'ajout de segmentations permet de faciliter la croissance du trafic ou de l'utilisation. Les segmentations utilisent des types de VM standards qui peuvent être ajoutés automatiquement afin de pouvoir gérer les augmentations de charge par segmentation. Plutôt que de modifier leur conception, vous pouvez également envisager de remplacer ces composants par des services gérés ayant été conçus pour évoluer horizontalement sans aucune action de la part de l'utilisateur.

Dégrader les niveaux de service de manière concertée

Pour éviter la défaillance totale de vos services en cas de surcharge, concevez-les de manière à détecter les surcharges et à renvoyer des réponses de qualité inférieure à l'utilisateur ou à supprimer partiellement le trafic. Par exemple, un service peut répondre aux requêtes des utilisateurs avec des pages Web statiques tout en désactivant temporairement un comportement dynamique plus coûteux, ou autoriser des opérations en lecture seule tout en désactivant temporairement les mises à jour des données.

Mettre en œuvre un intervalle exponentiel entre les tentatives avec la gigue

Lorsque les clients mobiles reçoivent une réponse d'erreur de la part de votre service, ils doivent réessayer après un délai aléatoire. S'ils reçoivent des erreurs répétées, ils doivent attendre plus longtemps de manière exponentielle avant de réessayer, en plus d'ajouter des décalages temporels aléatoires (gigue) à chaque nouvelle tentative. Cela empêche les grands groupes de clients de générer des pics de trafic instantanés après une défaillance du réseau mobile, car ces pics peuvent potentiellement entraîner le plantage de vos serveurs.

Prévoir et planifier les pics de trafic

Si votre système traverse des pics de trafic connus, tels que le Black Friday pour les commerçants, consacrez du temps à la préparation de ces événements afin d'éviter une perte importante de trafic et de revenus. Prévoyez la taille du pic de trafic, ajoutez un tampon et assurez-vous que votre système dispose d'une capacité de calcul suffisante pour gérer le pic. Effectuez un test de charge du système avec la combinaison attendue de requêtes utilisateur pour vous assurer que l'estimation de la capacité de gestion de la charge correspond à la capacité réelle. Réalisez des simulations de pannes avec votre équipe de développement, en répétant les procédures de réponse et en testant les procédures collaboratives de gestion des incidents décrites ci-dessous entre vos différentes équipes.

Effectuer des tests de reprise après sinistre

N'attendez pas qu'un sinistre se produise. Testez et vérifiez régulièrement vos procédures et processus de reprise après sinistre. Vous planifiez peut-être également une architecture pour la haute disponibilité. Celle-ci n'empiète pas totalement sur la reprise après sinistre, mais il est souvent nécessaire d'en tenir compte lorsque vous réfléchissez aux valeurs RTO (objectif de temps de récupération) et RPO (objectif de point de récupération). La haute disponibilité aide à fournir le niveau de performances opérationnelles qui a été convenu (généralement, un temps d'activité) pendant une période supérieure à la normale. Lorsque vous exécutez des charges de travail de production sur Google Cloud, vous pouvez utiliser un système distribué à l'échelle mondiale. Ainsi, en cas de problème dans une région, l'application continue de fournir le service, même s'il est moins disponible. Fondamentalement, cette application exploite son plan de reprise après sinistre.

Questions concernant la conception

  • Est-il possible de faire évoluer l'application à la hausse en ajoutant des VM et sans modifier l'architecture ?
  • Chaque composant de l'architecture est-il évolutif horizontalement, via la segmentation ou d'une autre manière ?
  • Les applications clientes sont-elles conçues pour éviter la synchronisation des requêtes entre les clients ?
  • L'application est-elle capable de gérer les défaillances de toute une région cloud sans traverser de panne globale ?
  • Les requêtes utilisateurs sont-elles réparties équitablement entre les segmentations et les régions ?
  • L'application peut-elle détecter une surcharge et adapter son comportement pour éviter une panne ?

Recommandations

  • Mettez en œuvre un intervalle exponentiel entre les tentatives avec une logique de nouvelle tentative aléatoire pour les applications clientes.
  • Mettez en œuvre une architecture multirégionale avec basculement automatique pour une haute disponibilité.
  • Distribuez les requêtes des utilisateurs entre les segmentations et les régions à l'aide de l'équilibrage de charge.
  • Concevez l'application de manière à ce qu'elle se dégrade de manière concertée en cas surcharge, en diffusant des réponses partielles ou en fournissant des fonctionnalités limitées plutôt qu'en échouant complètement.
  • Définissez un processus récurrent centré sur les données pour la planification de la capacité, en utilisant des tests de charge et des prévisions de trafic afin de faciliter le provisionnement des ressources.
  • Définissez des procédures de reprise après sinistre et testez-les régulièrement.

Créer des fonctionnalités de déploiement flexibles et automatisées

S'assurer que chaque modification peut faire l'objet d'un rollback

S'il n'existe pas de méthode bien définie pour annuler certains types de modifications, modifiez la conception du service de manière à ce qu'il accepte le rollback et testez régulièrement les processus de rollback. Cette opération peut s'avérer coûteuse pour les applications mobiles. En outre, nous suggérons aux développeurs d'appliquer Firebase Remote Config pour faciliter le rollback des fonctionnalités.

Diffuser le trafic pour les promotions et les lancements planifiés

Pour les événements promotionnels comme les ventes qui commencent à une heure précise (à minuit, par exemple) et incitent de nombreux utilisateurs à se connecter simultanément au service, concevez le code client de manière à répartir le trafic sur quelques secondes en ajoutant des retards aléatoires avant le lancement des requêtes. Cela permet d'éviter les pics de trafic instantanés susceptibles d'entraîner le plantage de vos serveurs à l'heure de début programmée.

Mettre en œuvre des déploiements progressifs avec des tests en version Canary

Déployez les nouvelles versions des exécutables et les modifications de configuration de manière incrémentielle, en commençant par un champ d'application limité (par exemple, quelques VM d'une zone). Votre objectif consiste à détecter les bugs dès qu'une petite partie du trafic utilisateur est affectée, avant de déployer la modification au niveau mondial. Configurez un système de "tests en version Canary" conscient de ces modifications et qui effectue une comparaison A/B entre les métriques des serveurs modifiés et des serveurs restants, signalant ainsi tout comportement anormal. Le système Canary doit alerter les opérateurs en cas de problème et peut même interrompre automatiquement les déploiements. Une fois que la modification a réussi les tests en version Canary, propagez-la progressivement à des champs d'applications plus larges, par exemple à une zone complète, puis à une deuxième zone. Ainsi, le système modifié a le temps de traiter progressivement des volumes de trafic utilisateur plus importants afin d'exposer les bugs latents.

Automatiser la création, le test et le déploiement

Éliminez les tâches laborieuses liées aux versions en utilisant des pipelines d'intégration continue ou de déploiement continu (CI/CD) pour intégrer des tests automatisés à vos versions. Effectuez un déploiement et des tests d'intégration automatisés.

L'automatisation est utile, mais ne résout pas tous les problèmes. Elle s'accompagne d'une part équitable de coûts et de risques liés à la maintenance pour atteindre un niveau de fiabilité supérieur aux coûts initiaux de développement et de configuration.

Nous vous recommandons de commencer par réaliser l'inventaire et l'évaluation du coût des tâches laborieuses pour les équipes qui gèrent vos systèmes. Faites en sorte que ce processus s'effectue de manière continue et qu'il soit initié avant d'investir dans l'automatisation personnalisée pour étendre les solutions déjà fournies par les services et partenaires Google Cloud. Vous pouvez ajuster régulièrement l'automatisation de Google Cloud (par exemple l'algorithme d'autoscaling de Compute Engine).

Nous considérons les tâches laborieuses comme un travail manuel, répétitif, automatisable et réactif qui a tendance à manquer de valeur durable et qui se développe au moins aussi rapidement que sa source. Pour en savoir plus, consultez le chapitre associé dans le livre sur l'ingénierie SRE Éliminer les tâches laborieuses.

Voici quelques-uns des principaux domaines dans lesquels la suppression des tâches laborieuses avec Google a contribué à fournir une automatisation configurable ou personnalisée dans le but d'aider nos clients :

  • Gestion des identités : par exemple, Cloud Identity et Google IAM.
  • Les solutions hébergées par Google Cloud par opposition aux solutions développées par vos soins, par exemple la gestion des clusters (Google Kubernetes Engine), des bases de données relationnelles (Cloud SQL), des entrepôts de données (BigQuery) et des API (Apigee).
  • Les services Google Cloud et le provisionnement des locataires (par exemple, Cloud Deployment Manager, Terraform, le kit Cloud Foundation).
  • Le provisionnement de capacité supplémentaire (par exemple, plusieurs produits Google Cloud proposent l'autoscaling configurable).
  • Les pipelines CI/CD avec déploiement automatisé (par exemple, Cloud Build).
  • Les analyses Canary permettant de valider les déploiements (par exemple, Kayenta).
  • L'entraînement automatisé des modèles (pour le machine learning), par exemple AutoML.

Premièrement, nous vous recommandons de privilégier l'élimination des tâches laborieuses avant d'initier l'automatisation, en exploitant autant que possible l'automatisation configurable fournie par Google afin de réduire les tâches laborieuses restantes lors de la deuxième étape. La troisième étape, qui peut être réalisée en parallèle de la première et de la deuxième, consiste à évaluer la conception ou l'achat d'autres solutions au cas où le coût des tâches laborieuses reste élevé (par exemple, plus de 50 % du temps pour toute équipe responsable de vos systèmes de production). Lorsque vous créez ou achetez des solutions, tenez compte des coûts d'intégration, de sécurité, de confidentialité et de conformité.

Si vous trouvez un produit ou un service Google Cloud qui ne répond que partiellement à vos besoins techniques dans le domaine de l'automatisation ou de la suppression des workflows manuels, envisagez d'envoyer une demande de fonctionnalité via votre responsable de compte Google Cloud. Il peut s'agir d'une priorité pour un plus grand nombre de nos clients ou elle peut déjà être incluse dans notre feuille de route. Si tel est le cas, connaître la priorité et la chronologie de la fonctionnalité vous permet d'évaluer au mieux les compromis entre le fait de créer votre propre solution ou d'attendre pour pouvoir l'utiliser en tant que fonctionnalité Google Cloud.

Questions concernant la conception

  • Le processus de modification des exécutables et des configurations est-il automatisé ?
  • L'automatisation des modifications est-elle conçue pour permettre un rollback rapide, pour chaque modification possible ?
  • Pour les modifications qui ne peuvent pas faire l'objet d'un rollback, telles que les modifications de schéma, existe-t-il un processus de vérification de la conception permettant d'assurer la compatibilité ascendante et la rétrocompatibilité entre les versions binaires actuelles et anciennes et les schémas de données ?
  • Les fichiers de configuration système sont-ils segmentés de manière à ce que les modifications apportées à la configuration puissent être déployées de manière incrémentielle plutôt que globale ?

Recommandations

  • Configurez des tests en version Canary pour les nouvelles versions et configurations.
  • Identifiez les tâches laborieuses pour vos équipes et évaluez régulièrement leur coût.
  • Éliminez les tâches laborieuses et les workflows inutiles avant de développer une automatisation personnalisée.
  • Utilisez l'automatisation existante déjà disponible via les services Google Cloud en adaptant la configuration par défaut ou en en créant une si aucune valeur par défaut n'est fournie.
  • Évaluez la possibilité de créer (ou d'acheter) une solution d'automatisation personnalisée si les coûts et les risques liés à la maintenance en valent la peine en termes de fiabilité et de sécurité du service. Nous vous recommandons également d'évaluer les logiciels Open Source correctement gérés.

Créer des alertes efficaces

Optimiser le délai d'alerte

Réglez le délai configuré avant que le système de surveillance n'avertisse les utilisateurs d'un problème afin de minimiser le délai de détection tout en optimisant le rapport signal-bruit. Utilisez le taux de consommation de la marge d'erreur pour obtenir la configuration d'alerte optimale.

Alerter sur les symptômes, pas sur les causes

Déclenchez des alertes en fonction de l'impact direct sur l'expérience utilisateur, c'est-à-dire en fonction du non-respect des SLO mondiaux ou des SLO associés à chaque client. Évitez de signaler chaque cause sous-jacente possible susceptible d'être à l'origine d'une défaillance, en particulier lorsque l'impact est limité à une seule instance dupliquée. En cas de défaillance d'une seule instance dupliquée, un système distribué bien conçu se rétablit de manière totalement transparente.

Créer un processus collaboratif de gestion des incidents

Inévitablement, votre système aussi bien conçu soit-il, finira par entrer en conflit avec un SLO. N'oubliez pas qu'en l'absence de SLO, vos clients définiront de manière approximative le niveau de service acceptable en fonction de leur expérience passée et qu'ils transmettront les problèmes rencontrés à votre assistance technique ou tout autre groupe similaire, quel que soit le contenu de votre contrat de niveau de service.

Afin de satisfaire vos clients, nous vous recommandons vivement de définir et de mettre en œuvre régulièrement un plan de gestion des incidents. Il peut s'agir d'une checklist d'une page comportant environ 10 éléments. Ce processus aidera votre équipe à réduire le temps moyen de diagnostic (MTTD) et le temps moyen de maintenance (MTTM). (Nous préférons utiliser le MTTM en raison de l'ambiguïté du MTTR). La lettre R correspond souvent aux termes "réparation" ou "récupération" qui sous-entendent une "correction complète", contrairement à la lettre M qui indique une atténuation ("mitigation" en anglais). Le MTTM signifie explicitement l'atténuation du problème par opposition à une correction complète.

Un système bien conçu avec des opérations d'excellente qualité aura un délai moyen entre les échecs (MTBF) plus élevé. Pour en savoir plus, consultez les sections consacrées à la conception de systèmes et à l'excellence opérationnelle.

Il est également important de mettre en œuvre une culture post-mortem irréprochable et un processus d'examen des incidents. Le terme "irréprochable" signifie que votre équipe doit évaluer et documenter les problèmes de manière objective, sans accuser qui que ce soit. Les erreurs sont considérées comme des opportunités d'apprentissage et non comme 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.

Réduire le temps moyen de diagnostic

Pour réduire le temps moyen de diagnostic, vous devez impérativement mettre en œuvre les recommandations décrites dans les sections "Observabilité" et "Définir vos objectifs de surveillance", par exemple en dissociant clairement les problèmes liés aux applications des problèmes sous-jacents 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 page Affiner vos métriques SLI : blog CRE Life Lessons.

Réduire le temps moyen de maintenance

Pour réduire le temps moyen de maintenance, définissez un plan de gestion des incidents bien documenté et correctement testé. En outre, ayez toujours des données aisément accessibles documentant les changements.

Exemple de plan de gestion des incidents

  • Des problèmes de production ont été détectés (alerte, page) ou m'ont été signalés.
  • Dois-je les déléguer ? Oui, si vous et votre équipe ne parvenez pas à résoudre ce 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 ce problème à l'équipe chargée de la confidentialité et 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, par exemple sur IRC, Hangouts Chat ou Slack.
    • Déléguez des rôles précédemment définis, par exemple :
      • Chargé d'incidents : responsable de la coordination générale.
      • Responsable des communications : chargé du traitement des communications internes et externes.
      • Responsable des opérations : chargé de l'atténuation du problème.
    • Déterminez quand l'incident est terminé. Vous aurez peut-être d'abord à vous adresser à un conseiller de l'équipe d'assistance.
  • Travaillez en collaboration sur le post-mortem.
  • Participez à une réunion régulière dédiée à l'examen des incidents post-mortem au cours de laquelle vous pourrez discuter des points à traiter et des tâches à effectuer.

Graphes

Voici une liste non exhaustive de graphiques à prendre en compte. Le personnel chargé de répondre aux incidents doit pouvoir les consulter sur un même écran.

  • Indicateur(s) de niveau de service (par exemple, le nombre de requêtes ayant réussi divisé par le nombre total de requêtes)
  • Déploiements de la configuration et/ou des binaires
  • Requêtes par seconde envoyées au système
  • Erreurs par seconde renvoyées par le système
  • Requêtes par seconde depuis le système vers ses dépendances
  • Erreurs par seconde depuis le système vers ses dépendances

En règle générale, les graphiques permettent également de consulter la taille des requêtes et des réponses, le coût des requêtes, les pools de threads (pour rechercher une régression induite par l'épuisement du pool) et les métriques JVM (le cas échéant).

Testez plusieurs scénarios pour la position de ces graphiques. Vous pouvez également appliquer le machine learning afin de mettre en avant le sous-ensemble approprié de ces graphiques (c'est-à-dire les techniques de détection d'anomalies).

Enfin, comme indiqué précédemment, une autre approche courante pour une atténuation rapide consiste à concevoir des systèmes et des modifications pouvant faire facilement l'objet d'un rollback.

Recommandations

  • Définissez un plan de gestion des incidents et formez vos équipes.
  • Mettez en œuvre les recommandations de la section "Observabilité" pour réduire le temps moyen de diagnostic.
  • Créez un tableau de bord intitulé "Qu'est-ce qui a changé ?" que vous pouvez consulter en cas d'incidents.
  • Documentez des extraits de requête ou créez un tableau de bord Data Studio.
  • Évaluez Firebase Remote Config pour limiter les problèmes de déploiement liés aux applications mobiles.
  • Mettez en œuvre les recommandations décrites dans la section "Reprise après sinistre" afin de réduire le temps moyen de maintenance pour un sous-ensemble de vos incidents.
  • Concevez des solutions adaptées aux rollbacks de la configuration et des binaires et effectuez des tests.
  • Mettez en œuvre les recommandations décrites dans les sections "Conception de systèmes" et "Reprise après sinistre" (tests) afin d'augmenter le délai moyen entre les échecs.

Ressources