Questions d'entretien Ingénieur plateforme

Je traite une plateforme développeur interne comme un produit dont les ingénieurs sont les utilisateurs, ce qui signifie appliquer les mêmes mécanismes de recherche utilisateur, d'itération et de feedback que les équipes produit utilisent en externe. La chose la plus importante qu'une équipe plateforme puisse faire est de réduire la charge cognitive : chaque décision qu'un développeur n'a pas à prendre sur l'infrastructure est une décision qu'il peut consacrer à son vrai problème. Une plateforme réussie dispose d'un chemin doré clair, une façon opinionée et bien documentée de déployer et d'opérer un service, mais elle ne force pas les développeurs à l'utiliser dans tous les cas. Le chemin doré doit couvrir 80 % des cas d'usage avec un minimum de friction. Pour les 20 % restants, la plateforme doit fournir des portes de sortie bien documentées. Le plus grand mode d'échec que je vois est les équipes plateforme qui construisent une infrastructure pour elles-mêmes plutôt que pour leurs utilisateurs. Je surveille les taux d'adoption et les scores de satisfaction des développeurs régulièrement.

Un pipeline CI/CD qui s'adapte à plusieurs équipes doit équilibrer standardisation et flexibilité. Mon approche consiste à définir un ensemble de templates de pipeline réutilisables couvrant les patterns les plus courants : construire et tester un service, construire et pousser une image de conteneur, déployer sur un cluster Kubernetes avec capacité de rollback. Ces templates sont maintenus centralement par l'équipe plateforme et versionnés, de sorte que les équipes consomment une version taguée plutôt qu'une référence flottante. Dans chaque template se trouvent des points d'extension bien documentés où les équipes peuvent ajouter des étapes personnalisées sans forker l'ensemble du pipeline. J'investis également dans la rapidité du feedback : les pipelines qui prennent 20 minutes à compléter seront contournés plutôt qu'utilisés. Je cible une boucle de feedback de 5 minutes pour les tests unitaires et le linting, et je réserve les tests d'intégration et de bout en bout plus longs pour les contrôles pré-fusion.

Je pense à l'observabilité en termes des trois piliers, métriques, logs et traces, mais l'objectif est toujours de pouvoir répondre à "pourquoi est-ce lent ou cassé ?" sans avoir à déployer du nouveau code. Pour les métriques, j'instrumente les services avec les métriques RED (Rate, Errors, Duration) comme baseline. Pour les logs, j'impose un logging structuré sur tous les services avec un schéma cohérent incluant l'ID de trace, le nom du service et la sévérité, de sorte que les logs de différents services peuvent être corrélés dans une seule requête. Pour les traces, j'utilise le tracing distribué avec une stratégie d'échantillonnage qui capture 100 % des traces d'erreur et un pourcentage configurable des traces de succès. Je construis également des tableaux de bord au niveau du service que tout ingénieur d'astreinte peut lire sans connaissance approfondie du service spécifique. La mesure d'une bonne configuration d'observabilité est le temps moyen de diagnostic.

Les mises à niveau de Kubernetes sont l'une des tâches les plus sensibles sur le plan opérationnel qu'une équipe plateforme effectue, et la clé est de les traiter comme une migration sans interruption plutôt qu'une fenêtre de maintenance. Mon approche commence trois mois avant une version cible en testant la nouvelle version dans un cluster de test dédié avec un échantillon de charge de travail représentatif. Je fais fonctionner la nouvelle version en parallèle avec le cluster existant pendant quatre à six semaines, en cherchant des avertissements de dépréciation, des changements d'API et des différences de comportement. Je documente les changements cassants et les communique aux équipes d'ingénierie au moins six semaines à l'avance. La migration réelle utilise une approche de cluster blue-green : je provisionne un nouveau cluster à la version cible, migre les charges de travail service par service avec déplacement du trafic au niveau du load balancer, et garde l'ancien cluster chaud pendant deux semaines en cas de besoin de rollback.

J'ai rejoint une équipe où les ingénieurs passaient en moyenne quatre heures à configurer un nouveau service de zéro, car il n'y avait pas de template standard et chaque service avait des patterns différents pour la journalisation, la configuration et le déploiement. J'ai mené cinq courtes interviews avec des développeurs pour comprendre les plus grands points de douleur, puis j'ai construit un outil de scaffolding qui générait un squelette de service prêt pour la production en moins de deux minutes avec des valeurs par défaut opinionées. Avant le changement, j'ai mesuré le temps de configuration en observant des ingénieurs passer par le processus. Six semaines après le lancement, j'ai répété la mesure et constaté que le temps de configuration moyen était passé de quatre heures à 25 minutes. L'enquête de satisfaction des développeurs a montré que l'outillage était le domaine le plus amélioré ce trimestre.

