Contratos de nível de serviço

Concluído

Até o momento, neste curso, falamos sobre as ideias fundamentais por trás da computação em nuvem e alguns dos modelos de serviço que surgiram sob o paradigma da computação em nuvem. Supondo que uma organização queira migrar a infraestrutura e os serviços para um provedor de nuvem, várias questões surgem. Por exemplo, como uma organização:

  • Define os requisitos em termos dos serviços que ela exige do provedor de serviços em nuvem?
  • Identifica o tipo e a quantidade dos serviços que ela requer?
  • Determina o nível de serviço e suporte que ela espera de um provedor de nuvem?
  • Monitora e valida o tipo e a qualidade do serviço garantido pelo provedor de serviços em nuvem?

Quando uma organização precisa declarar formalmente os requisitos de serviço em termos comerciais e jurídicos, ela define esses requisitos em termos de objetivos de nível de serviço, definidos da seguinte forma:

Objetivo de nível de serviço

(definição) Um objetivo de nível de serviço é definido como um elemento-chave que define algum aspecto do serviço esperado do provedor de serviços

Um objetivo de nível de serviço comum com os provedores de serviços em nuvem, por exemplo, é uma garantia do tempo de atividade em que é garantido que um serviço esteja disponível e executando dentro de parâmetros operacionais normais em uma porcentagem especificada do tempo.

Os objetivos de nível de serviço geralmente são estabelecidos entre o cliente e um provedor de serviços em um contrato maior conhecido como contrato de nível de serviço ou SLA, definido da seguinte forma:

Contrato de nível de serviço

(definição) Um contrato de nível de serviço (SLA) é um contrato entre um provedor de serviços (interno ou externo) e o cliente que define o nível de serviço esperado do provedor de serviços

Há acordos de nível de serviço em vários setores em que existe um relacionamento fornecedor-cliente para um serviço que é fornecido periodicamente pelo fornecedor ao cliente. Os SLAs em tecnologia da informação, em sua forma atual, são usados desde o final dos anos 80 por operadoras de telefonia fixa como parte dos contratos com clientes corporativos.

Um SLA típico pode ser formado pelos seguintes componentes:

  • Uma definição dos serviços que serão fornecidos ao cliente através do provedor de serviços
  • Métodos para medir o desempenho
  • Protocolos para gerenciar problemas
  • Uma lista de deveres do cliente
  • Garantias que precisam ser respeitadas pelo provedor de serviços
  • Procedimentos envolvidos na recuperação de desastre
  • Processo e políticas referentes ao encerramento do contrato

Os princípios que regem os SLAs há décadas são especialmente pertinentes no setor de computação em nuvem. É importante que as organizações entendam o que um provedor de serviços em nuvem garante ou não.

SLAs na computação em nuvem

Os SLAs evoluíram ao longo dos anos para atender a diferentes tipos de serviços de TI. A evolução dos serviços de infraestrutura compartilhada, como nuvens, exigiu o uso de acordos de nível de serviço sólidos. SLAs, por definição, podem definir qualquer nível de serviço, mas um SLA bem estruturado irá fazê-lo, idealmente1:

  • Codifica os parâmetros específicos e os níveis mínimos necessários para cada elemento do serviço, bem como soluções para o não cumprimento desses requisitos.
  • Afirma a propriedade dos dados armazenados pelo cliente no sistema do provedor de serviços e especifica os direitos do cliente para recuperá-los.
  • Detalha a infraestrutura do sistema e os padrões de segurança a ser mantidos pelo provedor de serviços, além dos direitos do cliente de auditar sua conformidade.
  • Especifica os direitos e o custo do cliente para continuar e descontinuar o uso do serviço do provedor de serviços em nuvem.

Para usuários da nuvem, o elemento mais importante de um SLA é normalmente o tempo de atividade garantido, que varia de acordo com o serviço e o provedor. O tempo de atividade geralmente é medido em "noves", em que três noves, por exemplo, significam 99,9%, quatro noves significam 99,99%, e assim por diante. Os fornecedores frequentemente oferecem créditos de serviço quando os SLAs não são cumpridos. A Amazon, por exemplo, concede aos clientes um crédito de serviço de 10% se o tempo de atividade mensal para uma instância do Elastic Beanstalk ficar abaixo de 99,99% e um crédito de 30% se ficar abaixo de 99%. A porcentagem de 99% parece alta, mas significa que um serviço pode ficar indisponível por cerca de 3,5 dias por ano. Isso é tempo demais para uma empresa como a Amazon ou a Expedia cuja principal interface com os clientes (e meios de gerar receita) é pela Web.

