SRE

Code sur l'écran des ordinateurs portables SRE vs DevOps – concurrents ou amis

Chez Swisscom, de plus en plus d’équipes ont recours au Site Reliability Engineering (SRE) pour répondre aux attentes de nos clients et utilisateurs. Un instant! Ne comptions-nous pas sur DevOps pour combler le fossé entre Dev et Ops, et atteindre un niveau de qualité élevé de nos logiciels dans la production? SRE n’est-il qu’un nouveau mot à la mode sur le marché pour attirer les talents? Dans ce blog, les équipes DevOps de Swisscom souhaitent établir une compréhension commune du positionnement du SRE par rapport à DevOps et montrer comment nous considérons SRE dans notre département Software chez Swisscom. Commençons par un peu de théorie sur DevOps et SRE:

DevOps

  • Le mouvement DevOps(ouvre une nouvelle fenêtre) est né de développeurs qui se sont mis à écrire du code sans trop savoir comment il fonctionnerait en production. Ils balançaient ce code à l’équipe d’exploitation, qui était ensuite chargée d’assurer le bon fonctionnement des applications.
  • DevOps est apparu comme une culture et un ensemble de pratiques visant à réduire le fossé entre le développement de logiciels et leur exploitation.
  • Cependant, le mouvement DevOps ne définit pas explicitement comment y parvenir(ouvre une nouvelle fenêtre).
  • En ce sens, DevOps fait figure de classe ou d’interface abstraite dans la programmation. Il définit le comportement général du système, mais les détails d’implémentation sont laissés à l’appréciation de l’auteur.

Site Reliability Engineering (SRE)

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(ouvre une nouvelle fenêtre),
 vice-président de l’ingénierie chez Google

Comment SRE aborde concrètement DevOps

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.

Différences DevOps <-> SRE

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(ouvre une nouvelle fenêtre)  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.

Ressources

Cet article de blog est en grande partie basé sur SRE vs. DevOps: competing standards or close friends?

Michael Ludwig

Michael Ludwig

Tribe Chief

Plus d’articles getIT

Prêt pour Swisscom

Trouve ton travail ou le monde de la carrière qui te convient. Dans lequel tu veux participer à la création et te développer.

Ce que tu en fais, c'est ce qui nous définit.

Vers les univers professionnels

Vers les postes vacants cybersécurité