Como reduzimos os erros no GOV.UK

Este artigo foi escrito por Chris Ashton e [Tim Motz](https://technology.blog.gov.uk / author / tim-motz-product-manager-gds /). Este artigo foi publicado pela primeira vez no Technology in Government GOV.UK Blog. Você pode ler o artigo original aqui .

Como todos os sites, GOV.UK às vezes enfrenta dificuldades técnicas. Isso pode ser causado por bugs no código, entradas inesperadas, carga pesada do sistema ou qualquer combinação dos itens acima. Problemas como esses são inevitáveis. O que podemos controlar é como os identificamos e os resolvemos rapidamente.

__• Quer escrever para nós? Dê uma olhada no [guia para colaboradores] do Apolitical (https://apolitical.co/opinion-writing-becoming-an-apolitical-contributor/) __

Nos últimos meses, reduzimos nossa contagem de erros em mais de 90%. Isso já nos permitiu descobrir novos problemas que antes se perdiam no meio do ruído. Também melhoramos a experiência do desenvolvedor integrando o relatório de erros ao Slack e melhorando nossa documentação. Envolvemo-nos com outras equipes para incentivar uma abordagem direcionada aos alertas do Slack, para manter nossa contagem geral de erros baixa.

Como rastreamos erros

No GOV.UK, rastreamos os erros usando um serviço externo chamado Sentry. Esta é uma plataforma de monitoramento que registra coisas inesperadas que ocorrem no GOV.UK. Fornece informações detalhadas para cada evento e permite que os desenvolvedores do GOV.UK descubram qual é o problema e como resolvê-lo. Outras ferramentas de monitoramento estão disponíveis; para obter uma explicação de por que escolhemos o Sentry, consulte esta [discussão no GitHub](https://github.com/alphagov/govuk-rfcs/blob/main/rfc-070-path-towards-continuous-deployment-cd.md # change-our-error-notification-framework).

Descobrimos que estávamos recebendo um número extremamente alto de erros a cada semana, tornando difícil navegar pelo Sentry. O alto número de erros também significa que o Sentinela não está armazenando todos os erros que enviamos, pois há um limite para o número de eventos que o Sentinela permite por hora. Os eventos acima do limite são descartados ("limitados por taxa"), não fornecendo aos desenvolvedores nenhuma informação para prosseguir e, no pior dos casos, nenhuma indicação de que haja um problema.

Precisávamos reduzir nossa contagem de erros no Sentry para nos colocar abaixo do limite de taxa e para ter certeza de que poderíamos detectar e lidar com novos problemas o mais rápido possível. Esta postagem do blog explica as 3 etapas que seguimos para fazer isso e como reduzimos nossa contagem de erros em mais de 90%.

O que queríamos melhorar

Embora o GOV.UK pareça um único site, ele é, na verdade, formado por mais de 50 aplicativos de front-end e back-end que são hospedados e mantidos de forma independente. Durante grande parte de 2020, registramos regularmente de 100.000 a 200.000 erros semanais nesses aplicativos. Isso parece extremamente alto, mas muitos deles podem ser atribuídos a um punhado de "questões" distintas. O Sentinela agrupa eventos em ocorrências, tornando mais fácil quantificar a frequência com que o problema ocorre. Também é possível escrever comentários sobre problemas e atribuir problemas aos desenvolvedores.

O grande número de problemas deixou o Sentinela barulhento. Isso não foi ajudado pelo fato de que muitos dos problemas pareciam estar duplicados, com problemas com o mesmo título aparecendo várias vezes na lista. Queríamos investigar como o Sentry agrupa seus problemas para ver se poderíamos configurá-lo para fazer um trabalho melhor.

O alto número de problemas foi agravado por ter uma conta GOV.UK Sentry compartilhada para todos os nossos ambientes. Um problema em um ambiente de teste pode nos fazer ultrapassar o limite de taxa e, portanto, dificultar o registro na produção. Era fundamental que reduzíssemos o número de eventos que enviamos para permanecer abaixo do limite, para que os problemas não se perdessem no sistema.

Finalmente, precisávamos de uma estratégia preventiva para impedir que o número de eventos aumentasse novamente.

Investigando agrupamento de Sentinelas

Por padrão, Sentry agrupa problemas por rastreamento de pilha, e se nenhum rastreamento de pilha estiver disponível, também observe o tipo / mensagem de exceção. No entanto, o Sentry também permite que você personalize como você agrupa os problemas, especificando seu próprio algoritmo de impressão digital, ou alterando a configuração na interface do usuário.

Investigamos se o agrupamento personalizado seria benéfico, auditando todos os problemas não resolvidos e considerando quais deveriam ser agrupados. Nossa auditoria mostrou muitos dos problemas que pareciam duplicados, na verdade, referiam-se a controladores e modelos diferentes, portanto, eram problemas separados, mesmo que parecessem semelhantes.

A auditoria destacou um problema: alguns problemas duplicados resultaram de [upgrades de dependência] inofensivos (https://www.gapintelligence.com/blog/application-dependencies-when-and-why-to-upgrade-them/), porque o a estrutura do arquivo da dependência mudaria ligeiramente, mudando o rastreamento de pilha (que o Sentry usa para agrupar questões). Na verdade, esses "rastros de estrutura" não são muito úteis para o agrupamento de problemas; o que nos preocupa é o ‘rastreamento do aplicativo’.

É possível "limpar" o rastreamento da pilha antes de enviá-lo para o Sentry, mas isso faria com que o rastreamento da pilha original nunca fosse registrado, perdendo informações valiosas de diagnóstico. Levantamos uma solicitação de recurso com o Sentry para usar apenas o rastreamento do aplicativo para agrupamento de problemas, enquanto ainda registra o rastreamento de pilha completo.

Concluímos que, no geral, o algoritmo de agrupamento padrão do Sentry funciona muito bem para nós.

Reduzindo os eventos enviados para o Sentry

Para recapitular, estávamos registrando muitos erros, o que significava que não tínhamos visibilidade dos erros que ocorreram acima do limite da taxa.

Criamos um painel Grafana para monitorar nossos erros no Sentry ao longo do tempo, para que pudéssemos medir o quão bem estávamos lidando com o problema. Também criamos um painel separado para erros em nosso aplicativo que mais gerava erros.

Este aplicativo registrava consistentemente quase 15.000 erros no Sentry todos os dias. Embora em grande volume, a maioria dos erros foi atribuída a um único problema, que parecia estar acontecendo apenas durante a [sincronização de dados] noturno (https://docs.publishing.service.gov.uk/manual/govuk-env- sync.html).

Todas as noites, todo o conteúdo do GOV.UK é copiado para nossos ambientes de teste e integração. Isso é obtido eliminando e recriando bancos de dados, o que significa que alguns serviços nesses ambientes podem ficar temporariamente indisponíveis e qualquer tentativa de fazer uma chamada para eles resulta em um erro. Esses erros específicos são inofensivos, esperados e não acionáveis, então queríamos impedir que eles fossem registrados no Sentry.

Decidimos implementar uma nova opção de configuração: uma lista de tipos de exceção que devem ser ignorados se ocorrerem durante a sincronização de dados. Isso foi adicionado ao nosso módulo GovukError, que nossos aplicativos usam para fazer interface com o Sentry. O efeito foi imediato: os erros no aplicativo que mais gerava erros caíram 98%.

Um aplicativo registrou consistentemente quase 15.000 erros por dia, até que aplicamos uma correção que quase os eliminou durante a noite (Gráfico: Gov.UK)

Continuamos a auditar o Sentry, escrevendo as questões mais prolíficas para desenvolvedores na [equipe de saúde da plataforma](https://insidegovuk.blog.gov.uk/2019/03/27/why-we-created-a-platform- health-team-on-gov-uk /) para trabalhar, então 'ignorando' o problema na interface do usuário do Sentry. Isso significava que os erros ainda estavam sendo registrados, mas não eram mais tão visíveis, o que ajudou a reduzir o ruído e nos permitiu detectar novos problemas à medida que surgiam. Nós ‘resolveríamos’ o problema assim que o consertássemos: este é um mecanismo útil, pois o Sentry envia um e-mail para o resolvedor do problema se o problema voltar.

Com o tempo, resolvemos os problemas de maior volume e fizemos outras melhorias em nossa configuração padrão, como apenas permitindo erros de ambientes específicos. Também nos tornamos mais específicos sobre o que deve ser registrado no Sentry, permitindo apenas erros de sistema acionáveis, e não, por exemplo, erros causados pelo usuário.

Conseguimos trazer nossa contagem geral de erros muito abaixo do limite de limitação de taxa. Nossa melhor semana foi em março de 2021, onde registramos apenas 5.500 erros; uma redução significativa nos mais de 100.000 erros que víamos regularmente de antemão.

Agora precisávamos começar a pensar em uma estratégia preventiva, para evitar que a contagem de erros aumentasse novamente.

Estratégia preventiva

Embora todos os nossos desenvolvedores tenham acesso ao Sentry, eles normalmente só fazem login no Sentry durante um [incidente](https://insidegovuk.blog.gov.uk/2015/11/18/what-happens-when-things-go-wrong -on-gov-uk /), ou para ficar de olho no funcionamento de um aplicativo durante a implantação. Isso torna mais fácil para que novos problemas passem despercebidos.

O Sentry possui uma integração com Slack que envia notificações quando ocorrem eventos, de acordo com as [regras de alerta] configuradas (https://docs.sentry.io/product/integrations/ slack / # alert-rules). Criamos um alerta para nos notificar quando um problema ocorre mais de 100 vezes no espaço de 60 minutos. Descobrimos que isso atinge o equilíbrio certo, pois prioriza nossos piores erros, evitando spam no canal. Esperamos reduzir gradualmente esse limite para que possamos resolver a "longa cauda" de problemas.

Um problema com essas notificações é que elas não são direcionadas: elas dependem de alguém que monitora o canal e se responsabiliza pelo problema. Muitos problemas surgem como resultado de mudanças no código feitas fora de nossa equipe, e seria muito mais eficiente notificar diretamente a equipe ou o desenvolvedor responsável pela mudança. Portanto, estamos incentivando outras equipes no GOV.UK a configurar seus próprios alertas do Slack para os aplicativos em que trabalham regularmente, o que esperamos evitará a introdução da maioria dos novos erros.

Próximos passos

A curto prazo, esperamos melhorar os alertas de produção que enviam nossa segunda linha e os desenvolvedores de plantão quando algo no GOV.UK precisa de uma resposta urgente. Além disso, estamos pensando em como podemos introduzir mais capacidade de observação no GOV.UK: [introduzimos recentemente o Real User Monitoring](https://insidegovuk.blog.gov.uk/2021/06/16/how- real-user-monitoring-will-improvement-gov-uk-for-everyone /), e estão considerando opções como Application Performance Management. Nosso projeto de reforma em andamento apresenta uma excelente oportunidade para projetar esses processos do zero. — Chris Ashton e Tim Motz

__ Queremos saber a sua opinião sobre este artigo. Proponha um artigo para nós ou envie seus comentários para [discussão@apolitical.co](mailto: Discussion@apolitical.co) __

(Crédito da imagem: Unsplash)