Unico Outage History

**Postmortem: Instabilidade no Serviço de Integração IDunico e liveness** ‌ **Resumo** Em 7 de abril de 2026, uma instabilidade na infraestrutura causou erros intermitentes e alta latência em nossa plataforma. Aproximadamente 3% das transações foram afetadas durante o período do incidente. A equipe de engenharia diagnosticou e mitigou o problema, restabelecendo a estabilidade normal dos serviços. ‌ **Impacto** O problema impactou principalmente as etapas de criação de processos e validações do sistema. Diversos clientes relataram erros HTTP 500, recebendo mensagens de tempo limite de requisição e operações canceladas. O impacto na disponibilidade teve início às 19:41 e a plataforma foi totalmente estabilizada às 21:25 do horário local. ‌ **Causa Raiz** A causa principal do incidente foi a saturação no controlador da malha de serviços \(service mesh\) e o consequente atraso na sincronização de configurações com as aplicações. ‌ * Esse cenário foi desencadeado por eventos de escalonamento \(aumentos e reduções\) da infraestrutura. * A falha na sincronização fez com que as aplicações entrassem em um estado de degradação, resultando em uma latência até 13 vezes maior que o normal. * Como essas instâncias degradadas não chegaram a falhar completamente ou a reiniciar sozinhas, os alertas padrões de saúde do sistema, que monitoram falhas totais, não foram acionados. **Resolução** A estabilidade foi restaurada após a equipe técnica identificar a causa e reiniciar manualmente as instâncias que apresentavam alta latência. Como medida adicional imediata, foi aplicada uma atualização nas configurações para forçar uma melhor distribuição das aplicações entre os servidores da infraestrutura, evitando a concentração de carga em um único nó. ‌ **Lições Aprendidas** * **Monitoramento e Alertas:** A ausência de alertas específicos para degradação prolongada de latência atrasou o diagnóstico. A implementação de alertas baseados em aumentos sustentados de tempo de resposta é necessária para reduzir drasticamente o tempo de detecção de problemas semelhantes no futuro. * **Distribuição de Carga:** A prática recomendada de evitar a alocação de múltiplas aplicações no mesmo servidor não estava sendo aplicada de forma universal. Isso acabou amplificando o impacto do incidente quando os recursos da infraestrutura foram saturados. * **Escalonamento e Resiliência:** A análise revelou que eventos agressivos de redução de escala em ambientes de infraestrutura dinâmica podem causar sobrecarga na malha de serviços e gerar falhas em cascata. É essencial revisar as políticas de escalonamento e as regras de rede dos serviços virtuais para garantir uma operação mais resiliente e segura.

**Postmortem: Instabilidade no Webhook Validação via Open Finance - IDPay** ### Resumo Entre os dias 25 e 31 de março de 2026, ocorreu um incidente que afetou nossa integração com o provedor de Open Finance, onde os _webhooks_ recebidos passaram a ser bloqueados com um erro de autorização \(erro 401\). Essa interrupção impediu a conclusão de pagamentos, fazendo com que as transações de nossos clientes ficassem presas no status "aguardando". ### Impacto O impacto direto aos clientes ocorreu entre às 23:05 do dia 25 de março de 2026 e às 13:08 do dia 31 de março de 2026. Durante esse período de aproximadamente cinco dias, um total de 7.101 transações não puderam ser concluídas automaticamente e permaneceram no status "aguardando". Nenhum evento de _webhook_ do nosso provedor parceiro foi processado com sucesso ao longo dessa janela de tempo. ### Causa Raiz A origem do problema foi devido a uma atualização de sistema em nossa camada de _Gateway_ de API, realizada no dia 25 de março por volta das 23:00, que tinha o objetivo de implementar limites de taxa \(_rate limiting_\) para um de nossos clientes corporativos. O _design_ dessa atualização utilizou um caminho de roteamento genérico, o que fez com que a nova política HTTP fosse aplicada a todos os _endpoints_, incluindo a rota específica de recebimento de _webhooks_ do nosso provedor de Open Finance. Essa nova política modificava os cabeçalhos de requisição automaticamente, adicionando o prefixo "Bearer" a qualquer cabeçalho de Autorização que não o possuísse. ‌ Como nosso provedor de integração utiliza um _token_ de acesso opaco e sem prefixo, o sistema modificou a requisição e a camada de segurança tentou validar esse novo formato como se fosse um _token_ JWT padrão. A validação falhou, resultando no erro de acesso negado \(401\). O erro não foi identificado na fase de testes \(ambiente de homologação/UAT\) porque existia uma divergência de configuração: o ambiente de testes possuía tratamentos de exceção para esse caminho específico, configurações estas que estavam ausentes no ambiente de produção. ### Resolução Ao identificar a causa raiz do problema no dia 31 de março, nossa equipe de engenharia executou uma reversão \(_rollback_\) imediata da atualização do _Gateway_ de API para a sua versão anterior. Essa ação removeu a política que alterava os cabeçalhos HTTP, restaurando o processamento normal dos _webhooks_. Logo após a confirmação da estabilidade sistêmica, todas as 7.101 transações afetadas que estavam presas foram reprocessadas e normalizadas com sucesso. ‌ ### Lições Aprendidas Durante a investigação e resolução deste incidente, identificamos oportunidades importantes de melhoria em nossa infraestrutura e processos operacionais: * **Necessidade de Alertas Específicos:** O problema durou dias de forma silenciosa pois não havia uma monitoria sistêmica ou alarmes configurados especificamente para a queda abrupta no volume de recebimento de _webhooks_. Fluxos dependentes de processos assíncronos precisam de mecanismos independentes de detecção de falhas. * **Paridade entre Ambientes:** A diferença de configuração entre os ambientes de teste e produção permitiu que a atualização fosse considerada segura erroneamente. É essencial garantir a paridade estrita entre os ambientes para evitar falsos positivos na validação de implantações. * **Gestão de Políticas Globais:** A utilização de roteamento amplo \(caminhos genéricos\) na aplicação de políticas de segurança introduz o risco de afetar rotas com requisitos de autenticação não padronizados. Exceções sistêmicas devem ser validadas e mapeadas explicitamente em todas as camadas de configuração.

