Resiliência de Aplicativos: Mantenha os Aplicativos do Windows Disponíveis

Introdução

Aplicativos do Windows muitas vezes dependem de muito mais do que o servidor que os hospeda. Bancos de dados, serviços de identidade, armazenamento, gateways, redes e pontos finais de usuários podem afetar se um aplicativo continua utilizável durante uma interrupção. Este artigo explica como as equipes de TI podem avaliar essas dependências, projetar resiliência em torno dos aplicativos do Windows existentes, monitorar as camadas corretas e testar se os planos de recuperação realmente preservam as funções de negócios nas quais os usuários confiam.

O que é Resiliência de Aplicação?

A resiliência de aplicativos é a capacidade de um aplicativo e da infraestrutura ao seu redor de continuar fornecendo funções vitais durante uma interrupção e de se recuperar de forma previsível após uma falha.

A interrupção pode ser pequena ou grande, e as causas podem variar desde falhas de hardware ou do sistema operacional, falhas de aplicativos, atualizações com falha, interrupções de banco de dados, interrupções de rede, falhas de autenticação, exaustão de recursos, dependências indisponíveis ou incidentes de segurança.

Uma arquitetura resiliente reconhece que falhas são inevitáveis e, em vez de tentar prevenir todos os incidentes, as organizações de TI buscam limitar o impacto de cada um e estabelecer procedimentos de recuperação controlados para manter ou restaurar o serviço.

A Resiliência de Aplicações É Mais do Que a Disponibilidade do Servidor

Um erro comum é usar a disponibilidade de um servidor como um proxy para a disponibilidade da aplicação, que é executada no servidor.

Para que um aplicativo de negócios esteja verdadeiramente disponível, um número de componentes precisa estar disponível ao mesmo tempo:

Infraestrutura → Sistema operacional → Aplicativo → Dependências → Caminho de acesso → Sessão do usuário → Processo de negócios

Um problema com qualquer elemento nesta cadeia pode resultar na aplicação efetivamente indisponível.

Por exemplo, um servidor de aplicativos pode estar saudável enquanto seu banco de dados está inacessível. Um aplicativo publicado pode estar funcionando corretamente, mas uma falha no gateway torna impossível para os funcionários remotos acessá-lo. Os usuários podem até iniciar o aplicativo com sucesso, mas serem impedidos de concluir uma transação porque um serviço de licenciamento, arquivo ou backend está indisponível.

A resiliência da aplicação, portanto, deve ser medida com base na capacidade do usuário de realizar a tarefa comercial necessária, em vez de se considerar se um servidor é capaz de responder a um teste de disponibilidade ou de saúde.

Por que a resiliência de aplicativos é diferente para aplicativos do Windows?

Práticas modernas de resiliência estão cada vez mais focadas em aplicações nativas da nuvem, contêineres, microsserviços e orquestração automatizada. Embora essas sejam abordagens valiosas, nem sempre são aplicáveis a todas as organizações.

Muitas organizações possuem aplicativos legados de negócios em Windows que foram desenvolvidos antes que arquiteturas nativas de nuvem se tornassem comuns. Software ERP, aplicativos de contabilidade, aplicativos de manufatura, aplicativos de saúde, aplicativos de engenharia e aplicativos desenvolvidos internamente podem ser todos críticos para as operações de uma organização.

Reestruturar esses aplicativos como microsserviços pode ser extremamente caro, tecnicamente desafiador ou até mesmo completamente inviável se a organização não controlar o código-fonte.

Nesses casos, pode haver um valor significativo em tornar as operações em torno da aplicação mais resilientes, em vez de tentar tornar a própria aplicação mais resiliente. Publicação de aplicativos pode fazer parte dessa abordagem mantendo as aplicações Windows existentes em uma infraestrutura centralizada enquanto muda a forma como os usuários acessam essas aplicações. Isso pode incluir mudanças na infraestrutura que hospeda a aplicação, como eliminar restrições de infraestrutura, criar hosts de aplicação redundantes, habilitar métodos de acesso alternativos e implementar procedimentos de recuperação mais responsivos para o host da aplicação.

Em qual caso a disponibilidade de um aplicativo Windows poderia falhar?

Construir a resiliência de aplicativos começa com a descoberta dos componentes necessários para entregar com sucesso um aplicativo de seus hosts para os usuários. Esse processo destaca pontos potenciais de falha que podem derrubar um aplicativo inteiro.

