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
Accepter le risque est en fait l’un des principes fondamentaux de l’ERS, et il est facile de comprendre pourquoi. Pour rendre un système plus fiable, vous devez envisager des scénarios de simulation et tirer des leçons des défaillances potentielles. Aucun système n’est jamais fiable à 100% et à un moment donné, quelque chose est voué à mal tourner. Malheureusement, la plupart des utilisateurs ne connaissent pas (ou ne s’en soucient pas particulièrement) de cette réalité. Ils veulent juste que les choses fonctionnent, et il y a toujours un coût pour atteindre cette fiabilité, que ce soit en argent, en temps ou même en maintien de la confiance des clients.
Pour les SRE, il est essentiel de s’appuyer sur le risque et d’apprendre de l’échec pour construire des systèmes résilients. Mais il y a toujours des compromis à peser. L’optimisation de la fiabilité peut signifier ralentir le rythme des nouvelles fonctionnalités, ou entraîner une augmentation des coûts sans beaucoup d’augmentation des revenus. L’idée n’est pas de rendre un système plus fiable qu’il ne doit l’être. Après tout, si les efforts et les ressources supplémentaires n’apportent pas de valeur ajoutée, il vaut mieux les dépenser ailleurs. Dans le SRE, il s’agit de trouver le niveau de fiabilité « juste » qui équilibre le coût, la vitesse et la valeur.
Objectifs de niveau de service
Le principe de l’acceptation du risque est étroitement lié aux objectifs de niveau de service (SLO). Pour décomposer, les SLO sont des objectifs de performance spécifiques dans le cadre d’un accord de niveau de service (SLA) qui sont mesurés par rapport aux indicateurs de niveau de service (SLI), les mesures réelles qui suivent les performances de votre service. Par exemple, si votre SLO indique que le temps de disponibilité doit être de 99,9 %, il mesure si vous atteignez cette marque. Ces SLI sont surveillés en permanence par les SRE, de sorte que si les performances descendent en dessous du seuil convenu, l’équipe est alertée et peut réagir rapidement. En fin de compte, les SLI concernent ce qui compte le plus pour les utilisateurs, en aidant les équipes à hiérarchiser les aspects du service qui ont un impact direct sur l’expérience utilisateur.
Voici un bref aperçu de ces termes :
- SLA : Les accords globaux avec les clients ou les clients sur le niveau de service à fournir.
- SLO : objectifs de performance spécifiques au sein du SLA, tels que le temps de disponibilité, le temps de réponse ou les normes de sécurité.
- SLI : Les mesures de performance réelles qui permettent de suivre la conformité aux SLO.
En substance, les SLO permettent aux équipes de mesurer les performances réelles par rapport au SLA, en définissant des attentes claires en matière de qualité de service. Cette structure renforce l’existence d’une tolérance au risque convenue, définissant le degré de variabilité ou de temps d’arrêt qu’un service peut supporter tout en répondant aux besoins des utilisateurs et aux objectifs commerciaux.
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 gratuit de Dotcom-Monitor ou planifiez une démo avec l’un de nos ingénieurs de performance.