# Postmortem: Instabilidade no serviço de liveness ## Sumário Entre as **09:01** e **09:13 BRT** do dia **30 de março de 2026**, identificamos uma instabilidade que afetou a disponibilidade dos plugins do SDK Web para um grupo específico de clientes. O incidente resultou em falhas de carregamento de recursos essenciais, impactando a execução de fluxos de biometria e liveness. ‌ ## Impacto O incidente causou a indisponibilidade total dos serviços de SDK para três clientes específicos que utilizavam uma configuração regional de exceção. ‌ * **Duração:** 12 minutos. * **Escopo:** Clientes operando em um ambiente regional específico, resultando em uma queda do indicador de disponibilidade \(SLO\) para abaixo de 95% durante o período. ## Causa Raiz A falha foi originada por um erro de automação durante a atualização de rotas de tráfego. ‌ Após a migração de versões do SDK, foi necessário realizar um ajuste de configuração para um grupo de clientes. No entanto, a ferramenta de automação \(GitHub Action\) utilizou uma versão obsoleta e com erros que estava armazenada em cache, em vez de carregar a versão corrigida mais recente. ‌ Como consequência, o processo de automação gerou um endereço de destino inexistente para as requisições, tornando o serviço inacessível para os clientes afetados. ‌ ## Resolução O incidente foi detectado via alertas automáticos de monitoramento às **09:09**. A equipe técnica identificou rapidamente a inconsistência no cache da automação e aplicou uma correção manual nas rotas de tráfego, restabelecendo a normalidade dos serviços às **09:13**. ‌ ## Lições Aprendidas * **Gerenciamento de Cache em CI/CD:** Identificamos a necessidade de implementar mecanismos mais rígidos de invalidação de cache para automações críticas que gerenciam infraestrutura de produção. * **Validação de Alvos de Roteamento:** Implementaremos etapas de validação \(health checks\) para garantir que qualquer novo endereço de destino seja verificado antes que as alterações de tráfego sejam aplicadas. * **Critérios de Comunicação:** Revisamos nossos processos de transparência para garantir que a comunicação em páginas de status siga critérios objetivos de impacto e jornada do usuário. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.‌ Atenciosamente, Equipe Unico.

