Questions d'entretien Senior DevOps / SRE

Ce qui est attendu au niveau Senior

On attend de l'architecture de fiabilité, une stratégie de SLO et un leadership opérationnel à l'échelle de l'organisation.

Exemples de questions d'entretien pour DevOps / SRE

• TechniqueUn service est lent. Décrivez comment vous le déboguez depuis le système d'exploitation vers le haut.
  Ce qu'une bonne réponse couvre

  • Utilisation de top/htop pour identifier les processus gourmands
  • Analyse des métriques CPU, mémoire, I/O disque et réseau
  • Examen des logs applicatifs et des traces de performance
  • Inspection des requêtes lentes en base de données (slow query log)
  • Vérification des limites de ressources système (ulimit, file descriptors)

  Voir un exemple de réponse

  Je commence par vérifier les métriques système avec des outils comme top ou htop pour identifier les processus consommant trop de CPU ou mémoire. Ensuite, j'examine l'utilisation des disques (iostat, vmstat) et du réseau (netstat, ss). Si le problème persiste, je plonge dans les logs applicatifs avec journalctl ou un agrégateur comme ELK. Je recherche aussi les requêtes lentes en base de données via le slow query log. Une cause fréquente est un manque de redimensionnement des pools de connexions. Si nécessaire, je profile le code avec un APM comme Datadog ou Jaeger pour isoler le goulot d'étranglement. Enfin, je vérifie les limites système (ulimit) et la configuration du serveur. L'erreur classique est de se concentrer uniquement sur le code sans d'abord exclure les contraintes d'infrastructure. Un suivi consiste à implémenter des métriques de durée de requête pour anticiper ces lenteurs.

• TechniqueQue se passe-t-il, étape par étape, quand vous tapez une URL et appuyez sur Entrée ?
  Ce qu'une bonne réponse couvre

  • Résolution DNS : cache navigateur, /etc/hosts, requête DNS récursive
  • Établissement de connexion TCP avec le serveur cible (3-way handshake)
  • Négociation TLS si HTTPS (handshake, échange de certificats)
  • Envoi de la requête HTTP (GET/POST) et réception de la réponse
  • Traitement côté serveur (serveur web, app, BDD) puis rendu navigateur

  Voir un exemple de réponse

  D'abord, le navigateur vérifie son cache DNS, puis /etc/hosts, et enfin interroge un résolveur DNS récursif pour obtenir l'adresse IP de l'hôte. Ensuite, il établit une connexion TCP via le triple handshake (SYN, SYN-ACK, ACK). Si l'URL est en HTTPS, une poignée de main TLS a lieu avec échange de certificats et génération de clés de session. La requête HTTP est alors envoyée, typiquement un GET. Le serveur web (Nginx, Apache) traite la requête, potentiellement en la passant à une application (Node, Python) qui interagit avec une base de données. Le serveur renvoie une réponse HTTP (par exemple 200 OK) avec les en-têtes et le contenu (HTML, CSS, JS). Le navigateur parse le HTML, charge les ressources supplémentaires, exécute JavaScript et affiche la page. Une cause de lenteur fréquente est une résolution DNS lente ou un trop grand nombre de requêtes tierces.

• TechniqueEn quoi les sondes liveness et readiness de Kubernetes diffèrent-elles ?
  Ce qu'une bonne réponse couvre

  • Liveness : détecte si le conteneur est bloqué (redémarrage)
  • Readiness : vérifie si le conteneur est prêt à servir le trafic
  • Conséquences : liveness entraîne un redémarrage, readiness retire du service
  • Cas typiques : liveness pour deadlocks, readiness pour dépendances non prêtes
  • Pitfall : utiliser une même sonde pour les deux sans comprendre la différence

  Voir un exemple de réponse

  La sonde liveness indique si le conteneur est sain ; si elle échoue, Kubernetes redémarre le conteneur. Elle sert à corriger les états de blocage (deadlocks, fuites mémoire). La sonde readiness indique si le conteneur est capable de recevoir du trafic ; un échec retire le pod des services, mais ne le redémarre pas. Elle est utile lorsque le conteneur a besoin de temps pour charger des données ou attendre des dépendances. Il est crucial de ne pas confondre les deux : une même vérification (comme un /healthz) peut être utilisée pour les deux, mais les conséquences diffèrent. Un piège courant est de ne configurer que liveness, ce qui peut entraîner des redémarrages intempestifs si le service est simplement temporairement surchargé. Une bonne pratique est de définir des endpoints distincts : /livez pour liveness (simple, sans dépendances) et /readyz pour readiness (incluant les dépendances).

