Avec le basculement du monde en ligne, la fiabilité des sites web, des applications et des infrastructures dans le cloud est devenue un impératif commercial critique, depuis les opérations de commerce électronique, jusqu’aux moteurs de recherche, en passant par les systèmes bancaires mondialisés. La manière dont sont gérés les systèmes et leur charge de travail a changé. Aujourd'hui, on pense rarement en termes de serveurs à haute proximité, haute performance, et très couteux, mais plutôt de mise en commun de serveurs courants par la virtualisation, et d’architecture logicielle distribuée pour empêcher que les pannes de serveur ne provoquent des temps d'arrêt. On est passé d'une infrastructure matérielle à une infrastructure logicielle et de processus manuels incohérents et propices aux erreurs à des tâches automatisées cohérentes, fiables et répétables. L'ingénierie de la fiabilité des sites consiste à maintenir cette infrastructure programmable et à maximiser la disponibilité des charges de travail qui y sont exécutées. Le métier d’ingénieur en fiabilité de site (SRE) est né dans les locaux de Google qui, au tournant du millénaire, voulait redéfinir la relation entre les développeurs de logiciels et les équipes opérationnelles - et les aider à travailler ensemble pour construire des systèmes robustes et flexibles, avec pour principes de base l'amélioration en continue et l'automatisation.

Qu'est-ce qu'un SRE ?

À la base, les ingénieurs de la fiabilité des sites (SRE) appliquent les principes du génie logiciel aux problèmes d'infrastructure et d'exploitation, en vue de créer des systèmes hautement évolutifs et fiables. « Fondamentalement, c'est ce qui se passe quand vous demandez à un ingénieur logiciel de concevoir une fonction d'exploitation », comme le dit souvent Ben Treynor, vice-président de l'ingénierie chez Google et parrain du concept de « Site Reliability Engineering ». L'une des responsabilités principales du SRE est d'établir des seuils de niveau de service, qui se manifestent souvent sous la forme d'objectifs de niveau de service (SLO), qui permettent de savoir si une release reçoit ou non une validation. Le Saint Graal est toujours d’atteindre le sacré « cinq neuf » équivalent à 99,999 % de temps de disponibilité. Plus le temps de disponibilité est élevé, plus les développeurs disposent de marge pour lancer de nouvelles choses et plus les SRE peuvent dormir tranquille, si bien que la relation est bénéfique aux développeurs et aux opérationnels, bien loin des anciens antagonismes. Une fonction SRE sera généralement mesurée à partir d'une série de paramètres de fiabilité clés, à savoir : la performance du système, la disponibilité, la latence, l'efficacité, le monitoring, la planification des capacités et la réponse aux situations d'urgence.

Principales responsabilités du SRE

Tout bon SRE sera obsédé par une chose en particulier : l'automatisation. Comme l’a écrit Jason Qualman, SRE de l’éditeur de logiciels de monitoring New Relic, dans un article de blog : « Une partie importante du métier consiste à penser aux tâches inefficaces et chronophages et à y mettre un terme dès que possible. Face à chaque tâche manuelle, le SRE se dit : « Je vais prendre le temps d'automatiser cela sans délai et empêcher les autres de répéter ce travail pénible ». Un autre aspect important du métier de SRE concerne « l'ingénierie des versions ». Celle-ci consiste à définir les meilleures pratiques pour garantir la cohérence et la reproductibilité des versions de logiciels. « Les ingénieurs de release ont une solide compréhension (si ce n’est une vraie expertise) de la gestion du code source, des compilateurs, des langages de configuration de build, des outils de construction automatisés, des gestionnaires de paquets et des installateurs. Ces compétences impliquent une connaissance approfondie de plusieurs domaines : le développement, la gestion de la configuration, les tests d'intégration, l'administration système et le support client », a écrit Dinah McNutt, responsable du programme technique chez Google, dans l’ouvrage de référence « Site Reliability Engineering » (publié par O'Reilly en 2016 et écrit par Jennifer Petoff, Niall Richard Murphy, Chris Jones et Betsy Beyer de Google).

Il y a aussi un aspect intervention dans ce métier. Il consiste à alerter, à être d’astreinte et à dépanner, à répondre aux urgences et aux incidents et à faire des analyses post-mortem. Il est essentiel que les ingénieurs de la fiabilité des sites sachent comment surveiller au mieux les systèmes et réagir quand les choses tournent mal, en rédigeant et en réécrivant constamment des manuels d'intervention pour réduire le temps de réparation de toute panne potentielle. Chez Google, cela implique de documenter un incident, de comprendre toutes les causes profondes qui y contribuent et de mettre en œuvre des actions préventives futures. « Rédiger une analyse post-mortem n'est pas une punition, c'est une opportunité d'apprentissage pour toute l'entreprise », ont déclaré John Lunney et Sue Lueder dans un chapitre du livre « Site Reliability Engineering ».

SRE vs. Ingénieur devops

