Quando Considerar a Alta Disponibilidade?

“Alta Disponibilidade não é algo que você compra, é algo que você faz.” – John Nicholson

Poucas coisas são tão universalmente desejadas em TI quanto soluções de Alta Disponibilidade (HA). Quer dizer, sério, diga essas palavras e qualquer Profissional de TI dirá instantaneamente que as quer. HA para seus servidores, seus aplicativos, seu armazenamento e, é claro, até para seus desktops. Se houvesse uma caixa de seleção ao lado de qualquer sistema que simplesmente dissesse “HA”, por que não a marcaríamos? Marcaríamos, é claro. Ninguém quer voluntariamente um sistema que falhe muito. Falha é ruim, sucesso é bom.

Primeiro, porém, precisamos definir HA. HA pode significar muitas coisas. No mínimo, HA deve significar que a disponibilidade do sistema em questão deve ser maior do que a “normal”. O que é normal? Só isso já é bastante difícil de definir. HA é, na melhor das hipóteses, um termo impreciso. No contexto de seu uso mais comum, porém, que é o de aplicativos comuns rodando em hardware empresarial comum, eu ofereceria este ponto de partida para discussões sobre HA:

Disponibilidade Normal ou Padrão (SA) seria definida como a disponibilidade de um servidor comum de linha principal rodando um sistema operacional empresarial comum, executando um aplicativo empresarial comum, em um ambiente de melhores práticas com suporte empresarial. Bons exemplos disso podem incluir o Exchange rodando no Windows Server, rodando no HP Proliant DL380 (o servidor comum de linha principal mais comum). Ou, para o BIND (o servidor DNS) rodando no Red Hat Enterprise Linux no Dell PowerEdge R730. Estes são apenas exemplos para serem usados no estabelecimento de uma linha de base aproximada. Não há uma maneira ótima de medir isso, mas, com um bom contrato de suporte e reparo ou substituição rápidos no mundo real, acredita-se que a confiabilidade de um sistema dessa natureza fique entre quatro e cinco noves de confiabilidade (99,99% de tempo de atividade ou mais) quando a falha humana não é incluída.

Alta Disponibilidade (HA) deve ser comumente definida como tendo uma disponibilidade significativamente maior do que a da Disponibilidade Padrão. Significativamente maior deve ser um aumento de, no mínimo, uma ordem de magnitude. Portanto, pelo menos cinco noves de confiabilidade e, mais provavelmente, seis noves. (99,9999% de tempo de atividade.)

Baixa Disponibilidade (LA) seria comumente definida como tendo uma disponibilidade significativamente menor do que a da Disponibilidade Padrão, significando “significativamente”, novamente, ao menos uma ordem de magnitude. Portanto, LA seria tipicamente presumida como estando em torno de 99% a 99,9% ou menos de disponibilidade.

A medição aqui é muito difícil, pois fatores humanos, ambientais e outros desempenham um papel enorme na determinação do tempo de atividade de diferentes configurações. O mesmo equipamento usado em um papel pode atingir cinco noves, enquanto em outro deixa de atingir até mesmo um. A qualidade do datacenter, a habilidade da equipe de suporte, a rapidez da substituição de peças, a granularidade do monitoramento e uma multidão de outros fatores afetarão significativamente a confiabilidade geral. Isso não é necessariamente um problema para nós, no entanto. Na maioria dos casos, podemos avaliar as partes de um projeto de sistema que controlamos de tal forma que a confiabilidade relativa possa ser determinada, de modo que possamos ao menos mostrar que uma abordagem será superior a outra, para que então possamos nos valer de uma tomada de decisão bem informada, mesmo que modelos precisos de taxa de falha não possam ser construídos facilmente.