Hosts de Aplicação

Um aplicativo em execução em um único servidor Windows tem um ponto único de falha claro.

Problemas de hardware, atualizações do Windows, corrupção do sistema operacional, exaustão de recursos ou falha de aplicativo podem interromper todos os usuários que dependem daquela máquina. Se as necessidades de disponibilidade exigirem, múltiplos hosts de aplicativo podem ser implementados para reduzir a dependência de uma única máquina e fornecer capacidade quando um servidor se torna indisponível.

Bancos de Dados, Armazenamento e Outras Dependências

Muitos aplicativos do Windows dependem de serviços externos ao host do aplicativo. Esses serviços podem incluir:

• bancos de dados SQL
• compartilhamentos de arquivos
• servidores de licenciamento
• Active Directory
• Sistema de Nomes de Domínio (DNS)
• certificados
• APIs
• middleware
• armazenamento em rede
• infraestrutura de impressão

A introdução de um segundo servidor de aplicativos oferece resiliência mínima se eles compartilharem uma dependência comum de banco de dados ou armazenamento que não está disponível. Torna-se evidente que o mapeamento de dependências precisa se estender além da infraestrutura de aplicativos visível.

Autenticação e Identidade

Os usuários não podem acessar um aplicativo saudável se a infraestrutura de autenticação necessária estiver indisponível.

As equipes de TI precisam identificar os serviços de identidade dos quais suas aplicações críticas dependem e garantir que tenham planos de failover em vigor para quando esses recursos estiverem inacessíveis. Active Directory, plataformas de identidade em nuvem, serviços de autenticação multifatorial (MFA) e gateways de autenticação podem ser confiáveis para fornecer uma cadeia de disponibilidade para uma aplicação.

Caminhos de Rede e Acesso Remoto

Para aplicativos Windows centralizados, a conectividade entre os usuários e o ambiente do aplicativo representa outro possível domínio de falha.

Vamos imaginar a cadeia completa:

Dispositivo do usuário → Internet ou LAN → gateway → host de aplicativo → serviços de backend

Uma falha em qualquer lugar nesta cadeia pode impedir os usuários de realizarem seus trabalhos, mesmo que a aplicação esteja funcionando corretamente. Isso é particularmente relevante para organizações distribuídas, onde a aplicação pode estar ativa e funcionando no data center, mas inacessível para usuários em outra localização.

Pontos de Extremidade

A resiliência de aplicativos não requer necessariamente que a estação de trabalho normal de um usuário esteja disponível.

Oferecer aos usuários autorizados os meios para acessar aplicativos hospedados centralmente a partir de um dispositivo alternativo ou via um navegador pode garantir o acesso, caso um laptop se torne indisponível, um escritório se torne inacessível ou os funcionários precisem trabalhar de um local diferente.

A arquitetura de entrega de aplicativos pode ser um componente de uma estratégia mais ampla de continuidade de negócios.

Qual é o processo de construção de resiliência de aplicativos para aplicativos Windows?

Nenhuma tecnologia única torna a aplicação resiliente. As equipes de TI, em vez disso, precisam reduzir o número de falhas que podem derrubar uma função completa e se preparar para mecanismos de recuperação controlada para aquelas que permanecem.

1. Identificar Aplicações Críticas e Processos de Negócios

Nem todos os aplicativos exigem o mesmo grau de proteção. Comece determinando quais aplicativos suportam operações primárias, em quais usuários confiam e qual é a tolerância a inatividade deles.

Dois objetivos de recuperação traduzem os requisitos de negócios em especificações técnicas. Orientações de planejamento de contingência do NIST define o Objetivo de Tempo de Recuperação (RTO) e o Objetivo de Ponto de Recuperação (RPO) como parâmetros-chave para determinar os requisitos de recuperação:

• Objetivo de Tempo de Recuperação (RTO): uma duração de inatividade aceitável antes que o serviço seja restaurado.
• Objetivo de Ponto de Recuperação (RPO): um intervalo de perda de dados aceitável, medido em tempo.

Um aplicativo usado intensivamente para processar pedidos pode ter um RTO de minutos, enquanto um aplicativo de relatórios financeiros executado uma vez por semana pode suportar dias de inatividade.

