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.