Close

O caminho para um gerenciamento de incidentes melhor começa aqui

O que é orçamento de erros — e por que ele é importante?

Cada equipe de desenvolvimento, operações e TI sabe que, às vezes, incidentes acontecem.

Até as maiores empresas com o talento mais brilhante e uma reputação de quase 100% de tempo de atividade às vezes observam frustradas a inatividade de seus sistemas. Basta olhar para a Apple, Delta ou Facebook, que perderam dezenas de milhões de dólares para incidentes nos últimos cinco anos.

Esta realidade implica que Acordos de Nível de Serviço (SLAs) nunca devem prometer 100% de tempo de atividade, porque essa é uma promessa que nenhuma empresa pode cumprir.

Também quer dizer que, se sua empresa é muito boa em evitar ou resolver incidentes, você pode sempre alcançar seus objetivos de tempo de atividade. Talvez você prometa 99% de tempo de atividade e alcance 99,5%. Talvez prometa 99,5% e alcance 99,99% em um mês típico.

Nesses casos, os especialistas do setor recomendam que, em vez de definir as expectativas do usuário como muito altas, ultrapassando constantemente suas promessas, você considere esse 0,99% extra como um orçamento de erro — tempo que sua equipe pode usar para correr riscos.

O que é um orçamento de erro?

Um orçamento de erro é a quantidade máxima de tempo que um sistema técnico pode falhar sem consequências contratuais.

Por exemplo, se o seu Acordo de Nível de Serviço (SLA) especificar que os sistemas vão funcionar 99,99% do tempo antes de a empresa ter que compensar os clientes pela interrupção, o que quer dizer que seu orçamento de erro (ou o tempo em que seus sistemas podem ficar inativos sem consequências) vai ser de 52 minutos e 35 segundos por ano.

Se o seu SLA promete 99,95% de tempo de atividade, seu orçamento de erro é de quatro horas, 22 minutos e 48 segundos. E com uma promessa de SLA de 99,9% de tempo de atividade, seu orçamento de erro é de oito horas, 46 minutos e 12 segundos.

Por que as equipes de tecnologia precisam de orçamentos de erro?

À primeira vista, orçamentos de erro não parecem tão importantes. São apenas mais uma métrica que a TI e o DevOps precisam acompanhar para garantir que tudo esteja funcionando sem problemas, certo?

A resposta, felizmente, é não. Orçamentos de erro não são apenas uma maneira conveniente de cumprir promessas contratuais. Também são uma oportunidade para as equipes de desenvolvimento inovarem e correrem riscos.

Como explicamos no artigo sobre SRE,

"A equipe de desenvolvimento pode 'gastar' esse orçamento de erro da maneira que quiser. Se o produto estiver funcionando em perfeito estado, com poucos ou nenhum erro, ela pode iniciar o que quiser, quando quiser. Por outro lado, se ela cumpre ou excede o orçamento de erro e está operando no SLA definido ou abaixo dele, todos os lançamentos são congelados até que a equipe reduza o número de erros para um nível que permita que o lançamento continue."

O benefício dessa abordagem é que ela incentiva as equipes a minimizar incidentes reais e maximizar a inovação, assumindo riscos dentro de limites aceitáveis. Ela também preenche a lacuna entre equipes de desenvolvimento, cujos objetivos são inovação, agilidade e operações, que estão preocupadas com a estabilidade e a segurança. Enquanto o tempo de inatividade permanecer baixo, os desenvolvedores podem permanecer ágeis e incentivar alterações sem atrito das operações.

Como usar um orçamento de erro

Primeiro, você vai precisar consultar SLAs e SLOs. Quais objetivos você já definiu para o tempo de atividade ou solicitações bem-sucedidas do sistema? Que promessas a empresa fez aos clientes? Esses fatores vão ditar o seu orçamento de erro.

Orçamentos de erro com base no tempo de atividade

A maioria das equipes monitora o tempo de atividade por mês. Se a disponibilidade estiver acima do número prometido pelo SLA/SLO, a equipe pode lançar recursos novos e assumir riscos. Se estiver abaixo do alvo, os lançamentos vão ficar parados até que os números alvo estejam de volta no caminho certo.

Para usar esse método com eficiência, você vai precisar converter seu alvo de SLO (em geral, uma porcentagem) em números reais com os quais seus desenvolvedores podem trabalhar. Quer dizer que vai ser necessário calcular a quantas horas e minutos correspondem ao seu 1% ou 0,5% ou 0,1% de tempo de inatividade permitido. Os objetivos comuns incluem:

Meta de SLA

Tempo de inatividade anual permitido

Tempo de inatividade mensal permitido

Disponibilidade de 99,99%

Tempo de inatividade anual permitido

52 minutos, 35 segundos

Tempo de inatividade mensal permitido

4 minutos, 23 segundos

Disponibilidade de 99,95%

Tempo de inatividade anual permitido

4 horas, 22 minutos, 48 segundos

Tempo de inatividade mensal permitido

21 minutos, 54 segundos

Disponibilidade de 99,9%

Tempo de inatividade anual permitido

8 horas, 45 minutos, 57 segundos

Tempo de inatividade mensal permitido

43 minutos, 50 segundos

Disponibilidade de 99,5%

Tempo de inatividade anual permitido

43 horas, 49 minutos, 45 segundos

Tempo de inatividade mensal permitido

3 horas, 39 minutos

Disponibilidade de 99%

Tempo de inatividade anual permitido

87 horas, 39 minutos

Tempo de inatividade mensal permitido

7 horas, 18 minutos

Orçamentos de erro baseados em solicitações bem-sucedidas

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.

a seguir
DevOps