Conceito e mecanismo
Um pedido de rede passa por resolução, encaminhamento, transporte e aplicação. Getent hosts observa a base de hosts através de NSS; uma consulta DNS direta pode ignorar outras fontes usadas pelo sistema, como hosts local. Depois de obter o endereço, ip route get permite observar a decisão de encaminhamento para um destino sem apagar rotas. No servidor, ss mostra sockets e listeners. Um listener em 127.0.0.1 aceita acesso local, mas não demonstra exposição pela interface remota. Não removas todas as firewalls apenas porque um cliente falhou. Primeiro identifica a camada, compara a configuração pretendida com a observada e conserva hora, origem e destino dos testes.
Aplicação guiada
Continuidade também exige critérios claros. RPO descreve o ponto de recuperação dos dados; RTO define o objetivo temporal de recuperação do sistema. Num exemplo fictício, aceitar quinze minutos de perda e duas horas de recuperação são compromissos diferentes. Backups, replicação e alta disponibilidade não são sinónimos. A replicação pode copiar uma eliminação acidental; versões ou backups recuperáveis permitem voltar a um estado anterior, se a retenção e o procedimento o suportarem. Um restore precisa de acesso, dependências, validação e tempo observado. O PM deve confirmar quem executa e quem aceita o resultado. Um ficheiro de backup presente e um host ligado não demonstram, por si só, que a aplicação recuperou dentro do prazo.
Nome correto e rota incorreta exigem investigação de encaminhamento, não alteração cega do DNS.
Armadilhas comuns
Ping como prova de aplicação; localhost como exposição remota; réplica como histórico; RPO e RTO trocados.
Tópicos relacionados: Linux, shell e permissões · Serviços, logs e capacidade · Cloud, responsabilidade e custo
Localiza a falha e mede recuperação até ao serviço necessário.
Referência: Linux routing · LFCA domains and competencies updated2025-09-16; current page confirmed2026-09-30