Ingénieur DevOps Questions d'entretien & Réponses

Exemple de réponse

Notre cluster de base de données principal a basculé en heures de pointe suite à un problème d'espace disque que notre supervision n'avait pas détecté. Le basculement lui-même a fonctionné, mais le réplica avait 30 secondes de retard, ce qui a provoqué des incohérences de données visibles par les utilisateurs. J'ai piloté la gestion de l'incident : problème isolé en 10 minutes, coordination avec l'équipe d'ingénierie pour identifier les utilisateurs affectés en 20 minutes, communication envoyée aux clients en 45 minutes. La durée d'interruption totale a été de 8 minutes. Lors du post-mortem, j'ai mis en place trois changements : ajout de la supervision de l'espace disque avec des alertes à 80 % de seuil, création d'un runbook pour les scénarios de basculement de base de données, et mise en place de tests hebdomadaires de chaos engineering pour nos mécanismes de basculement. Nous sommes également passés à la réplication synchrone pour les tables critiques. Sur les 12 mois suivants, nous n'avons eu aucun basculement de base de données non planifié.

Exemple de réponse

L'équipe de développement déployait manuellement via SSH et résistait aux déploiements automatisés parce qu'elle avait besoin de 'contrôle'. Au lieu d'imposer le changement, je suis parti de leurs problèmes concrets. J'ai mesuré que les déploiements manuels prenaient en moyenne 45 minutes, avec un taux d'échec de 15 %, et se produisaient systématiquement le vendredi à 17 h. J'ai construit un pipeline CI/CD qui reproduisait exactement leurs étapes manuelles, je l'ai fait tourner en parallèle pendant 2 semaines, et j'ai montré que les déploiements automatisés prenaient 3 minutes avec un taux d'échec de 1 %. J'ai laissé le développeur le plus sceptique effectuer le premier déploiement automatisé en production. Quand tout s'est déroulé sans accroc, il est devenu le plus grand défenseur du pipeline. En l'espace d'un mois, l'équipe déployait 3 fois par jour au lieu d'une fois par semaine. La clé : rendre le changement sûr, pas l'imposer.

Exemple de réponse

J'ai audité nos dépenses AWS et constaté que nous payions 28 000 $ par mois pour des ressources qui tournaient 24 h/24 mais n'étaient nécessaires que pendant les heures de bureau (environnements de développement, clusters de staging, traitement batch). J'ai mis en place un système de planification automatisé utilisant AWS Lambda et CloudWatch Events pour ramener les environnements hors production à zéro la nuit et le week-end. J'ai également redimensionné les instances de production en utilisant 3 mois de métriques CloudWatch : nous faisions tourner des instances m5.2xlarge qui ne dépassaient jamais 30 % de CPU. Le passage aux m5.large avec autoscaling a permis d'économiser 8 000 $ supplémentaires par mois. J'ai migré les données S3 peu consultées vers Glacier, économisant 3 000 $ par mois. Économies totales : 18 000 $ par mois (216 000 $ par an) sans impact sur les performances. J'ai mis en place un tableau de bord mensuel de revue des coûts, qui est devenu une pratique standard.

Exemple de réponse

Les développeurs passaient en moyenne 90 minutes à configurer leur environnement de développement local, et la dérive de configuration provoquait des bugs 'ça marche sur ma machine' chaque semaine. J'ai conteneurisé toute la stack de développement avec Docker Compose : base de données, file de messages, cache et tous les microservices. J'ai écrit une seule commande 'make dev' qui tirait les dernières images, initialisait la base de données et démarrait tous les services. Le temps de configuration est passé de 90 minutes à 5 minutes. J'ai aussi mis en place un système de hooks pre-commit qui exécutait le linting, la vérification des types et les tests unitaires en local, interceptant 80 % des échecs CI avant le push. Les scores de satisfaction des développeurs pour 'outillage et infrastructure' sont passés de 2,8 à 4,3 sur 5. L'insight clé : la productivité des développeurs est un problème d'infrastructure.

Exemple de réponse

Les VMs virtualisent le matériel : chaque VM exécute son propre noyau OS, géré par un hyperviseur. Les conteneurs virtualisent l'OS : ils partagent le noyau hôte et s'isolent au niveau des processus via les namespaces et les cgroups. Les conteneurs sont plus légers (Mo contre Go), démarrent plus vite (secondes contre minutes) et se déploient plus densément sur un hôte. Je choisis les conteneurs pour les microservices, les applications sans état et tout ce qui nécessite une mise à l'échelle rapide. Je choisis les VMs quand j'ai besoin d'une isolation complète de l'OS (environnements multi-locataires avec des exigences strictes de sécurité), que je dois faire tourner différents systèmes d'exploitation sur le même hôte, ou que j'exécute des logiciels nécessitant des modifications du noyau. En pratique, la plupart des charges de travail modernes sont conteneurisées. Mais les applications legacy, certaines exigences de conformité (environnements PCI-DSS imposant une isolation au niveau VM) et les charges de travail Windows peuvent encore être mieux adaptées aux VMs.

