Entendendo o conceito de Error Budget: como o Google lida com o downtime

Um dos tópicos que chama a atenção no livro "SRE - How Google Runs Production Systems” é o conceito de Error Budget, que, de forma resumida, é a maneira como os times do Google lidam com o downtime dos seus serviços. O downtime está relacionado ao tempo em que um serviço fica indisponível, seja por falha no serviço, na infra-estrutura ou pelo lançamento de uma nova versão.

Antes de entender melhor o conceito, vamos entender o que está por trás dele. Mas aqui vai um “disclaimer”: este artigo não tem a intenção de ir fundo no tema, mesmo por que este é um tema complexo e existem toneladas de informação na internet. A intenção aqui é explicar o conceito de forma simples e lógica, algo que eu percebi que não é fácil encontrar sobre o assunto.

“Abraçando o Risco”

A disponibilidade de um serviço é tradicionalmente medida pelo tempo em que o sistema fica disponível em um determinado período. Tradicionalmente utilizamos valores como 99.9% (significa que o serviço ficou fora 43 minutos durante o mês) ou 99.999% (significa que o serviço ficou fora 26 segundos durante o mês). Um link útil para este cálculo é este.

Se você já trabalhou de alguma forma com disponibilidade de sistemas, você sabe que o custo para garantir a disponibilidade aumenta de forma exponencial, conforme você caminha na direção para adicionar um “9” a mais. De acordo com o livro, este custo está diretamente relacionado ao “custo de infra-estrutura” (exemplo: redundância de servidores/recursos) e também com o “custo de oportunidade”. Este último está relacionado ao fato de que, uma vez que você passa a investir em aumentar a disponibilidade, alocando pessoas e recursos, você deixa de investir no desenvolvimento e implantação de novas features, como parte de evolução do produto. Ou seja, o custo de oportunidade é o mesmo conceito do mundo de finanças, onde você investe a sua grana em algo, como por exemplo na compra de um carro, que te impede de investir em algo mais “interessante”, que iria te trazer um retorno financeiro mais adiante.

Uma coisa coisa interessante sobre disponibilidade é que, a partir de um determinado momento, a indisponibilidade passa a ser quase imperceptível pelo usuário final, pois existem outras variáveis no meio do caminho. Por exemplo, um usuário utilizando um smartphone (que não é 100% confiável devido à conexão com internet) provavelmente não consegue perceber a diferença entre um sistema com 99.99% e 99.999% de disponibilidade. 

Ou seja, “abraçar o risco” significa aceitar de forma realista estas variáveis e decidir de forma racional onde se deve investir esforço. Para tomar esta decisão, é necessário fazer uma gestão utilizando indicadores. No fundo estamos falando aqui de gestão de risco.

Definindo a regra do jogo através de indicadores

Para gerenciar o risco de indisponibilidade de um serviço, segundo o livro, é necessário identificar qual é o target que queremos atingir. O target nada mais é do que o objetivo (SLO), ou seja, qual é o “número” utilizado para medir a disponibilidade. Uma vez entendido o target, é possível fazer uma análise de custo/benefício.

No Google, eles “simplificam” a identificação do SLO de disponibilidade através da utilização da medida de “unplanned downtime”. Unplanned downtime é capturado através do nível desejado de disponibilidade. Conforme comentado anteriormente, este número é expressado em “noves” (ex: 99.9%). Até aqui, nenhuma novidade.

Planned downtime is downtime that has been scheduled and is expected in the environment. It is typically caused by system maintenance that, while disruptive to the overall system, usually can't be avoided.

Unplanned downtime typically results from things like power outages, hardware failures, software crashes, network connectivity failures, security breaches, and operating system failures.

Fonte: https://www.sciencedirect.com/topics/computer-science/unplanned-downtime

Normalmente este número é baseado no tempo proporcional de uptime, ou seja, o tempo em que o serviço fica disponível em um determinado período.

Availability = uptime / (uptime + downtime)

No Google, eles utilizam um cálculo diferente, que é baseado na “taxa de sucesso” dos requests.

Availability = successful requests / total requests

A explicação para isso é que eles fornecessem serviços globais, e que eles teoricamente estão disponíveis parcialmente “up” durante todo o tempo). Mas independente da forma como a disponibilidade é calculada, o conceito de error budget pode ser aplicado.

Qual a sua tolerância à falhas? (ou a do seu chefe)

Ainda com o objetivo de determinar um “número” de disponibilidade para ser utilizado como objetivo (SLO), um aspecto importante é entender qual o nível de tolerância à falhas aceitável para determinado sistema ou serviço.

Para isso, no Google, o time de SRE trabalha junto com os product owners para transformar de forma explícita os objetivos de negócios em algo que possa ser implementado e medido.

Para determinar o nível de disponibilidade de um determinado serviço, alguns pontos devem ser levados em consideração, como por exemplo:

• É um serviço pago ou é free?
• Qual o nível de serviço oferecido pelos concorrentes?
• É um serviço corporativo ou para consumidores comuns?
• O serviço está diretamente ligado ao faturamento da empresa ? (missão crítica)

Outro aspecto a ser considerado é o tipo de falha: um serviço que falha quando deixa de retornar uma informação para o cliente tem um nível de criticidade. Agora, se este serviço retorna informação errada para o cliente, como por exemplo expondo dados de outros clientes, o nível de criticidade é muito maior. Ou seja, retirar o serviço do ar para uma correção emergencial será importante e isso irá afetar a disponibilidade do serviço.

Uma distinção que o livro faz também é com relação ao tipo de serviço, que pode ser um serviço voltado para “consumer” (cliente final) ou um serviço de infra-estrutura (sistema de storage, camada de caching, etc). Este é um aspecto que também deve ser levado em consideração para determinar o nível de disponibilidade esperado. Serviços de infra-estrutura normalmente afetam diversos outros sistemas, o que aumenta a necessidade de disponibilidade.

Como lidar com a falha através do “Error Budgets”

Agora que já exploramos alguns pontos relacionados à indicadores e tolerância à falhas, chegou o momento de falar sobre error budgets.

Com o intuito de endereçar o conflito clássico de interesse entre times de desenvolvimento e times de operação (SRE), onde um tem o interesse de entregar mais rápido e o outro tem o interesse em garantir a estabilidade do ambiente, o Google utiliza uma abordagem simples: utilizar um “orçamento de falhas”.

Explicando de forma simplista, é como se tivéssemos uma “quantidade de vidas” (ex: mensal, trimestral ou anual) que pode ser utilizada em alguns cenários de manutenção. Esta “quantidade de vidas” é compartilhada entre os “irmãos” do time de desenvolvimento e operação. Se esta cota for consumida dentro do período, não existirá mais espaço para novos releases. Simples assim.

É claro que na prática a implementação de uma metodologia de “error budget” parece ser muito mais complexa. Aspectos como “burning rate” e outros tem que ser levados em consideração.