RTO e RPO definem o tipo de proteção necessária para uma aplicação: failover instantâneo, restabelecimento rápido de serviços ou apenas um procedimento de recuperação documentado.

2. Mapeie toda a cadeia de dependência do aplicativo

Documente tudo o que precisa estar lá para que a aplicação faça seu trabalho.

Não pare no executável ou no servidor Windows. Não se esqueça de bancos de dados, armazenamento, autenticação, DNS, redes, certificados, sistemas de licenciamento, gateways e serviços externos.

Para cada um, pergunte:

O que acontece com o aplicativo se isso desaparecer?

Este exercício revelará pontos únicos de falha ocultos e estabelecerá a sequência de recuperação. Restaurar um host de aplicativo primeiro não ajuda muito se seu banco de dados, serviço de identidade ou armazenamento ainda não estiver disponível.

3. Remova Pontos Críticos Únicos de Falha

Uma vez que a árvore de dependência esteja estabelecida, determine quais componentes devem ser tornados redundantes, com base na importância para os negócios e nos objetivos de recuperação.

No caso da entrega de aplicativos do Windows, isso pode envolver a implantação de vários servidores de aplicativos em vez de depender das capacidades de um único host. Com uma camada de balanceamento de carga, as sessões podem ser distribuídas entre as instâncias de aplicativos durante as operações normais. Em caso de falha de um host, as conexões de entrada podem ser direcionadas para instâncias de servidores de aplicativos saudáveis.

O planejamento de redundância deve ser informado pela análise de dependência, no entanto. Múltiplos servidores de aplicativos acessando um único banco de dados crítico, gateway de rede ou camada de armazenamento ainda apresentam um único ponto de falha.

O design de alta disponibilidade deve, portanto, considerar o serviço de aplicação como uma entidade integrada. Para ambientes do Windows Server que exigem redundância em nível de infraestrutura, Documentação de Failover Clustering da Microsoft fornece orientações adicionais sobre topologias de alta disponibilidade e recuperação de desastres.

4. Separe Aplicativos de Endpoints Individuais

Instalar um aplicativo crítico diretamente na estação de trabalho de cada funcionário pode criar um tipo diferente de problema de resiliência. Se os usuários perderem o acesso ao computador regular, eles também podem perder o acesso aos aplicativos de que precisam para continuar trabalhando.

Centralizando aplicativos em hosts Windows gerenciados e apresentar a interface do aplicativo aos usuários elimina esse risco. Os dados e o estado do aplicativo são armazenados no host Windows gerenciado e acessados por endpoints autorizados.

Ao fazer isso, tornamos o aplicativo disponível para os usuários, mesmo que eles mudem de dispositivos ou locais. Embora a centralização de aplicativos não elimine problemas de infraestrutura, ajuda a movê-lo para um ambiente onde pode ser controlado pela TI.

5. Forneça Mais de Um Método de Acesso Prático

A resiliência também pode ser alcançada evitando a dependência desnecessária de um único tipo de endpoint ou método de conexão.

Dependendo da arquitetura de entrega de aplicativos, os usuários podem usar diferentes acesso remoto métodos, incluindo um cliente compatível com RDP, lançador de aplicativo dedicado, portal web ou sessão de navegador HTML5.

Métodos alternativos de conexão não devem ser confundidos com redundância de infraestrutura. Se todos estiverem dependendo do mesmo servidor com falha, o aplicativo ainda estará indisponível.

Eles fornecem resiliência de acesso quando a interrupção afeta o dispositivo normal de um usuário, o cliente instalado ou a localização, em vez do próprio serviço de aplicativo.

6. Monitorar Antes que a Degradação se Torne uma Interrupção

A resiliência de aplicativos não se trata apenas de recuperação, mas a detecção precoce o suficiente pode evitar a degradação em uma interrupção.

Indicadores úteis em ambientes de aplicativos Windows são utilização da CPU, pressão de memória, capacidade de disco e I/O, utilização de rede, sessões ativas, processo de aplicativo, tempo de resposta, conexão falhada e disponibilidade de serviços dependentes.

Monitoramento de tendências é crucial, pois um servidor que se aproxima repetidamente de seus limites ainda pode estar online enquanto a experiência do usuário se deteriora gradualmente.

Alertas de limiar permitem que os administradores investiguem os precursores de um incidente antes que os usuários percam o acesso.