# Postmortem: Instabilidade no Serviço de Alerta de comportamento ID Trust ## Sumário No dia **28 de março de 2026**, o serviço de Avaliação de Risco apresentou uma degradação significativa de performance, resultando em tempos de resposta elevados e falhas pontuais. O incidente foi desencadeado por um aumento repentino e massivo de tráfego proveniente de um único cliente, o que sobrecarregou nossos provedores de serviços externos \(APIs de terceiros\) localizados no México. ‌ ## Impacto O incidente teve início aproximadamente às **06:07 BRT**. Durante o período de pico, observamos os seguintes efeitos: ‌ * **Latência:** O tempo de resposta \(p99\) do processo de avaliação saltou de valores próximos de zero para um intervalo entre **8 e 9 segundos**. * **Conformidade de SLO:** A disponibilidade do serviço caiu para cerca de **97%**, ficando abaixo da meta estabelecida de 98,5%. * **Erros de Terceiros:** Nossos provedores externos começaram a retornar erros de _timeout_ \(HTTP 504\) e cancelamento de contexto devido à incapacidade de processar o volume de requisições recebido. ## Causa Raiz A causa principal foi a **saturação de recursos de terceiros** devido à falta de mecanismos de controle de tráfego por cliente no nível da nossa API Gateway. ‌ Um cliente específico iniciou um lote de requisições legítimas com um volume agressivo, atingindo cerca de **7-8 RPS** \(Requisições por Segundo\), o que representa mais de dez vezes o volume do segundo maior cliente e supera em quatro vezes o pico histórico de tráfego da região afetada. Além disso, a configuração de retentativas \(_retries_\) do sistema amplificou a carga sobre os provedores externos, agravando o cenário de saturação. ‌ ## Resolução O incidente foi mitigado através de duas frentes: 1. **Limitação de Taxa \(Rate Limiting\):** A engenharia aplicou uma regra de controle de tráfego específica para o cliente em questão, limitando o volume a 300 RPM \(Requisições por Minuto\). 2. **Segurança de Borda:** Coincidentemente, regras automatizadas de segurança da camada de rede identificaram o padrão de tráfego como anômalo e bloquearam as requisições excedentes \(HTTP 403\). Com essas medidas, o tráfego foi normalizado e a latência do sistema retornou aos níveis operacionais esperados por volta das **07:00 BRT**. ‌ ## Lições Aprendidas * **Proatividade no Controle de Tráfego:** A ausência de limites de taxa pré-configurados por cliente permitiu que um único usuário impactasse a infraestrutura compartilhada e outros clientes. * **Visibilidade de Erros:** Identificamos que certos erros de provedores externos estavam sendo suprimidos internamente, o que mascarou inicialmente a gravidade da falha nas métricas de aderência. * **Amplificação de Carga:** O uso de políticas de retentativa agressivas \(4 tentativas\) pode ser prejudicial durante incidentes de saturação; reduzir esse número ajuda a aliviar a carga em sistemas degradados. * **Ajuste de Políticas de Segurança:** Embora o bloqueio automático por segurança tenha ajudado na mitigação, ele não foi uma ação deliberada de infraestrutura, ressaltando a necessidade de revisar regras para evitar que tráfego legítimo de alta densidade seja confundido com ataques. Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.‌ Atenciosamente, Equipe Unico.

**Postmortem: Instabilidade no Serviço de Integração By Unico** ‌ **Resumo** No dia 26 de março de 2026, um de nossos serviços de processamento de documentos sofreu uma degradação temporária. A disponibilidade global da operação afetada caiu para 93,89%, ficando abaixo da nossa meta estabelecida de 97%. ‌ **Impacto** Durante o pico do incidente, a operação apresentou uma taxa de erro de 15,6%. Aproximadamente 2.000 requisições de clientes falharam ao longo de uma janela concentrada de quatro minutos, especificamente entre 23:03 e 23:07 \(horário de Brasília\). Serviços dependentes relataram erros de instabilidade e conexões recusadas durante esse período de indisponibilidade. O impacto foi encerrado e a estabilidade restaurada por volta das 23:38. ‌ **Causa Raiz** A análise detalhada confirmou que a interrupção foi causada pela saturação de recursos no nosso banco de dados, que atingiu 100% de utilização de CPU. Esse esgotamento foi desencadeado por um aumento substancial e não previsto no volume de tráfego de um cliente específico durante um evento de grande visibilidade ao público. O pico de acessos coincidiu com um processo interno de otimização de cache em execução no mesmo período, gerando uma severa contenção no banco de dados. Como consequência, o número de conexões abertas disparou de uma média de 80 para cerca de 500, resultando em até 300 processos bloqueados simultaneamente. Adicionalmente, a sobrecarga causou falhas nas verificações de integridade da aplicação, levando a reinicializações que agravaram a disponibilidade temporariamente. ‌ **Resolução** Nossos sistemas de alerta automatizados detectaram a violação de disponibilidade imediatamente, e a equipe de resposta a incidentes reconheceu e iniciou a atuação em apenas 1 a 2 minutos após o primeiro disparo. A equipe conseguiu identificar rapidamente a janela de impacto e isolar as falhas nos primeiros 10 minutos. Após a dissipação do surto repentino de tráfego, os serviços e o banco de dados estabilizaram-se sozinhos e a disponibilidade retornou aos níveis normais de operação. ‌ **Aprendizados** * **Eficiência na Detecção:** Nossas ferramentas de observabilidade provaram ser eficientes, permitindo que a equipe correlacionasse sinais em múltiplos serviços quase em tempo real e de forma estruturada. * **Gestão de Carga:** Identificamos que a configuração atual do banco de dados não está dimensionada de forma ideal para gerenciar o volume massivo de conexões concorrentes geradas por surtos anômalos de requisições. * **Impacto de Processos Internos:** Operações pesadas de otimização de cache durante picos de tráfego representam um risco para a estabilidade da aplicação. **Ações Preventivas** * **Otimização de Consultas:** Refatorar o padrão de consultas e as atualizações de cache no banco de dados para minimizar a latência e o consumo excessivo de recursos de CPU. * **Revisão de Provisionamento:** Avaliar e ajustar os limites de capacidade e resiliência do banco de dados e da infraestrutura subjacente para suportar aumentos extremos de carga com maior fluidez de conexão.