As garantias de tempo de atividade também podem variar de acordo com a configuração e a camada de serviço. A Microsoft, por exemplo, garante que você terá conectividade com uma máquina virtual do Azure pelo menos 99,99% do tempo, mas apenas se duas ou mais instâncias da máquina virtual forem implantadas em duas ou mais zonas de disponibilidade na mesma região do Azure. Além disso, alguns serviços em nuvem permitem escolher entre várias camadas de serviço, com camadas mais altas oferecendo maior tempo de atividade garantido. De forma geral, quanto maior o tempo de atividade garantido, maior o custo.

Auditoria na computação em nuvem

Embora a computação em nuvem ofereça inúmeras vantagens, um dos principais desafios é garantir e verificar a confiabilidade dos serviços de nuvem. Se um cliente assina um contrato de serviço garantindo um certo nível de disponibilidade, como o cliente sabe se o fornecedor está cumprindo os termos do contrato? Nesse caso, como o provedor de nuvem sabe?

Os principais provedores de nuvem, incluindo a Amazon, a Microsoft e o Google, contratam auditores externos para monitorar suas plataformas quanto à disponibilidade e outros fatores, incluindo segurança e confidencialidade dos dados. Os auditores geram relatórios SOC que estão em conformidade com o padrão SOC (Controles da Organização de Serviços) do AICPA (Instituto Americano de Contadores Públicos Certificados). Os relatórios SOC se enquadram em três categorias:

  • Relatórios SOC 1 que abordam relatórios financeiros
  • Relatórios SOC 2 que abordam segurança, disponibilidade e privacidade
  • Relatórios SOC 3 que também abordam segurança, disponibilidade e privacidade

Os relatórios SOC 1 e SOC 2 geralmente são privados e disponibilizados apenas para clientes que assinaram acordos de confidencialidade (NDAs) com o provedor de nuvem. Os relatórios SOC 3 estão disponíveis para o público.

Os principais provedores de nuvem também oferecem serviços de monitoramento para os deles. Esses serviços podem ser implantados juntamente com serviços de IaaS, PaaS e SaaS para alertar os clientes praticamente em tempo real se, por exemplo, um site ficar inativo ou uma VM ficar indisponível. Embora a responsabilidade pelo cumprimento dos termos do SLA seja, em grande parte, do provedor de nuvem, os clientes também podem arquitetar as soluções implementadas para maximizar a disponibilidade – por exemplo, empregando mecanismos de failover oferecidos pelo provedor de nuvem para garantir que o tráfego para um banco de dados ou VM que tenha ficado indisponível seja redirecionado para uma cópia desse banco de dados ou VM em outra região.

Dada a natureza dos serviços de nuvem, a auditoria e o monitoramento são imprescindíveis. Isso requer que a avaliação e o monitoramento ocorram em tempo real, a fim de disparar uma resposta rápida para proteger o serviço e a reputação do cliente. Em nuvens públicas, isso deve ser feito juntamente com prevenção da exposição de dados de um cliente para outros na nuvem. A auditoria praticamente em tempo real está evoluindo rapidamente e se tornando um requisito para serviços confiáveis de computação em nuvem, que exigirão trilhas de auditoria e monitoramento de métricas de serviço, desempenho e segurança, entre outros.

Referências

  1. Thomas Trappler. Se estiver na nuvem, obtenha-a em papel: problemas de contrato de computação em nuvem. https://www.educause.edu/ero/article/if-its-cloud-get-it-paper-cloud-computing-contract-issues

Verificar seu conhecimento

1.

A Microsoft oferece aos clientes um crédito de serviço de 10% se o tempo de atividade mensal de um Serviço de Aplicativo do Azure ficar abaixo de 99,95%. Supondo que um mês tenha 31 dias, quantos minutos um Serviço de Aplicativo deve estar inativo em um mês para acionar um crédito?

2.

Suponha que você crie uma solução que consista em dois serviços em nuvem interconectados, cada um com um SLA que garante que o serviço funcionará pelo menos 99,50% do tempo. Qual é o tempo mínimo de atividade esperado para a solução como um todo?