Ce pilier du framework d'architecture Google Cloud couvre 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 connaître les principes et recommandations de fiabilité spécifiques aux charges de travail d'IA et de ML, consultez la section Perspective IA et ML: fiabilité du framework d'architecture.
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 qu'un écart se produit
- Modèles de conception pour les éléments suivants :
- Évolutivité
- Haute disponibilité
- Reprise après sinistre
- Gestion automatisée des modifications
- Composants qui s'autoréparent (capables de résoudre les problèmes sans intervention manuelle)
- Code incluant une instrumentation pour l'observabilité
- Fonctionnement mains libres, par exemple avec l'exécution du service avec un minimum de travail manuel et de charge cognitive pour l'opérateur, et détection et atténuation rapides des défaillances
L'ensemble de l'organisation d'ingénierie est responsable de la fiabilité du service, y compris les équipes de développement, de gestion des produits, d'exploitation et d'ingénierie en fiabilité des sites (SRE). Les équipes doivent comprendre les cibles de fiabilité, les marges de risque et 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 jette les bases des documents plus détaillés qui suivent. En lisant cet article, vous découvrirez que l'approche de Google en termes de fiabilité est basée sur les principes de fiabilité suivants.
Prioriser la fiabilité
Les équipes d'ingénierie donnent parfois la priorité au développement de nouveaux produits. Les utilisateurs attendent de nouvelles mises à jour passionnantes de leurs applications préférées, mais 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.
Selon les normes actuelles, une page Web doit 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 bon niveau de fiabilité de service pour vos clients, vous devez mesurer les éléments suivants:
- Charge de travail visible par l'utilisateur: 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 les indicateurs clés de performance (KPI) pour le débit de données, tels que 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 sera terminé à 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 en sont satisfaits. En règle générale, les utilisateurs n'ont pas besoin d'une fiabilité à 100% pour être satisfaits. Définissez donc 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 aident à déterminer quand vous devez vous concentrer davantage sur la stabilité ou sur 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 autres documents du pilier de fiabilité du framework Architecture fournissent des principes de conception et opérationnels qui vous aident à maximiser la fiabilité du système. Les sections suivantes récapitulent les principes de conception et de fonctionnement 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 des 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 section 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 l'évolutivité et la haute disponibilité (HA), 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 d'exploitation en procédant comme suit:
- Choisir des noms logiques et autodéfinis pour les applications et les services
- Utiliser des tests Canary pour implémenter des déploiements progressifs de 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 de compilation, de test et de déploiement programmatique
- 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 : pratique consistant à injecter 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 section Créer des processus et des outils opérationnels fiables.
Créer des alertes efficaces
Lorsque vous créez vos alertes, nous vous recommandons de procéder comme suit:
- Optimiser les alertes pour les délais 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 section Créer des alertes efficaces dans le pilier 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. Une gestion efficace des risques IT comprend les éléments suivants:
- Propriété: attribuez des propriétaires de service clairs.
- 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:
- Cultivez une culture irréprochable dans votre organisation.
- Établissez un processus post-mortem qui se concentre sur le "quoi", et non sur le "qui".
- Tirez des enseignements de vos pannes en menant une enquête appropriée et en identifiant les domaines à améliorer pour éviter les récurrences.
Pour en savoir plus, consultez la section Créer un processus collaboratif de gestion des incidents dans le pilier de fiabilité du framework d'architecture.
Étape suivante
- Découvrez les composants des SLO.
- Découvrez les recommandations des autres piliers du framework d'architecture.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.