Exemple de réponse

Je le construirais en couches. La boucle interne (par service) : chaque microservice possède son propre pipeline déclenché par les commits dans son répertoire. Il exécute le linting, les tests unitaires, construit une image de conteneur avec un tag adressable par contenu (SHA git), la pousse vers un registre et déploie dans un environnement de développement. La couche d'intégration : après qu'un service a passé ses propres tests, les tests d'intégration s'exécutent sur un environnement de staging partagé avec tous les services. J'utiliserais les tests de contrat (Pact) pour détecter les problèmes de compatibilité entre services sans avoir besoin de tous les services en cours d'exécution. La couche de déploiement : j'utiliserais GitOps avec ArgoCD. La fusion dans la branche de déploiement met à jour un dépôt de manifests, et ArgoCD synchronise l'état du cluster. Les rollbacks sont un simple git revert. Pour la sécurité : déploiements canary avec rollback automatisé basé sur des seuils de taux d'erreur, fenêtres de déploiement avec blocages automatiques pendant les périodes de fort trafic, et une validation manuelle pour la production lors des premiers mois jusqu'à ce que la confiance soit établie.

Exemple de réponse

L'infrastructure as code consiste à définir votre infrastructure (serveurs, réseaux, bases de données, load balancers) dans des fichiers de configuration déclaratifs plutôt qu'en cliquant dans des consoles ou en exécutant des scripts ad hoc. Des outils comme Terraform, CloudFormation et Pulumi rendent cela possible. C'est important pour trois raisons. Premièrement, la reproductibilité : je peux déployer un environnement identique dans n'importe quelle région en exécutant le même code. Fini le 'on pense que le staging correspond à la production'. Deuxièmement, le contrôle de version : les changements d'infrastructure passent par le même processus de révision de code, d'approbation et de traçabilité que le code applicatif. Je peux voir qui a changé quoi, quand et pourquoi, et revenir en arrière si nécessaire. Troisièmement, l'automatisation : les changements d'infrastructure peuvent être testés, validés et appliqués par des pipelines CI/CD, éliminant les erreurs manuelles. En pratique, j'utilise Terraform avec l'état distant dans S3, le verrouillage d'état avec DynamoDB, et des modules pour les composants réutilisables. Chaque changement d'infrastructure passe par une pull request avec un résultat de 'terraform plan' pour révision.

Exemple de réponse