# Postmortem: Instabilidade no Serviço de Integração IdTrust ## Resumo No dia **26 de março de 2026**, entre **16:30 e 16:52 \(BRT\)**, observamos uma degradação significativa na performance de componentes críticos de nossa infraestrutura de biometria. O incidente resultou em um aumento súbito de latência e erros de conexão, impactando a taxa de sucesso de integração de novos processos. A situação foi normalizada automaticamente após a estabilização da infraestrutura de nuvem, sem necessidade de intervenção manual direta para a recuperação dos serviços. ‌ ## Impacto O incidente teve uma duração aproximada de **22 minutos**, com o período de maior instabilidade concentrado em uma janela de **5 minutos**. ‌ * **Disponibilidade:** Alguns endpoints apresentaram queda de disponibilidade para níveis entre **60% e 70%** durante o pico do evento. * **Latência:** O tempo de resposta para processamentos críticos \(p99\) saltou de uma média de 900ms para picos superiores a **10 segundos**. * **Clientes:** O impacto foi sentido por pelo menos **10 clientes corporativos** que utilizam nossas jornadas de verificação de identidade. ## Causa Raiz A instabilidade foi desencadeada por eventos de **preempção de nós \(Spot Nodes\)** em nosso cluster de processamento principal. Devido à natureza dessas instâncias de custo otimizado, o provedor de nuvem pode solicitar o desligamento imediato das máquinas para recuperar capacidade. ‌ A severidade do impacto ocorreu devido a dois fatores técnicos principais: 1. **Ausência de Desligamento Gracioso:** Os serviços afetados não possuíam uma configuração de _preStop hook_, o que impediu que as conexões em andamento fossem finalizadas corretamente antes do encerramento do contêiner, causando erros de rede imediatos. 2. **Configuração de Timeouts Internos:** A comunicação entre os componentes internos não possuía limites de tempo \(_timeouts_\) otimizados, fazendo com que as requisições ficassem "presas" aguardando resposta de nós que já haviam sido removidos, o que gerou o efeito cascata de latência. ## Resolução O sistema recuperou a estabilidade de forma orgânica assim que novos nós foram provisionados pelo orquestrador de contêineres e as cargas de trabalho foram redistribuídas. A equipe de engenharia confirmou a normalização dos indicadores de saúde \(liveness\) e latência às **16:52**. ‌ ## Lições Aprendidas Este incidente destacou vulnerabilidades em nossa estratégia de resiliência para cargas de trabalho críticas: * **Priorização de Infraestrutura:** Identificamos que serviços vitais para a jornada do cliente não devem depender exclusivamente de instâncias passíveis de interrupção imediata sem mecanismos robustos de tolerância a falhas. * **Padronização de Ciclo de Vida:** A configuração de encerramento gracioso deve ser um requisito padrão para qualquer serviço que processe tráfego síncrono. * **Gestão de Capacidade de Rede:** Gargalos de infraestrutura \(como exaustão de IPs no cluster\) podem atuar como bloqueadores ocultos para a execução de melhorias preventivas, devendo ser monitorados proativamente. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.‌ Atenciosamente, Equipe Unico.