• ProgrammationÉcrivez un script pour analyser des logs et rapporter les taux d'erreur les plus élevés.
  Ce qu'une bonne réponse couvre

  • Utiliser grep/awk pour filtrer les lignes d'erreur et extraire les timestamps
  • Regrouper par fenêtre temporelle (ex: minute) pour calculer le taux
  • Trier et afficher les N fenêtres avec le taux d'erreur le plus élevé
  • Prise en compte des faux positifs (distinguer erreur critique d'avertissement)
  • Complexité O(n log n) pour le tri, O(n) pour le parsing

  Voir un exemple de réponse

  Le script suivant parse un fichier de logs, filtre les lignes d'erreur, regroupe par minute et rapporte les 5 fenêtres avec le plus d'erreurs. Il utilise grep pour filtrer les erreurs, extrait le timestamp avec une expression régulière, puis sort et uniq pour compter. La complexité temporelle est O(n log n) due au tri final, et spatiale O(n) pour stocker les compteurs. Ce script suppose que les erreurs sont marquées "ERROR" et que le format du timestamp est ISO. Il est simple mais peut être étendu pour gérer des formats variés ou des fenêtres glissantes. Une alternative serait d'utiliser awk pour une solution plus rapide et personnalisable.

  #!/bin/bash
  # Script d'analyse de logs – trouve les minutes avec le plus d'erreurs
  # Utilisation : ./analyse_logs.sh <fichier.log>
  
  LOGFILE="$1"
  if [ -z "$LOGFILE" ]; then
    echo "Usage: $0 <logfile>"
    exit 1
  fi
  
  # Supposons un format : "2025-04-09 10:15:30 ERROR: something"
  # 1. Filtrer les lignes contenant "ERROR" (ajuster selon besoin)
  # 2. Extraire la minute (format YYYY-MM-DD HH:MM)
  # 3. Compter par minute
  # 4. Trier numériquement et afficher les 5 premières
  
  grep "ERROR" "$LOGFILE" \
    | grep -o '^[0-9]\{4\}-[0-9]\{2\}-[0-9]\{2\} [0-9]\{2\}:[0-9]\{2\}' \
    | sort \
    | uniq -c \
    | sort -rn \
    | head -5
  
  # Complexité : O(n log n) pour le tri final (car sort utilise merge sort)
  # Le grep et uniq sont O(n) dans la pratique.

• Conception de systèmesConcevez un pipeline CI/CD avec des déploiements en production sûrs et progressifs.
  Ce qu'une bonne réponse couvre

  • Intégration continue : builds, tests unitaires, linting sur chaque commit
  • Déploiement progressif : canary, blue/green, feature flags
  • Étapes : build → tests → staging → déploiement progressif → full prod
  • Sécurité : gate manuel, rollback automatique, monitoring des métriques
  • Outils : GitHub Actions, Jenkins, ArgoCD, Spinnaker, Helm

  Voir un exemple de réponse

  Le pipeline CI/CD commence par la détection d'un commit sur la branche principale. Une phase de build compile le code et exécute les tests unitaires, l'analyse statique (linting, SAST) et la construction d'une image Docker. L'image est poussée dans un registre. Ensuite, un déploiement en staging automatique permet des tests d'intégration et de non-régression. Pour la production, on utilise une stratégie de déploiement progressif comme canary : un petit pourcentage de trafic est dirigé vers la nouvelle version, avec des métriques (latence, taux d'erreur) surveillées en temps réel. Si les métriques sont saines, on augmente le trafic progressivement. En cas d'anomalie, un rollback automatique est déclenché. Un gate manuel peut être ajouté avant le déploiement complet. Des outils comme ArgoCD (GitOps) ou Spinnaker gèrent ces workflows. Une bonne pratique est d'utiliser des feature flags pour désactiver rapidement des fonctionnalités problématiques sans redéploiement.

