L’ingénierie de fiabilité de site en contexte
Avant d’explorer certaines des pratiques associés à l’ingénierie de fiabilité de site (SRE, Site Reliability Engineering), il serait bon de replacer dans le contexte certaines des idées que nous venons de voir dans l’unité précédente. Dans cette courte unité, nous allons découvrir l’historique de l’ingénierie de fiabilité de site et sa relation à d’autres pratiques opérationnelles que vous connaissez peut-être. Ces connaissances favoriseront nos chances de succès à l’avenir, car ces pratiques deviennent plus claires en contexte. De plus, quand vos amis vous demanderont « En quoi l’ingénierie de fiabilité de site diffère-t-elle de... », vous aurez une réponse toute prête.
Historique
Un historique hautement condensé de SRE commence par ses origines chez Google en 2003. Ben Treynor, aujourd’hui appelé Treynor Sloss, prit la direction de l’« équipe de production » de Google (qui ne comptait alors que sept ingénieurs logiciels). Il créa l’idée qu’il décrit comme « ce qu’il se passe quand vous demandez à un ingénieur logiciel de concevoir une fonction d’exploitation ». L’histoire est utile ici, car elle permet d’expliquer pourquoi SRE peut sembler très « ingénierie logicielle » au personnel d’exploitation qui l’aborde pour la première fois. Elle a adopté des valeurs et des outils de ce domaine, tels que l’importance du codage et des systèmes de contrôle de code source comme outil fondamental. L’implémentation initiale et actuelle de Google SRE est bien documentée dans ses deux livres publiés par O’Reilly (voir l’unité Bien démarrer).
À mesure que des employés de Google quittaient l’entreprise (et que le personnel de l’entreprise discutaient de plus en plus publiquement de leurs pratiques), l’ingénierie de fiabilité de site a commencé à s’étendre à d’autres organisations du secteur. Celles-ci ont adopté et adapté les principes et pratiques SRE en fonction de leur culture locale. Ce processus d’expansion a engendré différentes implémentations de SRE.
DevOps et SRE
L’industrie dans son ensemble était confrontée aux mêmes défis concernant la mise à l’échelle, la rapidité de développement vs. la stabilité opérationnelle, et d’autres problèmes de livraison de logiciels ayant généré le mouvement d’ingénierie de fiabilité de site. Des efforts parallèles visant à les résoudre en dehors de Google (et quelques grandes entreprises à ce moment-là) ont donné naissance à DevOps.
Pour obtenir de nombreuses informations sur DevOps, consultez le DevOps resource center.
Notes
Il est important de noter que DevOps et SRE sont deux tentatives différentes et parallèles de relever les mêmes défis. SRE ne constitue pas l’étape suivante dans l’évolution de DevOps. SRE n’a pas été créé pour être « l’avenir de DevOps ».
La différence entre SRE et DevOps est un sujet donnant encore lieu à de nombreuses discussions parmi les spécialistes. On reconnaît généralement les différences suivantes :
- La SRE est une discipline d’ingénierie axée sur la fiabilité. DevOps est un mouvement culturel né de la volonté d’éliminer les problèmes généralement associés à la séparation entre les organisations Développement et Opérations.
- SRE peut être le nom d’un rôle, par exemple « Je suis ingénieur de fiabilité de site ». DevOps, non. À proprement parler, personne n’exerce la fonction de « DevOps ».
- SRE tend à être plus normatif. DevOps est intentionnellement non-normatif. L’adoption presque universelle de l’intégration continue/livraison continue et des principes agiles représente ce en quoi DevOps s’en rapproche le plus à cet égard.
Les deux pratiques opérationnelles, DevOps et SRE, partagent un amour mutuel de la supervision/observation et de l’automatisation (peut-être pour des raisons différentes). C’est l’une des raisons pour lesquelles il est souvent plus facile d’importer les pratiques et principes SRE dans une organisation avec une pratique DevOps existante. Ce processus doit être effectué avec précaution et intention. De plus, il peut et doit être implémenté de façon incrémentielle. Il n’est pas nécessaire d’effectuer un changement soudain.
Avertissement
La simple permutation des fonctions des employés de l’organisation est une stratégie d’implémentation qui échoue presque toujours. Elle ne génèrera pas les avantages que SRE peut offrir. Pour obtenir de meilleures suggestions, consultez la section Bien démarrer de cette unité.
Conclusion
Dans cette courte unité, nous avons cherché à définir un contexte autour de SRE et DevOps. SRE et DevOps doivent être considérés comme des écoles de pensée opérationnelle voisines.
Maintenant que nous avons vu quel était le contexte de l’ingénierie de fiabilité de site, examinons certains de ses principes fondamentaux.