Ingénieur SRE - stagiaire
Pour commencer, permettez-moi de me prĂ©senter. Je suis , ingĂ©nieur front-end dans le groupe de GitLab. La semaine derniĂšre, j'ai eu l'honneur d'ĂȘtre stagiaire auprĂšs de l'un de nos SRE d'astreinte. L'objectif Ă©tait d'observer quotidiennement comment l'astreinte rĂ©agit aux incidents et d'acquĂ©rir une expĂ©rience pratique. Nous souhaitons que nos ingĂ©nieurs comprennent mieux les besoins des utilisateurs Monitor::Health.
J'ai dĂ» suivre l'ingĂ©nieur SRE pendant une semaine. J'Ă©tais prĂ©sent lors du passage de service, observais les mĂȘmes canaux d'alerte et rĂ©agissais aux incidents, s'il y en avait.
Incidents
Au cours de la semaine, deux incidents se sont produits.
1. Mineur de cryptomonnaie
Mercredi, nous avons constatĂ© une augmentation de l'utilisation sur GitLab.com due Ă des tentatives d'utilisation des minutes du runner pour miner des cryptomonnaies. Nous avons rĂ©solu l'incident Ă l'aide de notre propre outil de neutralisation des violations, qui arrĂȘte les tĂąches du runner et supprime le projet et le compte 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 à remarquer la violation. Une tùche a été créée pour cet incident, mais les informations à son sujet sont confidentielles.
2. DĂ©gradation des performances des applications Canary et Main
L'incident a été provoqué par des ralentissements et une augmentation de la fréquence des erreurs dans les applications web canary et main sur GitLab.com. Plusieurs valeurs Apdex ont été affectées.
TĂąche ouverte concernant l'incident :
Principales conclusions
Voici quelques points que j'ai compris au cours de ma semaine de service.
1. Les alertes sont les plus utiles lorsqu'elles détectent des anomalies.
Les alertes peuvent ĂȘtre divisĂ©es en plusieurs types :
- Alertes basées sur un seuil spécifique, comme '10 erreurs 5xx par seconde'.
- Alertes oĂč le seuil est une valeur en pourcentage, comme 'la frĂ©quence des erreurs 5xx est de 10 % du volume total des requĂȘtes dans un dĂ©lai donnĂ©'.
- Alertes basées sur la moyenne historique, comme 'erreurs 5xx dans le 90Úme percentile'.
En général, les types 2 et 3 sont plus utiles pour les SRE de garde, car ils révÚlent les anomalies au fil du temps.
2. De nombreuses alertes ne sont jamais escaladées en incidents
Les ingénieurs SRE sont confrontés à un flux constant d'alertes, dont beaucoup ne sont en réalité pas critiques.
Alors pourquoi ne pas limiter les alertes aux vraiment importantes ? Avec cette approche, cependant, vous pourriez passer à cÎté des premiers symptÎmes qui pourraient se transformer en un véritable problÚme menaçant de causer des dommages considérables.
La tĂąche d'un SRE de garde est de dĂ©terminer quelles alertes signifient vraiment quelque chose de sĂ©rieux et s'il faut les escalader et commencer Ă enquĂȘter. Je soupçonne que cela est Ă©galement dĂ» Ă l'inflexibilitĂ© des alertes : il serait prĂ©fĂ©rable d'introduire plusieurs niveaux ou des moyens « intelligents » de configurer les alertes en fonction de la situation dĂ©crite ci-dessus.
Proposition de fonctionnalité :
3. Nos SRE de garde utilisent de nombreux outils
Internes :
- Projet infra GitLab : ici résident les Runbooks, les transmissions de garde pour le changement/de la semaine, et les tùches relatives aux réponses aux incidents.
- ProblĂšmes GitLab : les enquĂȘtes, les analyses et la maintenance sont Ă©galement suivies dans les tĂąches.
- Ătiquettes GitLab : les tĂąches d'automatisation sont dĂ©clenchĂ©es par des Ă©tiquettes spĂ©cifiques, suivies par des bots surveillant l'activitĂ© des tĂąches.
Externes :
- PagerDuty : alertes
- Slack : c'est ici que le flux de messages de PagerDuty/AlertManager est dirigé. Intégration avec des commandes slash pour effectuer diverses tùches, telles que : fermer une alerte ou escalader en incident.
- Grafana : visualisation des métriques axée sur les tendances à long terme.
- Kibana : offre une visualisation/recherche dans les journaux, permettant d'explorer plus en profondeur certains événements.
- Zoom : il y a une « salle de discussion » Zoom toujours ouverte. Cela permet aux ingénieurs SRE de discuter rapidement des événements, sans perdre de temps précieux à créer une salle et à partager des liens avec les participants.
Et beaucoup, beaucoup d'autres.
4. Surveiller GitLab.com avec GitLab â c'est un point de dĂ©faillance unique
Si un important Ă©chec de services se produit sur GitLab.com, nous ne souhaiterions pas que cela affecte notre capacitĂ© Ă rĂ©soudre le problĂšme. Celui-ci peut ĂȘtre attĂ©nuĂ© en lançant une seconde instance de 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 serait utile pour les tùches liées aux incidents durant un événement, ainsi que pour 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é de déclencher différentes étapes du flux de travail GitLab en interne aidera à réduire la dépendance aux intégrations Slack. Par exemple, la possibilité d'autoriser des notifications dans PagerDuty via une commande slash dans une tùche GitLab.
Conclusion
Les ingénieurs SRE font face à de nombreuses complexités. Il serait intéressant de voir davantage de produits GitLab pour résoudre ces problÚmes. Nous travaillons déjà sur certaines améliorations du produit qui simplifieront les flux de travail mentionnés ci-dessus. Les détails sont disponibles dans .
En 2020, nous agrandissons l'équipe pour rassembler toutes ces fonctionnalités incroyables. Si cela vous intéresse, n'hésitez pas à consulter , et n'hésitez pas à contacter l'un des membres de notre équipe pour toute question.
Source : habr.com
