Questions d'entretien Ingénieur DevOps

Je commence par comprendre ce dont l'équipe a besoin pour livrer de façon sûre et rapide, pas par choisir des outils. Je cartographie les étapes que le code doit franchir : build, test, scan de sécurité, packaging, déploiement en staging, puis promotion en production. J'automatise chaque étape et définis des critères de promotion clairs pour qu'aucune étape ne progresse sans satisfaire les seuils de qualité. Pour un projet typique, j'utiliserais GitHub Actions ou GitLab CI pour le pipeline, avec des builds conteneurisés pour garantir la cohérence des environnements. J'inclus les tests unitaires et d'intégration automatisés tôt dans le pipeline pour que les échecs remontent rapidement et à faible coût. J'intègre aussi les scans de sécurité au niveau de l'image et des dépendances plutôt que de les traiter comme une préoccupation post-déploiement. L'objectif est que chaque commit sur la branche principale soit déployable. Je traite le pipeline comme du code et le versionne avec l'application.

Je traite l'infrastructure as code comme un principe fondamental, pas comme une optimisation. Si l'infrastructure n'est pas dans un contrôle de version, elle ne peut pas être revue, testée ni reproduite de façon fiable. Mon outil préféré pour l'infrastructure cloud-agnostique est Terraform, pour sa syntaxe déclarative, son écosystème de providers et sa communauté solide. Pour la gestion de configuration j'utilise Ansible quand je dois gérer l'état de machines existantes, et pour Kubernetes j'utilise Helm pour le packaging et ArgoCD pour la livraison GitOps. J'organise Terraform en modules par domaine pour garder les choses composables et réutilisables entre environnements. J'impose aussi un workflow plan avant apply en CI pour que les changements d'infrastructure soient revus comme des changements de code.

Je pense à l'observabilité selon les trois piliers : métriques, logs et traces. Les métriques vous disent qu'il y a un problème, les logs vous disent ce qui s'est passé, et les traces vous disent où dans un système distribué le problème a pris naissance. Mon approche standard consiste à instrumenter les applications avec des logs structurés dès le début, à exporter les métriques vers une base de données de séries temporelles comme Prometheus, et à utiliser le tracing distribué avec OpenTelemetry pour comprendre les flux de requêtes. Je construis des tableaux de bord autour des quatre signaux dorés : latence, trafic, erreurs et saturation. Je configure aussi des alertes sur les symptômes qui comptent pour les utilisateurs plutôt que sur des seuils de ressources bas niveau. Le test que j'applique à chaque alerte : si elle se déclenche à 3h du matin, vaut-il la peine de réveiller quelqu'un ?

Nous avons eu une saturation du pool de connexions à la base de données qui a mis hors service notre service principal pendant 35 minutes un après-midi de semaine. J'étais d'astreinte et ai pris la direction de l'incident. Ma première étape a été de déclarer l'incident formellement, d'ouvrir un canal de communication dédié, et d'alerter les ingénieurs concernés sans noyer le canal. J'ai séparé les communications internes et externes et ai donné à notre responsable technique une mise à jour factuelle courte toutes les 10 minutes. La mitigation immédiate a été un redémarrage et une augmentation de la limite du pool, qui a restauré le service en 12 minutes. La cause racine était un job en arrière-plan récent avec une libération de connexion manquante en cas d'erreur. Le changement de processus a consisté à ajouter une métrique du pool de connexions à notre tableau de bord principal et un test de circuit breaker à nos tests de charge pré-production.

Quand j'ai rejoint mon équipe précédente, les déploiements en production avaient lieu une fois par semaine le vendredi après-midi et nécessitaient un runbook manuel de 30 minutes exécuté par deux ingénieurs. J'ai construit un pipeline entièrement automatisé incluant des tests de fumée automatisés, un déploiement blue-green sur notre cluster Kubernetes et un rollback automatique si les tests échouaient. En deux mois, nous déployions plusieurs fois par jour sans étape manuelle, avec un temps moyen de récupération d'un mauvais déploiement inférieur à quatre minutes. La fréquence de déploiement est l'une des métriques DORA, et son amélioration a directement corrélé avec une réduction du taux d'échec des changements.

Quand j'ai rejoint une startup sans processus d'astreinte, j'ai introduit une rotation d'astreinte légère et un modèle simple de réponse aux incidents. J'ai animé un post-mortem sans reproches après le premier incident significatif et ai explicitement reconnu l'ingénieur qui avait signalé honnêtement un défaut de conception. Sur le trimestre suivant, j'ai animé trois sessions d'apprentissage interne sur les principes SRE et publié une checklist de préparation opérationnelle pour les nouveaux services. En fin d'année, chaque équipe avait une rotation d'astreinte, les temps de réponse aux incidents s'étaient améliorés, et les ingénieurs organisaient spontanément des post-mortems sur des presque-incidents.

Je ne stocke jamais les secrets dans des variables d'environnement codées en dur dans les manifestes de déploiement ou le code source, et je ne les committe jamais dans un contrôle de version. Mon approche préférée dans un environnement Kubernetes est d'utiliser un outil de gestion des secrets comme HashiCorp Vault ou AWS Secrets Manager, avec l'application qui récupère les secrets au moment de l'exécution via un sidecar ou un init container. Je fais tourner les secrets régulièrement et automatise la rotation quand le fournisseur le permet. Pour les pipelines CI/CD j'utilise la gestion des secrets intégrée à la plateforme. Je suis aussi le principe du moindre privilège pour tous les comptes de service : chaque service ne doit pouvoir lire que les secrets dont il a besoin.

La sécurité des conteneurs commence au niveau de l'image. J'utilise des images de base minimales, je scanne les images en CI pour les vulnérabilités connues avec un outil comme Trivy ou Snyk, et j'applique une politique qui bloque les déploiements d'images au-dessus d'un seuil de gravité. Dans Kubernetes j'applique des politiques réseau pour restreindre le trafic entre pods, j'utilise RBAC pour limiter ce que les comptes de service peuvent faire, et je fais tourner les pods en utilisateur non-root avec des systèmes de fichiers racine en lecture seule quand c'est possible. J'utilise des admission controllers pour appliquer les politiques au niveau du cluster. Pour les secrets j'utilise un magasin de secrets dédié plutôt que les Secrets Kubernetes, qui ne sont qu'en base64 sans chiffrement à moins de configurer le chiffrement au repos.

Je commence par la visibilité : on ne peut pas optimiser ce qu'on ne voit pas. Je mets en place des tableaux de bord de coûts qui décomposent les dépenses par équipe, service et environnement pour que les personnes prenant des décisions architecturales voient les implications en temps réel. Pour le dimensionnement, je regarde l'utilisation réelle des ressources sur une fenêtre de 30 jours avant de faire des changements. J'utilise l'autoscaling horizontal pour les charges de travail sans état, et des réservations ou des engagements d'utilisation pour la charge de base prévisible. Je programme aussi l'arrêt des environnements hors production en dehors des heures de travail. Pour le stockage, j'applique des politiques de cycle de vie pour déplacer automatiquement les données peu consultées vers des niveaux moins coûteux.