Ingénieur SRE - stagiaire
Pour commencer, permettez-moi de me présenter. JE - , ingénieur front-end dans le groupe GitLab. La semaine dernière, j'ai eu le privilège d'être stagiaire avec l'un de nos ingénieurs SRE en service. L'objectif était d'observer quotidiennement comment l'agent de service réagit aux incidents et d'acquérir une véritable expérience de travail. Nous aimerions que nos ingénieurs comprennent mieux les besoins des utilisateurs Moniteur ::Santé.
J'ai dû suivre le SRE pendant une semaine. C'est-à-dire que j'étais présent lors du transfert de service, que j'observais les mêmes canaux d'alerte et que je répondais aux incidents, si et quand ils se produisaient.
Incidents
Il y a eu 2 incidents en une semaine.
1. Cryptomineur
GitLab.com a enregistré une augmentation de son utilisation mercredi 'a, causé par des tentatives d'utilisation des minutes du coureur pour l'extraction de crypto-monnaie. L'incident a été résolu à l'aide d'un outil d'atténuation propriétaire qui arrête les tâches de l'exécuteur et supprime le projet et le compte qui lui sont associés.
Si cet événement n'avait pas été remarqué, un outil automatisé l'aurait détecté, mais dans ce cas, l'ingénieur SRE a remarqué la violation en premier. Une tâche d'incident a été créée, mais les informations la concernant sont fermées.
2. Dégradation des performances des applications Canary et Main
L'incident a été alimenté par des ralentissements et des taux d'erreur accrus dans les applications Web Canary et principales sur Gitlab.com. Plusieurs valeurs Apdex ont été violées.
Tâche ouverte par incident :
Principales conclusions
Voici quelques points que j'ai appris pendant la semaine de service.
1. Les alertes sont particulièrement utiles pour détecter les écarts par rapport à la norme.
Les notifications peuvent être divisées en plusieurs types :
- Alertes basées sur un certain seuil, telles que "10 erreurs 5xx se sont produites par seconde".
- Alertes où le seuil est une valeur en pourcentage telle que "taux d'erreur 5xx pour 10 % du nombre total de requêtes à un moment donné".
- Alertes basées sur une moyenne historique telles que "erreurs 5xx dans le 90e centile".
De manière générale, les types 2 et 3 sont plus utiles pour les SRE en service, car ils révèlent des anomalies dans le processus.
2. De nombreuses alertes ne dégénèrent jamais en incidents
Les ingénieurs SR traitent un flux constant d'alertes, dont beaucoup ne sont pas vraiment critiques.
Alors pourquoi ne pas limiter les alertes aux seules vraiment importantes ? Avec cette approche, cependant, les premiers symptômes de ce qui fera boule de neige en un véritable problème qui menace de causer des dommages majeurs peuvent être négligés.
La tâche du SRE en service est de déterminer quelles alertes signifient vraiment quelque chose de grave, et si elles doivent être escaladées et commencées à être triées. Je soupçonne que cela est également dû à la rigidité des alertes : il serait préférable qu'ils introduisent plusieurs niveaux ou des moyens "intelligents" de personnaliser les alertes en fonction de la situation décrite ci-dessus.
Suggestion de fonctionnalité :
3. Nos SRE utilisent beaucoup d'outils
Interne:
- Projet infra GitLab : Runbooks en direct ici, transferts de quart/semaine, tâches de réponse aux incidents.
- Problèmes GitLab : les enquêtes, les débriefings et la maintenance sont également suivis dans les problèmes.
- Étiquettes GitLab : les tâches d'automatisation sont déclenchées par des étiquettes spécifiques que les bots utilisent pour suivre l'activité des tâches.
Externe:
- Alertes PagerDuty
- Slack : c'est là que va le flux de messages PagerDuty/AlertManager. Intégration avec les commandes slash pour effectuer une variété de tâches, telles que fermer une alerte ou escalader un incident.
- Grafana : visualisation des métriques avec un accent sur les tendances à long terme.
- Kibana : offre une visualisation/recherche de journal, la possibilité d'approfondir certains événements.
- Zoom : il y a une "salle de discussion" permanente dans Zoom. Cela permet aux SRE de discuter rapidement des événements sans perdre un temps précieux à créer une salle et à relier les membres.
Et bien plus encore.
4. La surveillance de GitLab.com avec GitLab est un point de défaillance unique
Si GitLab.com subit une panne de service majeure, nous ne voulons pas que cela affecte notre capacité à résoudre le problème. Il peut être arrêté en exécutant une deuxième instance GitLab pour gérer GitLab.com. En fait, cela fonctionne déjà pour nous : .
5. Quelques fonctionnalités à envisager d'ajouter à GitLab
- , similaire à Google Docs. Cela aiderait dans les tâches d'incident pendant l'événement, ainsi que dans les tâches de débriefing. Dans les deux cas, plusieurs participants peuvent avoir besoin d'ajouter quelque chose en temps réel à la fois.
- Plus de webhooks pour les tâches. La possibilité d'exécuter diverses étapes de workflow GitLab depuis l'intérieur vous aidera à réduire votre dépendance aux intégrations Slack. Par exemple, la possibilité d'activer une alerte dans PagerDuty via une commande slash dans un ticket GitLab.
Conclusion
Les ingénieurs SRE ont du mal avec de nombreuses complexités. Ce serait formidable de voir plus de produits GitLab résoudre ces problèmes. Nous travaillons déjà sur quelques ajouts au produit qui faciliteront les flux de travail mentionnés ci-dessus. Les pièces sont disponibles en .
En 2020, nous agrandissons l'équipe pour réunir toutes ces fonctionnalités intéressantes. Si vous êtes intéressé, veuillez consulter , et n'hésitez pas à contacter un membre de notre équipe pour toute question.
Source: habr.com