Resumo do incidente
Na última quinta-feira, 04/08/2022, registramos uma instabilidade ocasionada por um conjunto de fatores que causou um pico de utilização da Clicksign. O fato gerou a indisponibilidade parcial da plataforma no período entre 11:53 e 17:09, no horário de Brasília.Este incidente ocasionou instabilidades no envio de documentos para assinatura, no processo de assinatura dos signatários, além do atraso para recebimento de e-mails.
Como contingência, aumentamos a capacidade de processamento, porém a situação demorou a se normalizar.
Foi o incidente de maior duração da nossa plataforma e se trata de uma exceção. Confira o histórico de disponibilidade em nossa Página de Status (https://status.clicksign.com/uptime).
Por mais que instabilidade e quedas são passíveis de ocorrer, pedimos desculpas pelo ocorrido e sabemos como a Clicksign é fundamental para o funcionamento de muitos negócios. Reafirmamos nosso compromisso em fornecer estabilidade ímpar na plataforma.
Cronograma
Recebemos o primeiro alarme às 11:53 do dia 04/08/2022, informando que havia fila em nosso sistema. Esse alarme é normal e temos procedimentos “in place” quando esse tipo de situação ocorre. Na maioria das vezes, o sistema escala automaticamente e a fila é zerada em alguns instantes.
Após 9 minutos do alarme inicial, recebemos um alarme com a informação de pico de CPU em um dos nossos bancos de dados e neste momento, seguimos o protocolo padrão, onde realizamos o rollback dos últimos deploys e desativamos as últimas funcionalidades que entraram em produção, eliminando assim a hipótese de algum novo código com bug ter entrado em produção com problemas.
O time de DBA identificou que as consultas que estavam sendo realizadas no banco de dados naquele momento não tinham problemas de performance e, sim, de quantidade de consultas simultâneas.
O ambiente foi escalado para o nível máximo configurado no autoscaling e, mesmo assim, continuava cada vez mais lento e as filas de processamento acumulando mais jobs.
Nesse momento, identificamos que o tempo de resposta de um fornecedor de autenticação estava muito elevado, o que também ocasionava em maior tempo de espera para concretização das assinaturas.
Aqui fizemos um upgrade no broker que armazena as filas, pois a quantidade de conexões e requisições (throughput) estava perto de atingir seus limites. Começou, então, um ciclo vicioso: quanto mais demorava para o problema ser solucionado, mais solicitações eram geradas, maior ficava a fila de processamento e maior era o tempo de espera dos usuários.
Para sanar esta situação, às 13:49, desabilitamos o módulo de assinatura de documentos. Com isso, derrubamos a quantidade de requisições e os números começaram a melhorar. Às 15:21, a fila foi zerada, possibilitando o recebimento da assinatura dos signatários.
Após 20 minutos, a mesma situação voltou a ocorrer. A fila começou a aumentar novamente e chegamos a 50% do tamanho da fila anterior. Voltamos a bloquear o serviço de assinatura às 15:45.
Fizemos um novo upgrade do broker, que gerencia as filas, e também bloqueamos usuários que estavam fazendo uso abusivo da aplicação durante o incidente.
Às 16:38, o processamento voltou a zerar e liberamos novamente o módulo de assinatura. O monitoramento ativo continuou até o final do dia.
Alguns eventos precisaram ser reprocessados, como o disparo de alguns Webhooks, e isso foi feito na manhã do dia seguinte, 05/08.
Causa raiz:
O que ocorreu foi a conjunção dos seguintes fatores:
Medidas Corretivas e Preventivas