Enxeñeiro SRE - en prácticas
En primeiro lugar, permíteme presentarme. eu - , enxeñeiro front-end no grupo GitLab. A semana pasada tiven a honra de facer prácticas cun dos nosos enxeñeiros SRE de garda. O obxectivo era observar como o axente de garda respondeu diariamente aos incidentes e adquirir experiencia real no traballo. Gustaríanos que os nosos enxeñeiros entendesen mellor as necesidades dos usuarios Monitor::Saúde.
Tiven que seguir ao enxeñeiro SRE a todas partes durante unha semana. É dicir, estiven presente no acto de entrega, monitorei as mesmas canles de alerta e respondín ás incidencias se e cando se producían.
Incidentes
Houbo 2 incidentes nunha semana.
1. Mineiro criptográfico
GitLab.com viu un salto no uso o mércores 'a, causado por intentos de utilizar os minutos do corredor para minar criptomoeda. O incidente tratouse mediante a nosa propia ferramenta de neutralización de infraccións, que detén as tarefas do corredor e elimina o proxecto e a conta asociados a el.
Se este suceso non se notara, unha ferramenta automatizada teríao detectado, pero neste caso, o enxeñeiro do SRE observou primeiro a infracción. Creouse unha tarefa de incidencia, pero a información sobre ela está pechada.
2. Degradación do rendemento das aplicacións Canarias e Principais
O incidente foi causado por desaceleracións e un aumento da frecuencia de erros nas aplicacións web canarias e principais de Gitlab.com. Varios valores de Apdex foron violados.
Abrir tarefa de incidencia:
Principais achados
Aquí tes algunhas cousas que aprendín durante a miña semana de servizo.
1. As alertas son máis útiles cando se detectan desviacións da norma.
As alertas pódense dividir en varios tipos:
- Alertas baseadas nun valor límite determinado, como "Ocurriron 10 erros 5xx por segundo".
- Alertas nas que o limiar é un valor porcentual como "frecuencia de erros 5xx por 10 % do volume total de solicitudes nun momento determinado".
- Alertas baseadas na media histórica como "erros 5xx no percentil 90".
En xeral, os tipos 2 e 3 son máis útiles para os SRE de servizo, xa que revelan desviacións da norma no proceso.
2. Moitas alertas nunca escalan a incidentes.
Os enxeñeiros de SR xestionan un fluxo constante de alertas, moitas das cales non son realmente críticas.
Entón, por que non limitar as túas alertas só ás realmente importantes? Con este enfoque, non obstante, é posible que non recoñeza os primeiros síntomas do que converterá unha bola de neve nun problema real que ameaza con danos importantes.
O traballo do SRE de garda é determinar cales son as alertas que realmente indican algo grave e se hai que intensificalas e tratarlas. Sospeito que isto tamén se debe á inflexibilidade das alertas: sería mellor que houbese varios niveis ou formas "intelixentes" de configurar as alertas de acordo coa situación descrita anteriormente.
Suxestión de funcións:
3. Os nosos SRE de servizo usan moitas ferramentas.
Interno:
- Proxecto GitLab infra: Runbooks viven aquí, asignacións de quendas/semanas, tarefas de resposta a incidentes.
- Problemas de GitLab: as investigacións, as revisións e o mantemento tamén se rastrexan nos problemas.
- Etiquetas de GitLab: as tarefas de automatización lánzanse usando etiquetas específicas, que os bots usan para rastrexar a actividade das tarefas.
Externo:
- PagerDuty: alertas
- Slack: o fluxo de mensaxes de PagerDuty/AlertManager vai aquí. Integración con comandos de barra para realizar unha variedade de tarefas, como pechar unha alerta ou escalar un incidente.
- Grafana: visualización de métricas con foco en tendencias a longo prazo.
- Kibana: dá visualización/busca de rexistros, capacidade de afondar en eventos específicos.
- Zoom: hai unha "sala de descanso" en funcionamento constantemente en Zoom. Isto permite aos enxeñeiros de SRE discutir eventos rapidamente sen perder un tempo valioso creando unha sala e vinculando os participantes.
E moitos outros.
4. O seguimento de GitLab.com con GitLab é un único punto de falla
Se GitLab.com experimenta unha interrupción importante do servizo, non queremos que afecte a nosa capacidade para resolver o problema. Pódese deter iniciando unha segunda instancia de GitLab para xestionar GitLab.com. De feito, isto xa nos funciona: .
5. Algunhas funcións que debes considerar engadir a GitLab
- , semellante a Google Docs. Isto axudaría nas tarefas sobre incidentes durante un evento, así como nas tarefas de debriefing. En ambos os casos, varios participantes poden necesitar engadir algo en tempo real.
- Máis webhooks para tarefas. A posibilidade de executar diferentes pasos do fluxo de traballo de GitLab desde dentro axudará a reducir a túa dependencia das integracións de Slack. Por exemplo, a capacidade de permitir unha alerta en PagerDuty mediante un comando de barra inclinada nun problema de GitLab.
Conclusión
Os enxeñeiros de SRE teñen dificultades con moitas complexidades. Sería xenial ver máis produtos de GitLab abordando estes problemas. Xa estamos a traballar nalgunhas incorporacións ao produto que facilitarán os fluxos de traballo mencionados anteriormente. Detalles dispoñibles en .
Ampliaremos o equipo en 2020 para reunir todas estas excelentes funcións. Se estás interesado, consulta , e non dubide en contactar con calquera persoa do noso equipo con calquera dúbida.
Fonte: www.habr.com