O que é um orçamento de erro, e o que um time deveria de fato fazer quando ele acaba?

Um orçamento de erro é a falta de confiabilidade que o seu SLO permite. Se o SLO é 99.9% ao longo de 28 dias, o orçamento é 0.1% das requisições, mais ou menos 40 minutos de indisponibilidade total. Times gastam isso em lançamentos arriscados, migrações e experimentos. Quando ele acaba, a política escrita normalmente congela releases de funcionalidade e redireciona o time para trabalho de confiabilidade até o orçamento se recuperar na janela móvel.

O orçamento é só o inverso do SLO. Com 99.9% em 28 dias a gente tinha uns 40 minutos de equivalente a queda total para gastar, e gastávamos deliberadamente em coisas como uma migração de banco ou um rollout arriscado. A parte importante é a política, não o número. A nossa dizia que se queimássemos mais da metade do orçamento no meio da janela, os canários ficavam mais lentos e toda mudança precisava de um segundo revisor, e se chegássemos a zero, releases de funcionalidade paravam e o time trabalhava confiabilidade até a janela móvel se curar. Isso foi aprovado pelo diretor de produto antes de a gente precisar, que é o único motivo de ter se sustentado na primeira vez que invocamos. A gente também rodava alertas de burn rate em múltiplas janelas, um rápido para queima de 14x em uma hora e um lento para queima de 6x em seis horas, então descobríamos durante o incidente em vez de no fim do mês.