Site Reliability Engineering #1 Implements DevOps

Site Reliabitlity Engineering or DevOps

Nous sommes ici pour régler les choses une fois pour toutes : déterminer le vainqueur entre DevOps et Site reliability Engineering (SRE).

Naviguer vers les autres articles du dossier :

• #2 Niveaux de service >> Lire l’article >
• #3 Risque et budget d’erreur >> Lire l’article >
• #4 Allez plus loin dans le SRE >> Lire l’article >

SRE VS DevOps

Pour commencer, il faut se souvenir que, par le passé, les opérateurs et les développeurs étaient nombreux à se disputer. En fait, les développeurs jetaient leur code aux opérateurs qui étaient responsables du maintien de ce code en production. Toutefois, d’un côté les opérateurs avaient peu de compréhension des bases de code. D’un autre côté, les développeurs avaient peu de compréhension des pratiques opérationnelles. Au fond, les développeurs, responsables des fonctionnalités, étaient préoccupés par la livraison du code et les opérateurs étaient préoccupés par la fiabilité. Cela signifie que les développeurs voulaient aller plus vite pour sortir leurs fonctionnalités plus rapidement, et les opérateurs voulaient aller plus lentement pour maintenir la stabilité des choses. Ce désalignement, forcément, provoque des tensions.

Qu’est-ce qu’apporte le DevOps ?

Globalement, le DevOps est un ensemble de pratiques et une culture conçue pour éliminer les barrières entre les développeurs, les opérateurs et les autres parties de l’entreprise. Il se décompose en cinq domaines clés :

1. La réduction des silos organisationnels : en supprimant les barrières entre les équipes, il accroît la collaboration et la rigueur ;
2. L’intégration des échecs au process : les ordinateurs sont intrinsèquement peu fiables et lorsque nous introduisons le facteur humain dans le système, nous obtenons encore plus d’imperfections ; l’erreur n’est pas anormale ;
3. La mise en œuvre progressive des changements car les petits changements incrémentiels sont plus faciles à examiner. De plus, cela nous permet aussi de réduire le temps moyen de retour en arrière en cas de problème ;
4. Les outils de l’automatisation : automatiser un maximum des tâches répétitives ou sans valeur ajoutée ;
5. La mesure : mesurer est un acte essentiel du succès, et sans un moyen de mesure, même si les quatre premiers piliers sont efficaces, il n’y aurait aucun moyen de le savoir.

En quoi le SRE est-il différent du DevOps ?

Si le DevOps est une philosophie, le SRE est une manière de mettre en œuvre cette philosophie. Donc si « DevOps » était une interface dans un langage de programmation, on pourrait dire que le SRE est une classe concrète qui implémente DevOps.

En cela, lorsque le DevOps parle d’éliminer les silos organisationnels, le SRE va plus loin. Il propose, par exemple, de partager la propriété de la production avec les développeurs et d’utiliser les mêmes outils afin de garantir que tout le monde ait la même vision et la même approche pour travailler avec la production.

• Lorsque le DevOps parle d’accepter les accidents et les échecs comme étant normaux, le SRE proposera d’effectuer des analyses post-mortem. Ainsi, il s’assurera que les échecs ne se reproduisent pas deux fois de la même manière. Le budget d’erreur indique dans quelle mesure le système est autorisé à sortir des spécifications.
• Quand le DevOps envisage d’apporter des changements fragiles, le SRE voudra déployer auparavant sur un petit pourcentage du parc avant de généraliser à l’ensemble.
• Le DevOps doit tirer parti de l’outillage et de l’automatisation, le SRE mesurera la quantité de travail accompli, pour identifier le travail manuel, puis il essayera d’automatiser ces tâches.
• Si le DevOps a besoin de mesurer, le SRE pense à mesurer la quantité de travail, la fiabilité et la santé des systèmes.

En somme, il s’avère que DevOps et SRE ne sont pas deux méthodes concurrentes. Plutôt, elles sont des amies proches conçus pour aider à éliminer les barrières organisationnelles afin de fournir plus rapidement de meilleurs logiciels.

Maintenant, plongeons un peu plus dans la notion de mesure.