7. Planeje picos de capacidade e failover

Uma aplicação que sobrevive a falhas em nível de hardware, mas fica completamente incapaz de funcionar sob demandas aumentadas, não é verdadeiramente resiliente a falhas de qualquer tipo.

O planejamento de capacidade deve levar em conta não apenas os padrões de uso diário, mas também considerar picos devido a demandas sazonais, mudanças de turnos, crescimento ou requisitos de hospedagem para outros aplicativos.

Particularmente em ambientes de hospedagem com múltiplos servidores, a perda de um único servidor deve ser considerada garantindo que outros nós de hospedagem tenham capacidade extra para acomodar quaisquer processos que de outra forma seriam executados no nó com falha.

Caso contrário, os procedimentos de failover podem simplesmente transformar um incidente isolado em um amplo problema de desempenho do sistema.

8. Proteger Dados e Configuração

Um servidor Windows de substituição é de pouca utilidade se a TI não conseguir restaurar os componentes necessários para fazer o aplicativo funcionar.

Isso pode significar que os procedimentos de backup precisam incluir dados de aplicativos, bancos de dados, arquivos de configuração, certificados, configurações de aplicativos, perfis de usuário, configuração de infraestrutura, scripts e informações de licenciamento.

A estratégia variará dependendo do Objetivo de Tempo de Recuperação (RTO) e do Objetivo de Ponto de Recuperação (RPO) da aplicação.

Acima de tudo, garanta que um backup bem-sucedido não é igual a uma recuperação bem-sucedida. As equipes de TI devem testar se é possível restaurar todo o serviço de aplicação a partir de dados e configurações protegidos.

9. Reduza o Raio de Impacto das Mudanças

Não é sempre uma questão de um desastre imprevisto que causa interrupções. Elas também podem ser causadas por melhorias implementadas. Assim, patches do Windows, atualizações de aplicativos e drivers, políticas de segurança e mudanças de configuração também podem ter um impacto negativo na disponibilidade do aplicativo. Recomenda-se evitar fazer mudanças semelhantes em todos os hosts de produção ao mesmo tempo, se possível.

Em uma configuração de múltiplos servidores, é possível realizar as mudanças de melhoria em etapas, permitindo assim que o administrador verifique se tudo está funcionando corretamente. A capacidade de reverter as mudanças feitas também é essencial.

Assim, ao projetar procedimentos de contingência, as opções de reversão também devem ser consideradas. O processo deve ser devidamente documentado, e a equipe deve saber o que fazer se uma alteração falhar, em vez de simplesmente deixar a critério deles.

10. Design para Degradação Elegante

Resiliência não é sobre manter 100% das funções normais em funcionamento o tempo todo.

Em alguns casos, sustentar operações para usuários ou aplicativos chave pode ser mais importante do que manter todos os serviços disponíveis para todos os usuários. As prioridades podem ser estabelecidas antes que um incidente ocorra pelas equipes de TI.

Se houver capacidade disponível que possa ser utilizada, pode fazer sentido alocá-la primeiro para produção, atendimento ao cliente, finanças ou outras funções.

Isso é degradação elegante: manter a capacidade de executar as funções que geram o maior valor para os negócios, em vez de permitir que a falha de elementos menos críticos faça todo o sistema falhar.

Como as equipes de TI devem monitorar a resiliência de aplicativos?

Monitorar servidores individuais pode ser útil, mas o monitoramento de resiliência deve refletir o serviço total da aplicação conforme percebido pelos usuários.

Um modelo realista compreende várias camadas:

Camada	O que Monitorar	Exemplo de Falha
Host	CPU, RAM, disco, disponibilidade do SO	Servidor sobrecarregado ou offline
Aplicativo	Processo e status do serviço	Falhas de aplicativo
Dependência	Banco de dados, DNS, identidade, armazenamento	O aplicativo é iniciado, mas não pode operar.
Acesso	Gateway, portal, caminho de rede	Usuários não podem se conectar
Sessão	Usuários ativos, falhas, latência	Aplicativo está online, mas inutilizável
Função empresarial	Conclusão bem-sucedida do fluxo de trabalho	O usuário não pode concluir a tarefa necessária.

A camada de função empresarial é uma das mais simples de se ignorar.

