Atribua erros às equipes e atualize o status dos erros

Atribua o erro à equipe correta

Na página Error group summary , você pode atribuir o grupo de erros à equipe correta.

Atribuir um erro a uma pessoa ou equipe elimina possíveis falhas de comunicação. As informações que ajudaram a solucionar o erro são entregues diretamente ao proprietário do código, permitindo que ele continue de onde parou.

A tarefa é então entregue à equipe por e-mail:

Marque o status do erro

Depois de atribuído, você pode atualizar o status de um erro.

Essa funcionalidade tem alguns benefícios diferentes:

• Se um grupo de erros for esperado, você poderá marcar o erro como

  Ignored

  . erros esperados são conhecidos por você e pela equipe – podem ser bugs não críticos ou podem ser erros associados ao usuário final (como alguém usando uma senha incorreta).

• No entanto, recomendamos resolver o erro esperado tanto quanto possível. Ignorar um grupo de erros não impede que a New Relic relate o erro no futuro, o que contribui para a ingestão de dados.

• A New Relic rastreia o status de um erro ao longo do tempo. Por exemplo, se você marcar um grupo de erros como

  Resolved

  , mas ele aparecer posteriormente com uma nova implantação, o New Relic marcará esse erro como

  Regression

  .

Investigue a causa raiz

Esteja você reduzindo erros comuns ou reagindo a uma interrupção crítica, você está acompanhando dados que levam à causa direta de uma ocorrência de erro. Você pode ter consertado o vazamento do cano que inundou seu quintal, mas ainda não descobriu o que causou a rachadura.

Ao atribuir grupos de erros às equipes, é mais fácil realizar retrospectivas onde todos identificam quais processos levaram a uma interrupção. Para trazê-lo de volta ao seu cano rachado: você se encontra com um encanador e ele lhe diz que as árvores do seu quintal estão crescendo em todos os seus canos. Retrospectivas onde todos podem ver os mesmos dados levam naturalmente a melhorias no fluxo de trabalho geral de sua equipe.

Aqui estão algumas causas comuns para interrupções de serviço:

• Testes de garantia inadequados no pré-ambiente de produção.

• Deixar de testar todas as funções ou métodos em uma base de código para garantir que os resultados sejam os esperados.

• Não compreender os requisitos de dependência upstream, a capacidade ou suas limitações. Por exemplo, se uma consulta ao banco de dados funciona bem na pré-produção com cargas menores, mas sob estresse começa a ficar lenta.

• Falta de planejamento de capacidade. Talvez seu código passe em todos os testes usuais sob cargas normais, mas quando a demanda atinge o pico, ele não funciona.

  A causa raiz pode ser tão variável quanto o número de equipes existentes. A lição, porém, é seguir os dados, comunicar e ir mais fundo além da causa direta.