O desastre de julho, ou a importância de monitorar erros em tempo real
TL;DR: perdi várias semanas de novos usuários por causa de um bug aleatório na nova versão do VS Code. Lição: se puder, implemente monitoramento de erros em tempo real desde cedo.
Desenvolver um projeto solo é difícil. Você precisa se desdobrar em vários papéis: dev, designer, marketing, suporte e mais um monte. É preciso equilibrar várias tarefas e prioridades ao mesmo tempo, e às vezes alguma coisa passa batido.
Na primeira semana de julho, uma atualização aleatória do VS Code mudou o sistema interno de autenticação, fazendo as versões existentes do GitByBit entrarem em um loop infinito logo na inicialização. Na prática, ninguém conseguia usar o curso até esse problema ser resolvido. Sem desconfiar de nada, eu estava trabalhando na futura prática de pull request (que, aliás, é superlegal e saiu semana passada).
Em algum momento, alguém finalmente reportou o problema no GitHub, e aí consegui corrigir e lançar uma versão nova. Mas basicamente perdi várias semanas de novos usuários, porque eles não conseguiam usar o curso.
Quando você percebe que o seu projeto passou as últimas semanas sem funcionar.
A maioria dos meus outros projetos são web apps normais, servidos do meu próprio servidor. Como são construídos com frameworks populares, como Laravel ou React, é fácil integrar o app com algum sistema de monitoramento de erros em tempo real, como Sentry ou Rollbar. Assim, quando um erro acontece, sou notificado na hora, subo a correção para o servidor e todos os usuários a recebem imediatamente. Depurar o problema também é mais fácil, porque tenho acesso aos logs do servidor e consigo ver exatamente o que deu errado.
Só que o GitByBit não é um web app comum. Existe a extensão para VS Code e a versão web, cada uma com front-end e back-end separados. Tudo isso é construído com tecnologias diferentes, então monitorar erros não é tão simples quanto colocar uma chave de API do Rollbar em algum lugar da configuração. Até então, todos esses lugares enviavam telemetria de volta para o meu servidor principal, onde ela fica armazenada em um log centralizado.
Mas, infelizmente, não havia nenhum sistema de monitoramento para me alertar sobre erros em tempo real. Então, para descobrir os erros, eu tinha que abrir e ler isto aqui:
Não muito legível, a menos que você fale klingon.
Dá para monitorar logs assim de vez em quando, mas, a menos que seja logo depois de um lançamento, não é muito prático. Na maior parte do tempo, nada de ruim acontece, então você para de verificar os logs com frequência. Você até olha uma vez por semana, mais ou menos, mas aí outras coisas tomam o seu tempo e você esquece.
Na verdade, eu coleto... Mas também é preciso monitorar os logs, não só coletá-los.
Você parte do princípio de que, se algo der errado, vai ficar sabendo pelos usuários ou vai acabar vendo nos logs. Tem um fundo de verdade nisso, mas pode demorar até você notar o problema — e, a essa altura, talvez já tenha perdido um monte de usuários que não conseguiram usar o curso por causa do bug. Foi exatamente o que aconteceu com o projeto em julho.
Ei, Alex, você não era um desenvolvedor experiente? Por que não implementou um monitoramento de erros decente desde o início? Por que esperou até agora?
Ótima pergunta! Esse é o desafio de ser dev solo: é coisa demais para fazer, e você só tem duas mãos (espero). É preciso PRIORIZAR! Além disso:
- Eu já tinha logs básicos configurados, então dava para ver o que estava dando errado quando eu olhava.
- Eu estava atolado com todo o trabalho de conteúdo, então gastar semanas implementando infraestrutura de back-end não parecia uma prioridade tão grande.
- Isto aqui é acesso antecipado, então as pessoas meio que esperam encontrar problemas e bugs. Minha esperança era que, se algo desse errado, os usuários avisariam e eu corrigiria rápido.
Mas agora que o curso está ficando mais popular, acho que chegou a hora de ter um jeito melhor de monitorar erros e problemas em tempo real.
PostHog ao resgate
Faz alguns anos que tento me desgooglizar, mas ainda uso principalmente o Google Analytics nos meus projetos para acompanhar as interações dos usuários. Recentemente, descobri o PostHog e resolvi dar uma chance. Ele combina vários recursos de que preciso: rastreamento de eventos, gravação de sessões e monitoramento de erros. Também tem um plano gratuito generoso, então posso usá-lo no meu projeto em acesso antecipado sem me preocupar com custos por enquanto. E eles têm um mascote fofo, um ouriço chamado Max, que eu simplesmente adoro.
Se você não gosta do Max, você é uma pessoa ruim.
As diretrizes para desenvolvedores do VS Code proíbem usar scripts próprios de analytics dentro da extensão, principalmente por questões de desempenho e segurança. Porém, a telemetria coletada pela API do VS Code é permitida, então você pode recebê-la no seu servidor e reenviá-la para o PostHog ou qualquer outro serviço de analytics. Assim, ainda dá para acompanhar interações dos usuários e erros na sua extensão do VS Code sem violar as diretrizes.
Agora os erros são coletados em um formato legível, então consigo ver o que deu errado e onde. Erros duplicados são agrupados, então dá para ver quantos usuários foram afetados.
Cada erro traz uma boa quantidade de detalhes que podem ajudar a depurar o problema por trás dele. Depois que um erro é corrigido, você pode marcá-lo como resolvido, para que ele não fique bagunçando a lista.
Isso resolveu o problema de legibilidade e rastreamento, mas eu ainda precisava de um jeito de ser notificado sobre novos erros em tempo real. O PostHog tem um sistema de alertas embutido que envia notificações via Discord, Slack ou outros canais quando um erro novo acontece. Assim, fico sabendo de qualquer problema imediatamente e posso resolver rapidinho.
Agora, se eu ouço um fluxo constante de BOOP!!! vindo do Discord, sei que o curso quebrou. Aí posso conferir rapidinho o dashboard do PostHog e ver o que está errado.