Principes SRE : les 7 règles fondamentales

Principes du SRE

Dans l’un de nos articles précédents,nous avons discuté de ce qu’est un SRE, de ce qu’il fait et de certaines des responsabilités communes qu’un SRE typique peut avoir, comme le soutien des opérations, la gestion des tickets d’incident et de la réponse aux incidents, ainsi que la surveillance et l’observabilité générales du système. Dans cet article, nous approfondirons les différents principes et directives SRE qu’un ingénieur en fiabilité de site pratique dans son rôle. Comme DevOps, ces principes SRE servent de guide pour favoriser l’alignement en ce qui concerne l’alignement, la réalisation et le soutien des objectifs de l’organisation.

Google a été la première entreprise à créer, adopter et mettre en avant le rôle de l’ingénierie de la fiabilité des sites. Depuis lors, le rôle du SRE a évolué à mesure que l’industrie a changé et est passée des structures monolithiques traditionnelles à de grands réseaux et microservices largement distribués. Cependant, une chose est restée en grande partie la même : les principes auxquels adhèrent les SAR. Ces principes fondamentaux du SRE sont axés sur une chose : la fiabilité du système de conduite et du service. Approfondissons ces principes fondamentaux du SRE.

 

Principes SRE

 

Adopter et gérer les risques

L’acceptation du risque est le premier des principes du SRE, et pour une bonne raison. Afin d’améliorer la fiabilité d’un système, il est important d’évaluer l’impact des défaillances « et si ». Il est entendu qu’aucun système n’est fiable à 100%. À un moment donné, quelque chose va mal tourner. Malheureusement, l’utilisateur ou le client de tous les jours ne sait pas, ou ne se soucie pas, d’être aussi compréhensif. Et il y a un coût inhérent associé à la fiabilité. Qu’il s’agisse d’un coût financier, d’un coût de temps ou simplement de la confiance d’un client dans vos services.

Une responsabilité de SRE est de s’appuyer sur l’échec et le risque afin d’apprendre comment ils peuvent finalement rendre leurs services et systèmes plus résilients. Cependant, il y a des compromis qui doivent être pris en compte. Par exemple, assurer une fiabilité maximale peut se faire au détriment de la possibilité de déployer plus rapidement les futurs services. Ou peut-être que d’autres améliorations ne signifient pas nécessairement un gain substantiel de revenus? L’objectif est de créer un système fiable, mais pas plus qu’il ne doit l’être, car le coût et le temps associés à cela l’emportent sur les avantages potentiels.

 

Objectifs de niveau de service

Le principe de l’acceptation du risque est étroitement lié aux objets de niveau de service, ou SPO. Pour aller un peu plus loin, les SRO sont l’ensemble formel d’objectifs au sein d’un contrat de niveau de service (SLA) qui sont mesurés par rapport aux indicateurs de niveau de service, ou SBI. Les SWI sont les mesures de performance réelles de vos services. Par exemple, si votre SLO indique que votre temps de disponibilité doit être de 99,9 %, le SLI réel doit atteindre ou dépasser cette mesure de performance afin de respecter ce SLO spécifique. Les SWI sont les indicateurs qu’un SRE surveillerait en permanence, de sorte que s’il sort de ce seuil, les équipes sont alertées et le problème peut être résolu rapidement. Les SWI sont vraiment liés à l’utilisateur pour déterminer ce qui est le plus important pour son expérience en ce qui concerne le service.

 

SLA vs SRO vs SWI

  • SLA. Accords conclus avec vos clients ou des clients qui définissent le niveau de service qui va être fourni.
  • SRO. Un accord au sein du SLA qui énonce des mesures spécifiques, telles que la disponibilité, le temps de réponse, la sécurité, la résolution des problèmes, etc.
  • SWI. Les performances réelles, ou les mesures, de vos STO qui déterminent le niveau de conformité.

 

Les STO mesuraient les performances réelles par rapport aux SLA, qui sont les accords entre un fournisseur de services et le client. Encore une fois, tout cela nous ramène à l’idée qu’il faut un accord ou une compréhension du niveau de risque, ou de tolérance, qui peut être autorisé pour un service donné.

Lire: En savoir plus sur la gestion de la conformité aux SLA au sein de votre organisation.

 

Éliminer le labeur

