Eu trabalho para uma pequena empresa de desenvolvimento que é cada vez mais solicitada a elaborar SLAs formais para nossos produtos com base em configurações específicas.
Do lado do desenvolvimento, estou confortável com isso, no entanto, não faz sentido dizer que atingiremos metas específicas do ponto de vista do software se elas não forem realistas do ponto de vista do hardware/plataforma - os clientes só se preocupam com o geral disponibilidade do sistema.
O que devo observar do ponto de vista da plataforma? Que tipo de métricas e níveis?
Além disso, quais são as dicas (por exemplo, do ponto de vista do software, eu nunca me comprometeria com um tempo de correção - não tenho ideia se terei que reescrever todo o produto para corrigir algo, dizendo que podemos corrigi-lo em 5 dias é potencialmente impossível - o que devo evitar do ponto de vista de hardware/sistema operacional/plataforma)?
Responder1
Tenho vasta experiência neste espaço; Eu faço muito trabalho para algumas empresas da Fortune 5 que operam seus data centers como um ISP faria para os vários departamentos da empresa que precisam de serviços de hospedagem e suporte.
Eles normalmente têm duas métricas chamadas SLA (Acordo de Nível de Serviço) e OLA (Acordo de Nível Operacional).
Os SLAs são atendidos de acordo com o tipo de hardware em uso. Ao falar sobre SLAs usamos níveis para descrevê-los. SLA-1 é zero tempo de inatividade, SLA-2 é algo como até 1 hora de inatividade, SLA-3 é de 8 horas, etc... Os SLAs são atendidos através do uso de equipamentos redundantes. Em uma empresa, usamos muito Cisco para criar alta disponibilidade (Cisco CSMs e equipamentos GSS). Quando falamos em níveis de SLA geralmente falamos em HA (High Availability) e DR (Disaster Recovery). Em situações em que uma empresa possui vários data centers, o componente HA geralmente é um atributo por data center, enquanto o DR é um atributo entre data centers; ambos medidos em termos de RPO (Objetivo de Ponto de Recuperação) e RTO (Objetivo de Tempo de Recuperação) para significar o nível de SLA.
OLAs são, em termos reais e básicos, a rapidez com que alguém (um ser humano) responde a um evento que requer intervenção manual/ação corretiva. Os OLAs também são normalmente medidos em termos de tempos de resposta; eles usam os mesmos objetivos de RTO/RPO. Uma empresa para a qual presto consultoria usa 6 níveis para suas métricas OLA. Os primeiros 3 níveis aqui são um exemplo disso:
OLA-1: RTO 0 < 2 horas OLA-2: RTO >= 2 e <= 4 horas OLA-3: RTO >= 24 horas e <= 30 dias se não for uma falha do data center, se falha de CC > 30 dias.
O que impulsiona as métricas OLA e SLA é algo chamado de classificação CIA. CIA = Confidencialidade, Integridade e Disponibilidade. Os dados de uma aplicação devem ser classificados pela unidade de negócios que paga essa aplicação. A CIA ajudará a definir o que o OLA e o SLA deveriam 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 Nível Mais Alto de Disponibilidade. Uma classificação da CIA de 3-3-3 é a mais baixa que você pode atingir. Assim, uma classificação CIA de 3-3-3 normalmente corresponde a um nível de SLA e OLA de 6, onde um SLA-6 e OLA-6 é o mais baixo (tempo de resposta mais longo) garantido.
A maneira como você obtém uma classificação da CIA geralmente significa descobrir quanto dinheiro uma empresa perderá se os dados forem roubados (Confidencialidade), comprometidos (Integridade) ou quando os sistemas estiverem inativos (Disponibilidade). Portanto, uma empresa que pode perder US$ 10 milhões se dados confidenciais forem roubados pode ter uma classificação C de 1 ou se a perda de dados não for crítica e custar apenas à empresa, digamos, US$ 1.000, então você pode ter uma classificação C de 3. .
Normalmente é assim que as grandes empresas que consultei lidam com essas coisas.
Responder2
Eu demoraria a me comprometer com um tempo de correção para problemas de hardware, assim como para software. Você nunca sabe quando estará esperando que um fornecedor conserte um bug crítico em alguma coisa. Em termos de níveis de SLA, descobri que eles tendem a ser do tipo "alguém estará trabalhando no seu problema dentro de X horas". X depende, claro, de quanto eles pagam, mas algo entre 1 e 8 horas pareceria normal, na minha experiência.
Responder3
Se você for solicitado a fornecer um SLA para restauração de problemas de hardware onde seu software estiver instalado, a resposta é “não”. Você pode se comprometer com um tempo de resposta, mas sem controlar toda a pilha de hardware/sistema operacional/software, você não pode se comprometer com um tempo de resolução.
Talvez o seu cliente esteja lhe dizendo de uma forma estranha que ele realmente precisa de uma oferta hospedada para o seu produto? Dessa forma, eles podem evitar quaisquer problemas internos que os preocupem e apenas passar um cheque para você.
Responder4
Uma coisa a se considerar na hora de contratar um SLA é que o SLA por si só não significa absolutamente nada, deve ser observado juntamente com as penalidades caso o SLA não seja cumprido.
Por exemplo, nosso ISP nos dá 100% de SLA na rede, mas o valor máximo que podemos recuperar é nossa fatura mensal, que é muito baixa, pois hoje em dia a largura de banda é barata e nem de longe a quantidade de dinheiro que perdemos quando a rede cai .
Além disso, o que normalmente está escrito nos contratos é a rapidez com que alguém responderá ao problema, nunca quanto tempo realmente levará para resolvê-lo. Então, se eles obrigarem você a se comprometer com tempos de resposta curtos, basta colocar um estagiário no turno da noite para embaralhar os ingressos para você até você acordar e pronto.
Na minha experiência, todo esse negócio de SLA significa praticamente muito, muito pouco, ou nada.