Liste de contrôle de la préparation à la production

La traduction de l'article a été préparée spécialement pour les étudiants du cours DevOps Practices and Tools , qui commence aujourd'hui!

---

Avez-vous déjà lancé un nouveau service en production? Ou peut-être engagé dans le maintien de tels services? Si oui, qu'avez-vous suivi? Qu'est-ce qui est bon pour la production et qu'est-ce qui est mauvais? Comment formez-vous les nouveaux membres de l'équipe à libérer ou à maintenir les services existants.

La plupart des entreprises en termes de pratiques d'exploitation industrielle finissent par adopter les approches du «Far West». Chaque équipe, par essais et erreurs, détermine indépendamment les outils et les meilleures pratiques. Mais cela affecte souvent non seulement la réussite des projets, mais aussi les ingénieurs.

La méthode des essais et erreurs crée un environnement dans lequel la recherche des auteurs et le transfert de responsabilité sont communs. Avec ce comportement, il devient de plus en plus difficile d'apprendre des erreurs et de ne plus les répéter.

Organisations réussies:

• reconnaître la nécessité de lignes directrices pour la production,
• apprendre les meilleures pratiques
• entamer une discussion sur l'état de préparation à la production lors du développement de nouveaux systèmes ou composants,
• assurer le respect des règles de préparation à la production.

La préparation de la production comprend un processus d'examen. Un examen peut prendre la forme d'une liste de contrôle ou d'un ensemble de questions. Un examen peut être effectué manuellement, automatiquement ou les deux. Au lieu de listes d'exigences statiques, des modèles de liste de contrôle peuvent être créés et peuvent être adaptés à des besoins spécifiques. De cette façon, les ingénieurs peuvent obtenir un moyen d'hériter des connaissances et d'une flexibilité suffisante en cas de besoin.

Quand vérifier si le service est prêt pour la production?

Il est utile d'effectuer un contrôle de préparation pour la production non seulement immédiatement avant la sortie, mais également lors du transfert à une autre équipe d'exploitation ou à un nouvel employé.

Vérifiez quand:

• Lancement d'un nouveau service en production.
• Transférer le fonctionnement du service de production à une autre équipe, telle que SRE.
• Transférer l'exploitation du service de production à de nouveaux collaborateurs.
• Organisez le support technique.

Liste de contrôle de la préparation à la production

Il y a quelque temps, à titre d'exemple, j'ai publié une liste de contrôle pour vérifier la préparation à la production. Bien que cette liste soit apparue lors de l'utilisation des clients Google Cloud, elle sera utile et applicable en dehors de Google Cloud.

Conception et développement

• Concevez un processus de génération 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 installez SLO pour vos services.
• Documentez les attentes quant à la disponibilité des services externes dont vous dépendez.
• Évitez un seul point de défaillance en supprimant les dépendances sur une ressource globale. Répliquez la ressource ou utilisez l'option de secours lorsque la ressource n'est pas disponible (par exemple, valeur codée en dur).

Gestion de la configuration

• Les configurations statiques, petites et non secrètes peuvent être transmises via les options de ligne de commande. Pour le reste, utilisez les services de stockage de configuration.
• La configuration dynamique doit avoir des paramètres de sauvegarde au cas où le service de configuration ne serait pas disponible.
• La configuration de l'environnement de développement ne doit pas être liée à la configuration de production. Sinon, cela peut entraîner l'accès aux services de production à partir de l'environnement de développement, ce qui peut 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, une augmentation temporaire de la latence due à des échecs de cache).
• Documenter les sorties des canaris.
• Élaborer un plan d'analyse des rejets de canaris et, si possible, des mécanismes de restauration automatique.
• Assurez-vous que les annulations peuvent utiliser les mêmes processus que le déploiement.

Aptitude au suivi (observabilité)

• Assurez-vous que vous compilez l'ensemble des métriques requises pour SLO.
• Assurez-vous de pouvoir distinguer les données client et serveur. Ceci est important pour le dépannage.
• Définissez des alertes pour réduire les coûts de main-d'œuvre. Par exemple, supprimez les alertes causées par des opérations de routine.
• Si vous utilisez Stackdriver, incluez les métriques de la plateforme GCP dans vos tableaux de bord. Configurez des alertes pour les dépendances GCP.
• Distribuez toujours la trace entrante. Même si vous ne participez pas à la trace, cela permettra aux services de niveau inférieur de déboguer les problèmes de production.

Protection et sécurité

• Assurez-vous que toutes les connexions externes sont cryptées.
• Assurez-vous que vos projets de production ont la configuration IAM correcte.
• Utilisez des réseaux pour isoler des groupes d'instances de machine virtuelle.
• Utilisez un VPN pour vous connecter en toute sécurité aux réseaux distants.
• Documentez et surveillez l'accès des utilisateurs aux données. Assurez-vous que tous les accès utilisateur aux données sont vérifié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 utilisateur. Configurez les limites de taille de charge utile pour l'entrée utilisateur.
• Assurez-vous que votre service peut bloquer sélectivement le trafic entrant pour des utilisateurs individuels. Cela bloquera les violations sans affecter les autres utilisateurs.
• Évitez les points de terminaison externes qui lancent un grand nombre d'opérations internes.

Planification des capacités

• Documentez l'évolution de votre service. 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: le nombre d'instances de machine virtuelle allouées, le nombre d'instances de Spanner, l'équipement spécialisé tel qu'un GPU ou TPU.
• Documenter les restrictions de ressources: type de ressource, région, etc.
• Documenter les limites de quota pour la création de nouvelles ressources. Par exemple, limiter le nombre de demandes d'API GCE si vous utilisez l'API pour créer de nouvelles instances.
• Envisagez d'effectuer des tests de résistance pour analyser la dégradation des performances.

C’est tout. Rendez-vous en classe!