Le labeur, tel qu’il est défini avec la portée du rôle SRE, est la quantité de travail manuel nécessaire pour s’assurer que les services sont en cours d’exécution. L’un des principaux objectifs d’un SRE est d’automatiser autant de travail que possible. Cela permet aux SAR d’ouvrir plus de temps pour des tâches plus importantes. Et quand on y pense, réduire le labeur devrait vraiment faire partie du travail de n’importe qui. Moins de temps nécessaire sur les tâches redondantes garantit une meilleure productivité à long terme. Chaque fois qu’un ingénieur en fiabilité de site doit s’engager dans des activités manuelles répétitives, en ce qui concerne la gestion du service de production, cela peut être décrit comme du labeur.

Dans de nombreux cas, il peut arriver qu’un SRE doive effectuer des activités manuelles et chronophages, mais toutes ne doivent pas être définies comme du labeur. Cependant, il est essentiel de définir quelles activités au sein de l’équipe SRE prennent le plus de temps. À partir de là, identifiez où des améliorations peuvent être apportées pour réduire la quantité de travail pour un meilleur équilibre du travail. Lorsque Google a introduit pour la première fois le rôle de SRE, ils se sont fixé pour objectif que la moitié du temps d’un SRE soit axée sur la réduction du travail opérationnel futur ou l’ajout de fonctionnalités de service. Le développement de nouvelles fonctionnalités est en corrélation avec l’amélioration de mesures telles que la fiabilité et les performances, ce qui réduit en fin de compte le labeur potentiel sur la ligne.

 

Surveillance

Chez Dotcom-Monitor, nous nous intétressons aux solutions de surveillance pour le suivi de la disponibilité, de la disponibilité, des fonctionnalités et des performances complètes des serveurs, des sites Web, des services et des applications. La surveillance est l’un des principes les plus importants du SRE dans le rôle. La surveillance continue garantit que les services fonctionnent comme prévu et peut aider à identifier le moment où les problèmes surviennent afin qu’ils puissent être résolus immédiatement. Comme nous l’avons mentionné dans la section précédente, le respect de ces SCO est la clé des SLA métier définis et, en fin de compte, des utilisateurs. La surveillance peut fournir aux SAR et aux équipes une tendance historique des performances et peut donner un aperçu de ce qui est un problème ponctuel par rapport à un problème systémique plus large. Comme défini par l’initiative Google SRE, les quatre signaux d’or de la surveillance comprennent les mesures suivantes:

 

  • Latence. La latence est le temps, ou le délai, qu’un service prend pour répondre à une demande. De toute évidence, des temps de réponse lents affecteront l’expérience utilisateur perçue. La surveillance peut fournir un moyen de différencier
  • Trafic. Le trafic fait référence à la quantité de demande de l’utilisateur, ou charge, sur le système. Cela peut être mesuré par des requêtes HTTP par seconde ou en fonction du service réel
  • Erreurs. Les erreurs font référence à la vitesse à laquelle les demandes adressées au service échouent. Cependant, il est important pour les équipes SRE de faire la différence entre les pannes techniques, telles que les erreurs de serveur 500, et les défaillances logicielles, telles qu’une réponse 200 OK qui a dépassé parce qu’un seuil de performance spécifique a été défini. Il est important de réfléchir à la façon de surveiller de manière appropriée ces différents scénarios comme ceux-ci.
  • Saturation. La saturation consiste à mesurer la quantité de ressources système d’un service donné. Jusqu’à un certain point, la plupart des services connaîtront une dégradation des performances. Comprendre où cela se produit peut aider à définir correctement les objectifs et les cibles de surveillance, afin que des mesures correctives puissent être effectuées.

 

Automatisation

Automatiser, automatiser, automatiser. Nous avons abordé ce principe plus tôt lorsque nous avons discuté de la réduction du labeur, mais on ne peut le sous-estimer. La nature du rôle du SRE est aussi diversifiée qu’un rôle peut l’être. Afin de réduire le potentiel d’intervention manuelle dans toutes les facettes de leurs responsabilités, l’automatisation des tâches est la clé du succès d’une entreprise. À mesure que les services évoluent et deviennent plus distribués, ils deviennent beaucoup plus difficiles à gérer. L’automatisation des tâches répétitives à tous les niveaux, qu’il s’agisse de tests, de déploiement de logiciels, de réponse aux incidents ou simplement de communication entre les équipes, l’automatisation offre des avantages immédiats, une efficacité et, surtout, une cohérence. Depuis la conception du rôle SRE, il y a eu un changement dans la façon dont les équipes de développement, d’assurance qualité et d’opérations collaborent. Pour soutenir ces nouveaux environnements et pratiques DevOps, diverses plateformes et outils ont été développés.

