Bien que les équipes DevOps et les ingénieurs en fiabilité du site (SRE) aient pris de l’importance dans les cercles informatiques, les similitudes et les différences entre les deux ne sont pas toujours bien comprises. Ils sont étroitement alignés dans les services qu’ils fournissent à leurs entreprises, mais il existe des lignes de démarcation claires entre les rôles qu’ils jouent, les outils qu’ils utilisent et la façon dont ils sont motivés à la fois sur le plan organisationnel et interne . Voici un bref aperçu :
Où se concentrent-ils ?
Tout ce qui concerne la pré-production est DevOps, tandis que le travail de post-production est SRE. Alors que DevOps se concentre principalement sur le développement et la production d’applications, les SRE se concentrent beaucoup plus sur la stabilité ou la fiabilité de la plate-forme une fois en production.
Quels outils utilisent-ils ?
Compte tenu des différents objectifs, les boîtes à outils qu’ils utilisent diffèrent également. Les équipes DevOps se concentrent davantage sur les workflows informatiques et les outils d’automatisation tels que Jenkins, Chef, Puppet et Harness. L’ingénierie cloud et les plates-formes d’infrastructure en tant que code telles que Ansible, Hashicorp et Pulumi sont également fiables.
Les SRE se concentrent davantage sur la surveillance via Data Dog, Prometheus et des plateformes similaires. Ils sont toujours sur appel, donc PagerDuty ou des outils similaires sont vitaux pour eux. Vous devez également être familiarisé avec les outils de définition des objectifs de niveau de service (SLO) et des indicateurs de niveau de service (SLI) tels que Blameless ou Nobl9. Ces outils se combinent pour leur fournir les informations dont ils ont besoin pour trouver, suivre et rapporter sur ces indicateurs.
Quoi de plus exigeant techniquement ?
En ce qui concerne la formation requise et la technique générale du rôle, les DevOps sont susceptibles d’être plus pratiques, car ils doivent savoir comment créer et maintenir un pipeline pour répondre aux besoins d’un large éventail de parties prenantes.
Les SRE doivent avoir plus de compétences en génie logiciel. Être capable de diagnostiquer les problèmes et de les transmettre aux bonnes personnes est vital dans leur monde. Bien que les SRE n’aient pas besoin de connaître les détails du déploiement de l’infrastructure, ils doivent savoir comment identifier quand ils rencontrent pour la première fois une latence sur un élément particulier de l’infrastructure cloud et pourquoi.
Comment êtes-vous arrivé là?
Lorsque les gens commencent tout juste leur carrière, ils doivent être flexibles et ne pas avoir une voix forte lorsqu’ils rejoignent une nouvelle organisation. Ce qu’ils savent et comment ils peuvent le démontrer détermine leur rôle. Soit ils sont experts en ingénierie de plate-forme et savent comment créer des plates-formes cloud, soit ils savent comment surveiller l’expérience utilisateur. Si votre expérience était en tant qu’administrateur système, DevOps est probablement mieux adapté. C’est une progression naturelle de la configuration de vos machines virtuelles Linux à l’automatisation du processus. D’un autre côté, si vous cherchez à mettre de l’ordre dans le chaos, SRE est probablement la voie que vous souhaitez emprunter.
quels sont leurs mauvais jours
Qu’est-ce qu’un mauvais jour pour DevOps ou SRE ? Pour un SRE, c’est feu après feu après feu. Surtout dans les grandes organisations, les SRE sont souvent la première ligne de défense. Vous êtes sur appel. Ils font le tri. Ils font reculer les choses et font tout ce qu’ils ont à faire pour que le service fonctionne à nouveau. Quand tout est en feu et que vous ne savez même pas à qui vous adresser, c’est une mauvaise journée pour l’équipe SRE.
Une mauvaise journée pour DevOps est lorsque Jenkins est en panne et que les pipelines DevOps ne fonctionnent pas. Quelqu’un publie un nouveau changement ou une nouvelle migration, puis se rend compte qu’un service critique dans le chemin n’a pas encore migré, et donc cette équipe crie sur DevOps. Lorsque les équipes d’ingénierie ne peuvent pas faire leur travail en raison de mesures DevOps dans le cadre d’un processus de migration, c’est une très mauvaise journée.
Quels sont vos grands jours ?
La meilleure chose qui puisse arriver à un SRE est la reconnaissance de sa valeur commerciale pure. Lorsque le patron de quelqu’un dit : « D’accord, nous avons économisé 5 millions de dollars en heures de travail ce trimestre, car nous avons eu 70 % de pannes en moins et 50 % de nos pannes ont été automatiquement corrigées grâce aux runbooks que nous avons mis en place », c’est une bonne journée pour un SRE.
Un grand jour pour DevOps est un jour de silence. Quand les gens déploient leur infrastructure, déploient des choses et que tout fonctionne comme il se doit, c’est une bonne journée. Lorsque les gens peuvent faire ce qu’ils doivent faire, que les pipelines fonctionnent et que tout est une machine rationalisée qui tourne en rond, c’est une bonne journée pour un ingénieur DevOps.
Une valeur ajoutée au quotidien
Des centaines, voire des milliers, de nouveaux rôles, termes, acronymes, plates-formes et organisations ont vu le jour ces dernières années, tous poursuivant le même objectif : l’excellence et la rapidité de la livraison de logiciels. Le terme DevOps, inventé il y a plus de dix ans, signifie quelque chose de très différent aujourd’hui qu’à l’époque. L’ingénierie de la fiabilité des sites, un rôle plus récent mais qui évolue tout aussi rapidement, gagne du terrain. Indépendamment de la façon dont ils se croisent et divergent, et de la façon dont cela change au sein d’une même entreprise (et c’est le cas), ces deux rôles sont au cœur du cycle de vie des logiciels de leurs organisations et deviennent de plus en plus précieux et stratégiques à mesure que le temps et la production avancent.
Le message Where DevOps and Site Reliability Engineers Intersect and Differ est apparu en premier sur Germanic News.