Qu'est-ce qu'un SRE? Le rôle primordial de l'ingénieur fiabilité de site

À mesure que le monde évoluait en ligne, la fiabilité des sites Web, des applications cloud et de l'infrastructure cloud est devenue un impératif commercial essentiel - pour tout, des opérations de commerce électronique aux banques mondiales en passant par les moteurs de recherche.

La façon dont nous gérons les systèmes et leurs charges de travail a changé. Aujourd'hui, nous pensons rarement en termes de serveurs précieux, hautement tactiles et hautes performances, mais au lieu de cela, rack sur rack de serveurs de base regroupés par virtualisation, avec une architecture logicielle distribuée empêchant les pannes de serveur de provoquer des temps d'arrêt. L'accent est passé du matériel à l'infrastructure définie par logiciel et des processus manuels incohérents et sujets aux erreurs à des tâches automatisées cohérentes, fiables et répétables.

L'ingénierie de la fiabilité du site consiste à maintenir cette infrastructure programmable et à maximiser la disponibilité des charges de travail qui y sont exécutées. Le titre du poste d'ingénieur en fiabilité de site (SRE) est né dans les halls de Google, qui, au tournant du millénaire, souhaitait redéfinir la relation entre les développeurs de logiciels et le personnel d'exploitation - et les aider à travailler ensemble pour construire des systèmes robustes et flexibles, avec l'amélioration constante et l'automatisation comme principes fondamentaux.

Qu'est-ce qu'un SRE?

Au niveau de la base, les SRE apportent des principes d'ingénierie logicielle aux problèmes d'infrastructure et d'exploitation, avec pour objectif nordique de créer des systèmes hautement évolutifs et fiables.

«Fondamentalement, c'est ce qui se passe lorsque vous demandez à un ingénieur logiciel de concevoir une fonction opérationnelle», comme l'a souvent dit Ben Treynor, vice-président de l'ingénierie chez Google et parrain de SRE.

La principale responsabilité de SRE est d'établir des seuils de niveau de service, souvent manifestés sous forme d'objectifs de niveau de service (SLO), qui aident à déterminer si une version reçoit le feu vert ou non. Le Saint Graal est toujours le sacré «cinq neuf» ou 99,999% de disponibilité. Plus le temps de fonctionnement est bon, plus les développeurs de corde peuvent lancer de nouvelles choses intéressantes et plus les SRE dorment, conduisant à une relation mutuellement bénéfique entre les fonctions, loin des vieux jours d'antagonisme des développeurs et des opérations.

Une fonction SRE sera généralement mesurée sur un ensemble de mesures de fiabilité clés, à savoir: les performances du système, la disponibilité, la latence, l'efficacité, la surveillance, la planification de la capacité et les interventions d'urgence.

[Aussi sur: Surveillance des applications: ce que les devops peuvent faire mieux]

Principales responsabilités professionnelles d'un SRE

Tout bon SRE sera obsédé par une chose en particulier: l'automatisation.

Comme Jason Qualman, un SRE chez l'éditeur de logiciels de surveillance New Relic, le déclare dans un article de blog: «Une grande partie de ce rôle consiste à réfléchir aux choses inefficaces et chronophages que les gens font et à y mettre un terme dès que possible. Au lieu de donner un coup de pied au travail manuel, vous dites: "Je vais prendre le temps d'automatiser cela dès maintenant et d'empêcher quiconque de faire cette chose douloureuse." "

Un autre élément clé du rôle SRE est ce qu'on appelle «l'ingénierie des versions», qui consiste à définir les meilleures pratiques pour garantir la cohérence et la répétabilité des versions de logiciels.