J'ai poussé une mise à jour de nos images de conteneurs de base qui incluait une version plus récente d'une bibliothèque partagée. Je l'avais testée sur nos propres services de plateforme mais n'avais pas vérifié tous les services consommateurs. Dans les deux heures suivant le déploiement, trois équipes ont signalé des builds cassés car la mise à jour de la bibliothèque avait introduit un changement d'API cassant qui n'était pas rétrocompatible. Ma réponse immédiate a été de revenir à la version précédente de l'image de base et d'envoyer une mise à jour d'incident claire à toutes les équipes affectées dans les 15 minutes. Une fois le problème immédiat résolu, j'ai effectué une revue post-incident. La cause principale était l'absence de tests de compatibilité automatisés pour les mises à jour de bibliothèques partagées. J'ai construit un pipeline de test qui valide les changements d'image de base contre les 20 services consommateurs principaux avant toute publication.

Je gérais un backlog de plateforme où deux équipes avaient des besoins urgents et concurrents : l'Équipe A voulait des performances améliorées pour les requêtes de logs car leur temps de débogage avait significativement augmenté, et l'Équipe B voulait une rotation des secrets en libre-service car son audit de sécurité avait signalé un processus manuel. J'ai mené une session de priorisation structurée avec les deux équipes, en présentant honnêtement la capacité de l'équipe plateforme et en demandant à chaque équipe de quantifier le coût du retard. La demande de l'Équipe B avait une échéance de conformité qui la rendait objectivement plus prioritaire. Je me suis engagé envers l'Équipe A avec une date de livraison spécifique dans quatre semaines et leur ai fourni un contournement temporaire entre-temps. J'ai ensuite livré la demande de l'Équipe B en trois semaines et celle de l'Équipe A en semaine cinq.

Terraform à grande échelle présente trois défis principaux : la gestion de l'état, la réutilisation des modules et la prévention de la dérive. Pour l'état, j'utilise un backend distant avec verrouillage, typiquement S3 et DynamoDB sur AWS, et je sépare l'état par environnement et par frontière de service. J'organise le code Terraform en un dépôt de modules et un dépôt de configurations. Le dépôt de modules contient des modules versionnés et testés qui encodent les standards organisationnels : un module de namespace Kubernetes standard incluant RBAC, politiques réseau et quotas de ressources ; un module de base de données standard qui impose le chiffrement au repos et les sauvegardes automatisées. Les équipes référencent des versions spécifiques de modules dans leurs configurations. J'exécute un plan Terraform automatisé en CI sur chaque pull request. La détection de dérive s'exécute sur un calendrier nocturne et alerte sur toute différence inattendue.

Les problèmes de voisin bruyant dans Kubernetes surviennent quand une charge de travail consomme plus de CPU ou de mémoire que prévu et impacte d'autres charges de travail sur le même nœud. La défense principale est une configuration correcte des requests et limits de ressources, mais les définir avec précision nécessite des données, pas des suppositions. J'utilise une combinaison de VPA (Vertical Pod Autoscaler) en mode recommandation pour collecter des données sur l'utilisation réelle des ressources sur deux semaines avant de définir les requests et limits, et j'impose que chaque déploiement doit avoir des requests et limits définis en utilisant des politiques de contrôle d'admission. J'utilise également des namespaces Kubernetes avec ResourceQuota et LimitRange pour empêcher une seule équipe de consommer plus que sa part allouée de la capacité du cluster. Pour les charges de travail avec des profils de ressources très différents, j'utilise des sélecteurs de nœuds et des taints pour co-localiser des charges similaires sur des pools de nœuds dédiés.

La gestion des secrets à grande échelle doit résoudre trois problèmes : le stockage sécurisé, le contrôle d'accès et la rotation sans interruption de service. Pour le stockage, j'utilise un gestionnaire de secrets dédié, HashiCorp Vault ou AWS Secrets Manager, et j'impose qu'aucun secret n'apparaisse jamais dans les variables d'environnement au niveau Kubernetes ou dans le contrôle de version. Les secrets sont injectés au moment de la création du pod via un pilote CSI ou un webhook d'admission qui tire du gestionnaire de secrets, de sorte que les développeurs n'ont pas besoin de gérer manuellement les secrets dans les manifestes de déploiement. Pour le contrôle d'accès, j'utilise des politiques qui accordent à chaque service l'accès uniquement aux secrets spécifiques dont il a besoin, basées sur l'identité du compte de service Kubernetes. Pour la rotation, je l'automatise en utilisant la fonctionnalité de rotation du gestionnaire de secrets avec des fonctions Lambda.