Gerenciamento de incidentes para equipes de alta velocidade
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.
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.
Aprenda a comunicação de incidentes com o Statuspage
Neste tutorial, você vai ver como usar templates de incidentes para se comunicar com eficácia durante interrupções. Adaptável a muitos tipos de interrupção de serviço.
Leia este tutorialA importância de um processo de análise retrospectiva de incidentes
Uma análise retrospectiva de incidente, também conhecida como revisão pós-incidente, é a melhor maneira de trabalhar o que aconteceu durante um incidente e capturar as lições aprendidas.
Leia este artigo