Quantificando o SLA para os serviços de TI na nuvem

Quantificando o SLA para os serviços de TI na nuvem

serviços na nuvemIntrodução

A prolongada quarentena que implicou na prática do “home office” acelerou fortemente a migração ou a contratação de novos serviços de TI na nuvem.

Sem dúvida a nuvem nas suas variadas opções oferece muitas vantagens quando comparado com o Data Center próprio: infraestrutura profissional muitas vezes com certificação Tier III ou IV (o máximo é V), escalabilidade, segurança reforçada, muitas redundâncias etc.   Já abordamos em vários posts estes benefícios, por exemplo neste https://strohlbrasil.com.br/computacao-em-nuvem-e-solucao-para-a-pandemia/ .

Porém, e sempre tem pelo menos um porém, a nuvem nada mais é do que um Data Center de um terceiro, às vezes de um quarto ou quinto, onde estes serviços/aplicações estão instalados.

Portanto, estes Data Centers também estão sujeitos a incidentes, alguns fora do seu controle, outros não, que podem interromper a prestação destes serviços por algum tempo.   Também temos abordado este assunto em outros posts, como neste https://strohlbrasil.com.br/10-indisponibilidades-de-servicos-na-nuvem/

Níveis de serviço

Portanto, é fundamental que os níveis de serviço a serem prestados estejam claramente estabelecidos no contrato de prestação de serviços de TI na nuvem e, principalmente, que este nível de serviço atenda às expectativas dos principais produtos, serviços e/ou processos da organização.

Tipicamente os contratos definem uma certa disponibilidade medida num determinado período de tempo com uma série de salvaguardas para proteger o prestador de serviços de TI na nuvem.   Um exemplo de disponibilidade pode ser: 99, 5% de “uptime” no mês, o que significa, neste exemplo, até 3 horas e 36 minutos horas de indisponibilidade.

Também estes contratos preveem que caso a disponibilidade média não seja atingida será concedido um desconto na fatura dos serviços e/ou um acréscimo no tempo de duração do contrato equivalente ao excedente do tempo de indisponibilidade previsto contratualmente.   Exemplo, digamos que o serviço ficou indisponível 4 horas e o contratado era 99,5%/mês.   Você será beneficiado com um acréscimo de 24 minutos no último mês do contrato vigente, ou seja, muito próximo a nada.

Se ao invés de 4 horas fossem 10 horas você seria beneficiado com um acréscimo de 6 horas e 24 minutos no seu contrato.   Isto te atende?

A Pergunta certa a ser feita?

A pergunta certa a ser feita é outra, o seu negócio suporta ficar parado mais do que 3 horas e 24 minutos como ilustrado?   Talvez sim, talvez não.   E 10 horas seguidas o equivalente a praticamente um dia comercial?   Você amargará os prejuízos da indisponibilidade dos seus serviços aos seus clientes enquanto, em contrapartida, você será “beneficiado” com 6 horas e 24 minutos totalmente grátis (alguns contratos preveem o pagamento de multas por lucros cessantes).   Isto sem falarmos de eventuais perdas de dados o que pode ser catastrófico para o seu negócio.

Como especificar o SLA?

Então, como especificar melhor o SLA para os serviços de TI na nuvem?   Na verdade isto vale para qualquer serviço de TI não só a nuvem.

Voltamos aos fundamentos da Continuidade de Negócios.   Você deve realizar uma Análise de Impacto nos Negócios (BIA), relacionar os produtos, serviços e processos às aplicações que os sustentam e quantificar, com os gestores de negócios, os RTOs e RPOs para cada aplicação. Não sabe o que são estas siglas?   Assista este vídeo https://www.youtube.com/watch?v=mK4bdnPxU3k)

Assumindo que estes sejam os valores aceitos pelo seu negócio versus o Apetite ao Risco a ser tomado, então estes são os valores a serem incluídos no contrato de prestação de serviços de TI na nuvem.

Ao invés de 99, 5% de “uptime” no mês passaremos a ter que “a indisponibilidade máxima de um determinado serviço ou aplicação será de XX horas e com uma perda máxima de dados de até YY horas“.    Muito mais objetiva que a cláusula anterior, concorda?   Depois seguiriam-se as cláusulas de penalidades pelo descumprimento dos SLAs contratados.

É conveniente também que seja realizada uma “due dilligence” no prestador de serviços na nuvem de forma confirmar que, de fato, estes SLAs serão atingidos, se necessário com um teste controlado e coleta de evidências.

O risco residual

Mesmo assim ainda resta um risco residual, a perda total ou do Data Center ou da infraestrutura que suporta os serviços contratados.   Obviamente, neste cenário, o prestador de serviços de TI na nuvem não fornecerá o SLA contratado e as eventuais multas e outras penalidades previstas no contrato não resolverão o seu problema de disponibilidade.

Você vai contratar os serviços de DR – Disaster Recovery ou vai assumir o risco?   Se for contratar o DR você poderá utilizar os mesmos RTOs e RPOs já quantificados, ou ser um pouco mais tolerante acrescentando algum tempo adicional, sempre lembrando que cada minuto a mais de indisponibilidade custa mais caro para o seu negócio.

E.T.: o tempo de indisponibilidade deve sempre ser medido a partir do momento em que o serviço ficou indisponível e não após alguma decisão formal interna do prestador de serviços de TI na nuvem.

BIA é a chave de tudo

A chave de tudo isto é a Análise de Impacto nos Negócios – BIA.

Você não sabe o que é BIA ou não fez uma?   Quem decidiu tudo foi a TI corporativa baseada na sua percepção de quanto cada produto, serviço ou processo de negócios pode ficar parado e/ou pelo preço?

Te desejamos muita sorte.   Isto é o mesmo que pular de um avião com um volume nas costas sem saber se é uma mochila ou um paraquedas.

Quer saber mais sobre Planos de Contingência ou Continuidade de Negócios, de Recuperação de Desastres (Disaster Recovery) ou Gestão de Crises?

Por favor preencha o formulário abaixo e entraremos em contato.

#servicosnanuvem   #servicosdetinanuvem   #sla  #disasterecovery   #continuidadedenegocios   #businesscontinuity   #Businessimpactanalysis   #analise de impacto nos negócios   #BIA   #RTO   #RPO

 

Compartilhe este Artigo

Compartilhar no email
Compartilhar no facebook
Compartilhar no twitter
Compartilhar no linkedin
Compartilhar no whatsapp

Artigos Relacionados

3 Usos da BIA nos Ataques Cibernéticos

3 Usos da BIA nos Ataques Cibernéticos Aparentemente neste período de quarentena houve um aumento significativo de ataques cibernéticos às organizações.   Pode ser somente um

Apetite ao Risco

Apetite ao Risco Introdução Um dos pilares da Continuidade de Negócios (BC) e da Recuperação de Desastres (DR) é o Apetite ao Risco. É baseado

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Este site utiliza cookies para proporcionar uma melhor experiência para nossos usuários. Ao continuar a navegação neste site, você estará de acordo com os cookies que estão sendo utilizados. Se quiser saber mais sobre nossa política de cookies, clique aqui.