Quantificando o SLA para os serviços de TI na nuvem
Introduçã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