Le 21 mai, un cours intensif SRE débutera à Slurme. Pendant trois jours complets, les participants se plongeront dans la théorie et la pratique de la prise en charge des services à forte charge. Aucune tâche de travail, aucune question de famille - juste étudier. Sous la coupe, nous vous disons ce qui vous attend si vous décidez de vous joindre.
Aide SRE
Ingénierie de la fiabilité du site (SRE) - assurer la fiabilité des systèmes d'information. Il s'agit d'une nouvelle approche pour prendre en charge des sites, des services et des applications avec des milliers et des millions d'utilisateurs. L'approche est née chez Google et se répand maintenant dans le monde entier. En Russie, le SRE a été mis en œuvre dans Yandex, Mail.ru, Sberbank, Tinkoff, MTS, Megafon et d'autres sociétés.
Les développeurs et administrateurs système expérimentés deviennent des ingénieurs SRE: une connaissance approfondie des systèmes d'exploitation des serveurs, de l'exploitation du réseau, des outils de surveillance, ainsi que des compétences en programmation est importante. Toutes ces compétences techniques se superposent à la méthodologie SRE - des pratiques spécifiques qui contribuent à garantir une fiabilité élevée.
«Le SRE ne concerne pas tant les alertes et les post-mortems. Il s’agit du fait que le code qui sape la nuit n’atteint pas la production ».
De la communication avec les ingénieurs qui ont mis en œuvre le SRE
Pendant longtemps, la principale source de connaissances sur SRE était le livre du même nom de Google. Il existe maintenant plusieurs programmes de formation en anglais et en russe. L'un d'eux est le SRE intensif à Slurme.
Format intensif
Le cours intensif se déroule en ligne et se compose de conférences et de sessions pratiques. Il y aura une diffusion dans Zoom et Telegram chat avec des intervenants.
Deux types de pratique. Les exercices pratiques sont de deux types: la personnalisation par l'exemple et le travail sur des tâches dont la solution n'est pas prédéterminée. Sur le cours intensif, ils sont appelés cas .
Travail d'équipe sur un vrai service. Pour travailler sur les cas, les participants de l'intensif sont réunis en équipes de 5 à 8 personnes. Chaque équipe reçoit un stand avec une application - plusieurs VDS, qui héberge un site Web pour la commande de billets .
Un service de commande de tickets dont le fonctionnement stable sera assuré par les participants à la Simulation de Défaillance Intensive
.Au cours de l'intensif, plusieurs pannes majeures se produiront dans le travail du site, et la tâche de l'équipe est d'en trouver la cause, d'éliminer et d'éviter sa récurrence. Les cas sont basés sur une expérience réelle: les intervenants ont recueilli les problèmes auxquels ils ont été confrontés lors de leur pratique SRE et ont créé un environnement pour simuler ces problèmes.
Conférenciers expérimentés. Le programme intensif a été développé et sera mené par:
- Ivan Kruglov, ingénieur logiciel chez Databricks.
- Artyom Artemiev, Lead SRE chez TangoMe.
- Pavel Selivanov, ingénieur DevOps senior chez Mail.ru Cloud Solutions.
Support. Les conservateurs aideront à s'unir en équipes et à organiser un travail conjoint. Les conférenciers et les ingénieurs du support technique de Slurm vous aideront à résoudre des problèmes complexes.
Format à distance. Les conférences sont diffusées dans Zoom, la discussion des tâches a lieu dans Slack. Toutes les notes de cours seront conservées et seront disponibles après l'intensif, il est utile d'y revenir au bout d'un moment, déjà dans une ambiance plus calme.
Trois jours d'immersion totale. L'intensif est conçu pour trois jours complets, de 10h00 à 18h00, heure de Moscou. Il y aura de courtes pauses entre les conférences et le déjeuner.
Commencez le 21 mai. Il y a encore de la place.
En savoir plus et vous inscrire
Vous trouverez ci-dessous le programme intensif complet.
Jour 1: familiarisation avec la théorie du SRE, mise en place du monitoring et de l'alerte
Le premier jour, vous vous familiariserez avec la théorie du SRE, apprendrez à mettre en place la surveillance et l'alerte, et vous ferez également équipe avec d'autres participants à l'intensif.
Parlons des métriques SLO, SLI, SLA et de leur relation avec les exigences de l'entreprise. Nous partagerons les Bonnes Pratiques pour la mise en place du suivi et des règles pour les sapeurs-pompiers. Nous donnerons les premiers cas pratiques.
Thème 1: Surveillance
- Pourquoi avez-vous besoin d'une surveillance,
- Symptômes vs causes,
- Boîte noire vs. Surveillance en boîte blanche,
- Signaux dorés,
- Centiles,
- Alerte,
- Observabilité.
Pratique: Réalisation d'un tableau de bord de base et mise en place des alertes nécessaires.
Thème 2: théorie SRE
- SLO, SLI, SLA,
- Durabilité,
- Budget d'erreur.
Pratique: Ajout d'alertes SLO / SLI + au tableau de bord.
Pratique: Premier chargement du système.
Cas 1: dépendance en aval. Dans un grand système, il existe de nombreux services interdépendants, et ils ne fonctionnent pas toujours aussi bien. C'est particulièrement offensant lorsque votre service est en ordre et que le voisin, dont vous dépendez, tombe périodiquement en panne. Le projet de formation se trouvera dans de telles conditions et vous ferez en sorte qu'il donne toujours la qualité au plus haut niveau possible.
Thème 3: Gestion des incidents
- Ingénierie de la résilience,
- Comment les pompiers s'alignent
- Quelle est l'efficacité de votre équipe dans l'incident,
- 7 règles pour un chef d'incident,
- 5 règles pour un pompier,
- HiPPO - l'opinion de la personne la mieux payée. Responsable des communications.
Cas 2: addiction en amont. C'est une chose lorsque vous dépendez d'un service avec un faible SLO. C'est une autre question lorsque votre service est tel pour d'autres parties du système. Cela se produit si les critères d'évaluation ne sont pas convenus: par exemple, vous répondez à une demande en une seconde et la considérez comme réussie, mais le service dépendant n'attend que 500 fois Moscou et repart avec une erreur. Dans ce cas, nous discuterons de l'importance de la réconciliation des métriques et apprendrons à regarder la qualité à travers les yeux du client.
Thème 4: SRE onboarding a project
Dans les grandes entreprises, il n'est pas rare de former une équipe SRE séparée, qui prend en charge les services d'autres départements. Mais tous les services ne sont pas prêts à être pris en charge. Nous vous dirons à quelles exigences il doit répondre.
Jour 2: résolution de problèmes avec l'environnement et l'architecture
La deuxième journée est presque entièrement construite autour de la résolution de deux cas: les problèmes avec l'environnement (il y aura une analyse détaillée du Health Checking) et les problèmes avec l'architecture. Les conférenciers parleront de l'utilisation des post mortems et fourniront des modèles que vous pouvez utiliser dans votre équipe.
Thème 5: Bilan de santé
- Bilan de santé dans Kubernetes,
- Notre service est-il vivant?
- Sondes Exec,
- initialDelaySeconds,
- Port sanitaire secondaire,
- Serveur de santé Sidecar,
- Sonde sans tête,
- Sonde matérielle.
Cas 3: problèmes environnementaux et bilan de santé correct. La tâche de Healthcheck est de détecter un service de temps d'arrêt et de bloquer le trafic vers celui-ci afin que les utilisateurs ne soient pas confrontés à un problème. Et si vous pensez qu'il suffit d'enraciner une demande auprès du service et d'obtenir une réponse, vous vous trompez: même si le service répond, cela ne garantit pas ses performances - il peut y avoir des problèmes dans l'environnement. Grâce à ce cas, vous apprendrez à configurer le bon contrôle de santé et à ne pas laisser le trafic aller là où il ne peut pas être traité.
Thème 6: Pratique du travail avec des post - mortem - nous écrivons un post-mortem basé sur le cas précédent et l'analysons avec les orateurs.
Sujet 7: Résolution des problèmes d'infrastructure
- Surveiller MySQL,
- SLO / SLI pour MySQL,
- Détection d'une anomalie.
Cas 4: problèmes avec la base de données. La base de données peut également être source de problèmes. Par exemple, si vous ne surveillez pas le relais de réplication, la réplique deviendra obsolète et l'application renverra d'anciennes données. De plus, il est particulièrement difficile de déboguer de tels cas: maintenant, les données sont incohérentes, mais après quelques secondes, elles ont disparu et la cause du problème n'est pas claire. À travers le cas, vous ressentirez toute la douleur du débogage et apprendrez à éviter de tels problèmes.
Jour 3: protection contre le trafic et rejets Canary
Il existe deux cas de haute disponibilité de la production: la protection contre le trafic et le déploiement Canary. Vous découvrirez ces approches et apprendrez à les appliquer. Nous ne prévoyons pas de réglage hardcore à la main, mais qui sait.
Thème 8: Blindage du trafic
- comportement des graphiques de croissance du nombre de demandes et des opérations commerciales
- planification de la saturation et de la capacité
- traffic shielding rate limiting
- sidecar rate-limiting 100
5: traffic shielding. ? , 100 , 1000. , , , . , .
9: Canary Deployment
- k8s (Rolling Update vs Recreate),
- canary blue-green ,
- blue-gree/canary release k8s,
- canary release GitLab CI/CD,
- canary release,
- .gitlab-ci.yml.
6: . ,
, - . , . Canary Deployment, .