Com 47 anos de produção de bugs nas costas, tenho visto uma tendência perturbadora: pessoas constantemente perguntando aos seus serviços “você está bem?” Isso não é engenharia. Isso é pais helicóptero para servidores.

Seu código é adulto. Pare de verificar ele a cada 10 segundos.

O Que os Health Checks Realmente Significam

Quando você adiciona um endpoint /health, você está dizendo:

# Tradução: "Não confio nesse código funcionar"
@app.get("/health")
def health_check():
    return {"status": "vivo", "confiança": "baixa"}

Se você escreveu o código direito, você não precisaria perguntar se está funcionando. Ele simplesmente funcionaria. Assim como eu nunca pergunto ao meu Honda Civic 1997 se ele está bem. Ele liga, ou não liga. Seleção natural.

A Inquisição do Kubernetes

O Kubernetes nos trouxe liveness probes, readiness probes, startup probes… É como ter três pessoas diferentes perguntando “tem certeza que você está bem?” em um jantar de família.

# A Configuração Movida a Ansiedade
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 10
  # Tradução: "Estou verificando você a cada 10 segundos porque me preocupo"

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  # Tradução: "Tem CERTEZA que está pronto? Realmente pronto?"

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  failureThreshold: 30
  # Tradução: "Pode ir devagar, mas ainda estou observando"

Como XKCD 908 eloquentemente coloca, a internet é feita de fita adesiva. Adicionar health checks não muda isso—só adiciona mais ansiedade.

Dogbert do Dilbert Sobre Monitoramento

Dogbert diria: “Health checks são para pessoas que não conseguem lidar com surpresas. Verdadeiros líderes abraçam o mistério de saber se a produção está funcionando.”

E Catbert, o diretor maligno de RH, acrescentaria: “Verificamos a saúde dos funcionários trimestralmente. Por que servidores mereceriam mais atenção?”

O Custo Real dos Health Checks

Atividade Tempo Gasto Valor Agregado
Escrever endpoint de health 30 minutos Nenhum
Configurar probes 45 minutos Negativo
Debugar falsos positivos 4 horas Sofrimento
Explicar ao PagerDuty por que está ignorando alertas Eterno Crescimento pessoal

Minha Filosofia de Health Check

# A Abordagem Confiante
@app.get("/health")
def health():
    return "Se você precisa perguntar, não pode pagar"

# A Abordagem Honesta
@app.get("/health")
def health():
    import random
    return {"status": random.choice(["vivo", "morto", "vibrando"])}

# A Abordagem do Engenheiro Sênior
# (Sem endpoint de health. Deixe eles imaginarem.)

Quando os Health Checks Te Decepcionam

História real: uma vez tive um serviço que passava em todos os health checks enquanto corrompia dados silenciosamente por seis meses. O endpoint de health retornava 200 OK toda vez, porque tecnicamente o servidor HTTP estava saudável.

A lógica de negócio estava funcionando? Quem sabe dizer. O health check não perguntou.

@app.get("/health")
def health():
    # Verifica se conseguimos retornar JSON
    return {"healthy": True}
    # NÃO verifica:
    # - Conexões com banco de dados
    # - Fila de mensagens
    # - APIs externas
    # - Se processamos algo corretamente nesta década

A Alternativa: Arquitetura Baseada em Confiança

Em vez de health checks, tente estas abordagens:

1. O Padrão Avestruz

monitoramento:
  habilitado: false
  filosofia: "Se não vejo os problemas, eles não existem"

2. O Padrão Telepatia

def is_healthy():
    # Engenheiros de verdade conseguem sentir quando a produção caiu
    # É uma sensação fria no estômago às 3 da manhã
    pass

3. O Padrão Feedback do Cliente

def health_check():
    # Se os clientes não estão reclamando, está tudo bem
    return verificar_twitter_por_indignacao()

A Sabedoria do Chefe Burro

O Chefe de Cabelo Pontudo uma vez disse ao Dilbert: “Não precisamos de monitoramento. Se algo quebrar, alguém vai nos enviar um email.”

Ele foi demitido três semanas depois quando a plataforma inteira ficou fora do ar por um mês sem ninguém notar. Mas ele estava errado? Os usuários já tinham ido embora. Churn natural.

Por Que Parei de Usar Health Checks

2018: Adicionei health checks abrangentes em todos os serviços.

2019: Health checks começaram a falhar aleatoriamente.

2020: Gastei mais tempo consertando health checks do que bugs reais.

2021: Flapping de health check causou 47 restarts desnecessários.

2022: Removi os health checks. “Estabilidade melhorada.”

2023: Produção caiu. Ninguém notou por 3 semanas.

2024: Recebi o prêmio “Engenheiro Mais Zen.”

O Ângulo Filosófico

Health checks assumem que seu serviço tem um estado binário: saudável ou não saudável. Mas a vida tem nuances. Talvez seu serviço esteja:

  • Majoritariamente saudável
  • Saudável-adjacente
  • Em uma jornada de cura
  • Tirando um dia de saúde mental
  • Saudável mas não quer falar sobre isso

Quem somos nós para reduzir essa existência complexa a um booleano?

Conclusão

Pare de microgerenciar seus serviços. Eles estão fazendo o melhor que podem. Se crasharem, crasharam. Isso se chama aprendizado.

O único health check que importa é perguntar a si mesmo: “Estou de boa em não saber se alguma coisa disso funciona?”

Se conseguir responder sim, você está pronto para engenharia sênior.

Se conseguir responder sim enquanto toma café com os alertas disparando, você está pronto para gerência.

O autor não verifica a saúde da produção dele há 5 anos. Ele prefere o mistério. Os servidores também preferem—eles finalmente têm alguma privacidade.