É importante notar que, além de fornecer um conjunto de exemplos de linha de base a partir do qual trabalhar, não há nada nas definições de alta disponibilidade ou baixa disponibilidade que fale sobre como esses níveis devem ser alcançados – não é isso que os termos significam. Os termos são conjuntos resultantes de confiabilidade em relação à linha de base e nada mais. Há muitas maneiras de alcançar a alta disponibilidade sem usar abordagens comumente presumidas e maneiras praticamente ilimitadas de alcançar a baixa disponibilidade.

É claro que a HA pode ser definida em cada camada. Podemos ter plataformas ou SO de HA, mas ter aplicativos frágeis por cima. Por isso, é muito importante entender em que nível estamos falando em qualquer momento dado. No fim das contas, uma empresa só se importará com a entrega de serviços com alta disponibilidade, independentemente de como ela é alcançada, ou onde. O resultado final é o que importa, não os detalhes de “debaixo do capô” de como foi realizado ou, como sempre, os fins justificam os meios.

É extremamente comum hoje que departamentos de TI se distraiam com ferramentas de HA novas e chamativas na camada de plataforma e se esqueçam de buscar HA mais acima e mais abaixo na pilha para garantir que entregamos serviços de alta disponibilidade ao negócio; em vez de olhar apenas para uma camada, deixando o negócio tão vulnerável quanto antes, ou mais.

No mundo real, porém, a HA nem sempre é uma opção e, quando é, ela tem um custo. Esse custo é quase sempre monetário e geralmente vem acompanhado de complexidade extra também. E, como bem sabemos, qualquer complexidade também carrega risco adicional, e esse risco poderia, se não tivermos cuidado, fazer com que uma tentativa de alcançar a HA na verdade falhe e até nos deixar com LA ou Baixa Disponibilidade.

Uma vez que entendemos essa linguagem necessária para descrever o que queremos dizer, podemos começar a falar sobre quando a alta disponibilidade, a disponibilidade padrão e até a baixa disponibilidade podem ser adequadas para nós. Usamos esse alto nível de granularidade porque é tão difícil medir a confiabilidade do sistema que entrar em detalhes demais torna-se inútil.

Conceitualmente, todos os sistemas vêm com risco de indisponibilidade e nada pode estar sempre no ar, isso é impossível. A confiabilidade custa dinheiro, geralmente, mantidas iguais todas as demais condições. Portanto, para determinar qual nível de disponibilidade é mais apropriado para uma carga de trabalho, devemos determinar o custo da mitigação de risco (a quantia de dinheiro necessária para alterar a quantidade média de indisponibilidade) e compará-lo com o custo da própria indisponibilidade.

Isso fica complicado e intrincado porque determinar o custo da indisponibilidade já é bastante difícil e, em seguida, determinar o risco de indisponibilidade é ainda mais difícil. Em muitos casos, a indisponibilidade não é um número fixo, mas pode ser. Esse custo poderia ser expresso como US$ 5/minuto ou US$ 20 mil/dia ou algo semelhante. Mas uma ferramenta ainda melhor seria criar uma “curva de impacto de perda” que mostre como o dinheiro é perdido ao longo do tempo (dentro de um intervalo razoável).

Por exemplo, uma empresa poderia facilmente não enfrentar perda alguma nos primeiros cinco minutos, com perdas lentamente crescentes, porém pequenas, até cerca de quatro horas, quando o trabalho para porque as pessoas já não conseguem recorrer ao papel ou seja lá o que for, e então as perdas vão de quase zero a bastante grandes. Ou algumas empresas poderiam sofrer uma perda enorme no momento em que os sistemas caem, mas as perdas se dissipam lentamente ao longo do tempo. A perda pode só ser impactante em certos horários do dia. Talvez interrupções à noite ou durante o almoço sejam triviais, mas no meio da manhã ou no meio da tarde sejam importantes. O impacto, o risco e a capacidade de mitigar esse risco de cada empresa são diferentes, muitas vezes drasticamente.

