Si vous savez quelque chose sur les origines du Site Reliability Engineering, ou SRE, vous savez que le concept est né chez Google.
Mais pourquoi Google a-t-il établi le rôle de SRE ? Et comment SRE s’est-il propagé du géant de la recherche aux entreprises de tous types, y compris, mais sans s’y limiter, les entreprises à l’échelle du Web ayant des besoins de fiabilité énormes ?
Continuez à lire pour obtenir des réponses à ces questions alors que nous explorons et analysons l’histoire de SRE de Google à nos jours.
Création par Google du rôle SRE
La première équipe SRE est née chez Google en 2003 sous la direction de Ben Treynor Sloss, qui avait commencé sa carrière en tant qu’ingénieur logiciel chez Oracle et plusieurs autres sociétés avant de rejoindre Google.
Ni Sloss, ni Google en général, n’ont dit grand-chose publiquement sur exactement Pourquoi ils ont créé le rôle SRE. Cependant, les facteurs probables comprenaient :
- Besoins de fiabilité à l’échelle du Web: Google a été l’une des premières entreprises à avoir des besoins de fiabilité vraiment énormes. Vers 2003, la plupart des entreprises pouvaient s’en tirer avec des temps d’arrêt ou des chargements de pages lents ; après tout, plus de 50 millions de foyers américains disposaient encore d’un accès commuté à l’époque. Mais en tant que l’une des plus grandes sociétés Web de la planète, Google était à la frontière d’un nouveau type d’expérience utilisateur qui impliquait un temps d’arrêt et une latence minimes. La constitution d’une équipe SRE était une étape évidente vers la réalisation de cet objectif.
- Infrastructures massives: Dans le même ordre d’idées, Google a été l’une des premières entreprises à disposer d’une infrastructure vraiment massive et distribuée. En 2003, le cloud public n’existait pas encore et peu d’entreprises avaient à gérer des centaines de milliers de serveurs répartis sur des dizaines de centres de données. Mais Google l’a fait, c’est pourquoi il avait besoin d’une stratégie qui permettrait une automatisation à grande échelle de la fiabilité dans cette infrastructure tentaculaire. La plupart des autres entreprises ne seraient pas confrontées à ce défi avant de commencer à migrer vers le cloud à la fin des années 2000.
- Il n’y avait pas de DevOps: Si Sloss avait rejoint Google cinq ans plus tard, il est raisonnable d’imaginer qu’il aurait formé une équipe DevOps au lieu d’une équipe SRE pour réaliser le type de gestion de la fiabilité pilotée par le code qu’il envisageait. Après tout, DevOps et SRE sont guidés par des méthodologies et des objectifs similaires (bien que non identiques). Mais, en 2003, DevOps n’existait pas encore, Google a donc dû inventer son propre concept à partir de zéro. (Pourquoi DevOps a émergé en parallèle de SRE, au lieu de fusionner avec lui, est une histoire pour une autre fois.)
Comment le SRE s’est-il propagé au-delà de Google ?
L’histoire de l’expansion progressive de SRE de Google vers des entreprises de tous types s’est déroulée en deux étapes principales.
Les SRE se propagent aux Web-scalers
La première étape impliquait l’adoption de SRE par d’autres grandes entreprises à l’échelle du Web similaires à Google. Facebook avait une équipe SRE en 2010, selon un article de blog de l’époque. Netflix a créé une «équipe SRE de base» en 2016. Uber a commencé à écrire la même année sur la façon dont il utilise SRE. LinkedIn vantait sa « culture SRE » en 2017.
Il est assez facile de comprendre pourquoi de grandes entreprises comme celles-ci importeraient le concept SRE de Google dans leurs propres organisations informatiques. Ils ont été confrontés aux mêmes défis que Google : dès le début, ils avaient des infrastructures massives et distribuées à gérer. Ils devaient également répondre aux attentes toujours plus élevées des utilisateurs en matière de performances et de disponibilité. Et bien que la plupart de ces entreprises aient adopté SRE après que DevOps était déjà bien établi, c’est probablement parce qu’il était clair au milieu des années 2010 que DevOps à lui seul ne garantit pas une excellente expérience utilisateur.
SRE pour les entreprises « ordinaires »
La deuxième étape, la plus intéressante de l’histoire de SRE, est l’adoption de SRE par des entreprises « ordinaires », c’est-à-dire celles qui n’ont pas d’énormes parcs de serveurs à gérer ou des milliards de transactions à gérer chaque jour. Au cours des dernières années, des entreprises de tous types ont commencé à embaucher des SRE, même si elles ne sont pas confrontées à des défis particuliers en matière de fiabilité.
Il y a deux explications possibles pour lesquelles le rôle de SRE est devenu un élément central des organisations informatiques au sens large. Le plus cynique est que SRE n’est qu’un nouveau nom à la mode pour ce qu’on appelait autrefois les opérations informatiques. En d’autres termes, les entreprises qui embauchent des SRE aujourd’hui n’ont peut-être pas vraiment changé leur mode de fonctionnement ; ils viennent d’adopter un titre de poste plus sophistiqué pour leurs ingénieurs informatiques.
Mais il y a aussi une explication moins cynique à l’adoption généralisée de la SRE. Cela se résume au fait que nous vivons dans un monde où les utilisateurs ont des attentes extrêmement élevées vis-à-vis des sites Web et des applications, et la stratégie d’exploitation informatique traditionnelle ne peut pas les satisfaire. Aujourd’hui, même si vous exploitez un site Web ordinaire ou des applications mobiles avec seulement quelques milliers d’utilisateurs, vous devez vous assurer que vous pouvez mesurer les temps de chargement du contenu en millisecondes et résoudre les problèmes de disponibilité en quelques minutes au lieu de plusieurs jours si vous voulez suivre votre concurrence. Les concepts, outils et stratégies apportés par les SRE ont aidé les petites entreprises à atteindre ces objectifs.
Conclusion : l’avenir de la SRE
C’est un bref résumé de la façon dont SRE a vu le jour tel que nous le connaissons aujourd’hui. Mais où va-t-il ensuite ?
Il est impossible de prédire l’avenir, bien sûr. Mais si nous devions deviner, nous dirions que le SRE deviendra encore plus répandu dans les petites entreprises. Nous prévoyons également une utilisation toujours plus importante des outils d’automatisation pour rationaliser les flux de travail SRE de manière à permettre aux petites entreprises de profiter plus facilement de SRE, même si elles ne disposent pas de grandes équipes informatiques internes.
Si quelque chose est certain, cependant, c’est que – bien qu’il soit à l’origine un concept relativement obscur au sein d’une entreprise d’élite il y a deux décennies – SRE ne va nulle part. Même si le taux de création de nouvelles équipes SRE se stabilise, SRE est si bien implanté à ce stade dans des entreprises de pratiquement tous types et de toutes tailles qu’il est difficile d’imaginer un avenir où SRE ne serait pas au cœur des stratégies informatiques partout.