• Conception de systèmesConcevez la supervision et les alertes d'un service multirégion.
  Ce qu'une bonne réponse couvre

  • Métriques clés : latence (p50, p99), taux d'erreur, débit, saturation
  • Architecture : agents locaux → agrégateur régional (Prometheus) → global (Thanos)
  • Alerting : règles par région + globales (ex: latence > 200ms sur 2 régions)
  • SLO/SLI : définir des objectifs de service (ex: 99.9% uptime)
  • Pitfall : éviter les alertes redondantes dans chaque région ; utiliser un système centralisé avec dé-duplication

  Voir un exemple de réponse

  La supervision multirégion doit collecter des métriques de chaque région via des agents locaux (Prometheus en mode federation avec Thanos). Les métriques essentielles sont la latence (p50, p99), le taux d'erreur (par statut HTTP), le débit (RPS) et la saturation (CPU, mémoire). On définit des SLO, par exemple 99.9% des requêtes répondent en moins de 200 ms. Les alertes sont configurées à deux niveaux : local (une région) et global (impact sur plusieurs régions). Par exemple, une alerte locale si la latence p99 dépasse 500 ms dans une région, et une alerte globale si plus de deux régions sont affectées. On utilise un outil comme Alertmanager avec dé-duplication et silences. Un dashboard centralisé (Grafana avec sources multiples) permet de visualiser l'état global. Un piège courant est de dupliquer les alertes pour chaque région : il faut un système d'agrégation. Le monitoring des dépendances (CDN, DNS) est aussi critique.

• ComportementalDécrivez-moi un incident que vous avez piloté et les actions du post-mortem.
  Ce qu'une bonne réponse couvre

  • Exemple concret : incident de base de données surchargée
  • Détection : augmentation de latence, alertes PagerDuty
  • Actions : mise à l'échelle verticale, mise en cache, kill de requêtes lentes
  • Post-mortem : analyse des causes racines, actions correctives (index, read replicas)
  • Leçon : importance des runbooks et des tests de charge réguliers

  Voir un exemple de réponse

  Récemment, j'ai piloté un incident où notre service principal est devenu lent à cause d'une requête SQL non optimisée sur une base PostgreSQL. La détection est venue d'une alerte PagerDuty sur la latence p99 dépassant 1 seconde. J'ai immédiatement escaladé en augmentant les ressources CPU de la base (vertical scaling) pour gagner du temps, puis j'ai identifié la requête lente via le slow query log. J'ai tué la requête et ajouté un cache Redis pour les données fréquemment accédées. Une fois le service rétabli, nous avons réalisé un post-mortem : la cause racine était l'absence d'index sur une colonne de jointure. Nous avons mis en place une action corrective pour créer l'index et ajouté des tests de régression dans la CI. De plus, nous avons amélioré les runbooks d'incident en ajoutant un checklist d'optimisation des requêtes. Une leçon clé est l'importance des tests de charge mensuels pour détecter ces régressions avant qu'elles n'atteignent la production.

• ComportementalComment équilibrez-vous le travail de fiabilité face aux demandes de fonctionnalités ?
  Ce qu'une bonne réponse couvre

  • Quantifier l'impact de la fiabilité : définir SLO et budget d'erreur
  • Priorisation basée sur le coût de l'absence de fiabilité vs valeur de la feature
  • Utilisation du time-boxing : allouer un pourcentage du sprint à la dette technique
  • Communication avec l'équipe produit sur les risques et compromis
  • Exemple : adoption de l'approche 'fiabilité d'abord' pour les systèmes critiques

  Voir un exemple de réponse

  Je gère cet équilibre en m'appuyant sur des SLO clairs et un budget d'erreur. Si le budget d'erreur n'est pas épuisé, l'équipe produit peut prioriser de nouvelles fonctionnalités. Sinon, nous nous concentrons sur la fiabilité (amélioration des performances, réduction des dettes techniques). Je propose de réserver un temps fixe dans chaque sprint (par exemple 20%) pour des tâches de fiabilité. Je communique régulièrement avec le product manager pour expliquer l'impact des problèmes de fiabilité sur l'expérience utilisateur et les revenus. Par exemple, une latence élevée peut faire perdre des clients. J'utilise aussi des indicateurs comme le 'coût des indisponibilités' pour justifier les investissements. Un incident récent a montré qu'ignorer la fiabilité entraîne plus de corrections urgentes, ce qui ralentit les fonctionnalités à long terme. L'idée est d'intégrer la fiabilité comme une feature à part entière, avec des critères d'acceptation.

Ce que les recruteurs évaluent

Comment se préparer

• Déboguez à partir des premiers principes — les recruteurs veulent une approche systématique et par couches.
• Cadrez vos réponses autour des SLO, des budgets d'erreur et des post-mortems sans blâme.
• Automatisez tout dans vos réponses ; les étapes manuelles se lisent comme des signaux d'alerte.

Questions fréquentes