Engenheiro SRE - estagiário
Primeiro, permita-me me apresentar. EU - , engenheiro front-end do grupo GitLab. Na semana passada tive a honra de estagiar com um de nossos engenheiros SRE de plantão. O objetivo era observar como o policial de plantão respondia diariamente aos incidentes e ganhar experiência real no trabalho. Gostaríamos que nossos engenheiros entendessem melhor as necessidades do usuário Monitorar::Saúde.
Tive que seguir o engenheiro do SRE por toda parte por uma semana. Ou seja, estive presente na entrega, monitorei os mesmos canais de alerta e respondi aos incidentes se e quando eles ocorreram.
Incidentes
Houve 2 incidentes em uma semana.
1. Minerador de criptografia
GitLab.com teve um salto no uso na quarta-feira 'a, causada por tentativas de usar os minutos do corredor para minerar criptomoedas. O incidente foi resolvido por meio de nossa própria ferramenta de neutralização de violações, que interrompe as tarefas do executor e exclui o projeto e a conta associada a ele.
Se esse evento não tivesse sido percebido, uma ferramenta automatizada o teria detectado, mas neste caso, o engenheiro do SRE percebeu primeiro a violação. Uma tarefa de incidente foi criada, mas as informações sobre ela estão fechadas.
2. Degradação de desempenho dos aplicativos Canary e Main
O incidente foi causado por lentidão e aumento na frequência de erros no canário e nos principais aplicativos da web no Gitlab.com. Vários valores de Apdex foram violados.
Tarefa de incidente aberto:
Principais descobertas
Aqui estão algumas coisas que aprendi durante minha semana de plantão.
1. Os alertas são mais úteis ao detectar desvios da norma.
Os alertas podem ser divididos em vários tipos:
- Alertas baseados em um determinado valor limite, como “ocorreram 10 erros 5xx por segundo”.
- Alertas em que o limite é um valor percentual como “frequência de erros 5xx por 10% do volume total de solicitações em um determinado momento”.
- Alertas baseados na média histórica, como "erros 5xx no percentil 90".
De modo geral, os tipos 2 e 3 são mais úteis para os SREs de plantão, pois revelam desvios da norma no processo.
2. Muitos alertas nunca se transformam em incidentes.
Os engenheiros de SR lidam com um fluxo constante de alertas, muitos dos quais não são realmente críticos.
Então, por que não limitar seus alertas apenas aos realmente importantes? Com esta abordagem, no entanto, poderá não reconhecer os primeiros sintomas do que se transformará num problema real que ameaça causar grandes danos.
O trabalho do SRE de plantão é determinar quais alertas realmente indicam algo sério e se eles precisam ser escalados e tratados. Suspeito que isso também se deva à inflexibilidade dos alertas: seria melhor se existissem vários níveis ou formas “inteligentes” de configurar alertas de acordo com a situação descrita acima.
Sugestão de recurso:
3. Nossos SREs de plantão utilizam muitas ferramentas.
Interno:
- Projeto de infra-estrutura GitLab: runbooks ao vivo aqui, atribuições de turno/semana, tarefas de resposta a incidentes.
- Problemas do GitLab: investigações, revisões e manutenção também são rastreadas em problemas.
- Rótulos GitLab: as tarefas de automação são iniciadas usando rótulos específicos, que os bots usam para rastrear a atividade da tarefa.
Externo:
- PagerDuty: Alertas
- Slack: o fluxo de mensagens do PagerDuty/AlertManager vai aqui. Integração com comandos de barra para executar diversas tarefas, como fechar um alerta ou escalar para um incidente.
- Grafana: visualização de métricas com foco em tendências de longo prazo.
- Kibana: Oferece visualização/pesquisa de log, capacidade de se aprofundar em eventos específicos.
- Zoom: Há uma “sala de descanso” em constante funcionamento no Zoom. Isso permite que os engenheiros do SRE discutam eventos rapidamente sem perder tempo valioso criando uma sala e conectando os participantes.
E muito, muito mais.
4. Monitorar GitLab.com com GitLab é um ponto único de falha
Se o GitLab.com sofrer uma grande interrupção no serviço, não queremos que isso afete nossa capacidade de resolver o problema. Ele pode ser interrompido iniciando uma segunda instância do GitLab para gerenciar o GitLab.com. Na verdade, isso já funciona para nós: .
5. Alguns recursos a serem adicionados ao GitLab
- , semelhante ao Google Docs. Isso ajudaria nas tarefas sobre incidentes durante um evento, bem como nas tarefas de interrogatório. Em ambos os casos, vários participantes poderão necessitar de acrescentar algo em tempo real.
- Mais webhooks para tarefas. A capacidade de executar diferentes etapas do fluxo de trabalho do GitLab ajudará a reduzir sua dependência das integrações do Slack. Por exemplo, a capacidade de permitir um alerta no PagerDuty por meio de um comando de barra em um problema do GitLab.
Conclusão
Os engenheiros de SRE enfrentam muitas complexidades. Seria ótimo ver mais produtos GitLab abordando esses problemas. Já estamos trabalhando em algumas adições ao produto que facilitarão os fluxos de trabalho mencionados acima. Detalhes disponíveis em .
Estamos expandindo a equipe em 2020 para reunir todos esses excelentes recursos. Se estiver interessado, por favor confira e sinta-se à vontade para entrar em contato com qualquer pessoa de nossa equipe em caso de dúvidas.
Fonte: habr.com