Site Reliability Engineering #4 Plus loin dans le SRE

Naviguer vers les autres articles du dossier :

• #1 Implements DevOps >> Lire l’article >
• #2 Niveaux de service >> Lire l’article >
• #3 Risque et budget d’erreur >> Lire l’article >

Finalement, qui est le vainqueur entre DevOps et SRE ?

L’objectif initial est bien de fiabiliser des systèmes qui doivent être capables d’évoluer. D’un côté le DevOps donne des axes de réponse pour y parvenir. Et de l’autre la notion de SRE, introduite par Google, concrétise les principes de DevOps. Elle n’est pas du tout concurrente de la notion de DevOps. Bien au contraire, avec SLI, SLO, SLA, risque et budget d’erreur, elle apporte un cadre pour mettre en application la plupart des principes DevOps :

1. Réduction des silos organisationnels ? En permettant aux partis de disposer des mêmes définitions de la disponibilité et des mêmes outils de contrôle de la disponibilité ;
2. Intégration des échecs au process ? En créant le budget d’erreur ;
3. Mise en œuvre progressive des changements ? en facilitant les allers-retours entre dev et ops ;
4. Mesures ? En plaçant les indicateurs de niveau de service au centre de la mécanique.

En conclusion, ces éléments permettent déjà de répondre à la question. Pourtant, le SRE ne se résume pas qu’à ça. Pour aller encore plus loin afin de comprendre son impact dans les pratiques, nous pourrions aussi découvrir ses mécaniques au niveau de l’alerting et de l’observabilité dans les systèmes distribués. Cela sera sûrement l’objet d’un autre article, alors, restons connectés !