Perdi Uma Semana Para Um Crash Que Eu Deveria Ter Sobrevivido

Uma vez perdi quase uma semana inteira de trabalho por causa de um único crash. Não porque o crash em si fosse alguma catástrofe rara — foi uma interrupção comum e banal, do tipo que acontece o tempo todo. Perdi a semana porque eu não tinha salvado nada ao longo do caminho. Então uma interrupção que ocorreu a poucos minutos do fim jogou fora dias de progresso acumulado, e não havia como recuperar nada disso. Simplesmente sumiu, e esteve passível de sumir o tempo todo sem que eu percebesse.

A parte dolorosa, em retrospecto, é o quão completamente evitável aquilo era. O crash não destruiu o meu trabalho. A minha falha em tornar o meu trabalho capaz de sobreviver é que destruiu.

O otimismo silencioso de supor que vai terminar

Eu havia construído os meus processos de longa duração como se eles sempre fossem rodar de forma limpa do início ao fim, sem interrupção, todas as vezes. Nenhum salvamento de estado intermediário. Nenhuma forma de recuperar a partir do meio. Bastava disparar, deixar rodar e supor que chegaria ao fim. Se você me perguntasse diretamente se essa suposição era segura, eu teria dito que não. Mas eu nunca havia me perguntado, e por isso continuei construindo em cima dela mesmo assim.

Esse é um tipo de otimismo difundido e quase invisível: supor silenciosamente que o caminho feliz é o único caminho. Você projeta para o mundo no qual tudo dá certo, porque é esse o mundo que você está imaginando enquanto constrói. E então você o lança no mundo real, que tem muitos outros caminhos, a maioria deles menos agradável.

Qualquer coisa que rode tempo o bastante será interrompida

Aqui está a verdade que eu me recusava a planejar levando em conta. Qualquer processo que rode por tempo suficiente vai, mais cedo ou mais tarde, ser interrompido. Um crash. Uma oscilação de energia. Uma máquina que fica sem memória. Um erro da minha parte. Um reboot que não podia esperar. A causa específica não importa, e há mais causas do que se consegue enumerar.

Numa janela curta, a interrupção é um risco. Num horizonte longo o bastante, ela deixa de ser um risco e se torna uma certeza. Não é uma questão de se uma coisa de longa duração vai ser interrompida, apenas de quando e com que frequência. E uma vez que você enxerga dessa forma, projetar como se isso não fosse acontecer se revela pelo que é: planejar, deliberadamente, para estar errado a respeito de algo garantido a ocorrer.

O custo é definido pelo que você salvou, não pelo crash

Esse é o insight que reorganizou a forma como eu pensava sobre tudo isso. O dano de uma interrupção é determinado quase inteiramente pelo quão recuperável o seu trabalho estava — não pelo quão severa foi a interrupção. O crash raramente é a variável que importa. O que importa é o que você fez de antemão.

Exatamente o mesmo crash, ocorrendo no exato mesmo instante, custa cinco minutos se você tivesse salvado o seu progresso recentemente, ou cinco dias se você não tivesse salvado nada. A interrupção é idêntica nos dois casos. A consequência é radicalmente diferente, e a diferença foi determinada inteiramente por uma escolha que você fez antes, muito antes de o crash chegar. O crash não decide o quanto você perde. Você decide, com antecedência, ao decidir o quanto estava disposto a tornar recuperável.

Checkpointing é aritmética, não paranoia

Uma vez que enquadrei a coisa dessa forma, o argumento a favor de salvar estado intermediário com regularidade deixou de parecer cautela excessiva e passou a parecer aritmética simples. A interrupção é certa ao longo do tempo. O custo quando ela acontece é limitado por quanto tempo faz desde a última vez que você salvou. Então salvar com frequência é apenas um seguro barato contra um evento garantido, com um prêmio que você pode definir tão baixo quanto quiser, salvando um pouco mais frequentemente.

Recusar-se a fazer isso não é coragem, nem foco, nem agilidade. É apenas matemática ruim — declinar de uma proteção barata contra algo certo de acontecer, em troca de uma pequena conveniência agora. Eu vinha me parabenizando por não desperdiçar tempo com redes de segurança, enquanto silenciosamente corria um risco enorme e não segurado contra um evento que sequer estava em dúvida.

Projete para retomar, não apenas para reiniciar

Há um nível além do salvamento periódico, no entanto, e é o que mais importou. A correção mais profunda é construir o trabalho de longa duração de modo que uma interrupção retome de onde parou, em vez de começar tudo de novo do início.

Essa distinção é tudo quando as interrupções são frequentes. Um processo que reinicia do zero toda vez que é derrubado pode, num ambiente ruim o bastante, nunca terminar — cada interrupção apaga tudo, e se elas vêm com frequência suficiente em relação ao tempo de execução, você não faz progresso líquido nenhum por mais que se esforce. Um processo que retoma, por outro lado, sempre avança. Ele pode ser derrubado vez após vez e ainda assim, eventualmente, chegar lá, porque cada interrupção custa apenas o pouquinho desde o último salvamento. Reiniciar é frágil de um jeito que se acumula; retomar é robusto de um jeito que se acumula na direção oposta.

O mesmo princípio, em quase todo lugar

Isso se generaliza muito além de qualquer computação de longa duração específica. Aplica-se a quase qualquer trabalho cujo valor se acumula ao longo do tempo e se perde se não for deliberadamente preservado. O padrão é idêntico: o progresso se acumula, uma interrupção chega, e tudo o que não foi tornado durável desaparece.

Então a pergunta que aprendi a fazer, sobre qualquer coisa que leve um tempo e que importe, não é mais a confortável — “e se isso for interrompido?” — mantida à distância como uma hipótese. É a versão crua, do tipo suponha-que-vai-acontecer: “quando isso for interrompido, quanto eu vou perder?” Essa pergunta, feita cedo, muda o que você constrói. A primeira pergunta permite que você tenha esperança. A segunda te obriga a se preparar.

A lição mais profunda: a interrupção é um evento agendado

Tudo se resume a isto: parei de projetar para o mundo onde tudo dá certo, e comecei a projetar para o mundo onde as coisas rotineiramente dão errado — porque o segundo é o mundo que de fato existe, e o primeiro nunca foi nada além de uma suposição agradável que eu havia silenciosamente substituído pela realidade.

A resiliência, vim a entender, não é pessimismo. É precisão. A interrupção não é uma hipótese remota a ser otimisticamente descontada. Ela é, na prática, um evento agendado — você simplesmente não é informado da data. Construir como se ela fosse chegar não é sombrio nem temeroso. É apenas ser honesto sobre o único mundo em que há para construir. Perdi uma semana aprendendo que o crash nunca foi o problema. O problema é que eu havia construído algo sem nenhuma forma de sobreviver a ser interrompido, num mundo onde ser interrompido é garantido.

— Sem sinais, sem retornos, não é recomendação de investimento.