Lire: Top 13 des outils de fiabilité de site (SRE).

 

Ingénierie des versions

Ingénierie de publication. Cela semble être un sujet complexe, mais en réalité, ce n’est qu’un moyen simple de définir comment les logiciels sont construits et livrés. Bien que l’ingénierie de publication en soi soit son propre titre et son propre rôle, dans le concept de SRE, cela signifie fournir des services stables, cohérents et, bien sûr, reproductibles. Cela nous ramène à la section précédente sur l’automatisation. Si vous voulez faire quelque chose, faites-le bien ET soyez capable de le répéter à nouveau, de manière cohérente, si nécessaire. La création d’un tas de services ponctuels prend beaucoup de temps et crée un labeur inutile.

Si nous revenons à l’histoire du poste de SRE chez Google, ils avaient des ingénieurs de publication dédiés qui travaillaient directement avec les SRE. Les ingénieurs de publication sont généralement chargés de définir les meilleures pratiques en matière de développement de services logiciels, de déploiement de mises à jour, de tests continus et de résolution des problèmes logiciels, en plus de nombreuses autres responsabilités. Ce rôle devient plus critique lorsque vous réfléchissez à la façon de mettre à l’échelle les services et de les déployer rapidement. Disposer d’un ensemble de meilleures pratiques et d’outils (et les appliquer) est essentiel pour pouvoir répondre à ces demandes et donner la tranquillité d’esprit aux équipes SRE une fois que cette version est mise en production.

 

Simplicité

Avec un poste qui n’a apparemment pas de fin au nombre de responsabilités et d’attentes comme le rôle de SRE, le dernier principe, ironiquement, est la simplicité. Peut-être plus facile à dire qu’à faire dans la pratique, ce principe se concentre sur l’idée de développer un système ou un service qui est seulement aussi complexe que nécessaire. Bien que cela puisse sembler contre-intuitif au début, cela revient vraiment à vouloir un système fiable, cohérent et prévisible. Cela peut sembler ennuyeux, mais pour un SRE, c’est l’un des objectifs finaux ultimes.

Les SLA s’efforcent d’obtenir un système ou un service qui n’est pas complexe ou difficile à gérer. Les SRE en veulent un qui fait simplement le travail pour lequel il a été conçu. Cependant, du point de vue de l’utilisateur, un service qui fournit de nombreuses fonctionnalités peut également offrir de nombreux avantages, mais pour un SRE, cela signifie simplement plus de maux de tête potentiels. Cependant, le changement est toujours inévitable si vous souhaitez ajouter de nouvelles fonctionnalités à un service Web, faites-le de manière réfléchie. Les modifications incrémentielles plus petites sont plus faciles (et plus simples) à gérer que la création et l’expédition de nombreuses fonctionnalités en même temps. Les SSR doivent également tenir compte des besoins et des objectifs de l’entreprise.

 

Principes SRE: Les 7 règles fondamentales – Réflexions finales

Le rôle de SRE se concentre sur la construction, la livraison et le maintien de systèmes et de services fiables à grande échelle. Ces sept principes fondamentaux aident à définir les pratiques pour les SAR qui aident à l’alignement au sein des pratiques DevOps et soutiennent les objectifs de l’entreprise. Il s’agit d’un rôle complexe qui cherche à équilibrer la fiabilité avec les versions de fonctionnalités, tout en maintenant des niveaux de qualité exceptionnels.

La plate-forme Dotcom-Monitor fournit aux SRE toutes les fonctionnalités de surveillance dont ils ont besoin pour assurer la continuité de leurs services. Des alertes et rapports configurables aux tableaux de bord et rapports en temps réel, la plateforme fournit les outils essentiels nécessaires pour gérer les performances de tous ses services à long terme. Par exemple, créez des scripts d’application Web basés sur le comportement, les actions et les chemins d’accès des utilisateurs et configurez des tâches de surveillance synthétiques pour garantir une expérience cohérente au fil du temps. Quel que soit le niveau de surveillance dont votre équipe a besoin, il existe une solution pour répondre à vos besoins.

Commencez gratuitement avec l’essai de 30 jours de Dotcom-Monitor ou planifiez une démonstration avec l’un de nos ingénieurs de performance.

 

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email
Share on print
Print