# Postmortem: Instabilidade no Serviço de Integração IDSerpro ## Resumo No dia 23 de março de 2026, identificamos uma instabilidade que afetou a conclusão de fluxos de autenticação biométrica que utilizam uma base de dados governamental de terceiros. O incidente foi causado por uma degradação de performance no provedor externo, o que resultou em erros internos e tempos de resposta acima do esperado em nossa plataforma. A situação foi normalizada após o ajuste de nossas configurações de tolerância a latência. ‌ ## Impacto Durante o período de instabilidade, usuários de diversos parceiros e setores enfrentaram dificuldades para finalizar processos de verificação de identidade. ‌ * **Disponibilidade:** O índice de sucesso do serviço de autenticação ficou temporariamente abaixo da nossa meta \(SLO\) de **95,5%**. * **Experiência do Usuário:** Clientes finais encontraram erros de "timeout" ou falhas inesperadas ao tentar realizar a biometria facial em fluxos integrados ao serviço afetado. ## Causa Raiz A investigação técnica revelou que o serviço externo de biometria passou a operar com latências significativamente elevadas, atingindo picos de **4,5 a 6 segundos** por requisição. ‌ Nossa integração estava configurada com um tempo de espera rígido \(timeout\) de **5 segundos**. Como o provedor externo excedeu esse limite de forma intermitente, o sistema encerrava as conexões prematuramente e reportava erros de processamento, em vez de aguardar a conclusão da verificação. ‌ ## Resolução A equipe de engenharia agiu prontamente para mitigar o impacto seguindo estes passos: 1. **Diagnóstico:** Identificamos a origem externa da latência e confirmamos a instabilidade com o fornecedor. 2. **Ajuste de Configuração:** Aumentamos o limite de tempo de espera \(timeout\) da integração de **5 para 30 segundos**. 3. **Estabilização:** Esta mudança permitiu que as requisições, embora mais lentas, fossem concluídas com sucesso, restaurando a disponibilidade do serviço e normalizando os fluxos de autenticação. O incidente foi totalmente resolvido em **51 minutos** após o primeiro alerta. ‌ ## Lições Aprendidas Este evento trouxe aprendizados importantes para fortalecer nossa resiliência: * **Resiliência a Terceiros:** Reforçamos a necessidade de implementar estratégias adaptativas, como _circuit breakers_ e sistemas de retentativa \(retries\) mais robustos, para que falhas em dependências externas não causem interrupções diretas aos nossos usuários. * **Monitoramento Preditivo:** Estamos aprimorando nossos alertas para detectar aumentos graduais de latência em serviços externos antes que eles atinjam os limites críticos de erro. * **Equilíbrio de Performance:** Avaliamos o compromisso entre tempo de resposta e taxa de sucesso, garantindo que o sistema saiba priorizar a conclusão da jornada do usuário mesmo em cenários de degradação externa. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.‌ Atenciosamente, Equipe Unico.

**PostMortem: Instabilidade no Serviço de Assinatura Digital \(ID Sign\)** ### Resumo Em 20 de março de 2026, observamos uma degradação na disponibilidade do nosso fluxo de criação de processos. Durante um período de aproximadamente 31 minutos, falhas inesperadas impediram a criação de processos que possuíam envelopes de assinatura. ### Impacto O incidente ocorreu entre 10:49 e 11:20 \(Horário de Brasília\). Durante essa janela de tempo, múltiplos clientes foram afetados pelas falhas. Como consequência, a taxa de disponibilidade do serviço de criação de processos caiu para abaixo do limite da nossa meta de nível de serviço \(SLO\). ### Causa Raiz O problema foi desencadeado pelo envio repentino de cargas de dados contendo documentos vazios \(com tamanho de 0 bytes\) entre os serviços internos. O serviço responsável por criar os envelopes de assinatura não possuía uma validação adequada para exigir um tamanho mínimo de documento. Como resultado, o sistema aceitava os arquivos vazios e tentava prosseguir com o processamento. Ao falhar na etapa de upload, o serviço retornava um erro genérico de servidor, em vez de rejeitar imediatamente a requisição inválida com uma mensagem clara de validação. A causa raiz exata que levou o serviço de origem a enviar esses arquivos vazios de forma repentina ainda está sob investigação, visto que o problema começou e parou de forma uniforme e sem que nenhuma alteração de código ou configuração tivesse sido feita. ### Resolução O incidente foi resolvido espontaneamente ao final da janela de impacto de 31 minutos. O envio de documentos com conteúdo válido foi normalizado, e o fluxo de serviços se recuperou sozinho, sem a necessidade de intervenções manuais, reversões \(rollbacks\) ou implantações por parte da nossa equipe. ### Ações Futuras * **Validação de Dados:** Implementar validações defensivas rigorosas para rejeitar arquivos vazios ou inválidos logo na entrada, retornando um erro claro indicando argumentos inválidos em vez de falhas genéricas de servidor. * **Investigação de Origem:** Continuar a investigação interna para entender o motivo pelo qual o serviço de origem gerou o envio temporário de dados vazios, prevenindo futuras recorrências. * **Melhoria na Comunicação:** Aprimorar o processo para garantir que as atualizações em nossa página de status sejam publicadas mais rapidamente durante incidentes que afetam múltiplos clientes. ### Lições Aprendidas * **O que funcionou bem:** Nossos sistemas de monitoramento baseados em métricas de SLO detectaram a degradação e alertaram a equipe rapidamente, antes mesmo de percepções manuais. Além disso, a equipe conseguiu investigar e correlacionar os erros com os tamanhos de arquivo quase imediatamente, isolando a falha em menos de uma hora. * **Oportunidades de melhoria:** A ausência de uma validação defensiva estrita entre as fronteiras dos nossos serviços permitiu que dados inválidos se propagassem de forma silenciosa e gerassem erros confusos. Também identificamos que a declaração formal do incidente ocorreu com atraso. Uma comunicação oficial mais rápida melhorará a coordenação e a transparência contínua com nossos clientes.

