Notre équipe adore les expériences. Chaque Slurm n’est pas une répétition statique des précédents, mais une réflexion sur l’expérience et une transition du bien au mieux. Mais avec nous avons décidé d'appliquer un tout nouveau format - pour offrir aux participants des conditions aussi proches que possible du « combat ».
Si l'on décrit brièvement ce que nous avons fait pendant le cours intensif : « On construit, on casse, on répare,
nous étudions." Le SRE ne vaut pas grand-chose en pure théorie : seulement de la pratique, de vraies solutions, de vrais problèmes.
Les participants ont été répartis en équipes afin qu'un esprit de compétition vigoureux ne permette à personne de s'endormir ou de lancer « Angry Birds » sur iPhone, à l'instar de Dmitry Anatolyevich.
Les problèmes, problèmes, bugs et tâches ont été fournis aux participants par quatre mentors. Ivan Kruglov, développeur principal chez Booking.com (Pays-Bas). Ben Tyler, développeur principal chez Booking.com (USA). Eduard Medvedev, CTO chez Tungsten Labs (Allemagne). Evgeniy Varavva, développeur général chez Google (San Francisco).
De plus, les participants sont répartis en équipes et s'affrontent. Intéressant?
Ivan, Ben, Eduard et Evgeniy regardent les pauvres participants du Slurm SRE avec de gentils regards léninistes avant le début de la compétition.
Donc la tâche :
Nous sommes à nous, nous allons construire un nouveau monde ...
Il existe un site Web d'agrégation de billets de cinéma. Les incidents sont inventés par des mentors dans un scénario pré-travaillé (même si personne n'exclut une improvisation particulièrement sophistiquée et insidieuse), la performance du site est décrite par diverses métriques. Les problèmes peuvent être très différents : les billets du théâtre du Moulin Rouge ne sont pas chargés dans la base de données ; les affiches de films et de spectacles sont chargées dans la base de données en plus de 10 secondes ; la description d'un film individuel se fige ; 0,1% des commandes sont déjà réservées ; De temps en temps, le système de traitement des paiements plante pendant une minute ou deux. Et beaucoup, beaucoup, beaucoup de choses désagréables qui peuvent arriver à un participant au Slurm SRE dans son vrai travail.
Nous sommes prêts à tout affronter... et à tout le monde.
Notre site Web qui souffre depuis longtemps se compose de plusieurs microservices. Sa tâche est de regrouper les données sur les spectacles, les prix et les places disponibles dans tous les cinémas ; il affiche les annonces de films, permet de sélectionner un cinéma, un spectacle, une salle et un lieu, de réserver et de payer les billets. En général, tout ce dont le spectateur ne peut que rêver. Mais l'utilisateur ne se doute même pas de la lutte titanesque qui se déroule à l'intérieur pour la stabilité et l'accessibilité du site.
Pour le site intensif, nous avons généré des indicateurs SLO, SLI, SLA, développé l'architecture et l'infrastructure, déployé le site, mis en place la surveillance et les alertes. Et c'est parti.
SLO, SLI, SLA
SLI - indicateurs de niveau de service. Les SLO sont des objectifs de niveau de service. SLA - accords de niveau de service.
SLA est un terme méthodologique ITIL qui désigne un accord formel entre le client d'un service et son fournisseur, contenant une description du service, les droits et obligations des parties et, surtout, le niveau de qualité convenu pour la fourniture de ce service. service.
Un SLO est un objectif de niveau de service : une valeur cible ou une plage de valeurs pour un niveau de service qui est mesurée par le SLI. Une valeur normale pour SLO est « SLI ≤ Target » ou « Lower Limit ≤ SLI ≤ Upper Limit ».
Le SLI est un indicateur de niveau de service, une mesure quantitative soigneusement définie d'un aspect du niveau de service fourni. Pour la plupart des services, la clé SLI est considérée comme la latence de la demande, c'est-à-dire le temps nécessaire pour renvoyer une réponse à une demande. D'autres SLI courants incluent le taux d'erreur, souvent exprimé en fraction de toutes les requêtes reçues, et le débit du système, généralement mesuré en requêtes par seconde.
Tout d'abord, nous briserons les avions, puis les filles, et ensuite les filles...
Des facteurs internes et externes ont commencé à « gâcher » SLO dès les premières minutes. Tout est tombé sur la tête des administrateurs : erreurs des développeurs, pannes d’infrastructure, afflux de visiteurs et attaques DDoS. Tout ce qui aggrave le SLO.
"- Chers participants, je m'empresse de vous faire plaisir, la première chose que vous échouez, c'est... tout !"
En cours de route, les intervenants ont discuté de la stabilité, du bilan d'erreurs, des pratiques de test, de la gestion des interruptions et de la charge opérationnelle.
Nous ne sommes ni chauffeurs, ni charpentiers...
Ensuite, les participants ont commencé à réparer les choses - l'essentiel est de comprendre quoi saisir en premier.
« - Seigneur, je ne l'ai jamais vu se briser ainsi, sous cette forme et dans une telle position !
Ainsi, un accident s'est produit. Le service de traitement des paiements est en panne. Comment agir pour restaurer la fonctionnalité dans les plus brefs délais ?
Les experts, regardant affectueusement les participants, préparent un autre tour.
Chaque équipe organise le travail du groupe pour éliminer l'accident - implique les collègues, informe les parties intéressées (parties prenantes). En parallèle, des priorités sont fixées. Les participants se sont ainsi entraînés à travailler sous pression dans des conditions de temps extrêmement limitées.
"Quel genre d'horreur est sorti ?!"
Expirez... et terminez l'exercice
Avec les intervenants, après chaque problème résolu et la stabilisation temporaire du site, l'équipe a étudié les incidents du point de vue SRE. Nous avons analysé les problèmes en détail - les causes de leur apparition, les progrès de leur élimination. Ensuite, équipe par équipe et collectivement, nous avons pris des décisions sur la manière de les prévenir davantage : comment améliorer la surveillance, comment modifier judicieusement l'architecture, comment ajuster l'approche de développement et d'exploitation, comment corriger les réglementations. Les intervenants ont démontré la pratique de la conduite d'autopsies.
« Qui d'autre veut du tourment ! - JE!"
Les succès des équipes étaient strictement et clairement enregistrés sur le tableau d'affichage électronique.
Pour les premières places - un bonus des parties prenantes.
Source: habr.com