Enxeñeiro/a SRE - en prácticas
Primeiro, permítanme presentarme. Son , enxeñeiro/a front-end do grupo GitLab. A semana pasada, tiven o privilexio de facer prácticas cun dos nosos enxeñeiros de SRE de garda. O obxectivo era observar como o enxeñeiro de garda responde aos incidentes a diario e adquirir experiencia no mundo real. Queremos que os nosos enxeñeiros comprendan mellor as necesidades dos usuarios. Monitor::Saúde.
Encargáronme seguir ao enxeñeiro de SRE durante unha semana. Isto significaba que estiven presente na entrega, monitorizando os mesmos canais de alerta e respondendo aos incidentes se e cando ocorrían.
Incidentes
Houbo 2 incidentes nunha semana.
1. Criptominero
GitLab.com rexistrou un pico no uso o mércores. Informouse dunha violación causada por intentos de usar minutos de corredor para a minería de criptomoedas. O incidente resolveuse usando a nosa propia ferramenta de mitigación, que finaliza as tarefas do corredor e elimina o proxecto e a conta asociados.
Se este evento pasara desapercibido, unha ferramenta automatizada teríao detectado, pero neste caso, o enxeñeiro de SRE foi o primeiro en decatarse da infracción. Creouse unha tarefa para o incidente, pero a información sobre el foi selada.
2. Degradación do rendemento das aplicacións Canary e Main
O incidente foi provocado por ralentizacións e aumento das taxas de erro nas aplicacións web principais e canary en Gitlab.com. Violáronse varios valores de Apdex.
Tarefa aberta para o incidente:
Principais achados
Aquí tes algunhas cousas que aprendín durante a miña semana de servizo.
1. As alertas son máis útiles cando detectan desviacións da norma.
As notificacións pódense dividir en varios tipos:
- Alertas baseadas nun determinado limiar, como "Producironse 10 erros 5xx por segundo".
- Alertas onde o limiar é un valor porcentual como "taxa de 5xx erros por cada 10 % do volume total de solicitudes nun momento determinado".
- Alertas baseadas nunha media histórica como "erros 5xx no percentil 90".
En xeral, os tipos 2 e 3 son máis útiles para as SRE de garda porque revelan desviacións da norma no proceso.
2. Moitas alertas nunca se converten en incidentes
Os enxeñeiros de SR lidan cun fluxo constante de alertas, moitas das cales non son realmente críticas.
Entón, por que non limitar as alertas só ás que son realmente importantes? Non obstante, esta estratexia pode pasar por alto sinais de alerta temperá do que podería converterse nun problema real que ameaza con danos importantes.
O traballo do SRE de garda é determinar que alertas son realmente graves e se cómpre escalalas e investigalas. Sospeito que isto tamén se debe á rixidez das alertas: sería mellor introducir varios niveis ou formas "intelixentes" de configurar as alertas segundo a situación descrita anteriormente.
Suxestión de función:
3. Os nosos SRE de garda empregan moitas ferramentas
Interno:
- Proxecto de infraestrutura de GitLab: alberga os runbooks, as entregas de tarefas por quendas/semanais e as tarefas de resposta a incidentes.
- As incidencias de GitLab: as investigacións, as revisións e o mantemento tamén se rexistran nas tarefas.
- Etiquetas de GitLab: as tarefas de automatización actívanse mediante etiquetas específicas que os bots usan para rastrexar a actividade das tarefas.
Externo:
- PagerDuty: Alertas
- Slack: Aquí é onde se envían as mensaxes de PagerDuty/AlertManager. A integración con comandos slash permite realizar varias tarefas, como descartar unha alerta ou escalala a un incidente.
- Grafana: Visualización de métricas centrada nas tendencias a longo prazo.
- Kibana: Ofrece visualización/busca de rexistros e capacidade para afondar en eventos específicos.
- Zoom: Zoom ten unha "sala de reunións" permanentemente activa. Isto permite aos enxeñeiros de SRE discutir rapidamente eventos sen perder un tempo valioso creando unha sala e compartindo a ligazón cos participantes.
E moito, moito máis.
4. A monitorización de GitLab.com con GitLab é un único punto de fallo
Se GitLab.com experimenta unha interrupción importante do servizo, non queremos que isto afecte á nosa capacidade para resolver o problema. Isto pódese mitigar lanzando unha segunda instancia de GitLab para xestionar GitLab.com. De feito, isto xa nos está a funcionar: .
5. Algunhas funcionalidades a considerar para engadir a GitLab
- , semellante a Google Docs. Isto sería útil para tarefas relacionadas con incidentes durante un evento, así como para sesións informativas. En ambos os casos, pode que varios participantes teñan que engadir algo en tempo real.
- Máis webhooks para tarefas. A capacidade de activar varios pasos do fluxo de traballo de GitLab internamente axudará a reducir a dependencia das integracións de Slack. Por exemplo, a capacidade de activar notificacións en PagerDuty mediante un comando de barra nunha tarefa de GitLab.
Conclusión
Os enxeñeiros de SRE enfróntanse a unha multitude de desafíos. Sería estupendo ver máis produtos de GitLab abordando estes problemas. Xa estamos a traballar nalgunhas adicións de produtos que simplificarán os fluxos de traballo mencionados anteriormente. Os detalles están dispoñibles en .
En 2020, ampliaremos o noso equipo para reunir todas estas fantásticas funcións. Se che interesa, consulta e non dubide en contactar con calquera membro do noso equipo se ten algunha dúbida.
Fonte: www.habr.com
