Site Reliability Engineer. Trois mots qui ne disent rien. Quand quelqu'un vous dit "Je suis SRE", vous hochez poliment la tête en vous demandant ce que ça implique vraiment. Voici la réponse : un SRE garde les applications en vie pendant que tout le monde dort.
Google a inventé le métier au début des années 2000. Le problème était simple : leurs applications grossissaient trop vite. Les administrateurs système traditionnels ne suivaient plus. Google avait besoin d'ingénieurs capables de coder des outils pour automatiser leur propre travail.
La mission principale : la fiabilité
Un SRE veille à ce que les applications tournent sans interruption. Pas de page d'erreur. Pas de temps de réponse interminable. Pas de panne à 3h du matin. Quand vous utilisez Gmail ou Netflix sans problème, un SRE a fait son travail.
Mais la fiabilité ne signifie pas perfection. Un SRE définit un objectif de disponibilité avec l'équipe produit. Par exemple : le service doit être accessible 99,9% du temps. Cela autorise 43 minutes de panne par mois. Au-delà, c'est un problème. En dessous, l'équipe peut prendre plus de risques.
Une journée type de SRE
Contrairement aux idées reçues, un SRE ne passe pas sa journée à éteindre des incendies. La plupart du temps se consacre à prévenir les problèmes avant qu'ils ne surviennent. Voici à quoi ressemble une journée classique.
Vérification des métriques
Consulter les tableaux de bord. Temps de réponse, taux d'erreur, utilisation des ressources. Tout est vert ? Parfait.
Automatisation d'une tâche répétitive
Écrire un script pour déployer les mises à jour automatiquement. Plus besoin de cliquer 50 fois.
Révision de code avec l'équipe dev
Vérifier que le nouveau code ne va pas cramer les serveurs en production. Suggérer des optimisations.
Post-mortem d'incident
Analyser la panne de la semaine dernière. Qu'est-ce qui a foiré ? Comment éviter que ça se reproduise ?
Configuration de nouvelles alertes
Mettre en place des notifications si le temps de réponse dépasse 2 secondes. Mieux vaut être prévenu tôt.
Les outils du quotidien
Un SRE manipule une boîte à outils impressionnante. Ces outils surveillent, automatisent et corrigent. Certains surveillent l'état des serveurs. D'autres détectent les anomalies. D'autres encore déploient automatiquement les correctifs.
Vous n'avez pas besoin de connaître ces noms. Retenez juste qu'un SRE passe autant de temps à configurer ses outils qu'à résoudre des problèmes. Un bon outil réduit le travail manuel de 90%.
Quand les choses tournent mal
Parfois, malgré toutes les précautions, un incident survient. Le site plante. Les utilisateurs voient une page d'erreur. Le téléphone du SRE de garde sonne. C'est là que le métier devient intense.
Le SRE ne panique pas. Il suit un runbook : un guide étape par étape pour diagnostiquer et résoudre l'incident. Première action : rétablir le service. On comprendra plus tard pourquoi ça a planté. L'urgence, c'est que les utilisateurs puissent accéder au site.
Règle d'or en incident : Restaurer d'abord, comprendre ensuite. Les clients n'ont pas besoin d'explications techniques. Ils veulent que ça fonctionne.
Une fois le service rétabli, le travail continue. Le SRE rédige un post-mortem : un document qui explique ce qui s'est passé, pourquoi, et comment éviter que ça se reproduise. Pas de blâme. Juste des faits et des améliorations à apporter.
Le paradoxe du SRE qui réussit
Un bon SRE automatise son propre travail jusqu'à disparaître. Si tout tourne parfaitement, personne ne pense à lui. Les pannes deviennent rares. Les déploiements se font sans accroc. Le site reste accessible même pendant les pics de trafic.
C'est le paradoxe de ce métier : plus vous êtes efficace, moins vous êtes visible. Mais quand les choses vont mal, tout le monde se souvient que vous existez. C'est un métier de l'ombre qui porte toute la lumière quand elle s'éteint.
Développeur ou ops ?
Un SRE se situe entre les deux. Il code comme un développeur mais pense infrastructure comme un ops. Il comprend le code suffisamment pour l'optimiser. Il connaît les systèmes suffisamment pour les faire tenir sous la charge.
Cette position unique fait du SRE un traducteur. Quand les développeurs veulent déployer vite, le SRE explique les risques. Quand les ops veulent tout verrouiller, le SRE montre comment innover sans casser. Il trouve l'équilibre entre vitesse et stabilité.
À retenir : Un SRE maintient les applications en vie en automatisant tout ce qui peut l'être. Il prévient les pannes, répond aux incidents, et s'assure que vous pouvez utiliser vos services préférés sans interruption. Son succès se mesure à son invisibilité.
Questions à poser à un SRE
La prochaine fois que vous croisez un SRE, voici des questions pertinentes : "Quel est votre objectif de disponibilité actuel ?" ou "Combien d'incidents avez-vous eu ce mois-ci ?" ou encore "Quelle partie de votre travail avez-vous automatisée récemment ?"
Ces questions montrent que vous comprenez le métier. Et vous obtiendrez des réponses fascinantes sur ce qui se passe dans les coulisses de vos applications préférées.