Poste
DevOps et ingénierie plateforme
Combien de personnes doivent faire quelque chose pour qu'un changement arrive en production ? Si c'est plus de deux, un déploiement est un événement et non une activité, et c'est pour cela qu'il a lieu rarement.
Entretien préalable
Quatre questions par lesquelles nous commencerions
Combien de personnes touchent un déploiement en production ?
Plus il y a de mains, moins vous déployez souvent, et moins vous déployez souvent, plus chaque changement devient gros et risqué.
À quelle vitesse apprenez-vous un problème en production ?
Si c'est par un utilisateur, la surveillance mesure autre chose que ce qui casse réellement.
Comment savez-vous que l'environnement de test correspond à la production ?
Si c'est par hypothèse, certaines anomalies de production ne se reproduisent nulle part ailleurs.
Qu'est-ce que vous ne faites pas, tout en sachant qu'il le faudrait ?
En général : vous ne rangez pas la configuration et vous ne passez pas en revue les coûts d'infrastructure. Toujours parce que rien ne brûle.
Nous prenons le travail répétitif, vous gardez les décisions sur la plateforme
La configuration des environnements, l'exécution des déploiements, le recueil du contexte pendant un incident et le récapitulatif des coûts peuvent être retirés du bureau. Les décisions sur le standard de la plateforme et sur la réponse à un incident restent à l'ingénieur.
- Un déploiement cesse d'être un événement. - Une exécution reproductible avec retour arrière rend les changements plus fréquents et plus petits plus sûrs que les rares et gros.
- Un incident commence avec du contexte. - Ce qui a changé ces dernières heures, ce qui a réagi d'autre, quels services sont liés, avant que quiconque ne commence à chercher.
- Le standard se voit et un écart porte un nom. - Une équipe peut faire autrement, mais alors on sait où et pourquoi, au lieu de le découvrir pendant une panne.
Périmètre
Ce qui peut être retiré d'une équipe plateforme
Vingt tâches à titre d'exemple. Chacune a un point de validation humaine. Ci-dessous une sélection ; le périmètre, nous l'ajustons à votre stack.
Environnements et leur configuration
- Configuration des environnements décrite et reproductible
- Une comparaison de l'environnement de test avec la production
- Un signal quand la configuration dérive
- Un registre des écarts au standard (décision : l'ingénieur)
Déploiements
- Une exécution de déploiement reproductible avec une étape de retour arrière là où elle est possible
- Des vérifications avant déploiement comme condition de démarrage
- Un registre des déploiements avec la portée des changements
- Un signal quand un déploiement s'écarte de l'exécution (appréciation : l'ingénieur)
Surveillance et alertes
- Une revue des alertes quant à leur utilité
- Signalement des alertes à forte part de faux positifs (jugement d'utilité : l'ingénieur)
- Lier une alerte à un service et à un responsable
- Un signal quand un service n'a pas de surveillance
Incidents
- Contexte avec l'avis : changements récents et services liés
- Les signaux de la même fenêtre temporelle réunis
- La chronologie de l'incident consignée pendant qu'il se déroule
- Un projet d'analyse post-incident (contenu : l'ingénieur)
Coûts d'infrastructure
- Coût affecté aux services et aux équipes
- Signalement des ressources inutilisées
- Évolutions de coût par rapport à la période précédente
- Matière pour une décision de changer la configuration (décision : l'ingénieur)
Une journée de travail
Aujourd'hui
- La configuration des environnements vit sa propre vie et dérive en silence
- Un déploiement exige plusieurs personnes présentes et une bonne journée
- Pendant un incident, vous commencez par établir ce qui a changé récemment
- Les alertes arrivent en quantités qui consomment l'attention de l'équipe
- Vous reconstituez la chronologie de l'incident après coup, de mémoire
- Vous regardez les coûts d'infrastructure quand la facture arrive
Avec l'assistance de l'IA
- La dérive de configuration entre environnements est signalée
- Le déploiement a une exécution reproductible et, pour les changements irréversibles, des paliers
- Un incident commence avec la liste des changements récents et des services liés
- Les alertes qui n'ont jamais mené à une action sont signalées
- La chronologie de l'incident se consigne seule pendant qu'il se déroule
- Le coût est affecté aux services et aux équipes au fil de l'eau
- Fréquence de déploiement
des changements plus petits plus souvent, au lieu de gros et rares
un déploiement n'exige pas de réunir plusieurs personnes
- Délai de rétablissement après un incident
un chemin plus court vers la cause
le contexte et les changements récents accompagnent l'avis
- Des environnements qui correspondent
moins d'anomalies qu'on ne peut reproduire hors production
la dérive de configuration est signalée
- Coût d'infrastructure
on voit ce qui coûte et à qui cela appartient
coût affecté aux services et aux équipes
Nous commençons par les déploiements, parce que leur fréquence influence tout le reste.
- Étape 1
Une exécution de déploiement reproductible
Avec une étape de retour arrière et des vérifications avant démarrage. Pour les changements irréversibles, avant tout les migrations de schéma, le retour arrière n'existe pas et nous ne prétendons pas le contraire : là on travaille par paliers et on corrige en avant, et l'exécution doit en tenir compte.
- Étape 2
Des environnements qui correspondent
Une comparaison de configuration et un signal de dérive.
- Étape 3
Contexte pendant un incident
Changements récents, services liés, chronologie consignée pendant le déroulement.
- Étape 4
Alertes et coûts
Une revue de l'utilité des alertes et l'affectation des coûts. En dernier, parce que cela exige des données de plusieurs périodes.
Questions fréquentes
Les questions qui reviennent à la première réunion
En quoi est-ce différent d'un administrateur systèmes ?
L'administrateur entretient ce qui tourne déjà : serveurs, sauvegardes, mises à jour. Ici, il s'agit des environnements dans lesquels le logiciel se construit et du chemin qu'un changement emprunte jusqu'en production. Les postes sont souvent combinés dans les petites entreprises, mais les problèmes qu'ils résolvent sont complètement différents.
L'équipe plateforme peut-elle être plus petite après cela ?
Les équipes plateforme sont en général un goulot d'étranglement et non un excédent : chaque équipe produit fait la queue devant une ou deux personnes. Reprendre les déploiements répétitifs et le recueil de contexte pendant les incidents ne réduit pas l'équipe, cela raccourcit cette file. C'est d'ailleurs la première chose que remarquent les équipes produit.
Cela relève-t-il du règlement sur l'IA ?
Travailler sur l'infrastructure n'est pas un usage à haut risque. Le seul point qui demande de la prudence, c'est que les données sur les déploiements et les incidents servent à améliorer la plateforme et non à évaluer des équipes ou les personnes qui ont livré un changement.
Une question qui ne figure pas ici ? Réservez un appel
Étape suivante
Combien de fois avez-vous déployé en production le mois dernier ?
Nous vous montrerons à quoi ressemble le travail plateforme quand un déploiement cesse d'être un événement et qu'un incident commence avec du contexte.