SLA vs. SLO vs. SLI: qual a diferença?

O que é SLA?

Um SLA (acordo de nível de serviço) é um acordo entre o provedor e o cliente sobre métricas mensuráveis, como disponibilidade, capacidade de resposta e responsabilidades.

Em geral, esses acordos são elaborados pelas equipes novas de negócios e jurídicas de uma empresa e representam as promessas que você faz aos clientes e as consequências se você não cumpri-las. As consequências incluem penalidades financeiras, créditos de serviço ou extensões de licença.

O desafio dos SLAs

Os SLAs são muito difíceis de medir, relatar e atender. Esses acordos — em geral escritos por pessoas que não são da área de tecnologia — muitas vezes fazem promessas difíceis para as equipes medirem, nem sempre se alinham com as prioridades de negócios atuais e em constante evolução e não levam nuances em consideração.

Por exemplo, um SLA pode prometer que as equipes vão resolver itens relatados com o produto X dentro de 24 horas. Mas esse mesmo SLA não descreve o que acontece se o cliente levar 24 horas para enviar respostas ou capturas de tela para ajudar a equipe a diagnosticar o problema. A janela de 24 horas da equipe foi consumida pela lentidão do cliente ou o relógio começa a contar e para com base em quando os clientes respondem? Os SLAs precisam responder a essas perguntas, mas muitas vezes não conseguem, o que criou muita animosidade com eles por parte dos gerentes de TI.

Para muitos especialistas, a resposta a esse desafio é, em primeiro lugar, que a equipe de tecnologia deve estar envolvida na criação de SLAs. Quanto mais o departamento de TI e de DevOps colaborarem com o desenvolvimento jurídico e de negócios para elaborar SLAs que abordem cenários reais, mais os SLAs vão começar a refletir realidades essenciais, como clientes que atrasam a própria resolução de itens.

Quem precisa de SLA?

Um SLA é um acordo entre um fornecedor e um cliente pagante. É improvável que as empresas que prestam serviço gratuito aos usuários queiram ou precisem de um SLA para esses usuários gratuitos.

O que é SLO?

O SLO (objetivo de nível de serviço) é um acordo dentro de um SLA sobre uma métrica específica, como disponibilidade ou tempo de resposta. Portanto, se o SLA for o acordo formal entre você e o cliente, os SLOs são as promessas individuais que você faz a esse cliente. Os SLOs são o que definem as expectativas do cliente e dizem às equipes de TI e DevOps quais metas precisam atingir e considerar como referência.

Os desafios dos SLOs

Os SLOs são menos odiados do que os SLAs, mas podem criar muitos problemas se forem vagos, muito complicados ou impossíveis de medir. O segredo para SLOs que não fazem com que os engenheiros queiram arrancar os cabelos é a simplicidade e a clareza. Apenas as métricas mais importantes devem se qualificar para o status de SLO. Os objetivos devem ser explicados em linguagem simples e, como acontece com os SLAs, devem sempre levar em consideração itens como atrasos por parte do cliente.

Quem precisa de SLOs?

Quando os SLAs só forem relevantes no caso de clientes pagantes, os SLOs podem ser úteis para contas pagas e não pagas, bem como para clientes internos e externos.

Sistemas internos, como CRMs, repositórios de dados do cliente e intranet, podem ser tão importantes quanto os sistemas voltados para o público externo. E ter SLOs para esses sistemas internos é uma parte importante não apenas para atingir as metas de negócios, mas também para permitir que as equipes internas atendam às próprias metas voltadas para o cliente.

O que é SLI?

O SLI (indicador de nível de serviço) mede a conformidade com o SLO (objetivo de nível de serviço). Assim, por exemplo, se o SLA especificar que os sistemas vão estar disponíveis 99,95% do tempo, é provável que o SLO vá ter 99,95% de disponibilidade, e o SLI é a medição real da disponibilidade. Talvez seja 99,96%. Talvez 99,99%. Para se manter em conformidade com o SLA, o SLI vai precisar cumprir ou superar as promessas feitas nesse documento.

Os desafios dos SLIs

Assim como acontece com os SLOs, o desafio dos SLIs é manter a simplicidade, escolher as métricas certas para rastrear e não complicar demais o trabalho da TI, rastreando muitas métricas que não são importantes para os clientes.

