Site Reliability Engineering (SRE) est un terme (avec la fonction ou le Job Role associé) inventé par Ben Treynor Sloss, vice-président de l’ingénierie chez Google.
SRE est une fonction, un ensemble de pratiques considérées comme efficaces par Google, et des convictions qui animent ces pratiques. Si l’on considère DevOps comme une philosophie et une approche du travail, SRE a alors pour mission d’en mettre en œuvre une partie.
«SRE est ce que vous obtenez lorsque vous demandez à un ingénieur logiciel de concevoir des fonctionnalités opérationnelles.»
Ben Treynor, vice-président de l’ingénierie chez Google
SRE incarne la philosophie de DevOps, mais est beaucoup plus normatif dans la façon de mesurer et d’atteindre la fiabilité à travers le travail d’ingénierie et d’exploitation. En d’autres termes, SRE prescrit la manière de réussir dans les différents domaines DevOps. Le tableau ci-dessous illustre par exemple les cinq piliers DevOps et les pratiques SRE correspondantes:
Ainsi, d’une certaine manière, la classe SRE implémente l’interface DevOps.
Il existe toutefois des différences significatives. DevOps est en quelque sorte une philosophie et une culture au sens large.
Cette approche ne précise pas la façon d’exécuter les fonctions opérationnelles à un niveau détaillé. Par exemple, elle n’établit pas de règles normatives quant à la gestion des services. Elle s’attache plutôt à éliminer les barrières dans l’organisation, ce qui est également très utile.
SRE, de son côté, a des responsabilités relativement bien définies et sa mission est en général orientée sur les services (et l’utilisateur final) plutôt que sur l’entreprise dans son ensemble. Il apporte donc un cadre intellectuel subjectif (y compris des concepts comme les error budgets au problème de l’exploitation efficace des systèmes. Bien que SRE soit, en tant que profession, très conscient des incitations et de leurs effets, il est en revanche peu précis sur des sujets comme la siloïsation et les barrières d’information. Il vient soutenir le CI (Continuous Integration) et le CD (Continuous Delivery) pas nécessairement à cause du Business Case, mais en raison de l’amélioration des pratiques opérationnelles que cela implique.
En d’autres termes, SRE croit aux mêmes choses que DevOps, mais pour des raisons un peu différentes.
Cet article de blog est en grande partie basé sur SRE vs. DevOps: competing standards or close friends?
Michael Ludwig
Tribe Chief
Trouve le Job ou l’univers professionnel qui te convient. Où tu veux co-créer et évoluer.
Ce qui nous définit, c’est toi.