Ingénierie de la fiabilité des sites - cours 65 000 roubles. de Slurm, formation, date du 1er janvier 2024.
Miscellanea / / November 29, 2023
AUX PERSONNES
Un ingénieur SRE peut être soit un ingénieur d’exploitation, soit un développeur. Pendant le cours intensif, vous pratiquerez beaucoup et les compétences et connaissances acquises pourront être adaptées et mises en œuvre dans n'importe quel domaine.
ENTREPRISE
SRE résout les mêmes problèmes que DevOps: il augmente la vitesse de publication de nouvelles fonctionnalités et améliore les processus au sein de l'équipe. Mais la tâche principale du SRE est d'assurer la stabilité et la fiabilité des services, en excluant les situations où les utilisateurs se plaignent de pannes et où les ingénieurs ont des horaires verts.
Nous construisons :
Notre site de formation est composé de plusieurs microservices. Il regroupe les données sur les spectacles, les prix et les places disponibles dans tous les cinémas, affiche les annonces de films, vous permet de sélectionner un cinéma, un spectacle, une salle et un lieu, de réserver et de payer vos billets.
Nous formulerons des indicateurs SLO, SLI, SLA pour ce site, développerons une architecture et une infrastructure qui les supporteront, mettrons en place une surveillance et des alertes.
Les erreurs des développeurs, les pannes d’infrastructure, l’afflux de visiteurs et les attaques DoS entraînent une aggravation des SLO.
Nous analysons la stabilité, le budget d'erreurs, les pratiques de tests, la gestion des interruptions et la charge opérationnelle.
Il y avait un accident. Le service de traitement des paiements est en panne. Comment agir pour restaurer la fonctionnalité dans les plus brefs délais ?
Nous organisons le travail de l'équipe d'intervention d'urgence: impliquer les collègues, informer les parties prenantes, fixer les priorités. Nous nous entraînons pour travailler sous pression dans des conditions de temps extrêmement limitées.
Regardons l'approche du site d'un point de vue SRE. Nous analysons les incidents (causes d'apparition, progression de l'élimination). Nous prenons des décisions pour les prévenir davantage: nous améliorons la surveillance, modifions l'architecture, l'approche de développement et d'exploitation, ainsi que la réglementation. Nous automatisons les processus.
— Nous avons des dizaines d'infrastructures construites et des centaines de pipelines CI/CD écrits,
— Administrateur Kubernetes certifié,
— Auteur de plusieurs cours sur Kubernetes et DevOps,
— Conférencier régulier lors de conférences informatiques russes et internationales.
JOUR 1: séance de lancement de l'AMA
Nous discuterons des buts et objectifs du cours, nous vous expliquerons également ce qu'est le SRE et le diviserons en équipes.
Ouverture de 2 sujets théoriques :
Thème 1: Surveillance
- Pourquoi une surveillance est-elle nécessaire ?
- Centiles
- Alerte
- Observabilité
Thème 2: Théorie SRE
- SLO, SLI, SLA
- Durabilité
- Bilan d'erreur
JOUR 2: analyse des pratiques et des cas
Pratique: Réaliser un tableau de bord basique et mettre en place les alertes nécessaires
Pratique: Ajout d'alertes SLO/SLI + au tableau de bord
Pratique: Premier chargement du système
Solution du 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 ennuyeux lorsque votre service est en ordre, mais que celui voisin, dont vous dépendez, tombe périodiquement en panne.
Le projet éducatif se trouvera exactement dans ces conditions et vous veillerez à ce qu'il produise toujours une qualité au plus haut niveau possible.
JOUR 3: Session AMA, réponses aux questions
L'accès au 2ème module théorique s'ouvre :
Résoudre les problèmes liés à l'environnement et à l'architecture
Le deuxième module est construit autour de la résolution de deux cas: les dépendances en amont et les problèmes d'architecture. Les intervenants parleront de la gestion des incidents, des règles pour les pompiers et du travail avec les autopsies et fourniront des modèles que vous pourrez utiliser dans votre équipe.
Thème 3: Gestion des incidents
- Ingénierie de la résilience
- Comment se constitue une brigade de pompiers
- Quelle est l’efficacité de votre équipe lors de l’incident ?
- 7 règles pour un responsable d'incident
- 5 règles pour un pompier
- HiPPO – opinion de la personne la mieux payée. Responsable des communications
TThème 4: Outils Varrum et gestion des alertes.
Meilleures pratiques d'autres entreprises dans l'organisation de la gestion des incidents.
JOUR 4: analyse des pratiques et des cas
Solution au cas 2: dépendance en amont.
C'est une chose lorsque vous dépendez d'un service avec un faible SLO. C'est une autre affaire lorsque votre service est le même pour les autres parties du système. Cela se produit si les critères d'évaluation ne sont pas cohérents: par exemple, vous répondez à une demande dans la seconde et la considérez comme un succès, mais le service dépendant n'attend que 500 heures de Moscou et repart avec une erreur.
Dans ce cas, nous discuterons de l’importance d’harmoniser les mesures et apprendrons à considérer la qualité à travers les yeux du client.
Solution au cas 3: 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 les anciennes données. De plus, le débogage de tels cas est particulièrement difficile: maintenant les données sont incohérentes, mais après quelques secondes elles ne le sont plus, et la cause du problème n'est pas claire.
Grâce au boîtier, vous ressentirez toute la douleur du débogage et apprendrez à éviter de tels problèmes.
Pratique: Nous rédigeons un post-mortem sur le cas précédent et en discutons avec les intervenants.
JOUR 5: Session AMA, réponses aux questions
Session AMA et réponses aux questions sur les sujets précédents.
L'accès au 3ème module théorique s'ouvre :
Protection du trafic et versions Canary
Dans le troisième module, nous analyserons un cas dédié à un problème avec l'environnement (il y aura une analyse détaillée de la santé Vérification), et nous analyserons également étape par étape comment mettre en œuvre le SRE dans les entreprises et apprendrons l'expérience des entreprises dans lesquelles travaillent les intervenants. intensif
Sujet 5: Vérification de la santé
- Bilan de santé dans Kubernetes
- Notre service est-il toujours en vie ?
- Sondes d'exécution
- InitialDelaySeconds
- Port de santé secondaire
- Serveur de santé secondaire
- Sonde sans tête
- Sonde matérielle
Sujet 6: Méthodes de déploiement
Thème 7: Intégration du projet SRE
Les grandes entreprises forment souvent une équipe SRE distincte, qui s'appuie sur les services d'autres départements pour le soutien. Mais tous les services ne sont pas prêts à être acceptés pour une assistance. Nous vous dirons à quelles exigences il doit répondre. Les intervenants partageront également leur expérience, comment ils ont mis en œuvre le SRE et quelles erreurs ils ont commises.
JOUR 6: analyse des pratiques et des cas
Solution au cas 4: il y a un problème avec l'environnement, il est impossible d'acheter des billets.
La tâche de Healthcheck est de détecter un service en panne et de bloquer le trafic vers celui-ci. Et si vous pensez que pour cela il suffit de faire une requête au service avec root et de recevoir une réponse, alors vous vous vous trompez: même si le service répond, cela ne garantit pas son fonctionnement - des problèmes peuvent survenir dans alentours.
Grâce à ce cas, vous apprendrez à configurer le bon bilan de santé et à ne pas autoriser le trafic à aller là où il ne peut pas être traité.
Résumer