Engenheiro SRE — estagiário
Para começar, permita-me apresentar. Eu sou , engenheiro front-end no grupo do GitLab. Na semana passada, tive a honra de ser estagiário de um dos nossos engenheiros SRE de plantão. O objetivo era observar diariamente como o engenheiro de plantão reage a incidentes e ganhar experiência prática. Gostaríamos que nossos engenheiros compreendessem melhor as necessidades dos usuários Monitor::Health.
Eu tinha que seguir o engenheiro SRE durante toda a semana. Ou seja, eu estava presente na passagem de plantão, observando os mesmos canais de alerta e reagindo a incidentes, se e quando eles aconteciam.
Incidentes
Na semana, ocorreram 2 incidentes.
1. Minerador de criptomoedas
Na quarta-feira, foi registrado um aumento no uso do GitLab.com, causado por tentativas de utilizar minutos do runner para minerar criptomoeda. O incidente foi resolvido com a ajuda de nossa própria ferramenta de neutralização de violações, que interrompe tarefas do runner e remove os projetos e conta associados. Se esse evento não tivesse sido notado, ele teria sido capturado por uma ferramenta automatizada, mas neste caso, o engenheiro SRE percebeu a violação primeiro. Uma tarefa de incidente foi criada, mas as informações sobre ela estão escondidas.
2. Degradação de desempenho das aplicações Canary e Main
O incidente foi provocado por lentidões e aumento da frequência de erros nas aplicações web canary e main no GitLab.com. Vários valores de Apdex foram afetados.
Tarefa aberta sobre o incidente:
Principais conclusões
Aqui estão alguns pontos que percebi durante a semana de plantão.
1. Alertas são mais úteis quando detectam desvios da norma.
Os alertas podem ser divididos em vários tipos:
Alertas baseados em um valor de limiar, como "ocorreram 10 erros 5xx por segundo".
- Alertas onde o limiar é uma porcentagem, como "a frequência de erros 5xx representa 10% do volume total de requisições em um determinado período".
- Alertas baseados na média histórica, como "erros 5xx no 90º percentil".
- Em termos gerais, os 2º e 3º tipos são mais úteis para os engenheiros SRE de plantão, pois revelam desvios da norma durante o processo.
2. Muitos alertas não são escalados para incidentes
Os engenheiros SRE lidam com um fluxo constante de alertas, muitos dos quais não são realmente críticos.
Os engenheiros SRE lidam com um fluxo constante de alertas, muitos dos quais não são realmente críticos.
Então, por que não limitar as notificações apenas às realmente importantes? Com essa abordagem, no entanto, pode-se não reconhecer os primeiros sintomas que crescerão descontroladamente em um problema real, que pode causar grandes danos.
A tarefa do SRE de plantão é determinar quais notificações realmente indicam algo sério e se elas devem ser escaladas e investigadas. Suspeito que isso também seja causado pela inflexibilidade das notificações: seria melhor se houvesse vários níveis ou maneiras "inteligentes" de configurar as notificações de acordo com a situação descrita acima.
Proposta da funcionalidade:
3. Nossos SREs de plantão utilizam muitas ferramentas
Internas:
- Projeto de infraestrutura do GitLab: aqui residem os Runbooks, as transferências de plantão por turno/semana e as tarefas de resposta a incidentes.
- Problemas do GitLab: investigações, análises e manutenções também são rastreadas em tarefas.
- Etiquetas do GitLab: as tarefas de automação são iniciadas com base em etiquetas específicas, que os bots monitoram quanto à atividade das tarefas.
Externas:
- PagerDuty: notificações
- Slack: aqui é onde flui o canal de mensagens do PagerDuty/AlertManager. Integração com comandos de barra para realizar diversas tarefas, como fechar notificações ou escalá-las para incidentes.
- Grafana: visualização de métricas com foco em tendências de longo prazo.
- Kibana: oferece visualização/pesquisa em registros, permitindo aprofundar-se em eventos específicos.
- Zoom: há uma "sala de discussão" em funcionamento permanente no Zoom. Isso permite que os engenheiros SRE discutam rapidamente eventos, sem perder tempo precioso criando uma sala e enviando links para os participantes.
E muito, muito mais.
4. Monitorar GitLab.com usando GitLab — é um único ponto de falha
Se ocorrer uma grande falha de serviços no GitLab.com, não gostaríamos que isso afetasse nossa capacidade de resolver o problema. Pode ser contido iniciando uma segunda instância do GitLab para gerenciar o GitLab.com. Na verdade, isso já está funcionando para nós: .
5. Algumas funcionalidades a serem consideradas para adição ao GitLab
- , semelhante ao Google Docs. Isso ajudaria nas tarefas de incidentes durante um evento, bem como nas tarefas de análise. Em ambos os casos, vários participantes podem precisar adicionar algo em tempo real.
- Mais webhooks para tarefas. A capacidade de acionar diferentes etapas do fluxo de trabalho do GitLab internamente ajudará a reduzir a dependência de integrações com o Slack. Por exemplo, a possibilidade de ativar notificações no PagerDuty através de um comando de barra na tarefa do GitLab.
Conclusão
Os engenheiros de SRE enfrentam muitas dificuldades. Seria incrível ver mais produtos do GitLab abordando esses problemas. Já estamos trabalhando em algumas adições ao produto que facilitarão os fluxos de trabalho mencionados acima. Os detalhes estão disponíveis em .
Em 2020, estamos expandindo a equipe para reunir todos esses recursos incríveis. Se estiver interessado, por favor, confira , e não hesite em entrar em contato com alguém da nossa equipe para quaisquer perguntas.
Fonte: habr.com