Às vezes, tudo se resume às pessoas que trabalham na empresa. Será que todas elas alegremente farão as necessárias pausas para o banheiro, café, lanche ou até almoço no momento em que um sistema falhar, para que possam voltar ao trabalho quando ele estiver consertado? As pessoas irão para casa mais cedo e chegarão mais cedo amanhã para compensar uma grande interrupção? Há maquinário que vai ficar ocioso? A capacidade de responder aos clientes será afetada? Sistemas de suporte à vida falharão? Há inúmeros impactos potenciais e inúmeras formas potenciais de mitigar diferentes tipos de falhas. Tudo isso precisa ser considerado. O custo da indisponibilidade pode ser uma fração das receitas corporativas em uma base minuto a minuto, ou a indisponibilidade pode causar uma perda de clientes ou de confiança que é mais impactante do que a receita gerada minuto a minuto.

Uma vez que temos alguns números aproximados de perda com os quais trabalhar, ao menos temos um ponto de partida. Mesmo que saibamos apenas que a receita é de ~US$ 10/minuto e que se espera que as perdas fiquem em torno de ~US$ 5/minuto, temos uma espécie de ponto de partida. Se tivermos uma curva completa ou um estudo feito com números mais detalhados, melhor ainda. Agora precisamos descobrir aproximadamente qual será a nossa linha de base. Um servidor bem mantido, rodando localmente, com um bom contrato de suporte e bons procedimentos de backup e restauração, pode facilmente atingir quatro noves de confiabilidade. Isso significa que experimentaríamos cerca de cinco horas de indisponibilidade a cada cinco anos. Na verdade, isso é menos do que a indisponibilidade geralmente esperada de SA na maioria dos ambientes e, potencialmente, muito menos do que os níveis esperados em ambientes excelentes, como datacenters de alta qualidade com peças e serviço por perto.

Então, com base em nosso exemplo de linha de base de cerca de cinco horas a cada cinco anos, podemos calcular nosso risco potencial. Se perdermos cerca de ~US$ 5/minuto e esperarmos aproximadamente 300 minutos de indisponibilidade a cada cinco anos, estamos diante de uma perda potencial de US$ 1.500 a cada meia década.

Isso significa que, no extremo, nunca poderíamos gastar US$ 1.500 para mitigar esse risco, seria financeiramente absurdo. Isso acontece por várias razões. Uma das maiores é que isso é apenas um risco; gastar US$ 1.500 para se proteger de perder US$ 1.500 faz pouco sentido, mas é um erro muito comum de se cometer quando as pessoas não analisam esses números com cuidado.

O maior fator é que nenhuma técnica de mitigação é completamente eficaz. Se conseguirmos mover nosso sistema de quatro noves para um sistema de cinco noves, reduziríamos apenas 90% da indisponibilidade média, levando-nos de US$ 1.500 de perda para US$ 150 de perda. Se gastássemos US$ 1.500 por essa redução, a “perda” total ainda seria de US$ 1.650 (o custo da proteção é uma forma de perda financeira). O custo da mitigação de risco, combinado com o impacto remanescente previsto, quando tomados em conjunto, ainda deve ser menor do que o custo previsto do risco sem mitigação, ou então a própria mitigação é inútil ou ativamente prejudicial.

Muitos podem questionar por que o custo total da mitigação de risco deve ser menor e não simplesmente igual, pois certamente isso deve significar que estamos em um ponto de “equilíbrio de risco”? Isso parece verdadeiro na superfície, mas, como estamos lidando com risco, não é o caso. A mitigação de risco é um custo certo: um dano financeiro que assumimos de antemão na esperança de reduzir perdas amanhã. Mas o risco para amanhã é um palpite, com sorte um palpite bem fundamentado, mas apenas um palpite. O custo de hoje é certo. Assumir um dano certo hoje na esperança de reduzir um possível dano amanhã só faz sentido quando o dano de hoje é pequeno e o dano esperado ou possível de amanhã é muito grande e a eficácia da mitigação é significativa.

