“A folha saiu errada. Vários funcionários receberam o dobro de adicional noturno.”
Essa frase, que chegou via mensagem no canal de suporte numa manhã de segunda-feira, parecia apenas mais um bug em produção. Mas, à medida que o time mergulhava na investigação, percebemos que o problema ia muito além de um
ifmal posicionado.Era hora de parar de tapar buracos e começar a entender o porquê real das falhas. Era hora de aplicar a Análise de Causa Raiz.
O começo: um bug como qualquer outro
O time responsável pelo módulo de folha de pagamento do nosso ERP recebeu a notificação:
clientes estavam reportando valores incorretos no adicional noturno do mês anterior.
Após uma análise inicial, o dev de plantão identificou que funcionários que bateram ponto entre 22h e 00h estavam tendo o adicional duplicado ou deslocado para o dia seguinte.
No código, a lógica de cálculo baseava-se no horário UTC da base de dados:
const inicioAdicional = dayjs(entrada).hour() >= 22;
Como o servidor rodava em UTC e os dados vinham em BRT, o horário registrado como "22h" no Brasil aparecia como "01h" do dia seguinte no banco.
— “Ah, é só ajustar a conversão do horário, já corrijo isso e faço o deploy.”
Feito. A folha foi reprocessada. RHs acalmaram-se. Vida que segue.
Mas no mês seguinte… o erro voltou, só que em outro ponto do cálculo.
E aí a ficha caiu: estávamos tratando efeitos, não a causa.
Por que Análise de Causa Raiz (RCA) importa tanto?
A Análise de Causa Raiz (Root Cause Analysis) é uma técnica usada para identificar a verdadeira origem de um problema — não apenas a sua manifestação visível.
Ela é amplamente utilizada em engenharia de software, SRE, DevOps, qualidade, e até em setores como saúde, segurança e indústria.
Ao invés de perguntar:
“Como eu resolvo esse bug agora?”
A RCA propõe:
“Por que isso aconteceu em primeiro lugar e o que posso mudar para que nunca aconteça de novo?”
Como aplicamos RCA na prática
1. Técnica: 5 Porquês (Five Whys)
Começamos com a técnica mais simples: perguntar repetidamente “por quê?” até chegar à causa raiz.
Aplicação no nosso caso:
Por que os adicionais noturnos estavam errados?
Porque estavam sendo calculados para o horário errado.Por que o cálculo usou o horário errado?
Porque o horário do ponto foi registrado em UTC.Por que estávamos usando UTC sem converter?
Porque a função de cálculo usavadayjssem configuração de timezone.Por que o timezone não foi configurado corretamente?
Porque a nova lib (day.js) não ajusta automaticamente o fuso horário.Por que isso não foi detectado antes?
Porque os testes automatizados não cobriam fuso horário e horários críticos como 22h ou 00h.
Conclusão: o problema não era apenas técnico — era estrutural: ausência de configuração de timezone + lacunas de teste.
2. Técnica: Análise de Mudança (Change Analysis)
Aqui, buscamos o que mudou recentemente que poderia ter causado o problema.
Aplicação:
- Dois dias antes do incidente, foi feito merge de um PR que trocou
moment.jsporday.js. - O objetivo era otimizar o bundle e melhorar performance.
- Porém,
day.jsnão tem suporte nativo para timezone — exige o uso de pluginutc+timezone.
Uma pequena mudança técnica acabou gerando um impacto funcional crítico, porque o contexto de negócio não foi considerado.
3. Técnica: Análise de Barreiras
Esta técnica nos ajuda a identificar quais proteções falharam e permitiram que o bug escapasse.
Aplicação:
Testes automatizados?
Existiam, mas não cobriam cenários com fuso horário nem jornadas noturnas. Os dados simulados usados em desenvolvimento seguiam uma jornada fixa de 08h–17h, que não refletia os casos reais de trabalho noturno ou de virada de dia. Como resultado, os testes automatizados não cobriam cenários com adicional noturno, viradas de datas ou DST (horário de verão). Isso criou uma falsa sensação de segurança, já que os testes “passavam”, mesmo com a regra incorreta no código.Revisão de código?
Foi feita, mas por um revisor júnior sem conhecimento de folha. Outro ponto importante foi a falta de alinhamento entre os times técnico e de produto. A ausência de um entendimento compartilhado das regras de negócio (como adicional noturno, jornada cruzando datas e impacto de timezone) dificultou a prevenção da falha. Quando o conhecimento está isolado ou implícito em um único time, decisões técnicas acabam desconsiderando aspectos funcionais fundamentais.Homologação funcional?
Foi realizada pelo time técnico e com dados genéricos, sem simular casos reais como jornada noturna. O deploy foi direto para produção sem validação do time de produto.
Múltiplas barreiras falharam em sequência, revelando fragilidade no processo, não apenas no código.
4. Técnica complementar: Diagrama de Ishikawa (Espinha de Peixe)
Essa técnica ajuda a visualizar categorias de causas em torno do problema.
| Categoria | Causa |
|---|---|
| Pessoas | Revisor sem experiência em folha de pagamento |
| Ferramentas | CI sem testes com timezone |
| Processo | Homologação funcional não exigida |
| Ambiente | Servidor usa UTC, usuários estão em BRT |
| Dados | Seed não contempla jornada noturna |
| Testes | Sem cobertura de cálculos entre 22h e 05h |
Isso reforça que o problema é multifatorial, não um simples bug isolado.
Veja abaixo como representamos isso em um diagrama de Ishikawa:
Vale observar que o diagrama também passou por refinamentos. Algumas causas foram condensadas para evitar redundância (por exemplo, “homologação fraca” e “sem revisão de cálculo”), enquanto outras foram mais bem destacadas. Esse exercício ajuda o time a visualizar as relações de causa e a tomar decisões sobre onde atuar primeiro.
Como construímos o Diagrama de Ishikawa
O Diagrama de Ishikawa, também chamado de Espinha de Peixe, é uma técnica visual usada para organizar as causas de um problema em categorias.
Nesse caso, o problema analisado foi:
"Adicional noturno calculado errado"
A partir dele, identificamos 6 grandes categorias de causas:
- Pessoas
- Ferramentas
- Processo
- Ambiente
- Dados
- Testes
Para cada categoria, listamos:
- Detail: causas diretas
- Sub-detail: causas mais específicas
Por exemplo, na categoria Pessoas:
-
Detail: Revisor júnior
- Sub-detail: Sem experiência em folha
- Sub-detail: Regra não documentada
Esse processo foi feito em conjunto com o time, combinando:
- Técnica dos 5 Porquês
- Análise de mudança
- Inspeção do código
- Levantamento de barreiras que falharam
Ao visualizar as causas dessa forma, ficou claro que não foi apenas um erro na linha de código, mas sim uma cadeia de falhas organizacionais, técnicas e de comunicação.
Contradições corrigidas:
| Problema Original | Correção Aplicada |
|---|---|
| Produto deveria revisar PR | Embora o time de Produto não revise código diretamente, é fundamental que ele esteja envolvido na validação das regras de negócio implementadas. Para PRs que afetam processos sensíveis como folha ou financeiro, o time técnico pode incluir uma etapa de validação funcional conjunta com Produto antes da homologação final. Essa colaboração evita que regras críticas passem despercebidas por quem entende mais do código do que da lógica do negócio. |
| Termo “seed” não explicado | Agora explicado como conjunto de dados simulados para testes |
| “DST ignorado” poderia confundir | Explicado como ausência de testes em dias de ajuste de horário de verão |
Conclusão didática
Ao final da análise, o diagrama serviu como um mapa visual da falha. Ele mostrou que o erro não veio de um só lugar — mas sim de várias partes do sistema que não estavam conversando bem entre si.
O que fizemos diferente desta vez
Ações corretivas imediatas:
- Corrigimos o cálculo com suporte explícito a timezone:
dayjs.tz(entrada, 'America/Sao_Paulo').hour() >= 22
- Reprocessamos as folhas dos clientes afetados.
Ações preventivas (de verdade):
-
Adicionamos testes automatizados com:
- Horários limítrofes (22h, 00h, 05h)
- Fusos diferentes (BRT, UTC, etc.)
- Casos de horário de verão (DST)
Criamos um checklist obrigatório para PRs que alteram regras de negócio sensíveis (folha, cálculo, financeiro).
Padronizamos o uso de timezone nas camadas de API, backend e testes.
Integramos o time de analistas de produto para revisão de regras em PRs sensíveis.
O valor do postmortem com storytelling
Em vez de documentar esse incidente em um postmortem seco e técnico, optamos por um formato com storytelling — narrando o que aconteceu como uma história.
Isso ajudou a:
- Engajar o time
- Facilitar o entendimento para pessoas não técnicas
- Tornar o aprendizado mais memorável
- Alimentar uma cultura de engenharia focada em melhoria contínua
Lições finais: RCA não é luxo — é sobrevivência
Corrigir bugs sem entender sua causa é como secar o chão sem consertar o cano.
A RCA ajuda a:
- Parar de apagar incêndios recorrentes
- Aprender com cada falha
- Criar um sistema mais robusto
- Evoluir processos de forma sustentável
Checklist para aplicar RCA no seu time
- [ ] Paramos para refletir sobre o erro?
- [ ] Investigamos o que mudou no sistema?
- [ ] Aplicamos os “5 Porquês”?
- [ ] Mapeamos as barreiras que falharam?
- [ ] Produzimos um postmortem claro e compartilhável?
- [ ] Tomamos ações preventivas reais?
Conclusão
Aquele bug que começou como um “problema de fuso” revelou lacunas técnicas, falhas de processo e falta de alinhamento de negócio.
Mais do que resolver o incidente, usamos a RCA para melhorar a forma como trabalhamos — e isso é o que diferencia times que só corrigem bugs dos que evoluem de verdade.
E você? Está apagando incêndios ou resolvendo o problema certo?
Top comments (0)