J’ai eu l’occasion de rencontrer Andi Grabner, DevOps Activist chez Dynatrace, lors de la deuxième journée de Dynatrace Perform. Je connais Andi depuis sept ans, et c’est l’une des personnes qui m’a aidé à comprendre DevOps depuis que j’ai commencé à écrire pour Développeurweb.com.
Nous avons abordé plusieurs sujets que je partagerai dans une série d’articles.
Comment DevOps et SRE fonctionnent-ils ensemble ?
SRE est le terme lui-même qui vient de Google. Mais essentiellement, c’est l’automatisation que DevOps met en place pour déployer les changements plus rapidement en automatisant le pipeline. SRE consiste à automatiser les aspects opérationnels du logiciel. Et l’automatisation des aspects opérationnels du logiciel signifie qu’en tant que SRE, il y a peut-être cinq ans, vous appeliez simplement ITOps. Maintenant, cela s’appelle SRE, ou Site Reliability Engineering.
Je pense que DevOps et SRE ont évolué pour utiliser l’automatisation et le code pour automatiser quelque chose de manière intelligente et également de manière codifiée. Le code est important car vous pouvez contrôler la source du code. Vous pouvez conserver l’historique de tous vos pipelines. Il en est de même pour SRE. SRE essaie d’utiliser les mêmes choses automatisées par le biais du code pour les aspects opérationnels de votre logiciel.
Par conséquent, SRE et DevOps fonctionnent très bien en tandem. J’ai une diapositive où DevOps et SRE se tiennent la main. Ils se tiennent la main parce qu’en fin de compte, il s’agit d’automatiser la livraison grâce à l’automatisation. SRE se concentre davantage sur l’automatisation de la résilience des éléments issus de DevOps.
Qu’en est-il du décalage vers la gauche par rapport au décalage vers la droite ? Est-ce un « Et » ou est-ce « Et/Ou ? »
C’est un « et ». Le décalage vers la gauche consiste vraiment à réfléchir plus tôt à toutes ces contraintes, à la manière dont nous traitons l’observabilité et à encourager les développeurs à réfléchir au type de données dont ils ont besoin pour déterminer si le système est sain.
Les traces, les journaux et le démarrage des tests plus tôt constituent le déplacement classique vers la gauche. Décaler vers la droite consiste à savoir comment fonctionne mon système. C’est comme connaître la fréquence cardiaque de mon système, comme mon temps de réponse. En développement, le décalage vers la droite signifie que je veux m’assurer que l’équipe SRE qui est responsable de l’exécution de mon logiciel, le décalage temporel, c’est ainsi que vous l’exécutez, c’est ce que je veux voir du point de vue de l’observabilité, et ce sont mes seuils . Si ces conditions ne sont pas remplies, je souhaite que vous exécutiez ces actions du point de vue des performances, de la disponibilité et de la fiabilité.
Je pense que nous avons toujours eu la division classique Dev et Ops. Le développement construirait quelque chose et le jetterait par-dessus le mur. Ensuite, les opérations ont dû déterminer comment l’exécuter correctement, comment le mettre à l’échelle et comment contrôler la capacité.
Maintenant, nous disons que nous devons examiner tous ces aspects beaucoup plus tôt. Nous devons comprendre dès le départ comment nous appliquons l’observabilité dans le développement, pas seulement dans les opérations. C’est pourquoi nous définissons l’observabilité, pour la tester.
Nous prenons tous ces ingrédients et identifions ce que nous allons observer. Observons-le également en production. Nous connaissons les seuils. Nous savons ce qui rend notre système sain. Assurons-nous également de valider cela en production. Nous savons si quelque chose échoue dans les tests, que faisons-nous pour ramener le système à un état idéal. Codifions cela également en production pour ramener le système de manière automatisée. C’est ma définition du déplacement vers la droite.