La traduction de l'article a été préparée spécifiquement pour les étudiants du cours , qui commence aujourd'hui !
Avez-vous déjà mis en production un nouveau service ? Ou peut-être avez-vous participé au soutien de tels services ? Si oui, qu'est-ce qui vous a motivé ? Qu’est-ce qui est bon pour la production et qu’est-ce qui est mauvais ? Comment former les nouveaux membres de l'équipe sur les versions ou la maintenance des services existants.
La plupart des entreprises finissent par adopter des approches du « Far West » en matière de pratiques d’exploitation industrielle. Chaque équipe décide de ses propres outils et meilleures pratiques par essais et erreurs. Mais cela affecte souvent non seulement le succès des projets, mais aussi les ingénieurs.
Les essais et erreurs créent un environnement dans lequel les reproches et les rejets de fautes sont fréquents. Avec ce comportement, il devient de plus en plus difficile d’apprendre de ses erreurs et de ne pas les répéter.
Organisations performantes :
- prendre conscience de la nécessité de lignes directrices pour la production,
- étudier les bonnes pratiques,
- entamer des discussions sur les problèmes de préparation à la production lors du développement de nouveaux systèmes ou composants,
- veiller au respect des règles de préparation à la production.
La préparation à la production comprend un processus de « révision ». L’examen peut prendre la forme d’une liste de contrôle ou d’une série de questions. Les révisions peuvent être effectuées manuellement, automatiquement ou les deux. Au lieu de listes statiques d’exigences, vous pouvez créer des modèles de listes de contrôle pouvant être adaptés à des besoins spécifiques. De cette façon, les ingénieurs peuvent bénéficier d’un moyen d’hériter de connaissances et d’une flexibilité suffisante en cas de besoin.
Quand vérifier qu’un service est prêt à être mis en production ?
Il est utile d'effectuer un contrôle de préparation à la production non seulement immédiatement avant la sortie, mais également lors du transfert de celle-ci à une autre équipe opérationnelle ou à un nouvel employé.
Vérifiez quand :
- Vous lancez un nouveau service en production.
- Vous transférez l'exploitation du service de production à une autre équipe, comme SRE.
- Vous transférez l'exploitation du service de production à de nouveaux collaborateurs.
- Organiser le support technique.
Liste de contrôle de préparation à la production
Il y a quelque temps, à titre d'exemple, j'ai liste de contrôle pour tester la préparation à la production. Bien que cette liste provienne des clients Google Cloud, elle sera utile et applicable en dehors de Google Cloud.
Conception et développement
- Développez un processus de build reproductible qui ne nécessite pas d’accès à des services externes et ne dépend pas de la défaillance de systèmes externes.
- Pendant la période de conception et de développement, définissez et définissez des SLO pour vos services.
- Documentez les attentes concernant la disponibilité des services externes dont vous dépendez.
- Évitez un point de défaillance unique en supprimant les dépendances sur une seule ressource globale. Répliquez la ressource ou utilisez une solution de secours lorsque la ressource est indisponible (par exemple, une valeur codée en dur).
Gestion de la configuration
- Une configuration statique, petite et non secrète peut être transmise via des paramètres de ligne de commande. Pour tout le reste, utilisez les services de stockage de configuration.
- Une configuration dynamique doit avoir des paramètres de secours au cas où le service de configuration serait indisponible.
- La configuration de l'environnement de développement ne doit pas être liée à la configuration de production. Sinon, cela pourrait conduire à un accès de l'environnement de développement aux services de production, ce qui pourrait entraîner des problèmes de confidentialité et des fuites de données.
- Documentez ce qui peut être configuré dynamiquement et décrivez le comportement de secours si le système de livraison de configuration n'est pas disponible.
Gestion des versions
- Documentez le processus de publication en détail. Décrivez comment les versions affectent les SLO (par exemple, augmentations temporaires de la latence dues à des échecs de cache).
- Documentez les versions Canary.
- Élaborez un plan de révision des versions Canary et, si possible, des mécanismes de restauration automatique.
- Assurez-vous que les restaurations peuvent utiliser les mêmes processus que les déploiements.
Observabilité
- Assurez-vous que l’ensemble de métriques requis pour le SLO est collecté.
- Assurez-vous de pouvoir différencier les données client et serveur. Ceci est important pour trouver les causes des dysfonctionnements.
- Configurez des alertes pour réduire les coûts de main-d’œuvre. Par exemple, supprimez les alertes provoquées par des opérations de routine.
- Si vous utilisez Stackdriver, incluez les métriques de la plate-forme GCP dans vos tableaux de bord. Configurez des alertes pour les dépendances GCP.
- Propagez toujours les traces entrantes. Même si vous n'êtes pas impliqué dans le traçage, cela permettra aux services de niveau inférieur de déboguer les problèmes en production.
Protection et sécurité
- Assurez-vous que toutes les connexions externes sont cryptées.
- Assurez-vous que vos projets de production disposent de la configuration IAM correcte.
- Utilisez des réseaux pour isoler des groupes d'instances de machines virtuelles.
- Utilisez un VPN pour vous connecter en toute sécurité aux réseaux distants.
- Documenter et surveiller l’accès des utilisateurs aux données. Assurez-vous que tous les accès des utilisateurs aux données sont audités et enregistrés.
- Assurez-vous que les points de terminaison de débogage sont limités par les ACL.
- Désinfectez les entrées des utilisateurs. Configurez les limites de taille de charge utile pour la saisie utilisateur.
- Assurez-vous que votre service peut bloquer de manière sélective le trafic entrant pour des utilisateurs individuels. Cela bloquera les violations sans affecter les autres utilisateurs.
- Évitez les points de terminaison externes qui lancent de nombreuses opérations internes.
Planification des capacités
- Documentez la manière dont votre service évolue. Par exemple : nombre d’utilisateurs, taille de la charge utile entrante, nombre de messages entrants.
- Documentez les besoins en ressources pour votre service. Par exemple : nombre d'instances de machines virtuelles dédiées, nombre d'instances Spanner, matériel spécialisé tel que GPU ou TPU.
- Documenter les limitations des ressources : type de ressource, région, etc.
- Documentez les restrictions de quota pour la création de nouvelles ressources. Par exemple, limiter le nombre de requêtes API GCE si vous utilisez l'API pour créer de nouvelles instances.
- Envisagez d'exécuter des tests de charge pour analyser la dégradation des performances.
C'est tout. Rendez-vous en classe !
Source: habr.com