A seção Framework de arquitetura do Google Cloud: confiabilidade deste documento apresenta detalhes sobre como alertar sobre SLOs.
Uma abordagem incorreta para introduzir um novo sistema de observabilidade, como SLOs, é usar o sistema para substituir completamente um sistema antigo. Em vez disso, você verá os SLOs como um sistema complementar. Por exemplo, em vez de excluir seus alertas atuais, recomendamos que você os execute em paralelo com os alertas de SLO apresentados aqui. Essa abordagem permite que você descubra quais alertas legados preveem alertas de SLO, quais são disparados em paralelo com seus alertas de SLO e quais nunca são disparados.
Um princípio da SRE é alertar com base em sintomas, não em causas (em inglês). Os SLOs são, por sua natureza, medições de sintomas. À medida que você adota alertas de SLO, é possível que perceba que o alerta sintomático é disparado junto com outros alertas. Se você descobrir que seus alertas legados e baseados em causas são disparados sem SLO ou sintomas, eles serão bons candidatos a serem desativados completamente, transformados em alertas de tíquetes ou registrados para referência futura.
Para mais informações, consulte a Apostila de SRE, capítulo 5.
Taxa de esgotamento do SLO
A taxa de esgotamento de um SLO é uma medida da rapidez com que uma interrupção expõe os usuários a erros e esgota o erro de orçamento. Ao medir a taxa de esgotamento, você determina o tempo até que um serviço viole o SLO. Os alertas com base na taxa de esgotamento do SLO são uma abordagem valiosa. Lembre-se de que seu SLO é baseado em uma duração, que pode ser bastante longa (semanas ou até meses). No entanto, a meta é detectar rapidamente uma condição que resulte em uma violação de SLO antes que ela realmente ocorra.
Na tabela a seguir, mostramos o tempo necessário para exceder um objetivo se 100% das solicitações falharem em um determinado intervalo, supondo que as consultas por segundo (QPS, na sigla em inglês) sejam constantes. Por exemplo, se você tiver um SLO de 99,9% medido ao longo de 30 dias, poderá suportar a inatividade total de 43,2 minutos durante esses 30 dias. Por exemplo, essa inatividade pode ocorrer de uma só vez ou espaçada em vários incidentes.
| Objetivo | 90 dias | 30 dias | 7 dias | 1 dia |
|---|---|---|---|---|
| 90% | 9 dias | 3 dias | 16,8 horas | 2,4 horas |
| 99% | 21,6 horas | 7,2 horas | 1,7 horas | 14,4 minutos |
| 99,9% | 2,2 horas | 43,2 minutos | 10,1 minutos | 1,4 minutos |
| 99,99% | 13 minutos | 4,3 minutos | 1 minuto | 8,6 segundos |
| 99,999% | 1,3 minutos | 25,9 segundos | 6 segundos | 0,9 segundos |
Na prática, não é possível arcar com incidentes de 100% de interrupção se você quer alcançar porcentagens de sucesso altas. No entanto, muitos sistemas distribuídos podem apresentar falha parcial ou se degradar naturalmente. Mesmo nesses casos, você ainda quer saber se uma pessoa precisa ser acionada, mesmo nessas falhas parciais, e os alertas de SLO fornecem uma maneira de determinar isso.
Quando alertar
Uma pergunta importante é quando agir com base na taxa de esgotamento do SLO. Como uma regra, se você esgotar seu erro de orçamento em 24 horas, o momento para chamar alguém para corrigir o problema é agora.
Medir a taxa de falha nem sempre é simples. Uma série de pequenos erros pode parecer assustadora no momento, mas acaba sendo rápida e tem um impacto irrelevante no seu SLO. Da mesma forma, se um sistema falhar levemente por muito tempo, esses erros poderão resultar em uma violação de SLO.
O ideal é que sua equipe reaja a esses sinais para que você gaste quase todo o erro de orçamento (mas não o exceda) em um determinado período. Se você gastar demais, violará o SLO. Se você gastar muito pouco, não correrá risco suficiente ou talvez sobrecarregue sua equipe de plantão.
Você precisa de uma maneira de determinar quando um sistema está corrompido o suficiente para que uma pessoa intervenha. Nas seções a seguir, apresentamos algumas abordagens sobre essa questão.
Esgotamentos rápidos
Um tipo de esgotamento do SLO é o esgotamento rápido, porque ele esgota seu erro de orçamento rapidamente e exige que você intervenha para evitar uma violação do SLO.
Suponha que seu serviço opere normalmente com 1.000 consultas por segundo (QPS, na sigla em inglês), e você queira manter 99% de disponibilidade conforme medido durante uma semana de sete dias. Seu erro de orçamento é de cerca de 6 milhões de erros permitidos (em torno de 600 milhões de solicitações). Se você tiver 24 horas antes do seu erro de orçamento se esgotar, por exemplo, isso representa um limite de cerca de 70 erros por segundo, ou 252.000 erros em uma hora. Esses parâmetros são baseados na regra geral de que os incidentes pagináveis devem consumir pelo menos 1% do erro de orçamento trimestral.
É possível detectar essa taxa de erros antes de transcorrer essa uma hora. Por exemplo, depois de observar uma taxa de 70 erros por segundo durante 15 minutos, é possível chamar o engenheiro de plantão, como mostrado no diagrama a seguir.
O ideal é que o problema seja resolvido antes de você gastar uma hora do seu orçamento de 24 horas. A detecção dessa taxa em uma janela mais curta (por exemplo, um minuto) provavelmente será muito propensa a erros. Se o tempo desejado de detecção for menor que 15 minutos, esse número poderá ser ajustado.
Esgotamentos lentos
Outro tipo de taxa de esgotamento é o esgotamento lento. Suponha que você introduza um bug que esgote seu erro de orçamento semanal no quinto ou sexto dia, ou seu orçamento mensal na segunda semana. Qual é a melhor resposta?
Neste caso, é possível apresentar um alerta de esgotamento lento do SLO que informa que você está prestes a consumir todo o erro de orçamento antes do fim da janela de alerta. É claro que esse alerta pode retornar muitos falsos positivos. Por exemplo, pode haver uma condição em que os erros ocorrem brevemente, mas a uma taxa que consome rapidamente seu erro de orçamento. Nesses casos, a condição é um falso positivo porque dura pouco tempo e não ameaça o erro de orçamento a longo prazo. Lembre-se de que o objetivo não é eliminar todas as fontes de erro, mas manter o intervalo aceitável para não exceder o erro de orçamento. Você quer evitar alertar uma pessoa para intervir em eventos que não sejam uma ameaça legítima ao seu erro de orçamento.
Recomendamos que você notifique uma fila de tíquetes (em vez de ligar ou enviar e-mail para alguém) para eventos de esgotamento lento. Os eventos de esgotamento lento não são emergências, mas exigem atenção de alguém antes que o orçamento se esgote. Esses alertas não podem vir em forma de e-mails para uma lista de equipes, que rapidamente se tornam um incômodo a ser ignorado. Os tíquetes precisam ser rastreáveis, atribuíveis e transferíveis. As equipes devem desenvolver relatórios para carregamento de tíquete, taxas de fechamento, possibilidade de ação e cópias. Tíquetes excessivos e não acionáveis são um ótimo exemplo de trabalho excessivo (em inglês).
O uso eficiente dos alertas de SLO pode levar tempo e depender da cultura e das expectativas da sua equipe. Lembre-se de que é possível ajustar os alertas de SLO ao longo do tempo. É possível também ter vários métodos de alerta, com janelas de alerta variadas, dependendo das suas necessidades.
Alertas de latência
Além dos alertas de disponibilidade, é possível ter alertas de latência. Com os SLOs de latência, você mede a porcentagem de solicitações que não atendem a uma meta de latência. Ao usar esse modelo, é possível usar o mesmo modelo de alerta para detectar esgotamentos rápidos ou lentos da margem de erro.
Conforme observado anteriormente sobre SLOs de latência mediana, metade das suas solicitações pode estar fora do SLO. Em outras palavras, seus usuários podem sofrer uma latência ruim por dias até você detectar o impacto em erro de orçamento de longo prazo. Em vez disso, os serviços precisam definir os objetivos de latência de cauda e de latência típica. Sugerimos usar o percentil 90º histórico para definir a latência típica e o percentil 99º para latência de cauda. Depois de definir essas metas, é possível definir os SLOs com base no número de solicitações que você espera receber em cada categoria de latência e quantas são muito lentas. Essa abordagem segue o mesmo conceito de um erro de orçamento e deve ser tratada da mesma forma. Assim, é possível acabar com uma declaração como "90% das solicitações serão processadas dentro da latência típica e 99,9% dentro das metas de latência de cauda". Essas metas garantem que a maioria dos usuários tenha sua latência típica e ainda permitem acompanhar quantas solicitações são mais lentas do que as metas de latência de cauda.
Alguns serviços podem ter tempos de execução esperados altamente variáveis. Por exemplo, é possível ter expectativas de desempenho muito diferentes para leitura de um sistema de armazenamento de dados em comparação com a gravação. Em vez de enumerar todas as expectativas possíveis, introduza buckets de desempenho do tempo de execução, conforme mostrado nas tabelas a seguir. Essa abordagem pressupõe que esses tipos de solicitações são identificáveis e pré-categorizados em cada bucket. Não espere para categorizar as solicitações imediatamente.
| Site voltado para o usuário | |
|---|---|
| Bucket | Tempo de execução máximo esperado |
| Leitura | 1 segundo |
| Gravação/atualização | 3 segundos |
| Sistemas de processamento de dados | |
|---|---|
| Bucket | Tempo de execução máximo esperado |
| Pequeno | 10 segundos |
| Médio | 1 minuto |
| Grande | 5 minutos |
| Gigante | 1 hora |
| Imenso | 8 horas |
Ao avaliar o sistema como ele é hoje, é possível entender quanto tempo essas solicitações costumam levar para ser executadas. Por exemplo, considere um sistema para processar envios de vídeo. Se o vídeo for muito longo, o tempo de processamento deverá levar mais tempo. Podemos usar a duração do vídeo em segundos para categorizar esse trabalho em um bucket, conforme mostrado na tabela a seguir. Na tabela, registramos o número de solicitações por bucket e os vários percentis para distribuição do tempo de execução ao longo de uma semana.
| Duração do vídeo | Número de solicitações medidas em uma semana | 10% | 90% | 99,95% |
|---|---|---|---|---|
| Pequeno | 0 | - | - | - |
| Médio | 1,9 milhão | 864 milissegundos | 17 segundos | 86 segundos |
| Grande | 25 milhões | 1,8 segundo | 52 segundos | 9,6 minutos |
| Gigante | 4,3 milhões | 2 segundos | 43 segundos | 23,8 minutos |
| Imenso | 81.000 | 36 segundos | 1,2 minuto | 41 minutos |
Com base nessa análise, é possível derivar alguns parâmetros para alertas:
- fast_typical: no máximo, 10% das solicitações são mais rápidas do que esse tempo. Se muitas solicitações forem mais rápidas do que esse tempo, as metas poderão estar incorretas ou algo sobre o sistema poderá ter sido alterado.
- slow_typical: pelo menos 90% das solicitações são mais rápidas do que esse tempo. Esse limite impulsiona seu SLO de latência principal. Esse parâmetro indica se a maioria das solicitações é rápida o suficiente.
- slow_tail: pelo menos 99,95% das solicitações são mais rápidas do que esse tempo. Esse limite garante que não haja muitas solicitações lentas.
- deadline: o ponto em que uma RPC de usuário ou processamento em segundo plano expira e falha (um limite geralmente codificado no sistema). Essas solicitações não serão, na verdade, lentas, mas falharão de fato com um erro e serão consideradas no seu SLO de disponibilidade.
Uma diretriz de definição de buckets é manter o fast_typical, o slow_typical e o slow_tail de um bucket dentro de uma ordem de magnitude entre eles. Essa diretriz garante que você não tenha um bucket muito amplo. Recomendamos que você não tente evitar a sobreposição ou as lacunas entre os buckets.
| Bucket | fast_typical | slow_typical | slow_tail | deadline |
|---|---|---|---|---|
| Pequeno | 100 milissegundos | 1 segundo | 10 segundos | 30 segundos |
| Médio | 600 milissegundos | 6 segundos | 60 segundos (1 minuto) | 300 segundos |
| Grande | 3 segundos | 30 segundos | 300 segundos (5 minutos) | 10 minutos |
| Gigante | 30 segundos | 6 minutos | 60 minutos (1 hora) | 3 horas |
| Imenso | 5 minutos | 50 minutos | 500 minutos (8 horas) | 12 horas |
Isso resulta em uma regra como api.method: SMALL => [1s, 10s].
Neste caso, o sistema de rastreamento do SLO verá uma solicitação, determinará o bucket
(talvez analisando o nome do método ou o URI e comparando o nome com uma tabela de consulta) e, em seguida,
atualizará a estatística com base no tempo de execução dessa solicitação. Se isso
levou 700 milissegundos, está dentro da meta de slow_typical. Se for de três
segundos, estará dentro de slow_tail. Se for de 22 segundos, estará além de
slow_tail, mas ainda não é um erro.
Em termos de satisfação do usuário, pense na falta de latência de cauda como equivalente à indisponibilidade. Ou seja, a resposta é tão lenta que deve ser considerada uma falha. Por causa disso, sugerimos que você use a mesma porcentagem usada para disponibilidade, por exemplo:
Você decide o que é considerada uma latência típica. Algumas equipes do Google consideram 90% uma boa meta. Isso está relacionado à sua análise e à maneira como você escolheu as durações de slow_typical. Por exemplo:
Alertas sugeridos
De acordo com essas diretrizes, a tabela a seguir inclui um conjunto de valores de referência sugeridos de alertas de SLO.
| SLOs | Janela de medição | Taxa de esgotamento | Ação |
|---|---|---|---|
|
Disponibilidade, esgotamento rápido Latência típica Latência de cauda |
Janela de uma hora | Menos de 24 horas para violação do SLO | Ligar para alguém |
|
Disponibilidade, esgotamento lento Latência típica, esgotamento lento Latência de cauda, esgotamento lento |
Janela de sete dias | Mais que 24 horas para violação do SLO | Criar um tíquete |
O alerta de SLO é uma habilidade que pode levar tempo para ser desenvolvida. As durações desta seção são sugestões. Ajuste-as de acordo com suas próprias necessidades e nível de precisão. Associar os alertas à janela de medição ou ao consumo de erro de orçamento pode ser útil, ou é possível adicionar outra camada de alerta entre os esgotamentos rápidos e lentos.