Ingénieur SRE - Stagiaire
Tout d'abord, permettez-moi de me présenter. Je suis @ tristan.read , un ingénieur front-end dans le groupe Monitor :: Health de GitLab. La semaine dernière, j'ai eu l'honneur d'être stagiaire avec l'un de nos ingénieurs SRE en service. L'objectif était de surveiller quotidiennement la façon dont le préposé répond 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 des fonctionnalités de Monitor :: Health.
J'ai dû suivre l'ingénieur SRE partout pendant une semaine. Autrement dit, j'ai assisté au quart de travail, regardé les mêmes canaux de notification et répondu aux incidents, si et quand ils se sont produits.
Incidents
Au cours de la semaine 2, des incidents se sont produits.
1. Cryptominer
Mercredi, GitLab.com a vu une augmentation de son utilisation de GitLab Runner , causée par des tentatives d'utiliser les minutes du coureur pour exploiter la crypto-monnaie. Nous avons traité l'incident en utilisant notre propre outil pour neutraliser les violations, ce qui arrête les tâches du coureur 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 été le premier à constater la violation. Une tâche incidente a été créée, mais les informations y relatives ont été fermées.
2. DĂ©gradation des performances des applications Canaries et principales
L'incident a été déclenché par des ralentissements et un taux d'erreur accru dans les applications Web canaries et principales sur Gitlab.com. Plusieurs valeurs Apdex ont été violées.
Tâche d'incident ouvert: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442
Constatations clés
Voici quelques points que j'ai appris au cours de la semaine de service.
1. Les alertes sont plus utiles lorsque des anomalies sont détectées.
Les alertes peuvent être divisées en plusieurs types:
- Des alertes basées sur une valeur de seuil spécifique telle que "10 erreurs 5xx par seconde" se sont produites.
- Alertes dans lesquelles le seuil est une valeur en pourcentage de type "fréquence d'erreurs 5xx pour 10% du volume total de demandes à un moment donné".
- Alertes basées sur la moyenne historique du type «erreurs 5xx dans le 90e centile».
De manière générale, les 2e et 3e types sont plus utiles pour les SRE de service, car ils révèlent des écarts par rapport à la norme dans le processus.
2. De nombreuses alertes ne dégénèrent jamais en incidents
Les ingénieurs SR sont confrontés à un flux constant d'alertes, dont beaucoup ne sont pas vraiment critiques.
Alors pourquoi ne pas limiter les alertes à celles qui sont vraiment importantes? Avec une telle approche, cependant, on ne peut pas reconnaître les premiers symptômes de ce qui va se développer, comme une boule de neige, en un véritable problème, menaçant des dommages majeurs.
Le devoir du SRE en service est de déterminer quelles alertes disent vraiment quelque chose de grave, et si elles doivent être intensifiées et commencer à comprendre. Je soupçonne que cela est également dû à la rigidité des alertes: il serait préférable que plusieurs niveaux ou des moyens «intelligents» de définir des alertes soient introduits conformément à la situation décrite ci-dessus.
Suggestion de fonctionnalité: https://gitlab.com/gitlab-org/gitlab/issues/42633
3. Nos préposés SRE utilisent de nombreux outils.
Interne:
- Projet infra GitLab: Runbooks en direct ici, quarts de travail / semaine, tâches de réponse aux incidents.
- Problèmes liés à GitLab: les enquêtes, l'analyse et la maintenance sont également suivies dans les tâches.
- Libellés GitLab: les tâches d'automatisation sont lancées en fonction de certains libellés, par lesquels les bots suivent l'activité des tâches.
Externe:
- PagerDuty: Alertes
- Slack: le flux de messages PagerDuty / AlertManager va ici. Intégration avec des commandes de barre oblique pour effectuer une variété de tâches, telles que la fermeture d'une alerte ou l'escalade vers un incident.
- Grafana: visualisation de métriques avec un focus sur les tendances à long terme.
- Kibana: donne une visualisation / recherche dans le magazine, la possibilité d'approfondir certains événements.
- Zoom: Zoom dispose d'une «salle de discussion» fonctionnant en permanence. Cela permet aux ingénieurs SRE de discuter rapidement des événements sans perdre de temps précieux à créer de l'espace et des liens pour les participants.
Et bien plus encore.
Si une panne de service majeure se produit sur GitLab.com, nous ne voulons pas que cela affecte notre capacité à résoudre le problème. Il peut être arrêté en exécutant la deuxième instance GitLab pour installer GitLab.com. En fait, cela fonctionne déjà pour nous: https://ops.gitlab.net/ .
5. Quelques fonctionnalités à considérer lors de l'ajout à GitLab
- Édition de tâches multi-utilisateurs similaire à Google Docs. Cela aiderait avec les tâches d'incident pendant l'événement, ainsi que les tâches d'analyse. Dans les deux cas, plusieurs participants peuvent avoir besoin d'ajouter quelque chose en temps réel.
- Plus de webhooks pour les tâches. La possibilité d'exécuter différentes étapes du flux de travail GitLab de l'intérieur aidera à réduire la dépendance aux intégrations Slack. Par exemple, la possibilité d'activer la notification dans PagerDuty via une commande de barre oblique dans la tâche GitLab.
Conclusion
Les ingénieurs SRE ont du mal avec de nombreuses difficultés. Ce serait formidable de voir plus de produits GitLab pour résoudre ces problèmes. Nous travaillons déjà sur certains ajouts de produits qui faciliteront les flux de travail mentionnés ci-dessus. Les détails sont disponibles dans la section Ops Product Vision .
En 2020, nous élargissons l'équipe pour rassembler toutes ces fonctionnalités intéressantes. Si vous êtes intéressé, veuillez lire les offres d'emploi , et n'hésitez pas à contacter quelqu'un de notre équipe pour toute question.