Como definir medidas apropriadas para um Acordo de Nível de Serviço?

Question

Eu trabalho para uma pequena empresa de desenvolvimento que está sendo cada vez mais solicitada a elaborar SLAs formais para nossos produtos com base em configurações específicas.

Do ponto de vista de desenvolvimento, estou confortável com isso, mas não adianta dizer que atingiremos metas específicas de uma perspectiva de software, se elas não forem realistas do ponto de vista de hardware / plataforma - somente os clientes se preocupam com a disponibilidade geral do sistema.

O que eu deveria estar olhando de uma perspectiva de plataforma? Que tipo de métricas e níveis?

Além disso, quais são as armadilhas (por exemplo, de uma perspectiva de software que eu nunca comprometeria com um tempo fixo? Eu não tenho idéia se vou ter que reescrever todo o produto para corrigir algo dizendo que podemos consertá-lo em 5 dias é potencialmente impossível - com o que devo evitar me comprometer do ponto de vista de hardware / SO / plataforma)?

    

Answer 1

Eu tenho uma vasta experiência neste espaço; Eu faço muito trabalho para algumas empresas da Fortune-5 que operam seus centros de dados como um ISP faria para os vários departamentos da empresa que precisam de hospedagem & serviços de suporte.

Eles normalmente têm duas métricas chamadas de SLA (Acordo de Nível de Serviço) e um OLA (Acordo de Nível Operacional).

Os SLAs são atendidos pelo tipo de hardware em uso. Quando falamos sobre SLAs, usamos níveis para descrevê-los. SLA-1 sendo tempo de inatividade zero, SLA-2 é algo como até 1 hora de inatividade, SLA-3 é 8 horas, etc ... Os SLAs são atendidos através do uso de equipamentos redundantes. Em uma empresa, usamos muito a Cisco para criar alta disponibilidade (Cisco CSMs e equipamentos GSS). Quando falamos sobre níveis de SLA, geralmente falamos sobre HA (High Availability) e DR (Disaster Recovery). Em situações em que uma empresa possui vários datacenters, o componente HA é geralmente um atributo por datacenter, enquanto o DR é um atributo entre datacenter; ambos medidos em termos de RPO (objetivo do ponto de recuperação) e RTO (objetivo do tempo de recuperação) para significar o nível de SLA.

Os OLAs são, em termos básicos reais, a rapidez com que alguém (um humano) responde a um evento que requer intervenção manual / ação corretiva. Os OLAs são tipicamente medidos em termos de tempos de resposta também; eles usam os mesmos objetivos RTO / RPO. Uma empresa que eu consultei usa 6 níveis para suas métricas de OLA. Os primeiros 3 níveis aqui são um exemplo disso:

OLA-1: RTO 0 < 2 horas OLA-2: RTO > = 2 & < = 4 horas OLA-3: RTO > = 24 horas & < = 30 dias, se não houver falha no datacenter, se falha de CC > 30 dias.

As coisas que conduzem as métricas de OLA e SLA são algo chamado de classificação da CIA. CIA = Confidencialidade, Integridade e Disponibilidade. Os dados de um aplicativo devem ser classificados pela unidade de negócios que paga pelo aplicativo. A CIA ajudará a impulsionar o que o OLA e o SLA devem ser. Cada parte do nível CIA recebe um número de 1 a 3. Assim, por exemplo, uma classificação CIA de 1-1-1 seria Altamente Confidencial, Nível Mais Alto de Integridade e Maior Nível de Disponibilidade. Uma classificação CIA de 3-3-3 é a mais baixa que você pode ir. Assim, uma classificação CIA de 3-3-3 tipicamente mapeia para um SLA & OLA nível 6, onde um SLA-6 & OLA-6 é o menor (tempo de resposta mais longo) garantido.

Como você obtém uma classificação da CIA geralmente equivale a descobrir quanto dinheiro uma empresa perderá se os dados forem roubados (Confidencialidade), comprometidos (Integridade) ou quando os sistemas estiverem inativos (Disponibilidade). Assim, uma empresa que perder US $ 10 milhões se dados confidenciais forem roubados pode ter uma classificação C de 1 ou se essa perda de dados não for crítica e custar à empresa, digamos, US $ 1.000, então você pode ter uma classificação C de 3 .

Normalmente, é como as grandes empresas que eu consultei lidam com essas coisas.

    

Answer 2

Eu demoro em me comprometer com um tempo fixo em problemas de hardware, o mesmo que em software. Você nunca sabe quando estará esperando por um fornecedor para consertar um bug crítico em algo. Em termos de níveis de SLA, descobri que eles tendem a ser da forma que "alguém estará trabalhando em seu problema dentro de X horas". X, se é claro, depende de quanto eles pagam, mas em algum lugar entre 1 e 8 horas parece normal, na minha experiência.

    

Answer 3

Se for solicitado que você forneça um SLA para a restauração de problemas de hardware nos quais seu software está instalado, a resposta é "não". Você poderia comprometer-se com um tempo de resposta, mas sem controlar toda a pilha de hardware / os / software que você não pode comprometer com um tempo de resolução.

Talvez o seu cliente esteja lhe dizendo de uma maneira estranha que ele realmente precisa de uma oferta hospedada para o seu produto? Dessa forma, eles podem evitar quaisquer problemas internos com os quais estejam preocupados e apenas lhe dar um cheque.

    

Answer 4

Uma coisa a considerar ao contratar um SLA é que o SLA por si só não significa absolutamente nada, deve ser observado junto com as penalidades caso o SLA não seja cumprido.

Por exemplo, nosso ISP nos oferece 100% de SLA na rede, mas a quantia máxima que podemos receber é nossa fatura mensal, que é realmente baixa, já que a largura de banda é barata e nem de longe a quantidade de dinheiro que perdemos a rede está inativa.

Além disso, o que geralmente é escrito nos contratos é a rapidez com que alguém responderá ao problema, nunca quanto tempo será necessário para corrigi-lo. Então, se eles fizerem você se comprometer com tempos de resposta curtos, basta colocar um estagiário no turno da noite para embaralhar as passagens para você até você acordar e lá ir.

Na minha experiência, todo esse negócio de SLA praticamente significa muito, muito pouco ou nada.