Crie um plano detalhado de recuperação de desastres

O que você vai fazer quando ocorrer tempo de inatividade? Se você ainda não souber a resposta a essa pergunta, a resposta padrão vai ser “perder tempo precioso descobrindo o que fazer”.

Quanto melhor for o plano de resposta a incidentes, mais rápida e eficaz vai ser a resposta das equipes aos incidentes. É por esse motivo que o primeiro passo de qualquer novo programa de gerenciamento de incidentes deve incluir processo e planejamento.

Quem precisa de SLIs?

Qualquer empresa que faça medição do desempenho em relação aos SLOs precisa de SLIs para fazer essas medições. Não é possível ter SLOs sem SLIs.

Crie SLAs em torno das expectativas do cliente

Cada parte do acordo do cliente deve ser criada em torno do que importa para o cliente. No back-end, um incidente pode envolver 10 componentes diferentes. Mas, na opinião do cliente, só o que importa é que o sistema funcione como esperado.

Os SLAs e os SLOs devem refletir essa realidade. Não complique indo até um nível granular e fazendo promessas individuais para cada um desses 10 componentes. Mantenha as promessas limitadas à funcionalidade geral voltada para o usuário. Assim, os clientes vão ficar mais felizes e menos confusos e você vai simplificar a vida dos profissionais de TI responsáveis por cumprirem as promessas do SLA.

Use linguagem simples nos SLAs

Os clientes nem sempre pedem esclarecimentos. Portanto, se a linguagem do SLA for complicada, é bem provável que você vá se incomodar com alguns mal-entendidos pela frente. Quanto mais simples for a linguagem, menos chances de surgirem conflitos com o cliente no futuro.

Com SLOs, menos é mais

Nem todas as métricas são vitais para o sucesso do cliente, então nem todas as métricas devem ser um SLO. Estabeleça compromissos com o menor número possível de SLOs e se concentre naqueles que mais importam para os clientes.

Nem todas as métricas rastreáveis devem ser um SLI

Da mesma forma, rastrear o desempenho de 10 componentes para cada um dos 10 SLOs pode ficar difícil bem rápido. Em vez disso, escolha com estratégia quais métricas importam de verdade para os SLOs principais e concentre sua energia para rastrear essas métricas com efetividade.

Inclua fatores fora do controle da equipe de TI

O que acontece quando é o cliente que está afetando o tempo até a resolução? Se você não for claro sobre o assunto no SLA, a equipe pode ficar presa ao padrão impossível de resolver itens do cliente sem envolvimento do cliente.

Crie um orçamento para erros

Deixar uma margem para falhas não só protege a empresa contra violações de SLA e consequências pesadas, mas também deixa margem para agilidade, para que a equipe faça mudanças com rapidez e tenha espaço para experimentar soluções novas e inovadoras que podem falhar.

Na verdade, o Google recomenda usar o orçamento de erros restante para tempo de inatividade planejado, o que pode ajudar a identificar itens imprevistos (por exemplo, serviços que fazem uso inadequado dos servidores) e manter as expectativas apropriadas dos clientes.

Não mire muito alto

Just because your team can probably maintain 99.99% uptime doesn’t mean that 99.99% should be your SLO number. It’s always better to under-promise and overdeliver. This is especially true for agile teams who want to launch early and often and need an error budget to keep up that quick pace.

Qual é o impacto para SREs?

Para aqueles que seguem o modelo do Google e que usam equipes de Engenharia de Confiabilidade do Site (SRE) para preencher a lacuna entre desenvolvimento e operações, SLAs, SLOs e SLIs são fundamentais para o sucesso. Os SLAs ajudam as equipes a definir limites e orçamentos de erro. Os SLOs ajudam a priorizar o trabalho. E os SLIs informam aos SREs quando precisam congelar todos os lançamentos para salvar um orçamento de erros em perigo e quando podem afrouxar as rédeas.

Fique por dentro dos SLAs para resolver solicitações com base em prioridades e use regras de escalonamento automatizadas para notificar os membros certos da equipe e evitar violações de SLA com o Jira Service Management.