## Postmortem: Instabilidade nos serviços de notificações via Webhook ID Cloud ### Resumo Em 19 de março de 2026, o serviço responsável pela publicação de eventos de Change Data Capture \(CDC\) — essencial para a entrega de notificações via webhook — apresentou falhas intermitentes. O serviço entrou em um ciclo de reinicialização automática após falhas de comunicação com o provedor de nuvem, resultando em atrasos no processamento de notificações para diversos clientes. ‌ ### Impacto O incidente durou aproximadamente **10 minutos**, entre 08:33 e 08:43 BRT. Durante este intervalo, as atualizações de status que deveriam ser entregues em tempo real sofreram atrasos. ‌ * Cerca de **12.177 notificações** de webhook foram retidas temporariamente na fila de processamento. * Dois clientes de grande porte concentraram a maior parte do volume afetado, com aproximadamente **8.340** e **3.393** atualizações atrasadas, respectivamente. * Não houve perda de dados ou comprometimento da integridade das informações; todas as mensagens foram entregues com sucesso após a estabilização do serviço. ### Causa Raiz O incidente foi desencadeado por uma combinação de fatores técnicos e de infraestrutura: * **Instabilidade no Provedor de Nuvem:** Ocorreu um pico transitório de latência no serviço de mensageria do Google Cloud, resultando em erros de conexão e tempos de resposta extremamente elevados. * **Limitação de Design do Conector:** O componente utilizado para processar as mensagens estava configurado para tratar qualquer tempo de espera \(timeout\) superior a 30 segundos como um erro fatal e não recuperável. * **Volume de Processamento:** Devido a um grande lote de mensagens sendo processado simultaneamente, o atraso em apenas 11 delas foi suficiente para exceder o limite de tempo e derrubar o serviço por completo. * **Configurações de Legado:** O serviço ainda operava com parâmetros de configuração antigos, que não incluíam políticas de retentativa ou tolerância a falhas de rede temporárias. ### Resolução Após a identificação do gargalo na infraestrutura de nuvem e das falhas no serviço de saída, a equipe técnica realizou a reinicialização dos componentes afetados. Uma vez restabelecida a conectividade com o provedor de nuvem, o sistema processou automaticamente o acúmulo de mensagens em cerca de 5 minutos, normalizando a entrega de todas as notificações pendentes. ‌ ### Lições Aprendidas * **Desacoplamento de Melhorias e Migrações:** Identificamos que melhorias críticas de resiliência não devem ficar estritamente atreladas a grandes migrações de infraestrutura, sob o risco de manter serviços expostos a falhas conhecidas por mais tempo do que o necessário. * **Redução do Raio de Exposição:** O uso de lotes de processamento muito grandes pode aumentar o impacto de falhas isoladas. Ajustar o tamanho desses lotes ajuda a isolar problemas de rede. * **Monitoramento Proativo de Latência:** A ausência de alertas específicos para latência de publicação impediu uma detecção precoce antes que o limite de interrupção do serviço fosse atingido. * **Resiliência como Padrão:** Configurações de retentativa e tratamento de erros devem ser padronizadas em todos os conectores de dados para suportar a volatilidade natural de ambientes de nuvem. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.‌ Atenciosamente, Equipe Unico.

# Postmortem: Instabilidade Parcial na Prova de Vida/Liveness ## **Sumário** No dia 13 de março de 2026, entre 19:00 e 19:15 \(BRT\), o serviço **Liveness Platform Predict** apresentou uma degradação significativa, com a disponibilidade caindo para aproximadamente **85%**. O incidente foi desencadeado por um pico atípico e repentino de tráfego que excedeu a capacidade de processamento imediata da infraestrutura e dos mecanismos de escalonamento automático. ‌ ## **Impacto** * **Duração:** Aproximadamente 15 minutos. * **Experiência do Usuário:** Cerca de **15% das transações** falharam durante a janela de pico. * **Erros Observados:** Os usuários enfrentaram erros de limite de taxa \(HTTP 429\), erros internos do servidor \(HTTP 500\) e falhas de conexão devido a desconexões prematuras \(timeout\). * **Conformidade de SLO:** A conformidade do nível de serviço caiu de uma meta de 99,8% para a faixa de 84-85%, consumindo totalmente o orçamento de erro planejado para o período. ## **Causa Raiz** O incidente foi resultado de uma combinação de três fatores principais: 1. **Pico de Tráfego Exacerbado:** Um único locatário apresentou um volume de requisições de aproximadamente **6.000 por segundo**, superando drasticamente o limite acordado de 350 TPS. 2. **Headroom de Latência Reduzido:** O componente principal de processamento estava operando com uma latência de linha de base muito próxima ao seu limite de _timeout_ de 6 segundos. Sob carga extra, as requisições excederam esse limite, impedindo o processamento bem-sucedido. 3. **Instabilidade na Camada de Rede \(Escalonamento Agressivo\):** O sistema de escalonamento automático reagiu tentando criar centenas de novas instâncias simultaneamente. Essa rápida expansão sobrecarregou o plano de controle da rede e esgotou os recursos de IP disponíveis no cluster, gerando falhas de conexão em vez de alívio de carga. ## **Resolução** A equipe de engenharia detectou a queda de disponibilidade em menos de 2 minutos através de alertas automáticos. A mitigação foi alcançada através das seguintes ações: ‌ * **Ajuste de Capacidade Mínima:** O número mínimo de instâncias ativas foi elevado manualmente para 500. * **Estabilização da Latência:** Com o aumento da capacidade fixa, a latência de processamento retornou ao patamar de **3 segundos**, estabilizando o serviço e restabelecendo a disponibilidade normal. ## **Lições Aprendidas** * **Revisão de Timeouts:** Identificamos que a derivação gradual da latência base precisa ser acompanhada de revisões periódicas nas configurações de _timeout_ para garantir margem de segurança operacional. * **Refinamento de Escalonamento:** O comportamento de escalonamento automático agressivo pode ser contraproducente se a infraestrutura de rede subjacente não estiver preparada para a velocidade da expansão. * **Governança de Tráfego:** É necessário reforçar os limites de tráfego por cliente antes que picos inesperados possam impactar a plataforma de forma global. * **Mapeamento de Erros:** Certos padrões de erro de rede não estavam adequadamente mapeados em nossos sistemas de interrupção de circuito, o que dificultou a contenção automática da falha. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.‌ Atenciosamente, Equipe Unico.

