What's the Difference Between DevOps and SRE? (class SRE implements DevOps)

Google Cloud Tech
1 Mar 201805:11

Summary

TLDRDans cette vidéo, Liz Fong-Jones, ingénieure en fiabilité des sites chez Google, et Seth Vargo, défenseur des développeurs chez Google, discutent des différences et des similitudes entre DevOps et SRE. Ils expliquent que DevOps vise à briser les silos organisationnels et à améliorer la collaboration entre développeurs et opérateurs, tandis que SRE est une méthode prescriptive pour appliquer cette philosophie. Ils explorent des concepts clés comme la gestion des échecs, l'automatisation, et l'importance de la mesure dans les deux pratiques, montrant que SRE est en fait une implémentation concrète de DevOps.

Takeaways

  • 😀 DevOps et SRE ne sont pas des méthodes concurrentes, mais plutôt complémentaires pour améliorer la collaboration et la fiabilité des logiciels.
  • 😀 DevOps est une philosophie visant à réduire les silos organisationnels et à améliorer la collaboration entre les développeurs et les opérateurs.
  • 😀 Les cinq principes clés du DevOps incluent la réduction des silos, l'acceptation de l'échec comme normal, le changement graduel, l'automatisation des outils et la mesure des performances.
  • 😀 L'approche SRE est un moyen prescriptif d'implémenter les principes DevOps, avec un accent sur la fiabilité et la scalabilité.
  • 😀 La méthode SRE inclut la prise en charge partagée de la production entre les développeurs et les opérateurs, facilitée par un outillage commun.
  • 😀 Dans le cadre de SRE, l'acceptation des erreurs se fait grâce à des **post-mortems sans culpabilité** et des **budgets d'erreurs** qui fixent un seuil acceptable pour les défaillances.
  • 😀 Le déploiement graduel des changements est une autre pratique clé de SRE, qui utilise des **déploiements canari** pour minimiser les risques.
  • 😀 L'élimination du travail manuel (appelé **toil**) est au cœur de SRE, avec l'objectif d'automatiser autant que possible les tâches répétitives.
  • 😀 Les **objectifs de niveau de service (SLOs)**, **indicateurs de niveau de service (SLIs)** et **accords de niveau de service (SLAs)** sont utilisés pour mesurer la fiabilité des systèmes dans SRE.
  • 😀 DevOps et SRE partagent une approche basée sur l'amélioration continue, mais SRE fournit des méthodes spécifiques pour assurer la stabilité tout en permettant des améliorations fréquentes et rapides.

Q & A

  • Qu'est-ce que le DevOps et pourquoi est-ce important ?

    -Le DevOps est une philosophie et un ensemble de pratiques visant à briser les silos entre les équipes de développement et d'exploitation. Cela permet d'améliorer la collaboration et l'efficacité, tout en garantissant des livraisons logicielles rapides et fiables.

  • Quels sont les cinq principes clés du DevOps mentionnés par Seth ?

    -Les cinq principes clés du DevOps sont : (1) réduire le silence organisationnel, (2) accepter les échecs comme normaux, (3) mettre en œuvre des changements progressifs, (4) utiliser l'automatisation et les outils, et (5) mesurer tout.

  • Pourquoi les échecs sont-ils considérés comme normaux dans la pratique du DevOps ?

    -Les systèmes informatiques sont intrinsèquement peu fiables, et l'introduction des humains dans le système entraîne encore plus d'imperfections. Accepter les échecs permet d'apprendre de ces erreurs et d'améliorer continuellement les systèmes.

  • Comment le SRE (Site Reliability Engineering) se distingue-t-il du DevOps ?

    -Le SRE peut être vu comme une implémentation plus spécifique et prescriptive du DevOps. Tandis que le DevOps est une philosophie, le SRE fournit des pratiques et des outils concrets pour atteindre les objectifs du DevOps, comme le partage de la responsabilité de la production et l'automatisation du travail manuel.

  • Qu'est-ce qu'un budget d'erreurs (error budget) et pourquoi est-il important dans le SRE ?

    -Un budget d'erreurs est une métrique définissant la quantité d'indisponibilité ou de dysfonctionnement d'un système qu'une organisation est prête à accepter. Cela permet de gérer le compromis entre fiabilité et innovation, en équilibrant les objectifs de performance et les risques d'échec.

  • Qu'est-ce qu'un déploiement 'canari' et comment est-il utilisé dans le SRE ?

    -Un déploiement 'canari' consiste à déployer une modification dans un petit sous-ensemble d'utilisateurs ou de serveurs avant de la rendre disponible à l'ensemble du système. Cela permet de tester les changements avec un risque minimal et de détecter les problèmes tôt.

  • Quelle est la signification des post-mortems sans reproche (blameless postmortems) dans le SRE ?

    -Les post-mortems sans reproche sont des revues après un échec où l'objectif est de comprendre pourquoi une défaillance s'est produite sans accuser les individus. Cela favorise l'apprentissage collectif et améliore les processus sans créer une culture de peur.

  • Comment le SRE mesure-t-il la fiabilité d'un système ?

    -Le SRE utilise des indicateurs de niveau de service (SLI), des objectifs de niveau de service (SLO) et des accords de niveau de service (SLA) pour mesurer la fiabilité d'un système. Ces métriques permettent de définir des attentes claires et de surveiller la performance.

  • En quoi le SRE se concentre-t-il sur la réduction du 'toil' et pourquoi est-ce crucial ?

    -Le 'toil' fait référence au travail manuel et répétitif qui n'ajoute pas de valeur à long terme. Le SRE cherche à automatiser ce travail afin de libérer du temps pour des tâches à plus forte valeur ajoutée, améliorant ainsi l'efficacité des équipes.

  • Pourquoi Liz Fong-Jones considère-t-elle que le SRE implémente le DevOps de manière concrète ?

    -Liz explique que le SRE fournit des méthodes pratiques et spécifiques pour appliquer les principes du DevOps, comme la gestion des échecs, l'automatisation, et la mesure de la fiabilité. Elle compare le DevOps à une interface et le SRE à une classe qui l'implémente, apportant des solutions pratiques aux principes abstraits du DevOps.

Outlines

plate

هذا القسم متوفر فقط للمشتركين. يرجى الترقية للوصول إلى هذه الميزة.

قم بالترقية الآن

Mindmap

plate

هذا القسم متوفر فقط للمشتركين. يرجى الترقية للوصول إلى هذه الميزة.

قم بالترقية الآن

Keywords

plate

هذا القسم متوفر فقط للمشتركين. يرجى الترقية للوصول إلى هذه الميزة.

قم بالترقية الآن

Highlights

plate

هذا القسم متوفر فقط للمشتركين. يرجى الترقية للوصول إلى هذه الميزة.

قم بالترقية الآن

Transcripts

plate

هذا القسم متوفر فقط للمشتركين. يرجى الترقية للوصول إلى هذه الميزة.

قم بالترقية الآن
Rate This

5.0 / 5 (0 votes)

الوسوم ذات الصلة
DevOpsSREFiabilitéCollaborationGoogleServices logicielsCulture DevOpsAutomatisationErreurs acceptéesChangement graduelPost-mortems sans blâme
هل تحتاج إلى تلخيص باللغة الإنجليزية؟