Quelle est la différence entre SRE et DevOps ?

À mesure que notre dépendance à l'égard de la technologie s'accroît, des disciplines sont apparues pour garantir que les changements sont déployés efficacement et que nos systèmes sont là quand nous en avons besoin. L'essor des cultures et pratiques DevOps et Site Reliability Engineering s'est imposé au cours des dernières années.

 

Il est important de comprendre les chevauchements et les différences entre les DevOps et SRE de compétences et les organisations. Les deux résolvent des défis très distincts avec des approches uniques et innovantes, ouvrant la voie à de nouveaux paradigmes technologiques.

 

 

Disposer de systèmes plus efficaces et plus fiables n'est pas un objectif nouveau pour la technologie. Comme de nombreuses autres facettes de la technologie, les connaissances et la science qui sous-tendent ces deux objectifs ont augmenté au point de justifier des organisations et des ingénieurs spécialisés.

Le mouvement DevOps a pour but de briser les silos. La quintessence de la déconnexion entre l'équipe de développement et l'équipe d'exploitation est exactement ce que les ingénieurs et dirigeants DevOps tentent de résoudre. Ce clivage est logique, car ceux qui écrivent les logiciels ne sont généralement pas ceux qui les font fonctionner. Il faut du temps pour démêler ces pratiques dans les organisations et l'évolution des mentalités est difficile à prévoir.

Les ingénieurs DevOps sont des ingénieurs axés sur les opérations qui résolvent les problèmes de développement. Les SRE sont des ingénieurs axés sur le développement qui résolvent les problèmes d'exploitation, d'échelle et de fiabilité. Les deux groupes d'ingénieurs franchissent le gouffre en apportant leur expertise et leurs opinions à l'autre côté de l'équation.

Qu’est ce que la loi de Conway ?

La loi de Conway est un élément organisationnel populaire dont on parle dans la culture DevOps. Il s'agit d'un adage selon lequel les organisations conçoivent des systèmes qui reflètent leur propre structure de communication. Nous sommes des personnes, et en tant que personnes, nous concevons des systèmes. Si l'on considère les structures des équipes DevOps, celles-ci s'efforcent de briser les silos organisationnels créés par la loi de Conway et de créer un changement culturel vers la collaboration et la communication. Ces silos institutionnels sont des obstacles à l'efficacité de l'ingénierie, deux groupes de personnes ou plus pour faire passer les fonctionnalités et être opérationnel avec des objectifs distincts.

Quels sont les problèmes résolus par les équipes DevOps ?

Les équipes DevOps s'efforcent d'éliminer les goulots d'étranglement tout au long du SDLC en supprimant les obstacles à la production et à l'automatisation. Avec l'adoption de la méthode Agile, les changements de production sont créés et doivent être déployés à une vitesse plus rapide, car les changements incrémentiels sont désormais attendus.

Les équipes DevOps sont les pourvoyeurs d'outils de développement, qu'il s'agisse de fournir des conseils au début du SDLC avec des recommandations de gestion du code source (SCM) ou de permettre l'intégration continue et la livraison continue dans une organisation. Avec un large éventail de responsabilités, les équipes DevOps peuvent être propriétaires et superviser un certain nombre d'outils et de plateformes.

Quels sont les problèmes résolus par les SRE ?

Les équipes de SRE se concentrent sur la sécurité, la santé, le temps de fonctionnement et la capacité à remédier aux problèmes imprévus. Un pilier important du travail consiste à combattre les incidents, et les SRE passent beaucoup de temps à s'assurer que la lutte contre les incendies ne se produise pas grâce à leur vaste expertise.

En supprimant certaines des charges complexes liées à la mise à l'échelle et au maintien de la disponibilité des systèmes distribués, les pratiques SRE permettent aux équipes de développement de se concentrer sur le développement de fonctionnalités plutôt que sur les nuances liées à la réalisation et au maintien des engagements de niveau de service.

Quels sont les indicateurs et les mesures de la performance en SRE ?

Les équipes DevOps et SRE apprécient les mesures, car il est impossible d'améliorer ce que l'on ne peut pas mesurer. Les indicateurs et les mesures de la performance d'un système peuvent être représentés par l'un des engagements de niveau de service (SLI). Il existe un trio de mesures, les SLA, les SLO et les SLI, qui donnent une image de l'accord conclu par rapport aux objectifs et aux réalisations pour respecter l'accord. Avec les SLO et les SLI, on peut se faire une idée de la santé d'un système.

SLAs

Les accords de niveau de service sont l'engagement/accord qu’on prend avec ses clients. Les clients peuvent être internes, externes ou un autre système. Les SLA sont généralement élaborés autour des attentes des clients ou des attentes du système. Les SLA existent depuis un certain temps et la plupart des ingénieurs considèrent qu'un SLA est "nous devons répondre en 2000 ms ou moins", ce qui, dans la nomenclature actuelle, serait en fait un SLO. Un SLA, dans ce cas, serait "nous avons besoin d'un temps de disponibilité de 99%".

SLOs 

Les objectifs de niveau de service sont des buts qui doivent être atteints afin de respecter les SLA. La méthode RED de Tom Wilkie peut aider à définir de bonnes mesures pour les SLO : demandes, erreurs et durée.

SLIs 

Les indicateurs de niveau de service mesurent la conformité/le respect d'un ALS. Si l'on se réfère au SLO "nous devons répondre en 2000 ms ou moins 99% du temps" mentionné ci-dessus, le SLI serait la mesure réelle. Peut-être que 98% des demandes reçoivent une réponse en moins de 2000 ms, ce qui ne correspond pas à l'objectif de l'ALS. Si les SLO/SLI ne sont pas respectés, il faut consacrer du temps à remédier aux problèmes liés aux ralentissements.

Métriques Accelerate pour les équipes DevOps

Pour les équipes DevOps, la santé et la disponibilité du système ne signifient pas que l'efficacité de l'ingénierie est atteinte. Une autre série de mesures à examiner pour les équipes DevOps sont les mesures Accelerate.

La méthode Accelerate recommande de mesurer les performances en matière de livraison de logiciels selon quatre paramètres clés. Le délai d'exécution, la fréquence de déploiement, le temps moyen de restauration (MTTR) et le pourcentage d'échec des modifications.

Délai d'exécution

Dans le cadre de la production au plus juste, le délai d'exécution est le temps qui s'écoule entre la demande d'un client et la satisfaction de cette demande. Dans le domaine technologique, il peut s'agir du délai entre le moment où le code est enregistré et celui où il est déployé en production.

Fréquence des déploiements

Plus vos clients internes peuvent déployer fréquemment, plus le processus de livraison de logiciels est efficace.

Temps moyen de restauration

Tiré de la production allégée, le MTTR est une mesure d'incident qui calcule le temps moyen de restauration d'un système. Dans le domaine des logiciels, la restauration consiste à revenir à la dernière version connue de l'application. Le temps moyen de réparation est le moment où la réparation commence, c'est-à-dire le début du retour en arrière. La partie "restauration" du temps moyen de restauration correspond au moment où le système retrouve sa fonctionnalité précédente.

Pourcentage d'échec des changements

Il s'agit du pourcentage de changements en production qui échouent. Après avoir traversé tous les exercices de mise en confiance menant à la production, avec le nombre d'inconnues en production, un changement échouera. Réduire le taux d'échec des changements permet de renforcer la confiance dans la production. Dans les méthodes de livraison modernes, échouer plus souvent et plus tôt (dans un environnement réduit) est la clé de l'échec en production.