# Postmortem: Incidente de Disponibilidade na Plataforma de Biometria e Liveness ## Resumo Em 12 de março de 2026, nossa plataforma de captura de dados e biometria enfrentou uma degradação significativa de serviço. O incidente foi desencadeado por um pico repentino de tráfego que sobrecarregou o servidor de modelos de _liveness_, levando a um aumento drástico na latência e a uma queda acentuada na disponibilidade para o processamento de inferências. ## Impacto Entre **09:10 e 09:22 \(BRT\)**, a disponibilidade para os fluxos de biometria e _liveness_ caiu para níveis próximos a **1%**, afetando todos os clientes que utilizavam esses serviços no período. O sistema apresentou lentidão extrema e erros de tempo de resposta \(_timeout_\), impactando a experiência do usuário final. A estabilidade total das métricas foi confirmada às 17:31, após a implementação de ajustes estruturais. ## Causa Raiz A investigação identificou uma falha de design na forma como o sistema lidava com saturação de carga. O incidente seguiu a seguinte progressão: 1. **Pico de Requisições:** Um aumento inesperado no volume de tráfego proveniente de setores específicos sobrecarregou o servidor de modelos. 2. **Degradação Silenciosa:** A aplicação de inferência aceitou mais conexões simultâneas do que sua capacidade de processamento permitia. Em vez de rejeitar o excesso de carga com erros rápidos, o sistema tentou processar todas as requisições, o que causou uma disputa de recursos de CPU. Isso elevou o tempo de resposta de 2 segundos para mais de 30 segundos. 3. **Invisibilidade do Circuit Breaker:** Os mecanismos de proteção da rede não detectaram a falha, pois as desconexões dos clientes por lentidão e as respostas de limite de taxa \(_Rate Limit_\) foram interpretadas como eventos normais de rede, impedindo o isolamento automático dos componentes degradados. 4. **Efeito Cascata:** O tempo de inicialização de novos recursos para escala automática foi insuficiente para absorver o impacto imediato, sobrecarregando ainda mais as instâncias ativas. ## Resolução Para mitigar o problema e restaurar o serviço, foram tomadas as seguintes medidas: * **Ajuste de Configurações:** Revertemos alterações recentes nos limites de detecção de anomalias que se mostraram contraproducentes sob estresse. * **Gestão de Tráfego:** Implementamos novos limites locais de taxa de transferência e consolidamos as janelas de escalonamento para garantir que o sistema estivesse melhor preparado para picos de demanda. * **Estabilização:** As alterações foram implantadas via ferramentas de entrega contínua, e a estabilidade da latência foi confirmada após o deploy final às 17:31. ## Lições Aprendidas * **Falha por Lentidão vs. Falha por Erro:** Aprendemos que o sistema deve ser configurado para "falhar rápido" \(_fail fast_\). Aceitar requisições além da capacidade nominal causa degradação silenciosa, que é mais difícil de detectar e corrigir do que erros explícitos. * **Visibilidade do Mesh:** Identificamos a necessidade de tornar erros de limite de taxa \(429\) e desconexões de clientes visíveis para os mecanismos de auto-recuperação da malha de serviços. * **Backpressure:** A ausência de limites estritos de fila de conexões impediu a geração de pressão reversa \(_backpressure_\) necessária para proteger a integridade do sistema. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.‌ Atenciosamente, Equipe Unico.