Je suis les trois piliers : métriques, logs et traces. Les métriques (Prometheus + Grafana) me donnent l'état global du système : CPU, mémoire, taux de requêtes, taux d'erreur, percentiles de latence. Je configure des alertes sur les symptômes (taux d'erreur élevé, latence accrue) plutôt que sur les causes (CPU élevé), parce que les symptômes indiquent que les utilisateurs sont affectés. Les logs (ELK ou Loki) fournissent un contexte d'événements détaillé pour le débogage. J'impose le logging structuré (JSON) avec des identifiants de corrélation afin de pouvoir tracer une requête entre les services. Les traces (Jaeger ou Tempo) me montrent le chemin complet d'une requête dans le système, révélant quel service est lent et pourquoi. Au-delà des trois piliers, je construis des tableaux de bord métier : commandes par minute, inscriptions par heure, taux de succès des paiements. Ce sont les premiers éléments que je vérifie lors d'un incident, car ils répondent à la question 'les utilisateurs sont-ils affectés ?' avant de plonger dans les métriques d'infrastructure. Je mets également en place des SLOs avec des budgets d'erreur, ce qui transforme la supervision du 'est-ce que quelque chose est cassé ?' en 'respectons-nous nos engagements de fiabilité ?'

Exemple de réponse

À court terme : j'activerais le Kubernetes Cluster Autoscaler pour ajouter des nœuds automatiquement quand les pods ne peuvent pas être programmés. Je vérifierais que notre pool de nœuds a de la marge pour évoluer et que les politiques de mise à l'échelle de l'autoscaler sont sensées (montée en charge rapide, descente lente). Je vérifierais aussi si les ressources existantes sont sur-allouées : il est courant que les pods demandent 2 fois les ressources qu'ils utilisent réellement. Le redimensionnement des demandes de ressources selon l'utilisation réelle pourrait libérer 30 à 40 % de capacité sans ajouter de nœuds. À moyen terme : j'implémenterais le Horizontal Pod Autoscaler (HPA) sur toutes les charges de travail avec des cibles CPU/mémoire appropriées, et j'envisagerais le Vertical Pod Autoscaler (VPA) pour les charges de travail aux patterns de ressources imprévisibles. Je déplacerais aussi les charges de travail batch vers des instances spot/préemptibles. À long terme : j'analyserais les patterns de trafic et implémenterais une mise à l'échelle prédictive. Si on sait que les heures de pointe sont de 9 h à 11 h, il vaut mieux pré-évoluer 15 minutes avant plutôt que de réagir à la demande. J'évaluerais aussi si certaines charges de travail devraient passer en serverless (Lambda/Cloud Run) pour supprimer entièrement la contrainte de planification de capacité.

Exemple de réponse

D'abord, je résoudrais le problème immédiat : annuler la modification de configuration et rétablir le service. Ensuite, je mènerais un post-mortem sans reproche. L'objectif est le système qui a permis cela, pas la personne qui a fait le changement. Mes mesures préventives : premièrement, tous les changements de configuration passent par le même pipeline CI/CD que le code (pull request, révision, validation automatisée, déploiement progressif). Pas de push direct vers la config de production. Deuxièmement, mettre en place une validation de configuration dans le pipeline : vérification du schéma, application en mode dry-run et tests d'intégration sur un environnement de staging. Troisièmement, déploiement progressif pour les changements de config : appliquer à 5 % des instances, surveiller les taux d'erreur pendant 10 minutes, puis passer à 25 %, 50 %, 100 %. Quatrièmement, déclencheurs de rollback automatisé : si le taux d'erreur dépasse la référence d'un facteur 2 dans les 5 minutes suivant un changement de config, annuler automatiquement. L'objectif est de rendre le chemin sûr le chemin facile : il devrait être plus difficile de pousser la config directement que de passer par le pipeline.

Exemple de réponse

Je ne ferais jamais une réécriture totale d'un coup. C'est un modèle d'échec constant. J'utiliserais plutôt le pattern strangler fig : extraire les services de façon incrémentale pendant que le monolithe continue de servir le trafic. Étape 1 : identifier les frontières de service avec le design piloté par le domaine. Cartographier les domaines du monolithe, la propriété des données et les dépendances. Commencer par le service le moins couplé et à plus haute valeur. Étape 2 : construire le nouveau service en parallèle du monolithe, en routant le trafic vers lui via une API gateway. Le monolithe et le nouveau service partagent initialement la base de données. Étape 3 : une fois le service stable, migrer ses données vers sa propre base de données et supprimer la dépendance à la base partagée. Étape 4 : répéter pour le service suivant. Je m'attendrais à ce que la migration complète prenne 12 à 18 mois pour un monolithe de taille moyenne. Principes clés : chaque service extrait doit être déployable et testable indépendamment, le système doit fonctionner dans l'état hybride (certains services extraits, d'autres encore dans le monolithe), et j'ajouterais une supervision complète à la frontière entre ancien et nouveau pour détecter les problèmes d'intégration tôt.

Exemple de réponse

J'évaluerais sur la base de quatre facteurs plutôt que par préférence personnelle. Premièrement, l'expertise existante : que maîtrise déjà l'équipe ? Les courbes d'apprentissage cloud sont abruptes, et le coût de productivité d'un changement est réel. Si l'équipe a 3 ans d'expérience AWS, la nouvelle plateforme doit offrir un avantage convaincant pour justifier le temps de montée en compétence. Deuxièmement, les exigences de services spécifiques : le projet nécessite-t-il un service qu'un cloud gère nettement mieux ? GCP pour le ML (Vertex AI), Azure pour l'intégration entreprise (Active Directory), AWS pour le catalogue de services le plus large. Troisièmement, le modèle de tarification : j'estimerais les coûts en utilisant le calculateur de chaque cloud pour notre pattern de charge de travail spécifique. Les instances réservées, les prix spot et les coûts d'egress varient considérablement. Quatrièmement, le contexte organisationnel : accords fournisseur, exigences de conformité et infrastructure existante. Si l'entreprise dispose déjà d'un AWS Enterprise Agreement, utiliser GCP ajoute de la complexité d'approvisionnement. Je présenterais une recommandation avec une matrice de décision claire, pas juste mon intuition.