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

O dia que a nuvem pegou fogo

O dia que a nuvem pegou fogo Histórico No nosso post de 10/03/21 divulgamos na seção NEWS da nossa newsletter semanal o incêndio no data

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.