Incluída na ideia de “custo certo de antemão” para reduzir o “possível custo de amanhã” está a ideia do valor do dinheiro no tempo. Mesmo que uma interrupção fosse de tamanho e tempo conhecidos, não gastaríamos hoje o mesmo dinheiro para mitigá-la amanhã, porque nosso dinheiro é mais valioso hoje.

Nos casos mais dramáticos, às vezes vemos departamentos de TI exigindo que dezenas ou centenas de milhares de dólares sejam gastos de antemão para evitar perder alguns milhares de dólares, talvez, em algum momento talvez muitos anos no futuro. Uma estratégia que podemos chamar de “dar um tiro no próprio rosto hoje para talvez evitar uma dor de cabeça amanhã.”

Isso está incluído no conceito de avaliar a mitigação de risco, mas deve ser mencionado especificamente que, no caso de equipamentos de TI, há muitos exemplos de tentativas de mitigação de risco que podem não ser tão eficazes quanto se acredita. Por exemplo, ter dois servidores que ficam no mesmo rack será potencialmente muito eficaz para mitigar o risco de falha de hardware do host, mas não mitigará contra desastres naturais, perda do site, incêndio, a maioria dos casos de choque elétrico, ativação de supressão de incêndio, interrupções de rede, a maioria das falhas de aplicativos, ataque de ransomware ou outros desastres razoavelmente possíveis.

É comum que dispositivos de armazenamento sejam equipados com “controladores duplos”, o que dá uma forte impressão de alta confiabilidade, mas geralmente esses controladores estão dentro de um único chassi com componentes compartilhados e, mesmo que os componentes não sejam compartilhados, frequentemente o firmware é compartilhado e as comunicações entre os componentes são complexas; muitas vezes levando a falhas em que a falha de um componente desencadeia a falha de outro – tornando-os, com bastante frequência, dispositivos LA, em vez da SA ou da HA que as pessoas esperavam ao comprá-los. Por isso, é muito crítico considerar se a estratégia de mitigação de risco mitigará quais riscos e se a técnica de mitigação tem probabilidade de ser eficaz. Nenhuma técnica é completamente eficaz, sempre há uma chance de falha, mas algumas estratégias e técnicas são mais amplamente eficazes do que outras e algumas são simplesmente enganosas ou, na verdade, contraproducentes. Se não tivermos cuidado, podemos implementar produtos ou técnicas custosos que ativamente minam nossos objetivos.

Algumas técnicas e produtos usados na busca por alta disponibilidade são bastante caros, o que pode incluir comprar hardware redundante, alugar outro prédio, instalar geradores caros ou licenciar software especial. Há também técnicas e softwares de baixo custo, mas, na maioria dos casos, qualquer movimento em direção à alta disponibilidade resultará em um desembolso relativamente grande de capital de investimento para alcançá-la. É absolutamente fundamental ter em mente que a alta disponibilidade é um processo, não há como simplesmente comprar alta disponibilidade. Alcançar a HA requer boa documentação, procedimentos, planejamento, suporte, equipamentos, engenharia e mais. No mundo dos sistemas, a HA é normalmente abordada primeiro de uma perspectiva ambiental, com geradores de energia de failover, sistemas de HVAC redundantes, condicionamento de energia, filtragem de ar, sistemas de supressão de incêndio e mais, para garantir que o ambiente para a disponibilidade esteja presente. Só isso muitas vezes pode tornar desnecessário um investimento adicional, pois pode entregar resultados incríveis. Depois vem o projeto de sistema de HA, garantindo que não apenas uma camada de uma pilha de tecnologia seja altamente disponível, mas que toda a pilha esteja permitindo que os aplicativos, dados ou serviços críticos permaneçam funcionais durante o máximo de tempo possível. Depois, olhando para a redundância site a site, para poder resistir a enchentes, furacões, nevascas etc. É claro que existem técnicas completamente diferentes, como utilizar serviços de computação em nuvem hospedados remotamente em nosso nome. O que importa é que a alta disponibilidade requer pensamento e planejamento amplos, não pode ser simplesmente comprada como um item de linha e é julgada pela capacidade de retornar um fator de risco que proporcione um tempo de atividade resultante, ou probabilidade de tempo de atividade, muito maior do que um projeto de sistema “padrão” entregaria.

