Engenheiro SRE - Estagiário
Primeiro, deixe-me me apresentar. Sou @ tristan.read , um engenheiro front-end do grupo Monitor :: Health do GitLab. Na semana passada, tive a honra de ser estagiário com um de nossos engenheiros de plantão. O objetivo era monitorar diariamente como o atendente responde aos incidentes e obter experiência de trabalho real. Gostaríamos que nossos engenheiros entendessem melhor as necessidades dos usuários dos recursos do Monitor :: Health.
Eu tive que seguir o engenheiro da SRE em todos os lugares por uma semana. Ou seja, participei da mudança de serviço, observei os mesmos canais de notificação e respondi a incidentes, se e quando eles ocorreram.
Incidentes
Durante a semana, ocorreram 2 incidentes.
1. Cryptominer
Na quarta-feira, o GitLab.com viu um salto no uso do GitLab Runner , causado por tentativas de usar os minutos do corredor na mineração de criptomoedas. Lidamos com o incidente usando nossa própria ferramenta para neutralizar violações, o que interrompe as tarefas do corredor e exclui o projeto e a conta associados a ele.
Se esse evento não tivesse sido notado, uma ferramenta automatizada o teria capturado, mas nesse caso, o engenheiro do SRE foi o primeiro a perceber a violação. Uma tarefa de incidente foi criada, mas as informações nela foram fechadas.
2. Degradação do desempenho das aplicações Canárias e Principais
O incidente foi desencadeado por desacelerações e um aumento da taxa de erros nos aplicativos canários e principais da Web no Gitlab.com. Vários valores do Apdex foram violados.
Tarefa de incidente aberta: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442
Principais conclusões
Aqui estão alguns pontos que aprendi durante a semana de serviço.
1. Os alertas são mais úteis quando são detectadas anormalidades.
Os alertas podem ser divididos em vários tipos:
- Ocorreram alertas com base em um valor limite específico, como "10 erros 5xx por segundo".
- Alertas nos quais o limite é um valor percentual do tipo "frequência de erros 5xx por 10% do volume total de solicitações em um determinado momento".
- Alertas com base na média histórica do tipo "erros 5xx no percentil 90".
De um modo geral, os 2º e 3º tipos são mais úteis para as SREs de serviço, uma vez que revelam desvios da norma no processo.
2. Muitos alertas nunca passam para incidentes
Os engenheiros da SR estão lidando com um fluxo constante de alertas, muitos dos quais não são realmente críticos.
Então, por que não limitar os alertas apenas aos realmente importantes? Com essa abordagem, no entanto, não é possível reconhecer os primeiros sintomas do que se transformará, como uma bola de neve, em um problema real, ameaçando grandes danos.
O dever do SRE de plantão é determinar quais alertas realmente falam de algo sério e se eles precisam ser escalados e começar a entender. Suspeito que isso também seja causado pela inflexibilidade dos alertas: seria melhor se vários níveis ou formas "inteligentes" de definir alertas fossem introduzidos de acordo com a situação descrita acima.
Sugestão de recurso: https://gitlab.com/gitlab-org/gitlab/issues/42633
3. Nossos atendentes de SRE usam muitas ferramentas.
Interno:
- Projeto infra GitLab: Runbooks moram aqui, turnos / semana, tarefas de resposta a incidentes.
- Problemas no GitLab: Investigação, análise e manutenção também são rastreadas nas tarefas.
- Rótulos GitLab: as tarefas de automação são iniciadas de acordo com certos rótulos, pelos quais os bots rastreiam a atividade das tarefas.
Externo:
- PagerDuty: Alerts
- Slack: o fluxo de mensagens do PagerDuty / AlertManager vai aqui. Integração com comandos de barra para executar uma variedade de 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: fornece uma visualização / pesquisa na revista, a capacidade de se aprofundar em determinados eventos.
- Zoom: existe uma “sala de discussão” em constante trabalho no Zoom. Isso permite que os engenheiros do SRE discutam rapidamente os eventos sem perder tempo valioso, criando espaço e links para os participantes.
E muito, muito mais.
Se ocorrer uma falha de serviço importante no GitLab.com, não queremos que isso afete nossa capacidade de resolver o problema. Pode ser interrompido executando a segunda instância do GitLab para instalar o GitLab.com. De fato, isso já funciona para nós: https://ops.gitlab.net/ .
5. Alguns recursos a serem considerados ao adicionar ao GitLab
- Edição de tarefas multiusuário semelhante ao Google Docs. Isso ajudaria nas tarefas de incidentes durante o evento, bem como na análise de tarefas. Nos dois casos, vários participantes podem precisar adicionar algo em tempo real.
- Mais webhooks para tarefas. A capacidade de executar várias etapas do fluxo de trabalho do GitLab a partir do interior ajudará a reduzir a dependência das integrações do Slack. Por exemplo, a capacidade de ativar a notificação no PagerDuty por meio de um comando de barra na tarefa GitLab.
Conclusão
Os engenheiros do SRE enfrentam dificuldades com muitas dificuldades. Seria ótimo ver mais produtos GitLab na solução desses problemas. Já estamos trabalhando em algumas adições de produtos que facilitarão os fluxos de trabalho mencionados acima. Os detalhes estão disponíveis na seção Ops Product Vision .
Em 2020, estamos expandindo a equipe para reunir todos esses ótimos recursos. Se estiver interessado, leia as vagas e não hesite em entrar em contato com alguém da nossa equipe para esclarecer qualquer dúvida.