# Postmorte: Instabilidade nos serviços de mensagerias da Unico, impactando todos os produtos integrados aos fluxos de mensagens via WhatsApp ## **Resumo** No dia **10 de março de 2026**, nossos serviços enfrentaram dificuldades na entrega de mensagens e no recebimento de confirmações \(callbacks\) de notificações enviadas via WhatsApp. O problema foi originado por uma instabilidade global em um provedor externo, impactando a comunicação em tempo real com os usuários finais. ‌ ## **Impacto** O incidente ocorreu entre **13:50 e 15:12** \(horário de Brasília\). Durante esse período: ‌ * Aproximadamente **1.560 transações** foram afetadas pela falta de confirmação de entrega. * Houve uma degradação significativa na taxa de sucesso das mensagens, com picos de falha reportados em torno de **39%** em determinados canais. * Clientes que dependiam de notificações instantâneas para fluxos de autenticação e transações experimentaram atrasos ou ausência de status. ## **Causa Raiz** A falha foi identificada como uma **dependência externa**. O provedor da API do WhatsApp Business \(Meta\) apresentou instabilidades na infraestrutura de entrega de mensagens. Embora nossos parceiros tenham monitorado a situação, a causa técnica específica da instabilidade não foi divulgada publicamente pela Meta até o momento. ‌ ## **Resolução** A recuperação do serviço ocorreu de forma gradual à medida que a infraestrutura da Meta foi estabilizada. ‌ * **13:48:** Início da detecção de falhas nos callbacks. * **14:40:** Identificação de instabilidade generalizada e início da investigação técnica. * **15:12:** Confirmação de que as mensagens voltaram a ser entregues e os logs de erro cessaram. * **15:29:** O incidente foi declarado resolvido após monitoramento da normalização das taxas de entrega. ## **Lições Aprendidas** * **Dependência de Terceiros:** O incidente reforçou a necessidade de planos de contingência para serviços que dependem exclusivamente de APIs de terceiros, cujas falhas fogem ao controle direto da nossa engenharia. * **Monitoramento Granular:** Identificamos uma oportunidade de melhoria em nossa observabilidade. Atualmente, nossos alertas são segmentados, e a percepção da falha geral exigiu uma análise manual. Implementaremos alertas de visão macro para detectar anomalias globais de callback com maior agilidade. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.‌ Atenciosamente, Equipe Unico.

# Postmortem: Instabilidade ID Sign para Assinaturas Multidocumentos ## Sumário Entre o final de fevereiro e o início de março de 2026, identificamos uma instabilidade que impedia a conclusão de assinaturas em envelopes que continham mais de um documento. O problema foi originado por uma falha na validação de eventos de aceite no carregamento da interface, impedindo que os usuários finalizassem o processo de assinatura conforme o esperado. ## Impacto O incidente afetou exclusivamente os fluxos de assinatura de envelopes com múltiplos documentos. * **Volume de erro:** Foram registrados **32.006 erros de validação** durante o período. * **Experiência do Usuário:** O sistema apresentava incorretamente todos os documentos como "aceitos" na interface, liberando o botão de submissão prematuramente. Ao tentar concluir, o usuário recebia um erro de validação \(Precondition Failed\), pois o sistema de segurança detectava que nem todos os documentos haviam sido tecnicamente processados. ## Causa Raiz A falha foi causada pela reintrodução de um erro de lógica em uma atualização de software. ‌ * **Falha Técnica:** O método responsável por retornar os dados do envelope passou a enviar apenas as informações de aceite relativas ao primeiro documento do pacote. * **Consequência:** Como o painel frontal recebia dados incompletos, ele "entendia" que o fluxo estava completo e ignorava as etapas de validação obrigatórias para os demais documentos, resultando em uma falha de conformidade no momento da assinatura final. ## Resolução Após a detecção e análise do comportamento anômalo, a equipe técnica realizou o **rollback** \(reversão\) para a versão estável anterior \(2.262.0\). ‌ * A reversão foi concluída com sucesso no dia 06 de março de 2026. * As taxas de erro caíram imediatamente após a aplicação da versão anterior, confirmando a estabilização do serviço. ## Lições Aprendidas * **Prevenção de Regressão:** Identificou-se que este era um problema recorrente que já havia sido tratado anteriormente, o que destaca a necessidade de testes de regressão mais rigorosos para fluxos específicos de múltiplos documentos. * **Monitoramento de Interface vs. Backend:** O incidente revelou uma discrepância entre o que o usuário visualizava \(sucesso falso\) e o que o backend processava, reforçando a importância de alertas baseados em erros de validação de contrato. * **Gestão de Cache:** Observou-se que, mesmo após a correção, alguns erros residuais ocorreram devido a sessões antigas armazenadas em cache, o que servirá de insumo para melhorar as estratégias de invalidação de cache em futuras correções. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.