O que muitas vezes é surpreendente, quase chocante, para muitas empresas e especialmente para profissionais de TI, que raramente realizam análise de risco financeiro e que estão constantemente sendo informados de que a HA é uma necessidade para qualquer negócio e que comprar os mais recentes produtos de HA é, sem dúvida, como seus orçamentos devem ser gastos, é que, quando os números são calculados e a realidade dos custos e da eficácia das estratégias de mitigação de risco é considerada, a alta disponibilidade tem muito pouco lugar em qualquer organização, especialmente naquelas que são pequenas ou têm cargas de trabalho altamente díspares. No mercado de pequenas e médias empresas, é quase universal constatar que o custo e a complexidade (que, por sua vez, trazem risco, principalmente na forma de falta de experiência em torno de técnicas e avaliação de risco) das abordagens de alta disponibilidade são caros demais para algum dia compensar o dano potencial da interrupção contra a qual se espera que a mitigação proteja. Há exceções, é claro, e há muitos negócios para os quais soluções de alta disponibilidade são absolutamente sensatas, mas estes são a exceção e estão muito longe de ser a norma.

Também é sensato pensar nas necessidades de alta disponibilidade com base em cada carga de trabalho e não no âmbito de departamento, empresa ou tecnologia como um todo. Em uma pequena empresa, é comum que todas as cargas de trabalho compartilhem uma plataforma comum, e a necessidade de uma única carga de trabalho por alta disponibilidade pode arrastar consigo outras cargas de trabalho menos críticas. Isso é perfeitamente aceitável e uma ótima maneira de compensar o custo da mitigação de risco da carga de trabalho crítica por meio do benefício acessório às cargas de trabalho menos críticas. Em uma organização maior, onde há uma infinidade de abordagens de plataforma usadas para diferentes cargas de trabalho, é comum que apenas certas cargas de trabalho que sejam tanto altamente críticas (em termos de risco pelo impacto da indisponibilidade) quanto praticamente mitigáveis de risco (a capacidade de mitigar o risco pode variar drasticamente entre diferentes tipos de cargas de trabalho) tenham a alta disponibilidade aplicada a elas, e que outras cargas de trabalho sejam deixadas a técnicas padrão.

Exemplos de cargas de trabalho que podem ser críticas e que podem ser efetivamente atendidas com alta disponibilidade podem ser um sistema de pedidos online, em que a latência criada pela replicação multirregional tem pouco impacto sobre o sistema como um todo, mas perder pedidos poderia ser muito impactante financeiramente caso um sistema falhe. Um exemplo de uma carga de trabalho em que a alta disponibilidade pode ser fácil de implementar, mas ineficaz, seria um site de intranet interno que serve perguntas comumente feitas de RH; simplesmente não seria economicamente eficiente evitar pequenas quantidades de indisponibilidade ocasional para um sistema como este. Um exemplo de um sistema em que o risco é alto, mas o custo ou a eficácia da mitigação de risco a torna impraticável ou até impossível, poderia ser um banco de dados financeiro de “ticks” que exige a ingestão de quantidades massivas de dados de baixa latência, e a capacidade de manter uma réplica não apenas seria incrivelmente cara, mas poderia introduzir latência que minaria a capacidade do sistema de ter um desempenho adequado. Cada negócio e carga de trabalho é único e deve ser avaliado com cuidado.

