Slurm SRE. Une expérience continue avec des experts de Booking.com et Google.com.

Notre équipe aime l'expérimentation. Chaque Slërm n'est pas une répétition statique des précédents, mais une réflexion sur l'expérience et un passage de l'excellent à l'exceptionnel. Mais avec le Slërm SRE nous avons décidé d'appliquer un tout nouveau format — donner aux participants des conditions aussi rapprochées que possible de celles du terrain.

Pour résumer, voici ce sur quoi nous avons travaillé lors de l'atelier : «Nous construisons, nous détruisons, nous réparons,
nous étudions». Le SRE ne vaut pas grand-chose en théorie — seule la pratique, des solutions réelles, des problèmes réels comptent.

Les participants ont été divisés en équipes, afin que l'esprit compétitif dynamique n'endorme personne ou n'incite pas à lancer «Angry Birds» sur l'iPhone, à l'exemple de Dmitry Anatolyevich.

Les problèmes, les bogues, les bugs et les tâches étaient fournis par quatre mentors. Ivan Kruglou, Développeur principal chez Booking.com (Pays-Bas). Ben Tyler, Développeur principal chez Booking.com (États-Unis). Édouard Medvedev, CTO chez Tungsten Labs (Allemagne). Evgueni Varavva, Développeur généraliste chez Google (San Francisco).

Et en plus, les participants sont divisés en équipes — et s'affrontent les uns les autres. Intéressant ?

Ivan, Ben, Édouard et Evgueni, avec un regard bienveillant à la manière de Lénine, observent les malheureux participants du Slërm SRE avant le début de la compétition.

Alors voici la tâche :

Nous bâtissons notre, notre nouveau monde...

Il y a un site d'agrégation de billets de cinéma. Les incidents sont imaginés par les mentors dans un scénario préétabli (bien que personne n'exclut une improvisation particulièrement raffinée et sournoise), la fonctionnalité du site est décrite par différentes métriques. Les problèmes peuvent être très variés : les billets du théâtre «Moulin Rouge» ne se chargent pas dans la base ; les affiches de films et de spectacles se chargent dans la base en plus de 10 secondes ; la description d'un film particulier se fige ; 0,1% des commandes se retrouvent déjà sur des places réservées ; le système de traitement des paiements plante périodiquement pendant une ou deux minutes. Et tant d'autres désagréments qui peuvent s'abattre sur un participant du Slërm SRE dans son travail réel.

Nous sommes prêts à faire face à tout... et à tous.

Notre site en difficulté est composé de plusieurs microservices. Sa mission est d'agréger des données sur les séances, les prix et les disponibilités de tous les cinémas, de montrer des aperçus de films, de permettre de choisir le cinéma, la séance, la salle et la place, de réserver et de payer les billets. En somme, tout ce dont le spectateur peut rêver. Cependant, l'utilisateur n'a même pas conscience de la lutte titanesque qui se déroule en interne pour assurer la stabilité et la disponibilité du site.

Pour le site de l'intensif, nous avons défini des indicateurs SLO, SLI, SLA, développé l'architecture et l'infrastructure, déployé le site, et configuré la surveillance et les alertes. Cela a été un vrai départ.

SLO, SLI, SLA

SLI — indicateurs de niveau de service. SLO — objectifs de niveau de service. SLA — accords de niveau de service.

SLA est un terme de la méthodologie ITIL désignant un contrat formel entre le client du service et son fournisseur, contenant une description du service, les droits et obligations des parties, et surtout, le niveau de qualité convenu pour la prestation de ce service.

SLO est un objectif de niveau de service : une valeur cible ou une plage de valeurs pour le niveau de service, mesurée par SLI. La valeur normale pour SLO est « SLI ≤ valeur cible » ou « limite inférieure ≤ SLI ≤ limite supérieure ».

SLI est un indicateur de niveau de service — une mesure quantitative soigneusement définie d'un des aspects du niveau de service fourni. Pour la plupart des services, le SLI clé est le temps de réponse — combien de temps il faut pour renvoyer une réponse à une demande. D'autres SLI courants incluent le taux d'erreurs, souvent exprimé comme une part de toutes les demandes reçues, et la capacité du système, généralement mesurée en requêtes par seconde.

Tout d'abord, nous allons faire tomber des avions, et pour les filles, eh bien, pour les filles, ce sera plus tard...

Des facteurs internes et externes ont commencé à « dégrader » le SLO dès les premières minutes. Tout est tombé sur la tête des administrateurs : des erreurs de développeurs, des pannes d'infrastructure, une affluence de visiteurs et des attaques DDoS. Tout ce qui nuit au SLO.

« - Chers participants, je suis heureux de vous annoncer, en premier lieu, que tout... tombe ! »

Au fil de la présentation, les intervenants ont abordé la résilience, le budget d'erreurs, les pratiques de test, la gestion des interruptions et la charge opérationnelle.

Nous ne sommes pas des chauffeurs, ni des charpentiers...

Ici, les participants ont commencé à réparer — l'essentiel est de comprendre par où commencer en premier.

«- Mon Dieu, je n'ai jamais vu quelque chose se casser ainsi, dans cet état et dans cette position ! »

Donc, un accident s'est produit. Le service de traitement des paiements a échoué. Que faire pour rétablir le bon fonctionnement dans les plus brefs délais ?

Les experts jettent un regard bienveillant sur les participants tout en préparant un nouveau défi.

Chaque équipe organise le travail du groupe pour gérer l'accident — elle mobilise des collègues, informe les parties prenantes. En même temps, les priorités se mettent en place. Ainsi, les participants s'entraînaient à travailler sous pression dans des conditions de temps exceptionnellement limité.

«- Qu'est-ce que c'est que cette horreur qui est sortie ?!»

On a soufflé… et on a terminé l'exercice.

Avec les intervenants, après chaque problème résolu et le site temporairement stabilisé, les équipes ont étudié les incidents du point de vue SRE. Elles ont analysé en détail les problèmes — leurs causes, le déroulement de la résolution. Ensuite, tant au niveau des équipes qu'en collectif, elles ont pris des décisions sur leur prévention future : comment améliorer la surveillance, comment modifier correctement l'architecture, comment ajuster l'approche au développement et à l'exploitation, comment corriger les règlements. Les intervenants ont montré la pratique de la post-mortem.

«- Qui d'autre veut des tourments ! — Moi ! »

Les succès des équipes étaient enregistrés de manière stricte et claire sur le tableau électronique.

Des récompenses offertes par les parties prenantes pour les premières places.

Source : habr.com