Recuperação de falhas

O que é

Recuperação de falhas é histórico de versões mais reversão instantânea para o seu aplicativo no ar. Cada mudança que você faz é salva como um ponto de restauração, então, se uma edição quebrar algo, você volta à última versão que funcionava com um clique. O que fica protegido é o aplicativo em funcionamento no seu domínio, não apenas um rascunho no editor.

Por que importa

Um sistema de negócio fica no ar o tempo todo — pedidos chegam, clientes fazem login, pagamentos são processados —, então a indisponibilidade causada por uma mudança ruim custa dinheiro e confiança de verdade. Poder desfazer na hora significa que você pode continuar melhorando o aplicativo sem apostar o negócio inteiro em cada edição. A segurança é o que torna sensato iterar sobre um sistema em funcionamento.

Como funciona no ybuild

O ybuild tira uma cópia instantânea do seu aplicativo a cada mudança e mantém o histórico completo por trás da versão em funcionamento. Se algo quebrar, você reverte para um ponto que sabia estar bom e o seu domínio volta a servir o aplicativo funcionando em instantes — sem backups para restaurar na mão. Como o ybuild hospeda o aplicativo, a recuperação é um clique, não um chamado de suporte.

O que um ponto de restauração realmente captura

Uma reversão vale tanto quanto aquilo que ela salva. A versão ingênua do "desfazer" guarda uma cópia do front-end e nada mais — o que é inútil para um aplicativo real, porque um sistema de negócio são quatro coisas funcionando juntas: o front-end que os seus clientes veem, a lógica de back-end que processa um pedido ou uma reserva, o esquema do banco de dados que dá forma aos seus registros e as regras de autenticação que decidem quem pode fazer login. Reverta uma delas sem as outras e você tem o pior tipo de defeito: uma tela que carrega bem, mas que aponta para um back-end que já não corresponde, disparando erros exatamente na ação que um cliente está tentando concluir.

É por isso que um ponto de restauração do ybuild versiona toda a pilha como uma única unidade. Toda vez que você muda o aplicativo, a plataforma captura uma cópia instantânea coerente — front-end, back-end, esquema e autenticação juntos —, de modo que a versão para a qual você reverte é um sistema que de fato funcionava, não um amontoado de peças desencontradas. Quando você restaura, o ybuild não reconstrói nada do zero; ele mantém de pé a versão anterior que funcionava e aponta o seu domínio de volta para ela. A recuperação é uma troca de ponteiro, e é por isso que ela parece instantânea, em vez de levar os minutos ou horas de uma reimplantação completa. É a mesma ideia que as grandes plataformas de nuvem usam quando mantêm duas versões de um aplicativo vivas e revertem virando um balanceador de carga em vez de reimplantar — o ybuild apenas faz isso de forma automática, no seu próprio domínio, sem que você configure nada.

Construir o seu próprio botão de desfazer vs. tê-lo no ybuild

Fazer isso por conta própria é um projeto de engenharia de verdade. A maneira tradicional de fazer mudanças em produção com segurança significa marcar cada build no controle de versão para conseguir identificar uma que você sabe estar boa, manter um ambiente de homologação que imite a produção bem o suficiente para você confiar nele, adotar uma implantação azul-verde ou canary para que uma reversão seja uma mudança de configuração em vez de uma correria e — a parte que afunda as pessoas em silêncio — manter os scripts de reversão das migrações do banco de dados sincronizados com o código, além de backups que você realmente tenha testado restaurar. Um backup que você nunca restaurou não é um backup; é um palpite.

Há um modo de falha ainda mais desagradável por baixo de tudo isso: a própria reversão pode falhar. Se uma implantação quebrada já migrou o seu banco de dados para um formato que o código antigo não consegue ler, reverter apenas o código deixa você preso entre as versões. Acertar nisso é exatamente o que separa os times fortes dos fracos. A pesquisa DORA do Google, a medida mais citada do setor sobre entrega de software, constata que times de elite se recuperam de uma falha em produção em menos de uma hora, enquanto os de baixo desempenho levam muito mais tempo — e que os times mais rápidos são também os mais estáveis, não os mais imprudentes. O problema é o custo: à medida que as metas de recuperação ficam mais agressivas, a infraestrutura para alcançá-las normalmente fica mais cara, e é por isso que configurações sérias de recuperação contínua historicamente estiveram fora do alcance de um fundador solo ou de um pequeno negócio.

No ybuild, nada disso é seu para construir ou pagar à parte. A plataforma versiona a pilha inteira a cada mudança, mantém as versões anteriores que funcionavam aquecidas para que uma reversão seja uma troca de ponteiro em vez de uma reconstrução, e expõe tudo isso como um único clique. Você obtém um comportamento de recuperação de nível elite sobre o aplicativo que você descreveu em linguagem simples — funcionando no ybuild, servido no seu próprio domínio — sem levantar ambientes de homologação, escrever reversões de migração ou testar backups na mão.

