Framework d'architecture Google Cloud : Fiabilité

Last reviewed 2024-03-29 UTC

Cette catégorie du framework d'architecture Google Cloud décrit les principes de conception requis pour concevoir et exploiter des services fiables sur une plate-forme cloud à un niveau élevé.

Le framework d'architecture décrit les bonnes pratiques, fournit des recommandations de mise en œuvre et explique certains des produits et services disponibles. Son but est de vous aider à concevoir votre déploiement Google Cloud pour répondre aux besoins de votre entreprise.

Pour exécuter un service fiable, votre architecture doit inclure les éléments suivants :

  • Des objectifs de fiabilité mesurables que vous corrigez rapidement chaque fois que des écarts se produisent.
  • Modèles de conception pour les éléments suivants :
    • Évolutivité
    • Haute disponibilité
    • Reprise après sinistre
    • Gestion automatisée du changement
  • Des composants qui s'autoréparent (ont la possibilité de résoudre les problèmes sans intervention manuelle)
  • Code comprenant une instrumentation pour l'observabilité
  • Opérations en mode mains libres telles que les exécutions de service avec un minimum de travail manuel, la charge cognitive de l'opérateur, ainsi que la détection et l'atténuation rapides des défaillances

L'ensemble du service d'ingénierie est responsable de la fiabilité du service, y compris les équipes de développement, de gestion des produits, d'opérations et d'ingénierie en fiabilité des sites (SRE). Les équipes doivent comprendre les cibles de fiabilité, les risques et les marges d'erreur de leur application, et être responsables de ces exigences. Les conflits entre la fiabilité et le développement des fonctionnalités produit doivent être hiérarchisés et être remontés en conséquence.

Principes de fiabilité de base

Cette section explore les principes fondamentaux d'un service fiable et pose les bases des documents plus détaillés qui suivent. Au fil de votre lecture sur ce sujet, vous découvrirez l'approche de Google en termes de fiabilité basée sur les principes de fiabilité suivants.

Prioriser la fiabilité

Les équipes d'ingénieurs donnent parfois la priorité au développement de nouveaux produits. Alors que les utilisateurs anticipent les nouvelles mises à jour de leurs applications préférées, les mises à jour de produits sont un objectif à court terme pour vos utilisateurs. Vos clients s'attendent toujours à la fiabilité du service, même s'ils ne s'en rendent pas compte. Un ensemble étendu d'outils ou de graphiques sophistiqués dans votre application n'a aucune importance si vos utilisateurs ne peuvent pas accéder à votre service ou si votre service présente de mauvaises performances. En cas de mauvaises performances des applications, ces fonctionnalités seront rapidement inutiles.

Mesurer la fiabilité du point de vue de l'utilisateur

En résumé, votre service est fiable lorsque vos clients sont satisfaits. Les utilisateurs ne sont pas toujours prévisibles, et vous pouvez surestimer ce qu'il faut pour les satisfaire.

À l'heure actuelle, une page Web devrait se charger en deux secondes environ. L'abandon de page est d'environ 53% lorsque le temps de chargement est retardé d'une seconde supplémentaire, et augmente considérablement pour atteindre 87% lorsque le temps de chargement est retardé de trois secondes. Toutefois, viser un site qui génère des pages en une seconde n'est probablement pas le meilleur investissement. Pour déterminer le niveau de fiabilité de service approprié pour vos clients, vous devez mesurer les éléments suivants:

  • Charge de travail destinée aux utilisateurs: mesurez l'expérience utilisateur. Par exemple, interrogez le taux de réussite des requêtes des utilisateurs, et pas uniquement les métriques du serveur telles que l'utilisation du processeur.
  • Charges de travail par lot et par flux: mesurez des indicateurs clés de performance (KPI) pour le débit de données, comme le nombre de lignes analysées par fenêtre temporelle. Cette approche est plus informative qu'une métrique de serveur telle que l'utilisation du disque. Les KPI de débit permettent de s'assurer que le traitement demandé par l'utilisateur se termine à temps.

Ne pas viser 100 % de fiabilité (mauvaise cible)

Ce principe est une extension du précédent. Vos systèmes sont suffisamment fiables lorsque les utilisateurs sont satisfaits. En règle générale, les utilisateurs n'ont pas besoin d'une fiabilité à 100% pour être satisfaits. Par conséquent, définissez des objectifs de niveau de service (SLO) qui définissent le seuil de fiabilité sur le pourcentage nécessaire pour satisfaire les utilisateurs, puis utilisez des marges d'erreur pour gérer le taux de variation approprié.

N'appliquez les principes de conception et d'exploitation de ce framework à un produit que si le SLO de ce produit ou de cette application en justifie le coût.

Fiabilité et innovation rapide sont complémentaires

Utilisez des marges d'erreur pour trouver un équilibre entre la stabilité du système et l'agilité des développeurs. Les conseils suivants vous aideront à déterminer quand vous concentrer davantage sur la stabilité ou le développement:

  • Lorsque la marge d'erreur diminue, ralentissez et concentrez-vous sur les fonctionnalités de fiabilité.
  • Lorsqu'une marge d'erreur suffisante est disponible, vous pouvez innover rapidement et améliorer le produit ou lui ajouter des fonctionnalités.