Os painéis de infraestrutura podem mostrar todos os servidores, serviços e caminhos de rede como saudáveis, enquanto o fluxo de trabalho de um usuário real está comprometido. É importante, portanto, que aplicações críticas monitorem sua saúde a partir da perspectiva da operação que foram projetadas para suportar.

Como a resiliência de aplicativos deve ser testada?

Uma arquitetura de resiliência que nunca experimentou uma falha controlada contém suposições não testadas.

Use testes para avaliar a resposta do sistema quando componentes-chave se tornam indisponíveis. Os testes devem incluir colocar um host de aplicativo offline, parar um serviço de aplicativo, simular a perda de uma rota de rede, verificar o comportamento do gateway ou de balanceamento de carga, restaurar a partir de um backup e acessar o aplicativo de um ponto de extremidade alternativo.

Os processos de teste devem se estender além dos aspectos técnicos da recuperação. As equipes de TI devem revisar se os alertas estão sendo enviados ao pessoal administrativo correto, se os passos de recuperação estão sendo realizados na sequência correta e se os usuários conseguem realizar uma tarefa comercial real após os serviços terem sido restaurados.

Procedimentos operacionais são parte integrante de um sistema resiliente. Procedimentos de escalonamento de alertas: quem recebe o alerta? Quem tem a autoridade para iniciar a troca? Onde estão armazenados a documentação de recuperação e as credenciais? Qual dependência precisa ser ativada primeiro?

A redundância técnica oferece pouco benefício se os processos para recuperar o acesso não foram testados.

O que pode ser a lista de verificação de resiliência de aplicativos?

Antes de embarcar em uma aplicação crítica do Windows resiliente, as equipes de TI devem ser capazes de responder às seguintes perguntas:

• Quais processos de negócios dependem da aplicação?
• Quais são seus RTO e RPO?
• Quais servidores, bancos de dados e serviços externos são necessários?
• Onde estão seus pontos críticos de falha?
• Um outro host de aplicativo pode aceitar usuários se um host falhar?
• Os usuários podem se conectar se seu endpoint ou local normal estiver indisponível?
• Há capacidade de sobra suficiente para operação degradada?
• Os problemas de infraestrutura, dependência e sessão são monitorados ativamente?
• Os administradores são alertados antes que os limites importantes se tornem interrupções?
• Os dados e a configuração do aplicativo estão protegidos?
• A restauração foi realmente testada?
• As mudanças problemáticas podem ser revertidas?
• A sequência de recuperação está documentada?
• Os usuários podem concluir o processo de negócios necessário após a recuperação?

Nem todas as respostas exigem uma infraestrutura de alta disponibilidade cara. O nível certo de proteção depende do custo e do impacto operacional da inatividade.

O que importa é que as decisões sobre disponibilidade, redundância e recuperação sejam tomadas de forma deliberada, em vez de serem assumidas.

Como o TSplus pode ajudar a manter os aplicativos do Windows disponíveis?

Para organizações que dependem de aplicativos Windows existentes, podemos ajudar a melhorar a disponibilidade centralizando aplicativos em servidores Windows gerenciados e entregando-os aos usuários por meio de clientes compatíveis com RDP, acesso no estilo RemoteApp ou um portal web HTML5. Isso reduz a dependência de terminais individuais dos usuários e oferece às equipes de TI mais flexibilidade quando os usuários precisam se conectar de outro dispositivo ou local.

TSplus Acesso Remoto também pode suportar implantações em múltiplos servidores com balanceamento de carga e acesso baseado em gateway. Quando combinado com bancos de dados resilientes, armazenamento, serviços de identidade e redes, essa arquitetura pode reduzir a dependência de um único host de aplicação e ajudar a manter o acesso a aplicativos Windows críticos durante interrupções na infraestrutura.

Conclusão

A resiliência da aplicação depende da compreensão do caminho completo entre a infraestrutura e o uso comercial. Redundância, monitoramento, backup, planejamento de capacidade e procedimentos de recuperação são mais eficazes quando são projetados em torno de dependências de aplicação e objetivos de recuperação claramente definidos.

Para aplicativos Windows existentes, a resiliência muitas vezes vem do fortalecimento do ambiente ao redor do software, em vez de reconstruir o próprio aplicativo. O teste chave continua simples: quando ocorre uma interrupção, os usuários conseguem continuar trabalhando ou a TI pode restaurar a função de negócios necessária dentro da janela de recuperação acordada?