Os casos extremos e o que eles significam para um negócio no ar

As perguntas que mais importam são as que tratam dos seus dados. Quando você reverte um recurso quebrado, o que acontece com os pedidos que chegaram enquanto ele estava quebrado? A resposta certa, e aquela para a qual o ybuild foi feito, é que uma reversão devolve a lógica e a estrutura do aplicativo a uma versão que funcionava, enquanto os registros ao vivo no seu banco de dados gerenciado continuam se acumulando — de modo que desfazer uma edição ruim conserta o aplicativo sem apagar os clientes, as reservas ou os pagamentos que chegaram nesse meio-tempo. Essa distinção é o jogo inteiro: você está revertendo o aplicativo, não apagando o negócio.

Vale a pena saber onde os backups comuns param, porque isso explica por que o histórico de versões é uma ferramenta diferente. A Atlassian, que opera produtos em nuvem para empresas enormes, afirma sem rodeios que os seus backups de infraestrutura não são usados para reverter mudanças destrutivas iniciadas pelo cliente — um script que sobrescreve, um projeto apagado — e que as suas metas de recuperação miram indisponibilidades não planejadas, não os seus próprios erros. Em outras palavras, um backup de infraestrutura protege o data center; ele não lhe dá um desfazer limpo para uma mudança que você fez de propósito e que acabou dando errado. Esse desfazer é exatamente o que um ponto de restauração por mudança oferece, e é por isso que o ybuild mantém um histórico de versões rotulado que você pode percorrer para encontrar o último ponto bom em vez de adivinhar um horário.

Para um negócio no ar, isso é mais bem compreendido nos dois termos que o planejamento de recuperação de desastres usa: por quanto tempo você pode ficar fora do ar (o seu tempo de recuperação) e quanto você pode se dar ao luxo de perder (o seu ponto de recuperação). Num aplicativo de reservas ou de checkout, isso não são abstrações — cada minuto offline é receita indo embora e confiança se corroendo em tempo real. A reversão instantânea de um clique empurra os dois números para perto de zero. Mas a recompensa mais profunda é comportamental. Quando o desfazer é de fato instantâneo, você deixa de ter medo de mexer no aplicativo. Você publica a melhoria, testa o campo novo, muda o fluxo — porque o custo de errar é um clique, não um fim de semana perdido. Um negócio cujo dono não tem medo de melhorá-lo é um negócio que continua melhorando, e é isso que uma rede de segurança de verdade sob um sistema em funcionamento no seu próprio domínio realmente compra para você.

Perguntas frequentes

Se eu reverter, perco os pedidos e os clientes que chegaram desde então?

Não. Uma reversão devolve a lógica e a estrutura do seu aplicativo à última versão que funcionava, enquanto os registros ao vivo no seu banco de dados gerenciado continuam se acumulando. Desfazer um recurso quebrado conserta o aplicativo sem apagar os pedidos, as reservas ou os pagamentos que chegaram enquanto ele estava quebrado.

Até quando eu posso voltar?

O ybuild mantém o histórico de versões completo do seu aplicativo por trás da versão em funcionamento, então você pode restaurar qualquer ponto de restauração anterior que funcionava — não apenas o mais recente. Cada mudança é o seu próprio ponto rotulado, então você consegue encontrar o exato último momento bom em vez de adivinhar um horário.

Quão rápida é a recuperação — os clientes vão perceber?

É quase instantânea. O ybuild mantém a versão anterior que funcionava aquecida e reverte apontando o seu domínio para ela, então é uma troca de ponteiro e não uma reconstrução. O seu site volta a servir o aplicativo funcionando em instantes, em vez dos minutos ou horas que uma reimplantação manual ou a restauração de um backup levaria.

Isso não é só um backup?

É relacionado, mas mais forte. Backups protegem os seus dados; o histórico de versões mais a reversão protegem o aplicativo inteiro — front-end, back-end, esquema e autenticação juntos. Até as grandes plataformas observam que backups de infraestrutura não desfazem uma mudança que você fez de propósito e que deu errado. Os pontos de restauração por mudança do ybuild foram feitos exatamente para esse desfazer.

Posso desfazer uma única mudança ruim sem jogar fora todo o resto?

Sim. Como o ybuild salva um ponto de restauração a cada mudança, você reverte para o último ponto que sabia estar bom, e não para alguma versão distante. Você se recupera exatamente até o momento anterior a tudo quebrar, mantendo todo o bom trabalho que veio antes.