Automações
Automação Compensatória (Rollback)
Para restaurar um estado aceitável após falha parcial, a automação compensatória executa ações inversas ou equivalentes às etapas já concluídas. Inspirada em sagas de sistemas distribuídos, é usada quando não existe transação ACID sobre dispositivos físicos. Um exemplo é desligar a bomba e reabrir uma válvula se a confirmação de fluxo falhar em 30 s. O erro comum é chamar de rollback perfeito: efeitos físicos, notificações e ações externas podem ser irreversíveis ou apenas compensáveis.
⚙ Definição Técnica
Automação compensatória, também chamada de rollback por compensação, é uma sequência planejada para reduzir, desfazer ou neutralizar os efeitos de etapas já concluídas quando uma operação composta falha antes de atingir o objetivo. O conceito não equivale a uma transação ACID com restauração exata, porque dispositivos físicos, APIs e pessoas não compartilham um banco transacional. Ele se aproxima do padrão Saga descrito em sistemas distribuídos desde a década de 1980: cada etapa possui uma ação de negócio e, quando necessário, uma compensação correspondente. Em uma casa inteligente, ligar bomba, abrir válvula, ajustar termostato, criar registro e enviar notificação podem ocorrer em serviços diferentes. Se a terceira etapa falha, o sistema executa compensações para as anteriores. A compensação precisa ser idempotente, condicionada ao contexto correto, observável e segura. Alguns efeitos são irreversíveis: uma mensagem enviada não pode ser desvista; apenas uma correção pode ser enviada. Água já liberada não retorna. Por isso, o objetivo é restaurar um estado aceitável e registrar divergências, não prometer reversão perfeita.
Tipos comuns de gatilhos
Compensação de sequência física
Uma automação abre válvula, liga bomba e espera fluxo. Se o sensor não confirma em 30 s, desliga bomba e fecha ou reabre a válvula conforme estado seguro. A ordem de compensação costuma ser inversa à execução, mas precisa seguir segurança física. Desligar a bomba antes de fechar pode evitar pressão. O controlador local deve possuir proteções independentes. Cada etapa registra sucesso e estado anterior. A compensação não deve operar um dispositivo se outra execução legítima assumiu controle depois. Use run_id, lock ou versão. Verifique o estado atual e a propriedade da operação. Se a comunicação falha, o resultado é desconhecido e exige alerta.
Compensação de cena parcial
Uma cena altera luzes, cortinas, climatização e áudio. Se o áudio falha, nem sempre é desejável desfazer tudo. A política pode ser best effort: manter ações úteis e apenas informar. Compensação deve ser proporcional ao objetivo. Em uma cena “sair de casa”, falhar uma lâmpada não deve reabrir fechaduras. Em “cinema”, pode restaurar brilho se a cortina não fechou. O projeto precisa classificar etapas obrigatórias e opcionais. Um rollback automático universal é perigoso. Capture estado anterior apenas dos dispositivos que serão restaurados. Estados podem mudar manualmente durante a execução; não sobrescreva a decisão do morador sem verificar contexto.
Compensação de integração com API
Um fluxo cria recurso em serviço A, registra em B e falha em C. A compensação exclui ou desativa os recursos anteriores. APIs podem não oferecer exclusão. Nesse caso, marque cancelado. A operação de compensação também pode falhar e precisa de retentativa e DLQ. Idempotency keys evitam duplicidade. O status deve incluir pending_compensation, compensated e compensation_failed. Em residência, exemplos incluem reservas, notificações, armazenamento de mídia e sincronização de configurações. O contrato da API define. Não use ação destrutiva sem confirmar que o recurso foi criado por esta execução. IDs retornados devem ser guardados.
Compensação por restauração de snapshot
Antes da mudança, a automação captura estados: brilho 40%, temperatura 23 °C, modo auto. Se falha, restaura. O snapshot precisa ser completo e válido. Alguns atributos não são graváveis. Restaurar estado antigo após minutos pode contrariar mudança manual. Inclua timestamp e contexto. Uma estratégia é compensar apenas se o estado ainda corresponde ao valor aplicado pela automação. Compare-and-set. Se o morador alterou, não sobrescreva. Para dispositivos unavailable, mantenha pendência ou alerte. O snapshot pode conter dados sensíveis e deve ter vida curta. Não presuma que state restoration do motor equivale a estado físico.
Compensação manual assistida
Quando o efeito é irreversível ou o risco é alto, a automação não age sozinha. Gera checklist, mostra etapas concluídas, estado atual e ações sugeridas. O operador confirma. Exemplo: falha durante atualização de fechadura ou mudança de configuração de segurança. A compensação automática poderia bloquear acesso. O sistema cria incidente e oferece botão seguro. Esse desenho custa mais tempo, mas reduz risco. O trace precisa ser claro. Para cada ação, indique consequência. A decisão deve usar autenticação forte. Automação compensatória inclui processos humanos quando o ambiente físico não permite reversão confiável.
Considerações de Implementação
Rollback perfeito raramente existe no mundo físico
Energia consumida, água liberada, mensagem enviada, gravação apagada e porta aberta não podem ser desfeitas integralmente. A compensação cria novo efeito para aproximar o estado desejado. O termo deve ser usado com honestidade. Defina invariantes: bomba desligada, válvula segura, acesso auditado. O sucesso é cumprir invariantes, não restaurar cada detalhe. Para ações irreversíveis, obtenha confirmação antes, use etapas preparatórias ou adie commit. Notificação corretiva não apaga a primeira. Logs devem manter ambas.
A compensação pode falhar e precisa de plano próprio
O mesmo serviço pode continuar indisponível. A válvula pode não responder. Cada compensação tem timeout, retries, estado e escalonamento. Não entre em loop infinito tentando “desfazer”. Após limite, marque compensation_failed e alerte. Funções críticas exigem mecanismo local fail-safe, não dependência do hub. Uma automação que falha e depois falha ao compensar é cenário esperado de projeto. Testes devem simular. O trace precisa mostrar ações originais e compensatórias separadas. A recuperação manual deve ser documentada.
Estado anterior precisa ser capturado antes do primeiro efeito
Sem snapshot ou registro de etapas, não se sabe o que restaurar. Capture apenas o necessário, com timestamp e versão. Em execuções paralelas, isole. Se a ação é idempotente e o estado seguro é conhecido, talvez seja melhor convergir para ele que restaurar. Exemplo: em vazamento, sempre fechar válvula, não voltar ao estado anterior. O objetivo de segurança supera rollback. O desenho deve escolher entre restauração, compensação e fail-safe. Não aplicar uma regra genérica a todos os dispositivos.
Saga e máquina de estados tornam o processo auditável
Modele estados: pending, running_step_1, running_step_2, compensating, compensated, completed e failed. Persista quando necessário. Cada etapa possui ação e compensação. O orquestrador decide. Para fluxos simples, um script com choose basta. Para longos, máquina de estados evita depender da memória de uma execução que pode reiniciar. O custo é mais código e armazenamento. O benefício é recuperação após falha e clareza. Critério: quanto maior a duração, criticidade e número de sistemas, mais explícito deve ser o modelo.