«Les ingénieurs de publication ont une solide (sinon experte) compréhension de la gestion du code source, des compilateurs, des langages de configuration de build, des outils de build automatisés, des gestionnaires de packages et des installateurs. Leur ensemble de compétences comprend une connaissance approfondie de plusieurs domaines: développement, gestion de la configuration, intégration des tests, administration système et assistance client », a écrit Dinah McNutt, responsable du programme technique chez Google, pour le livre fondateur Site Reliability Engineering (publié par O'Reilly dans 2016 et rédigé par les googleurs Jennifer Petoff, Niall Richard Murphy, Chris Jones et Betsy Beyer).

Ensuite, il y a la partie réponse du rôle, qui implique l'alerte, la disponibilité et le dépannage, ainsi que la réponse aux urgences et aux incidents et les post-mortems.

Essentiellement, il est important que les SRE sachent comment surveiller au mieux les systèmes et réagir lorsque les choses tournent mal, en écrivant et en réécrivant constamment des playbooks de réponse pour réduire le temps de réparer toute panne qui pourrait survenir. Chez Google, cela implique de documenter un incident, de comprendre toutes les causes profondes contributives et de mettre en œuvre de futures actions préventives.

«Écrire un post-mortem n'est pas une punition - c'est une opportunité d'apprentissage pour toute l'entreprise», écrivent les Googleurs John Lunney et Sue Lueder dans un chapitre du livre Site Reliability Engineering .

[Aussi sur: 3 étapes pour appliquer des méthodologies agiles dans les opérations informatiques]

Ingénieurs SRE vs devops

Je sais ce que tu penses. Tout cela ressemble beaucoup au devops, mais en termes de terminologie, le titre du poste SRE est en fait antérieur à l'ingénieur devops d'environ cinq ans.

Les deux sont fondés sur des principes similaires, mais la différence est à la fois subtile et importante. Les deux méthodes de travail impliquent de faire tomber les barrières entre les développeurs et le personnel d'exploitation, et toutes deux visent à augmenter la vitesse des équipes de développeurs tout en maintenant la résilience de base de ces services.

La principale différence est que les ingénieurs devops ont tendance à se concentrer sur la prise en charge de la livraison continue et de la vitesse des développeurs, tandis que les SRE assument la responsabilité de la fiabilité et de l'automatisation tout au long du cycle de vie du logiciel, en mettant l'accent sur le déploiement et la surveillance des versions et le maintien de l'infrastructure définie par le logiciel. Le SRE a une fonction intégrale au sein de l'équipe d'ingénierie au sens large: s'assurer qu'il y a un siège de spécialiste à la table axé sur la construction de systèmes stables.

Comme le dit Jayne Groll du Devops Institute: «Devops se concentre sur l'ingénierie de la livraison continue jusqu'au point de déploiement; SRE se concentre sur l'ingénierie des opérations continues au point de consommation du client. »

L'histoire de SRE chez Google

Remonter les principes SRE à leurs origines chez Google au début des années 2000 fournit une leçon essentielle de la discipline.

«Lorsque je suis arrivé chez Google, j'ai eu la chance de faire partie d'une équipe qui était en partie composée d'ingénieurs logiciels et qui étaient enclins à utiliser des logiciels pour résoudre des problèmes historiquement résolus à la main. Alors quand il était temps de créer une équipe formelle pour faire ce travail opérationnel, il était naturel d'adopter l'approche «tout peut être traité comme un problème logiciel» et de fonctionner avec », a déclaré Ben Treynor dans une interview sur le blog interne de Google.

«Donc, SRE effectue fondamentalement un travail qui a toujours été effectué par une équipe d'exploitation, mais en utilisant des ingénieurs possédant une expertise en logiciel, et en misant sur le fait que ces ingénieurs sont intrinsèquement à la fois prédisposés et capables de substituer l'automatisation au travail humain, »Ajoute Treynor.

Google réfléchit également de manière assez rigide à la manière de constituer une équipe SRE. Tous les SRE de Google doivent être des ingénieurs logiciels Google ou des «candidats très proches des qualifications de Google Software Engineering». Ils doivent également avoir des compétences en gestion d’infrastructure, le plus souvent «une expertise en interne et en réseau Unix (couche 1 à couche 3)».

Les qualifications SRE ont encore tendance à varier d'une entreprise à l'autre, mais en ce qui concerne les principes de base, l'approche Google est un point de départ solide. Les détails dépendront des besoins de l'entreprise, des processus établis et de la pile technologique déjà adoptée par l'organisation.

Description du poste et salaire SRE

Les SRE passent généralement environ 50% de leur temps à exécuter des fonctions opérationnelles traditionnelles, comme être sur appel et intervenir pour résoudre les problèmes. Les 50% restants se concentrent sur le développement de logiciels pour rendre les systèmes sous-jacents plus résilients, automatisés et auto-réparateurs au fil du temps. C'est pourquoi le poste nécessite un solide mélange de compétences en génie logiciel et en opérations. Un bon SRE sera organisé, cool sous pression et un solutionneur de problèmes. Les responsables SRE sont responsables de la performance, de la stratégie et de l'optimisation de l'équipe.

Mais qu'en est-il des organisations où le rôle SRE n'existe pas? Dans le rapport O'Reilly «Qu'est-ce que SRE?» Kurt Andersen de LinkedIn et Craig Sebenik de Split (un éditeur de logiciels de gestion des versions) recommandent d'adopter une approche «à la base». Ils recommandent de trouver «une équipe de développement motivée pour changer et y mettre en place une petite équipe SRE (ou un individu). Au fil du temps, vous pouvez utiliser ce succès comme un exemple positif pour d'autres équipes. »

Le salaire annuel moyen d'un SRE est d'environ 130 000 $ aux États-Unis et 76 000 £ au Royaume-Uni, selon le site Indeed.

Ressources SRE

Les ressources abondent pour développer les compétences SRE, des certifications de l'Institut DevOps aux livres et ressources en ligne d'O'Reilly, Microsoft et Google. L' ingénierie de fiabilité de site  géante de 550 pages susmentionnée  par Jennifer Petoff, Niall Richard Murphy, Chris Jones et Betsy Beyer est le livre incontournable sur le sujet, publié en 2016. Le livre est également disponible gratuitement en ligne sur Google. 

D'autres livres plus récents sur le sujet incluent  Training Site Reliability Engineers  par Jennifer Petoff, JC van Winkel et Preston Yoshioka; Qu'est-ce que SRE?  par Kurt Andersen et Craig Sebenik; Seeking SRE  de David N. Blank-Edelman et  The Site Reliability Workbook  de Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara et Stephen Thorne.

O'Reilly dispose également d'une bibliothèque complète d'actifs en ligne, de vidéos et de livres électroniques sur le sujet, soigneusement organisée dans cette liste de lecture SRE Essentials par l'ancienne ingénieure en fiabilité des sites Google, Liz Fong-Jones.

Le mastodonte de l'apprentissage en ligne Coursera propose plusieurs cours, dont le populaire Site Reliability Engineering: Measuring and Managing Reliability from Google Cloud Training. Ce cours est également disponible auprès de Pluralsight, tout comme le cours pour débutants Site Reliability Engineering (SRE): The Big Picture d'Elton Stoneman. La Linux Foundation propose un cours autoguidé intitulé DevOps and SRE Fundamentals: Implementing Continuous Delivery.

Le Jellyfish Training, basé au Royaume-Uni, propose diverses options de cours de formation privés de deux jours pour la Fondation SRE (SREF).

En savoir plus sur les devops

  • Qu'est-ce que devops? Transformer le développement logiciel
  • 3 façons de lancer un programme devops
  • Bonnes pratiques Devops: les 5 méthodes à adopter
  • 15 KPI pour suivre la transformation devops
  • Surveillance des applications: ce que les devops peuvent faire mieux
  • Où l'ingénierie de fiabilité des sites rencontre les devops
  • 5 principes pour devenir une équipe devops agile collaborative
  • 3 étapes pour appliquer des méthodologies agiles dans les opérations informatiques
  • Comment les équipes agiles peuvent soutenir la gestion des incidents
  • Comment Dataops améliore les données, les analyses et l'apprentissage automatique
  • Application de devops à la science des données et à l'apprentissage automatique
  • 7 questions pour prioriser votre backlog devops