Est-ce que vous avez déjà regardé une course de Formule 1 ?
Après tout, même si vous n’êtes pas un fan de Grands Prix, vous avez probablement vu des images de circuits à la télévision. Vous savez alors que le pilote s’arrête régulièrement à un stand, qui s’appelle le paddock.
Et vous avez sûrement remarqué ces dizaines de personnes qui s’agitent autour du véhicule et du pilote, pour le faire repartir en moins de deux secondes dans les meilleures conditions et viser la victoire.
Et bien, le pilote, c’est le développeur.
La voiture c’est l’infrastructure.
Et les dizaines d’ingénieurs qui travaillent dans l’ombre sur le paddock, ce sont les Ops.
Sans eux, impossible de gagner la course.
Vous aviez déjà fait le lien entre l’infrastructure et la F1 ?
Vous voyez l’image.
Maintenant, si l’on regarde dans le détail, quel est vraiment le rôle de chacun ?
Le développeur est en charge de la conception technique d’un site web, d’un logiciel ou d’une application. Il travaille à partir d’un cahier des charges, qui détaille les différentes fonctionnalités qu’il doit progressivement ajouter à son application, en fonction des besoins des utilisateurs.
Le rôle de l’Ops (ou historiquement “Administrateur système” ou “Administrateur réseau”) est d’assurer la stabilité du système informatique. Quels que soient le nombre d’applications présentes dans le système d’information et les nouvelles fonctionnalités ajoutées progressivement, l’objectif de l’Ops est qu’elles restent disponibles, fiables et sécurisées.
Traditionnellement, les métiers de Dev et d’Ops visent des objectifs plutôt contradictoires : l’un souhaite délivrer de nouvelles fonctionnalités en permanence pour faire évoluer l’application alors que l’autre recherche de la stabilité et de la robustesse.
Aujourd’hui, de plus en plus d’entreprises adoptent la culture DevOps, qui vise à faire travailler les équipes Dev et Ops ensemble. Elles ont alors un objectif commun : la production de valeur business grâce au déploiement continu de nouvelles fonctionnalités, sans pour autant altérer la qualité.
Finalement, si on compare le système informatique à un navire, on pourrait considérer que le développeur se situe sur le pont du bateau : il sait naviguer et voit où il va. Passer du dev à l’ops, c’est faire la démarche de descendre dans la cale, et de comprendre comment ça fonctionne pour que le bateau ne prenne pas l’eau.
Et le SRE dans tout ça ?
Le terme SRE, ou Site Reliability Engineering, a été introduit par Google en 2003. Il fait référence à une discipline permettant d’adopter la culture DevOps.
Le Site Reliability Engineer se distingue notamment de l’Ops traditionnel par les trois rôles qu’il remplit au quotidien :
Le rôle du SRE est alors davantage connecté au business et à l’utilisateur. Par exemple, le SRE accepte l’erreur et sait que son application ne pourra pas être fiable à 100%. Il doit alors réfléchir au parcours critique de son client final, afin de définir l’error budget le plus adapté.
Les avantages à passer côté infrastructure lorsqu’on vient du monde du développement sont nombreux : envie de découvrir la big picture, de travailler sur des technologies différentes, d’adresser des challenges complexes...
Nous en avons retenu deux qui font particulièrement sens pour nous, chez Padok.
On pense souvent à tort que le fait de travailler sur l’infrastructure éloigne l’Ops des problématiques business. Pourtant, l’impact de l’infrastructure sur l’utilisateur final est colossal.
En 2020, en pleine crise du Covid-19, le gouvernement français lance le Prêt Garanti par l’Etat, une aide financière de 300 milliards d’euros pour soutenir les entreprises. L’application web enregistrant les demandes de prêt doit soutenir 500 000 requêtes par heure, avec des pics de trafic de 50 000 requêtes en 1 minute. Sans une infrastructure sécurisée et de qualité, des millions d’entrepreneurs n'auraient pas eu accès à leur enveloppe de prêt.
La disponibilité de l’infrastructure joue aussi sensiblement sur l’expérience client proposée par une marque. Un site indisponible, trop lent, qui bug au moment du paiement, génère autant de stress que d'insatisfaction et peut souvent compromettre l’acte d’achat.
Finalement, le trio Ops - Dev - Business doit être envisagé non pas de façon linéaire, mais plutôt triangulaire :
L’impact sur le business de l’Ops est plus fort qu’on ne le croit.
Lorsqu’on est développeur, on travaille généralement avec deux types d’interlocuteurs : le sponsor du projet et le client final qui est l’utilisateur.
Lorsqu’on est SRE, on conserve ces deux interlocuteurs, mais surtout, on collabore avec un troisième type d’acteur : le développeur. Ce dernier est en réalité le premier client du SRE, car c’est lui qui utilise l’infrastructure. Les interactions sont constantes et les échanges sont particulièrement riches, car on parle le même langage !
D’ailleurs, avoir une expérience en développement avant de devenir SRE peut s’avérer très utile ! D’une part, ça permet d’avoir un réflexe business : comme le développeur, le SRE doit toujours se poser la question de ce qui est le meilleur pour l’utilisateur final, et de ce qui va apporter le plus de valeur.
D’autre part, les bonnes pratiques de développement s’appliquent aussi côté infrastructure : faire relire son code, partager ce qui a été réalisé, se concentrer sur la qualité...
Vous êtes convaincus ? Ok, maintenant comment passer de l’autre côté de la barrière et se lancer en tant que SRE ?
Pour apprendre une nouvelle discipline, il n’y a pas de secret, il faut d’abord passer par la théorie !
Voici quelques ouvrages qui pourront vous être utiles :
La clé pour monter en compétences sur un sujet précis, c’est de s’entourer de personnes meilleures que soi et de ne pas hésiter à les solliciter. Il faut alors toujours le faire avec beaucoup d’humilité et de curiosité. C’est du temps investi certes pour la personne qui se forme, mais aussi pour son mentor qui accepte de partager son savoir et son expérience.
Si vous ne savez pas à qui vous adresser, sachez qu’il existe différents groupes Meetups très actifs sur le sujet du DevOps et du SRE. Allez aussi faire un tour sur Twitter ou rejoignez une communauté Slack :
Groupes Meetup :
Comptes Twitter :
Communautés Slack :
La théorie, c’est essentiel, mais il faut aussi de la pratique pour progresser. A un moment donné, il faut nécessairement se confronter au terrain. D’ailleurs, c’est toujours en faisant des erreurs qu’on apprend le plus !
Le meilleur réflexe, c’est d’aller à la rencontre des équipes Ops ou SRE de son entreprise. Et s’il n’y en n’a pas, discutez-en avec votre tech Lead ou votre CTO.
Enfin, la meilleure manière de passer côté SRE lorsqu’on est développeur, c’est tout simplement de candidater à des offres d’emploi.
On l’a dit, le SRE, c’est davantage un état d’esprit à adopter plutôt qu’une série de compétences à maîtriser. D’après Google, tout ingénieur capable de développer un système peut prétendre au poste de SRE.
“Great SREs aren’t hired, they’re actually trained.”
Jennifer Ptoff, Head of SRE Education chez Google.
Beaucoup d’entreprises sont d’ailleurs prêtes à recruter des Développeur Backend motivés pour les former au rôle de SRE.
Finalement, le rôle de SRE est une évolution tout à fait pertinente pour un développeur backend ou full stack, qui s’intéresse aux problématiques systèmes. Il réserve son lot de challenges techniques et d’interactions avec des équipes tech, tout en ayant un impact fort sur le business.
Pour se lancer, pas de secret : il faut passer par la case formation et s’entourer des bonnes personnes qui vous aideront à progresser. Si déjà, vous êtes dans cet état d’esprit, il est probable que vous trouviez un employeur qui accepte de vous accompagner dans votre montée en compétences.
Alors, qu’est-ce que vous attendez pour postuler ?