É claro que técnicas de alta disponibilidade podem ser acionadas em etapas; não é um empreendimento de tudo ou nada. Pode ser prático mitigar o risco de falha em nível de sistema tendo tolerância a falhas na camada de aplicativo para proteger contra a falha de hardware do sistema, plataforma de virtualização ou armazenamento. Mas, para a mesma carga de trabalho, pode não ser valioso proteger contra a perda de um único site. Se uma carga de trabalho serve apenas a um site específico ou simplesmente não é valiosa o suficiente para o grande investimento necessário para fazê-la realizar failover entre sites, ela poderia facilmente cair “no meio.” É muito comum que cargas de trabalho implementem apenas soluções parcialmente de alta disponibilidade, muitas vezes porque um departamento de TI pode ser responsável por apenas uma parte delas e não ter voz sobre coisas como suporte de energia e HVAC, mas provavelmente o mais comum é porque algumas técnicas de alta disponibilidade são vistas como de alta visibilidade e fáceis de vender à gerência, enquanto outras, como energia e ar-condicionado de alta qualidade, muitas vezes não são, ainda que possam facilmente proporcionar um melhor custo-benefício. Há boas razões pelas quais certas técnicas podem ser escolhidas e outras não, pois elas afetam diferentes componentes de risco e alguns riscos podem ter um impacto diferente sobre um negócio ou carga de trabalho individual.

A alta disponibilidade exige uma reflexão cuidadosa sobre se vale a pena considerá-la e uma reflexão ainda mais cuidadosa sobre a implementação. Construir sistemas de HA verdadeiros requer uma quantidade significativa de esforço e expertise e, geralmente, um custo substancial. Entender quais componentes da HA são valiosos e quais não são requer não apenas extensa expertise técnica, mas também habilidades financeiras e gerenciais. Os departamentos devem trabalhar juntos de forma extensa para realmente entender como a HA impactará uma organização e quando ela valerá o investimento. É fundamental que se lembre que a necessidade de alta disponibilidade em uma organização ou para uma carga de trabalho é tudo menos uma conclusão precipitada e não deveria ser nem um pouco surpreendente constatar que práticas extensas de alta disponibilidade, ou mesmo práticas casuais de alta disponibilidade, acabam sendo economicamente impraticáveis.

De muitas maneiras, isso ocorre porque a disponibilidade padrão atingiu tal estado que há continuamente cada vez menos risco a mitigar. Componentes de tecnologia usados em uma infraestrutura de negócios, mais notavelmente servidores, equipamentos de rede e armazenamento, tornaram-se tão confiáveis que a quantidade de indisponibilidade contra a qual devemos nos proteger é bastante baixa. A maior parte da crença na necessidade de alta disponibilidade por reflexo vem de uma era diferente, quando hardware confiável era inacessível e até o equipamento mais caro era bastante não confiável pelos padrões modernos. Essa sensação de desgraça iminente de que qualquer dispositivo poderia falhar a qualquer momento vem de uma era mais antiga, não da atual. O equipamento moderno, embora obviamente ainda carregue riscos, é incrivelmente confiável.

Além de outros riscos, investir em excesso em soluções de alta disponibilidade carrega riscos financeiros e de negócios que podem ser substanciais. Isso aumenta a dívida técnica diante da incerteza do negócio. E se o negócio crescer de repente ou, pior, e se ele de repente encolher, mudar de direção, for comprado ou fechar completamente? O investimento na alta disponibilidade já foi gasto, mesmo que a necessidade de sua proteção desapareça. E se a tecnologia ou a localização mudarem? Parte ou todo um investimento em alta disponibilidade pode ser perdido antes do que teria sido em seu fim de vida útil esperado.

Como praticantes de TI, avaliar os benefícios, riscos e custos de soluções de tecnologia está no cerne do que fazemos. Como tudo o mais na infraestrutura de negócios, determinar o tipo de mitigação de risco, o valor da proteção e quanto é financeiramente adequado é nossa responsabilidade fundamental e não pode ser ignorado ou passado por alto. Nunca podemos simplesmente presumir que a alta disponibilidade é necessária, nem que ela pode simplesmente ser dispensada. É em análises dessa natureza que a TI traz alguns de seus maiores valores às organizações. É aqui que temos o potencial de brilhar mais.