Garantir o nível de serviço ou garantir o uptime?

Por que gerentes de TI são tão obcecados com os SLAs?

Não importa quanto tempo você gaste para elaborar um acordo SLA, não é possível garantir 100% de tempo de atividade.

Mas SLAs dão uma sensação de controle. Sentadas em uma sala, redigindo um contrato e tendo um tratamento especial, as pessoas se sentem como se estivessem afirmando seu domínio. E se sentem muito bem.

Outro motivo pelo qual as pessoas são obsessivas com SLAs, é que elas podem ter uma base para regatear no futuro. Ser durão pode significar uma maior compensação mais tarde. Mas, olhando em perspectiv, não importa o quanto tentar cobrir, 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.

Portanto, mantenha toda essa discussão sobre SLA em perspectiva.

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, é atingido por um iceberg e afunda, todo o tempo gasto negociando a localização e as condições de sua cadeira de praia vão por água abaixo, literalmente.

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.

Eis alguns passos relevantes.

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 implementação para o 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 aplicativo por 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 uptime requerem aumento dos níveis de complexidade técnica, ou seja, 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.

Site: CIO
Data: 02/10/2015
Hora: 9h17
Seção: Tecnologia
Autor: Bernard Golden
Link: http://cio.com.br/tecnologia/2015/10/02/garantir-o-nivel-de-servico-ou-garantir-o-uptime/