Principes de conception et opérationnels

Les documents restants dans la catégorie de fiabilité du framework d'architecture fournissent des principes de conception et d'exploitation qui vous aident à optimiser la fiabilité du système. Les sections suivantes récapitulent les principes de conception et d'exploitation que vous trouverez dans chaque document de cette série.

Définir vos objectifs de fiabilité

N'oubliez pas que la satisfaction des utilisateurs définit la fiabilité et que vos objectifs de fiabilité sont représentés par les SLO que vous définissez. Lorsque vous définissez vos SLO, tenez compte des points suivants:

  • Choisissez les indicateurs de niveau de service (SLI) appropriés.
  • Définir des SLO en fonction de l'expérience utilisateur
  • Améliorer les SLO de manière itérative
  • Utiliser des SLO internes stricts
  • Gérer la vitesse de développement à l'aide des marges d'erreur

Pour en savoir plus, consultez la page Composants des objectifs de niveau de service.

Intégrez l'observabilité dans votre infrastructure et vos applications.

Optimisez l'observabilité en instrumentant votre code. Pour en savoir plus, consultez la page Intégrer l'observabilité dans votre infrastructure et vos applications.

Concevoir des solutions évolutives et à haute disponibilité

En ce qui concerne le scaling et la haute disponibilité, tenez compte des principes suivants:

  • Créer une redondance pour la haute disponibilité
  • Répliquer les données dans plusieurs régions pour la reprise après sinistre (DR)
  • Concevoir une architecture multirégionale pour la résilience aux pannes régionales
  • Dégrader les niveaux de service de manière concertée en cas de surcharge
  • Prévenir les défaillances de manière à préserver la fonctionnalité système
  • Concevoir des appels d'API et des commandes opérationnelles réexécutables
  • Tenez compte des dépendances :
    • Identifier et gérer les dépendances système
    • Minimiser les dépendances critiques
  • S'assurer que chaque modification peut faire l'objet d'un rollback

De plus, les activités suivantes contribuent à la fiabilité de votre service:

  • Éliminer les goulots d'étranglement liés à l'évolutivité
  • Anticiper et atténuer les pics de trafic
  • Nettoyer et valider les entrées

Pour plus d'informations, consultez la section Concevoir des solutions évolutives et à haute disponibilité.

Créer des outils et des processus opérationnels fiables

Intégrez la fiabilité aux outils et aux processus opérationnels en procédant comme suit:

  • Choisir des noms logiques et auto-définis pour les applications et les services
  • Utiliser les tests Canary pour mettre en œuvre des déploiements progressifs des procédures
  • Planifier vos promotions et lancements afin de répartir le trafic et de réduire la surcharge du système
  • Développer des processus programmatiques de compilation, de test et de déploiement
  • Se protéger contre les incidents d'origine humaine, intentionnels ou non
  • Développer, tester et documenter les activités de gestion des échecs
  • Développer et tester régulièrement les procédures de reprise après sinistre
  • Ingénierie du chaos: injectez des pannes dans le système pour déterminer la tolérance aux pannes et la résilience de votre service.

Pour en savoir plus, consultez la page Créer des processus et des outils opérationnels fiables.

Créer des alertes efficaces

Lorsque vous créez vos alertes, nous vous recommandons d'effectuer les opérations suivantes:

  • Optimiser les alertes pour les retards appropriés
  • Alerter sur les symptômes plutôt que sur les causes
  • Alerter sur les anomalies plutôt que sur les moyennes

Pour en savoir plus, consultez la page Créer des alertes efficaces dans la catégorie de fiabilité du framework d'architecture.

Créer un processus collaboratif de gestion des incidents

La gestion des incidents (IRM) est essentielle pour la reprise du service et la réduction des dommages. La fonctionnalité IRM efficace inclut:

  • Propriété: désignez clairement des propriétaires de services.
  • Alertes bien réglées: améliorez la gestion des incidents et réduisez le temps de détection grâce à des alertes soigneusement conçues.
  • Plans et formations IRM: réduisez le temps nécessaire à la résolution avec des plans, une documentation et une formation complets.
  • Tableaux de bord: concevez des dispositions et du contenu de tableau de bord pour alerter efficacement en cas de problèmes afin de minimiser le temps nécessaire à la résolution.
  • Documentation: créez et gérez des contenus clairs et concis pour tous les aspects de l'assistance du service, y compris les procédures de diagnostic et l'atténuation des risques de scénarios d'interruption.
  • La culture non accusatoire:
    • Créez un environnement irréprochable dans votre organisation.
    • Mettez en place un processus de post-mortem qui se concentre sur quoi, et non qui.
    • Profitez de vos pannes en examinant correctement et en identifiant les domaines à améliorer et en évitant les récurrences.

Pour en savoir plus, consultez la section Créer un processus collaboratif de gestion des incidents dans la catégorie de fiabilité du framework d'architecture.

Étapes suivantes