Description

Êtes-vous prêt à plonger dans l'univers fascinant des systèmes informatiques fiables ? Dans cet épisode captivant du podcast SRE, Nicolas vous dévoile le rôle central du site-reliability-engineer, un poste clé qui assure la pérennité et la performance des services numériques. Créé par Google en 2003, le concept de SRE a émergé à une époque où la fiabilité des systèmes était plus que jamais cruciale pour accompagner l'expansion fulgurante de leurs services. Mais qu'est-ce qu'un SRE exactement ?

Nicolas nous guide à travers les multiples facettes de cette profession, décrivant un ingénieur qui allie compétences en codage et compréhension approfondie des systèmes en production. Un site-reliability-engineer ne se contente pas de réagir aux pannes ; il analyse les performances, anticipe les problèmes et met en place des solutions durables. Dans cet épisode, vous découvrirez les responsabilités d'un SRE avant, pendant et après la mise en production d'un système, et pourquoi la fiabilité et l'observabilité sont des éléments essentiels du succès.

Au fil de la discussion, Nicolas met en lumière l'importance d'une culture de post-mortem, où l'analyse des incidents se fait sans recherche de coupables, mais plutôt dans un esprit d'amélioration continue. Cette approche permet aux équipes de tirer des leçons précieuses des échecs passés et d'optimiser leurs processus pour l'avenir. En intégrant les principes de l'adminsys et du devops, le SRE devient le pilier d'une infrastructure résiliente et performante.

Que vous soyez déjà familier avec le monde des SRE ou que vous souhaitiez en savoir plus, cet épisode vous apportera des insights inestimables et vous préparera à aborder les défis de la fiabilité des systèmes informatiques. Alors, n'attendez plus et rejoignez-nous pour explorer ce rôle fascinant qui façonne l'avenir des technologies numériques.

Et ce n'est pas tout ! Restez à l'écoute pour notre prochain épisode, où nous aborderons les bonnes pratiques des SRE, en vous offrant des conseils pratiques et des stratégies éprouvées pour exceller dans ce domaine en constante évolution. Ne manquez pas cette opportunité d'enrichir vos connaissances et de devenir un acteur clé dans le monde des systèmes fiables. Écoutez dès maintenant cet épisode essentiel sur le site-reliability-engineer et transformez votre perspective sur la gestion des systèmes informatiques !

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

• Speaker #2

  Bonjour, je suis Nicolas et je vous souhaite la bienvenue sur mon podcast. L'idée est de parler SRE. Qu'est-ce qu'un SRE ? Quelles sont les bonnes pratiques ? Comment devenir SRE ? Comment recruter des SRE ? Dans cet épisode, je vais vous présenter ce qu'est un SRE. C'est une question qu'on me pose souvent. Qu'est-ce que ça veut dire, SRE ? Qu'est-ce que c'est un SRE ? SRE ça veut dire Site Reliability Engineer, ingénieur de la fiabilité du site. Bigre. Google a créé ce concept en 2003. Il faut se rappeler que Google date de 98. La vente de mots clés, 2000, Gmail 2004, Maps 2005. Donc en 2003, site ça voulait dire LE site web de Google, le seul, l'unique. En 2003, il y avait 2000 employés chez Google et forcément déjà des problèmes de fiabilité et de scalabilité. L'idée de l'époque, c'est d'approcher le problème avec des méthodes d'ingénieurs. Et d'ingénieurs logiciels d'ailleurs parce que c'est tout ce qu'ils avaient sous la main. Donc, au lieu d'avoir une armée de 6 admins pour surveiller et réparer une ferme de machines qui grandissait, ils ont décidé d'écrire des programmes pour gérer ces fermes de machines. Aujourd'hui, à Isere chez Google... C'est un ingénieur qui sait coder, mais qui comprend aussi ce qui se passe en production et qui sait comment ça marche à bas niveau, qui a de bonnes notions de performance et qui est entraîné à analyser les systèmes et à découvrir des pannes. Et là, on parle d'analyse avant le lancement d'un projet, aussi bien que d'analyse sur les systèmes en production. Par contre, SRE ça reste un terme assez vague et chaque société a sa propre définition. Parfois c'est juste un sysadmin pur dont on a changé le nom pour être un peu plus à la mode. L'important, c'est pas tellement le nom que vous donnez à votre équipe, c'est comment il travaille. Le SRE va normalement avoir un rôle avant, pendant et après la mise en production d'un système. Avant, il est conseiller de l'équipe de développement, il commente l'architecture, propose des évolutions d'algorithmes, etc. Pendant ? Il est souvent le garant de la revue de production. Il applique une checklist avec tout ce qu'il convient de vérifier avant d'aller en production. Après la mise en prod, il intervient en astreinte. C'est lui qu'on appelle quand le système est cassé. Avant la mise en production, le SRE va focaliser son attention sur la fiabilité. Qu'est-ce qui va casser ? Comment ça va impacter le système ? Comment éviter le problème ? Mais le SRE va aussi regarder l'observabilité du système. Comment va-t-on savoir ce qu'il se passe pour comprendre les problèmes et les résoudre ? Là, on parle de log, de monitoring, de page de statut. Après la mise en production, le SRE va attendre que le système se casse, en général en s'occupant de la prochaine version du système, ou d'un autre système, ou en buvant une bière. En cas de panne, le SRE va chercher d'abord à réduire l'impact sur les utilisateurs, souvent en appliquant des procédures préétablies, telles que le retour à la version précédente ou le basculement sur un site de secours. L'analyse de la cause primaire vient juste après, comprendre ce qu'il s'est passé pour que cela ne se reproduise pas. La culture SRE, c'est de réaliser des post-mortem, des documents qui décrivent ce qu'il s'est passé et qui a fait quoi. L'idée n'est absolument pas de chercher des coupables. Le coupable, c'est toujours le processus mis en place pour rendre le système fiable. Et l'idée du post mortem, c'est de l'améliorer. Si Intel a fait une fausse manip, c'est probablement qu'il manque une validation par un autre opérateur, ou que le bouton arrêter le système n'est pas assez rouge.

• Speaker #0

  Allô ? Allô ? Que bien ne marche ! Le serveur ne répond pas.

• Speaker #1

  Intel est de série. Intel est de série.

• Speaker #2

  Mais renonce à nos moutons. Qu'est-ce qu'elle est série ? Un série, c'est un ingénieur qui applique des techniques d'ingénieur pour rendre les systèmes fiables. C'est un développeur qui sait écrire du code et surtout lire du code. C'est un architecte qui sait appréhender un système complexe pour le découper en petits composants. C'est un sysadmin qui sait aller se connecter sur les machines pour les réparer. Et c'est aussi un pompier qui sait éteindre les incendies, mais qui n'oublie pas qu'il faut d'abord évacuer les personnes avant d'éteindre les feux. Voilà, vous savez un peu plus. presque c'est qu'un SRE. Dans le prochain épisode, je vous parlerai des bonnes pratiques des SRE, en particulier des indicateurs de fiabilité. Abonnez-vous si vous voulez être au courant dès que le nouvel épisode sera mis en ligne. Merci de votre écoute.