Tout cela ressemble beaucoup au métier de devops, direz-vous. Mais en ce qui concerne la terminologie, le métier d’ingénieur de la fiabilité des sites a précédé d'environ cinq ans celui d'ingénieur devops. 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 consistent à faire tomber les barrières entre les développeurs et les équipes opérationnelles, et toutes deux visent à rendre les équipes de développeurs plus rapides tout en maintenant la résilience de base de ces services. La principale différence, c’est que les ingénieurs devops se concentrent plutôt sur le maintien d'une livraison continue et sur la vitesse de développement, tandis que les SRE assument la responsabilité de la fiabilité et de l'automatisation tout au long du cycle de vie des logiciels, et mettent davantage l'accent sur le déploiement et le suivi des versions et le maintien du rythme de l'infrastructure définie par logiciel. Le SRE a une fonction indispensable au sein de l'équipe d'ingénierie au sens large : il assure la présence d'un spécialiste soucieux de la stabilité des systèmes. Comme le dit Jayne Groll du Devops Institute : « Le Devops se concentre sur l'ingénierie de la livraison continue jusqu'au point de déploiement ; le SRE se concentre sur l'ingénierie des opérations continues au point de consommation du client ».

L'histoire du SRE chez Google

Les principes à la base du SRE, énoncés au début des années 2000 chez Google, permettent de tirer une leçon essentielle sur cette discipline. « Quand je suis arrivé chez Google, j'ai eu la chance de faire partie d'une équipe comportant quelques ingénieurs logiciels qui cherchaient toujours à utiliser les logiciels pour résoudre des problèmes historiquement résolus à la main. Ainsi, quand nous avons dû créer une équipe formelle pour effectuer ce travail opérationnel, il était naturel de chercher à résoudre tout problème comme un problème logiciel et d’avancer comme ça », a déclaré Ben Treynor dans une interview sur le blog interne de Google. « Donc, le SRE accomplit un travail anciennement effectué par l’équipe opérationnelle, mais en s’appuyant sur des ingénieurs ayant une expertise logicielle, et en misant sur le fait que ces ingénieurs sont intrinsèquement prédisposés à, et ont la capacité de substituer l'automatisation au travail humain », a ajouté Ben Treynor. Google réfléchit également de manière assez stricte à la façon de constituer ses équipes SRE. Chez Google, tous les SRE sont soit des ingénieurs logiciels de Google, les Google Software Engineers, soit des « candidats avec des qualifications très proches du Google Software Engineering ». Ils doivent également avoir des compétences en matière de gestion des infrastructures, le plus souvent « une expertise en système Unix Internals et en matière de réseau (du Layer 1 au Layer 3) ». Les qualifications des SRE varient toujours d'une entreprise à l'autre, mais pour ce qui est des principes de base, l'approche de Google offre un bon point de départ. Le reste dépendra des besoins de l'entreprise, des processus établis et de la pile technologique déjà adoptée.

Poste et salaire du SRE

Les SRE passent généralement 50 % de leur temps environ à effectuer des opérations traditionnelles, notamment à être d’astreinte et à intervenir rapidement pour résoudre des problèmes. Les 50 % restants sont consacrés au développement de logiciels afin de rendre les systèmes sous-jacents plus résistants, automatisés et de plus en plus capables à s’auto-régénérer. C'est pourquoi ce poste exige un sérieux mix de compétences en ingénierie logicielle et opérationnelles. Un bon SRE sera organisé, saura garder son calme en dépit de la pression et résoudre les problèmes. Les managers SRE sont responsables des performances de l'équipe, de la stratégie et de l'optimisation. Mais qu'en est-il des entreprises où il n’y a pas de poste de SRE ? Dans le rapport O'Reilly intitulé « Qu'est-ce qu’un SRE ? », Kurt Andersen de LinkedIn et Craig Sebenik de Split (un éditeur de logiciels de gestion de versions) recommandent d'adopter une approche « de base ». Ils recommandent de trouver « une équipe de développement qui est motivée pour changer ses habitudes et de mettre en place une petite équipe de SRE (ou un seul SRE). « Avec le temps, vous pourrez utiliser ce succès comme exemple pour motiver d’autres équipes », ont-ils ajouté. Le salaire annuel moyen d'un SRE est d'environ 130 000 dollars aux États-Unis et de 76 000 livres sterling au Royaume-Uni, selon le site d'emploi Indeed et de 42 000 euros en France (source Neuvoo).

Les ressources de l'ESR

Les ressources ne manquent pas pour développer ses compétences en ingénierie de la fiabilité des sites, depuis les certifications du DevOps Institute jusqu’aux livres et ressources en ligne de O'Reilly, Microsoft et Google. L'ouvrage de 550 pages susmentionné, intitulé « Site Reliability Engineering » auxquels ont contribué Jennifer Petoff, Niall Richard Murphy, Chris Jones et Betsy Beyer et publié en 2016, est la référence sur le sujet. À signaler que l’ouvrage est disponible gratuitement en ligne sur le site de Google. Parmi les autres ouvrages plus récents sur le sujet (en anglais), citons « Training Site Reliability Engineers », de Jennifer Petoff, JC van Winkel et Preston Yoshioka ; « What Is SRE ? », de 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 de ressources en ligne, de vidéos et de livres électroniques sur le sujet, très bien organisée.

Appelée SRE Essentials, cette bibliothèque est tenue à jour par l'ancienne ingénieure en fiabilité des sites de Google, Liz Fong-Jones. On trouve aussi en ligne plusieurs cours, dont le très populaire « Site Reliability Engineering : Measuring and Managing Reliability » du Google Cloud Training. Ce cours est également disponible auprès de Pluralsight, de même que le cours pour débutants intitulé « Site Reliability Engineering (SRE) : The Big Picture », par Elton Stoneman. La Linux Foundation propose un cours en self-service intitulé « DevOps and SRE Fundamentals : Implementing Continuous Delivery ». Basé au Royaume-Uni, Jellyfish Training propose diverses options de cours de formation privés de deux jours accrédités par la SRE Foundation (SREF).