Redundância de infraestrutura: por que o acesso é interrompido?

O fato de um serviço estar em execução no servidor não demonstra, por si só, que ele esteja acessível ao usuário. Um incidente de acesso vivenciado por nós, da X Mind Solutions, reforçou essa distinção de maneira prática. Nossos serviços e servidores estavam funcionando normalmente e os alarmes vigentes não indicavam falhas; ainda assim, os usuários não conseguiam acessar o serviço. Diante desse cenário, analisar apenas o estado interno do sistema não é suficiente. É fundamental incluir na avaliação as conexões e dependências externas pelas quais as requisições dos usuários trafegam.

Em nossas verificações iniciais, focamos no ambiente Docker, nos túneis e nos serviços do servidor. Analisamos o servidor e os registros de log e constatamos que o processo do Cloudflared estava ativo. Contudo, essas checagens não comprovavam a integridade de todo o caminho de acesso. O fato de um processo estar ativo é diferente da capacidade de estabelecer uma conexão de ponta a ponta por meio dele. Por isso, na investigação de falhas, abordar a pergunta “está funcionando?” em conjunto com “o usuário realmente consegue acessar?” proporciona uma abordagem mais assertiva.

Na sequência da investigação, nossa atenção se voltou para a infraestrutura externa aos nossos servidores, diante de uma instabilidade de acesso na região de Frankfurt. No entanto, sem detalhes técnicos comprovados sobre o que ocorreu em componentes específicos de um determinado provedor, não seria adequado apontar uma causa raiz definitiva. A principal lição aqui é que as dependências externas também fazem parte da continuidade do serviço. Resultados positivos nas verificações locais não significam ausência de problemas em outro ponto da cadeia de conectividade; é preciso expandir o escopo da análise de acordo.

Para se preparar para essas situações, é essencial aproximar a abordagem de monitoramento da experiência do usuário. Além de monitorar os recursos do servidor e os processos dos serviços, podem ser planejadas verificações de acesso realizadas externamente. O objetivo não é apenas observar se um componente está ativo, mas testar se o serviço consegue fornecer a resposta esperada. Controles executados a partir de diferentes pontos de acesso podem ajudar a evidenciar a discrepância entre a integridade do sistema local e a disponibilidade percebida pelo usuário, definindo com maior clareza o que os alarmes realmente medem.

Após essa experiência, um dos tópicos a serem avaliados foi a utilização de sistemas redundantes baseados em infraestruturas distintas. Nesse ponto, é necessário diferenciar o backup de dados da redundância de serviços: dispor de uma cópia dos dados não significa que o tráfego de usuários possa ser direcionado para um sistema alternativo. O aprendizado que extraímos na X Mind Solutions é questionar também se essas alternativas convergem para as mesmas dependências externas. Um plano consistente deve contemplar a integridade dos dados, as condições de transição e os procedimentos de retorno, além de ter sua viabilidade validada por meio de testes.