Categoria: post-mortem

  • Interrupção no serviço isaCloud 2026-02-06 🐞

    Reading Time: 2 minutes

    Na madrugada de hoje, 06/02/2026, o serviço do isaCloud ficou indisponível às 01:45:

    Nesse momento, recebemos o alerta, porém devido a um impeditivo (muito sono), não foi iniciada nenhuma investigação.

    Às 6:40 iniciamos o troubleshooting e percebemos que o container que roda o serviço do isaCloud no servidor primário estava parado, com código de saída 137. O mesmo não reiniciava sozinho porque ele é configurado para política restart: unless-stopped. E isso já era um indicativo 🕵️‍♀️.

    Percebemos que ao iniciar o container novamente, o mesmo sempre parava após alguns segundos – impreterivelmente.

    Eventualmente isso ocorre com containers em caso de shared memory sendo excedida – e daí o container para. Fizemos o ajuste no docker-compose.yaml para setar um shm_size maior que o padrão do Docker que é muito pequeno. E então…. nada.

    Imaginamos que poderia estar ocorrendo algum bug inesperado na versão do Docker. Foi feito update dos pacotes e….RÁ! Nada…

    Foi então que começamos a desligar outros mecanismos que funcionam em conjunto com o serviço do isaCloud. Paramos o lsyncd e o novíssimo isaCloud HA Manager. E então…. FUNCIONOU, o container não caiu mais.

    Pois bem, eram 7:20 e era hora de tomar banho e sair pro escritório.

    Chegando no escritório fomos investigar os logs do lsyncd e do isaCloud HA Manager.

    O log do lsyncd aparecia um shutdown limpo, com SIGTERM, padrão. Próximo log a ser investigado era do isaCloud HA Manager (que está em validação ainda).

    Ao olhar o log do isaCloud HA Manager, no horário das 01:45 da manhã…

    A verificação de DNS externa do IP para onde o isaCloud está apontando começou a falhar. O serviço ipinfo.io parou de responder as requisições, gerando um valor inconsistente para a variável que contém o IP atual (nil) e por um bug, ao invés do isaCloud HA Manager abortar a rotina que assegura a role do servidor (primário ou standby), ele seguiu adiante entendendo que o servidor era standby e, com isso, parava o container do serviço.

    Pois é… se a Cloudflare e a AWS estão sujeitas a bugs que geram impacto em seus serviços, o isaCloud também 😇.

    O código do isaCloud HA Manager que estava em testes vai ser corrigido, criando condições melhores para tratamento de erros bobos como esse, especialmente quando é alguma rotina que depende de um serviço externo.

    Aprendizados

    Dos aprendizados desse incidente, temos:

    • Ser mais inteligente na hora de programar 🫏
    • Continuar firme sem vibe coding
    • Jamais parar de evoluir o serviço para que ele continue sendo confiável

    —

    Com carinho,

    Isadora,
    The XMPP Lady (fail edition)

  • Interrupções no serviço isaCloud 2026-01-13

    Reading Time: 2 minutes

    Na terça-feira, dia 13/01/2026, por volta de 06:40 AM foi percebida uma instabilidade na conexão com o servidor primário que atende o isaCloud Messenger na região nordeste-1 do datacenter Magalu Cloud.

    Nesse momento, tentamos acessar a console de gerenciamento dos serviços no Magalu Cloud, porém a própria console estava indisponível – já era um sinal de que algo mais generalizado estava ocorrendo.

    Conseguimos abrir chamado com o time do Magalu Cloud, informamos qual a instância e região que estavam indisponíveis e recebemos a informação de que o time de engenharia já estava atuando.

    Ficamos acompanhando na página de status de serviços deles e de fato o incidente foi registrado. Apesar de não especificar o problema, indicava que o serviço de Virtual Machines da região NE-1 estavam sendo impactados.

    A linha do tempo do incidente deles está neste link:

    https://status.magalu.cloud/incident/AthcGya5reLhDSid0WReNRcYrBAn5biUjH5iIhWyX-tLvo5gFdkQqRbyMIq-CwDIrV18uBzuQSGji6lCJtDNng==

    Do lado do isaCloud, ativamos nossa contingência na região BR-SE-1 (São Paulo) por volta de 8:40 AM. Usuários levaram no máximo 1h para conseguirem reconectar após a ativação da contingência devido à propagação de DNS na desec.io.

    Algumas medidas foram tomadas após o incidente para reduzir ainda mais o tempo de ativação da contingência:

    • Entradas no desec.io foram configuradas como CNAME para entradas que estão na Cloudflare pois esta oferece um TTL bem mais baixo (300s contra 3600s da desec.io).
    • O mecanismo de detecção dos papéis primário / standby do nosso cluster irá executar algumas ações automaticamente tão logo identificar uma mudança nesses papéis.

    —

    Por fim, gostaria pessoalmente de agradecer a todos os usuários pela compreensão de sempre e garantir que os 2 incidentes ocorridos em 1 ano de operação do isaCloud resultaram num amadurecimento dos nossos processos de backup e contingência.

    Saibam que o isaCloud é provido com muito carinho e comprometimento com cada um de vocês 💜

    Com carinho,
    Isadora

  • Interrupções no serviço isaCloud em 25 e 27/10/2025

    Reading Time: < 1 minute

    Nos últimos dias o serviço isaCloud passou por dois momentos de interrupção de serviço causados por uma falha técnica no ambiente de nuvem no datacenter primário utilizado pelo mensageiro.

    O isaCloud utiliza uma estrutura que conta com 4 datacenters, sendo dois no Brasil (Magalu Cloud) – um na região sudeste e outro na região nordesta – e dois na Europa (Contabo, Scaleway) – em dois diferentes provedores na Alemanha. Essa estrutura mantém uma replicação de 3 datacenters em tempo real e o 4º datacenter como base de monitoramento.

    Estamos ainda buscando com o Magalu Cloud mais detalhes técnicos sobre a interrupção de serviços que afetou nossa estrutura primária na região sudeste, mas no dia 25/10/2025 houve pelo menos um incidente em escala que foi reportado na status page deles:

    https://status.magalu.cloud/incident/AthcGya5reLhDSid0WReNRcYrBAn5biUjH5iIhWyX-vFGxu2AVIl1XMKcVUe4263npb7HAJWa_x3E6xjZMqFow==

    Sobre o incidente do dia 27/10/2025, ainda estamos buscando mais detalhes.

    A indisponibilidade total das duas interrupções somadas foi de mais de 20h, sendo que, no dia 27/10/2025, quando estava completando 3h de interrupção, executamos o plano de contingência e ativamos o datacenter secundário em outra região no Brasil.

    Conforme novas informações chegarem, atualizaremos esta publicação.

    Com carinho,
    Isadora

    Atualização – 28/10/2025 15:50

    Conforme o RCA enviado pelo time Magalu Cloud, o que afetou a instância primária do isaCloud tanto no dia 25 quanto no dia 27 foi uma falha no tenant físico onde estavam diversas instâncias. Foi confirmado pelo time deles que as instâncias foram migradas para um outro tenant do cluster.

    Por hora o isaCloud utilizará outra região como site primário e manterá o mecanismo de replicação para as demais regiões do Magalu, bem como para os 2 datacenters alocados na Europa.

    Com carinho,
    Isadora