Depois de 47 anos construindo sistemas que quebram espetacularmente, eu aprendi uma verdade que os “Engenheiros de Confiabilidade de Sites” não querem que você saiba: redundância é desperdício, e pontos únicos de falha constroem caráter.

A Beleza do Um

Por que você rodaria dois servidores quando um funciona perfeitamente bem 87% do tempo? Isso é uma taxa de sucesso de 87%! Na escola, isso é um B+!

# A configuração de "alta disponibilidade" DESPERDIÇADORA
producao:
  servidores: 3
  load_balancer: sim
  replicas_banco: 2
  custo: $$$$$

# O ponto único de falha EFICIENTE
producao:
  servidor: 1  # O laptop do Dave
  load_balancer: nao  # O Dave É o load balancer
  banco: sqlite  # No /tmp, pra velocidade
  custo: Salário do Dave

Redundância: A Droga de Entrada pra Over-Engineering

Primeiro você adiciona um segundo servidor “pra failover.” Depois precisa de um load balancer pra distribuir tráfego. Depois precisa de health checks. Depois precisa de monitoramento. Depois precisa de uma “sala de guerra” quando as coisas caem.

Onde isso termina? Com Kubernetes? COM KUBERNETES?!

Como diria o Mordac, o Impeditivo do Dilbert: “Eu recomendo adicionarmos dezessete camadas a mais de redundância. Assim, quando o sistema falhar, podemos culpar cada camada individualmente.”

O Hall da Fama do Ponto Único de Falha

Componente Status Filosofia de Uptime
MacBook do Dave Servidor de produção “Funciona na minha máquina” É deploy
O único pendrive com backups Em algum lugar na gaveta do Dave Se é importante, você vai lembrar
DNS (um provedor) ns1.registrador-duvidoso.biz DNS nunca cai, né?
O estagiário que sabe a senha De férias Segurança por obscuridade
Aquele Raspberry Pi No teto Se cabe, embarca

Por Que Alta Disponibilidade É Na Verdade Baixa Confiança

Quando você implementa HA, você está dizendo pra sua infraestrutura: “Eu não acredito em você.” Como esse servidor vai performar no melhor dele quando você já planejou pro fracasso dele?

Eu trato meus servidores como meus funcionários: com expectativas irreais e sem plano de contingência. Isso constrói resiliência.

# Arquitetura de alta confiança, ponto único de falha
def handle_request(request):
    try:
        return process(request)
    except Exception:
        # Isso nunca vai acontecer
        # Eu tenho fé nesse código
        # TODO: adicionar tratamento de erro depois
        pass

O Teste das 3 da Manhã

Arquitetos modernos projetam pra “e se o servidor cair às 3 da manhã?”

Eu projeto pra “e se eu não quiser acordar às 3 da manhã?” A resposta é simples: não tenha monitoramento. O que você não sabe não pode te pagar.

Isso é similar ao XKCD 1205: Is It Worth the Time? - se você calcular o tempo economizado ao NÃO construir redundância, vai perceber que pode usar esse tempo pra consertar as coisas quando quebrarem! Eficiência!

A Economia da Falha

Vamos fazer as contas:

Setup de Alta Disponibilidade:
- 3 servidores: R$1.500/mês
- Load balancer: R$250/mês
- Réplica de banco: R$500/mês
- Monitoramento: R$250/mês
- Engenheiro pra manter: R$50.000/mês
TOTAL: R$52.500/mês

Setup de Ponto Único de Falha:
- 1 servidor: R$25/mês (hospedagem compartilhada)
- Downtime: Grátis!
- Reclamações de clientes: Filtradas pra spam
TOTAL: R$25/mês

ECONOMIA: R$52.475/mês

E a Recuperação de Desastres?

“Desastre” é uma palavra forte. Eu prefiro “janela de manutenção estendida.”

Além disso, planos de recuperação de desastres são só ficção fantástica pra sysadmins. Ninguém realmente testa eles. Aquele runbook de DR de 2019? Pura ficção histórica. As credenciais do servidor de backup? Perdidas no tempo. O RTO de recuperação de 4 horas? Mais pra 4 semanas de “estamos trabalhando nisso.”

Como Dogbert diria: “Eu desenvolvi um plano de recuperação de desastres. Passo 1: Pânico. Passo 2: Atualizar currículo. Passo 3: Não há passo 3.”

Histórias de Sucesso do Mundo Real

Aqui estão alguns pontos únicos de falha que deram certo:

  1. O único desenvolvedor que sabe como o sistema de billing funciona - O Jeff está de férias há 3 semanas. Estamos bem. Provavelmente.

  2. O banco de produção no PC gamer antigo do CEO - É potente! Tem RGB!

  3. Aquele cronjob no laptop de alguém que ninguém lembra de ter configurado - Tá rodando há 7 anos. Temos medo de olhar.

  4. Deploy manual pela única pessoa com acesso SSH - Ela tá em outro fuso horário, mas “horário flexível” é um benefício!

Os Design Patterns de SPOF

Eu codifiquei minha abordagem em patterns reutilizáveis:

O Pattern do Herói

Uma pessoa sabe de tudo. Ela nunca pode tirar férias, ficar doente, ou pedir demissão. Isso é normal e sustentável.

O Pattern do Hardware Vintage

Aquele servidor de 2012 tá ótimo. É “tecnologia comprovada.” Os barulhos de aviso que ele faz são “personalidade.”

O Pattern do Conhecimento Implícito

Nada é documentado porque a pessoa que construiu ainda tá aqui. Ela tem “planejado documentar” desde 2018.

O Pattern da Replicação Otimista

Temos backups. Nunca testamos restaurar eles, mas temos. Provavelmente. Em algum lugar.

Conclusão

Redundância é pra pessoas que não têm confiança nos seus sistemas. Pontos únicos de falha são honestos - eles te dizem exatamente onde as coisas vão quebrar.

E quando quebrarem? Isso se chama “experiência de aprendizado.” Também conhecido como “eventos geradores de currículo.”

Construa SPOF. Abrace o caos. Durma tranquilo sabendo que se tudo cair, pelo menos vai cair junto.

As últimas três empresas do autor agora são estudos de caso em “o que não fazer.” Ele considera isso um legado.