Não importa quanto tempo você gaste para elaborar um acordo SLA, não é possível garantir 100% da entrega.
Olhando a programação de uma conferência sobre computação em nuvem, observei que havia uma série de sessões dedicadas à negociação de SLAs (sigla em inglês para contratos em nível de serviço) com os provedores de cloud. Um SLA é fundamental para o sucesso do uso da computação em nuvem.
As sessões descritas detalhavam como iriam auxiliar os participantes com temas como computação em nuvem:
• Definições de disponibilidade, desempenho e uptime
• Técnicas de negociação na elaboração de um SLA
• Quais fatores incluir em um SLA? Disponibilidade de máquinas virtuais, tempos de resposta, latência de rede, etc
• Negociação de multas por violação de SLA
Olhando para uma série de discussões sobre o tema de SLAs, as descrições dessas sessões inevitavelmente trouxeram à mente a seguinte verdade: SLAs não são sobre melhorar a disponibilidade, a sua finalidade é fornecer a base legal para o caso de um incidente.
No entanto, nenhuma das sessões apontava para isso. As descrições das sessões parecem sugerir que uma negociação SLA inteligente de alguma forma garante que os aplicativos sejam imune a falhas. Na verdade, nada poderia estar mais longe da verdade.
A realidade é que toda infraestrutura terá interrupções de um tipo ou outro. Enquanto a avaliação cuidadosa das capacidades de um provedor deve permitir a seleção de um fornecedor mais robusto e o pagamento de uma taxa mais elevada pode garantir uma resposta mais rápida ou ter comunicação com uma equipe dedicada, não há imunidade a falhas. Não importa quanto tempo você gaste para elaborar um acordo SLA, não é possível garantir 100% de tempo de atividade.
Então, por que as pessoas ficam obcecadas com os SLAs?
Por um lado, porque elas têm a sensação de controle. Sentado em uma sala, redigindo um contrato e insistindo em um tratamento especial, as pessoas se sentem como se estivessem afirmando seu domínio. E se sente muito bem. Mas não imagine que você vai mudar fundamentalmente o contrato com o provedor. Aprendi isso em uma apresentação sobre SLA dada por um advogado.
Depois de dedicar 90 minutos para as minúcias dos contratos, ele concluiu dizendo: "Obviamente, você não será capaz de mudar muito o contrato padrão, porque todos são escritos para reduzir a responsabilidade do provedor. O que você está discutindo é qual crédito que você vai receber por um serviço. "
Outro motivo pelo qual as pessoas são obsessivas com SLAs, é que elas podem dar uma base para regatear no futuro. Ser durão pode significar uma maior compensação mais tarde. Mas, olhando em perspectiva: não importa o quanto pechinchar, você não vai ser totalmente compensado pelas perdas de negócios decorrentes da interrupção.
É preciso reiterar: a compensação prevista no SLA está limitada a um crédito contra o custo do serviço – não o custo para o usuário com a interrupção. E o custo do serviço é muitas vezes uma percentagem pequena do preço da interrupção.
Eis um exemplo que um ex-funcionário de uma das maiores empresas de terceirização compartilhou comigo: o site de um grande cliente do setor varejista caiu. Compras não puderam ser realizadas durante seis horas, resultando em perda de 50 milhões de dólares em receita. Qual foi a compensação do contratante para o varejista? Um crédito de seis horas de serviço, cerca de 300 dólares.
A moral dessa história? Manter toda a discussão sobre SLA em perspectiva. Não há garantia de que sua aplicação estará disponível.
A pior coisa em investir muita energia em SLA é que pode distraí-lo de uma questão muito mais importante: como garantir uptime. Se você está no Titanic, e que é atingido por um iceberg e afunda, todo o tempo que você gastou negociando a localização e as condições de sua cadeira de praia não vai ajudar nem um pouco seus clientes.
A questão mais importante é, como você deve pensar se a aplicação sair do ar e quais são suas opções para melhorar o uptime?
Como ponto de partida, mantenha em mente a observação de Voltaire: "Le mieux est l'ennemi du bien". Traduzido livremente, a perfeição é inimiga do bem. Aplicada a computação em nuvem, isso pode ser pensado como "Não evitar a adoção de um provedor de nuvem porque não pode garantir uptime de 99,999%, quando os próprios data centers estão longe de um uptime aceitável".
Se adotar a computação em nuvem melhora significativamente o tempo de atividade, é a coisa certa a fazer. Se não, há estatísticas reais da disponibilidade de ambiente computacional próprio, é um sinal dizendo que a mudança para um provedor de nuvem é dar um passo na direção certa.
Pode não ser perfeito, mas é muito melhor do que um ambiente que não pode sequer acompanhar o seu próprio tempo de atividade. Acredite em mim, há muitas, muitas organizações de TI com nada mais do que garantias de penhor sobre o seu desempenho uptime.
Eis alguns passos que você pode tomar para melhorar o tempo de funcionamento do aplicativo:
1. Arquitetar seus aplicativos para o caso de falha de recurso. Talvez o maior passo que você pode tomar para melhorar o uptime da sua aplicação é ter uma arquitetura para que ele possa continuar a realizar em face da insuficiência de recursos individuais (por exemplo, falha no servidor). Redundância de servidores assegura que a aplicação vai continuar funcionando mesmo se houver uma queda de servidor.
2. Arquitetar sua topologia para o caso de falha da infraestrutura. Enquanto o design criterioso pode proteger a disponibilidade do aplicativo, no caso de uma falha de hardware, ele não pode ajudá-lo se o ambiente do aplicativo falha. Se o data center inteiro no qual um aplicativo é executado cai, o uso de aplicativos redundantes é fútil. A resposta, nesse caso, é implementar a distribuição de aplicativos geográficos de modo que mesmo se uma parte da própria aplicação torna-se indisponível devido à falta de um provedor de grande escala, o aplicativo pode continuar a funcionar. É claro que isso faz com que o design da aplicação seja mais complexa, mas garante uma maior medida de proteção durante a inatividade.
3. Arquitetar sua implemtação no caso de fracasso do provedor. Por exemplo, toda infraestrutura de rede do provedor poderia ir abaixo, ou a do fornecedor de cloud cair abruptamente. Pode ser exagerado, mas ambos os cenários poderiam acontecer com os serviços on-line no passado. A solução é estender a arquitetura de seu aplicativopor meio de vários provedores. Fazê-lo é extremamente difícil porque a semântica de como os provedores de cloud variam torna difícil projetar um aplicativo que pode incorporar funcionalidades diferentes. No entanto, é possível implementar essa arquitetura de aplicações com o planejamento suficiente e design cuidadoso.
O que deveria ser óbvio a partir dessa discussão é que os níveis mais elevados de certeza uptime requerem aumento dos níveis de complexidade técnica, que se traduz em aumento dos níveis de investimento.
Decidir se uma determinada aplicação requer esse nível de investimento é um exercício de avaliação de risco. Certamente isso deve ser um exercício explícito, em que as trocas entre a exposição de negócios, investimento e complexidade operações técnicas são avaliadas. Não é nenhum exercício fácil, e provavelmente não há respostas fáceis. No entanto, aumenta a probabilidade de ter um resultado aceitável do que uma prolongada, porém fútil, discussão sobre SLA.
Bernard Golden é CEO da consultoria HyperStratus, especializada em virtualização, computação em nuvem e assuntos relacionados. Ele também é o autor de "Virtualization for Dummies", o best-seller sobre a virtualização de data.
