O Que É um Readiness Probe? Explicado
Um readiness probe verifica se uma instância está pronta para receber tráfego, para que requisições sejam enviadas a ela apenas depois que ela terminar de inicializar.
Iniciar não é o mesmo que estar pronto. Um serviço pode estar em execução enquanto ainda carrega config, aquece caches ou estabelece conexões. Um readiness probe captura essa distinção para que a plataforma, e seus jobs de CI, esperem por "pronto" em vez de meramente "iniciado", o que é uma fonte frequente de corridas.
O que "pronto" significa
Um readiness probe responde uma pergunta estreita: esta instância consegue atender requisições agora? Até que ele passe, a instância existe mas não deve receber tráfego. Uma vez que passa, ela é conectada ao pool. É assim que rolling deploys evitam enviar requisições para instâncias que ainda não foram aquecidas.
Readiness vs liveness
Um liveness probe pergunta se um processo está vivo ou travado (falhá-lo dispara um restart). Um readiness probe pergunta se ele consegue atender (falhá-lo o remove da rotação, mas não o reinicia). Confundi-los causa ou restarts desnecessários ou tráfego para instâncias não prontas.
Por que CI se importa
Uma falha instável clássica é um teste que roda antes de seu banco de dados ou serviço estar pronto. O container reporta "iniciado", o teste dispara, e ele falha porque a dependência ainda não estava de fato atendendo. Esperar por uma condição de readiness, não apenas uma de iniciado, remove essa corrida por completo.
Implementando bem
- Verifique um caminho de atendimento real (uma query, um endpoint de ping), não apenas que uma porta está aberta.
- Em CI, controle os steps dependentes pela condição de readiness antes de rodar testes.
- Permita tempo de inicialização suficiente para que um start lento-mas-ok não seja tratado como falha.
O ângulo Latchkey
Readiness probes são uma ferramenta de design de jobs que reduz corridas; a autocorreção cuida do resíduo. Quando um soluço transitório de inicialização ainda derruba um job, os managed runners de autocorreção da Latchkey automaticamente fazem retry, para que um soluço pontual não quebre seu build.
Principais conclusões
- Um readiness probe verifica se uma instância já pode atender tráfego.
- Iniciado não é pronto; essa lacuna é uma fonte comum de corridas.
- Readiness remove da rotação; liveness reinicia, não os confunda.
- Controlar steps de CI pela readiness evita flakiness por condição de corrida.