Este documento descreve os SLOs para o Serviço de Jogo Exemplo.
- Status: Publicado
- Autor: Steven Thurgood
- Data: 19-02-2018
- Revisores: David Ferguson
- Aprovadores: Betsy Beyer
- Data de Aprovação: 20-02-2018
- Data de Revisão: 01-02-2019
Visão geral do serviço
O Serviço de Jogo Exemplo permite que usuários de Android e iPhone joguem uns com os outros. O aplicativo roda nos telefones dos usuários, e os movimentos são enviados de volta para a API por meio de uma API REST. O banco de dados armazena os estados de todos os jogos atuais e anteriores. Um pipeline de pontuação lê esta tabela e gera classificações atualizadas para o dia de hoje, para a semana e de todos os tempos. Os resultados das classificações estão disponíveis no aplicativo, via API e também em um servidor HTTP público.
O SLO utiliza uma janela deslizante de quatro semanas.
SLIs e SLOs
| Categoria | SLI | SLO |
| API | ||
| Disponibilidade | A proporção de requisições bem-sucedidas, conforme medido pelas métricas do balanceador de carga. Qualquer status HTTP diferente de 500–599 é considerado bem-sucedido.
contagem de “api” http_requests que não possuem um código de status 5XX dividido por contagem de todas as “api” http_requests |
97% de sucesso |
| Latência | A proporção de requisições suficientemente rápidas, conforme medido pelas métricas do balanceador de carga.
“Suficientemente rápido” é definido como < 400 ms ou < 850 ms. contagem de “api” http_requests com uma duração menor ou igual a “0,4” segundos dividida pela contagem de todas as “api” http_requests contagem de “api” http_requests com uma duração menor ou igual a “0,85” segundos dividida pela contagem de todas as “api” http_requests |
90% das requisições < 400 ms
99% das requisições < 850 ms |
| HTTP server | ||
| Disponibilidade | A proporção de requisições bem-sucedidas, conforme medido pelas métricas do balanceador de carga.
Qualquer status HTTP diferente de 500–599 é considerado bem-sucedido. Contagem de “web” http_requests que não possuem um código de status 5XX dividida pela contagem de todas as “web” http_requests |
99% |
| Latência | A proporção de requisições suficientemente rápidas, conforme medido pelas métricas do balanceador de carga.
“Suficientemente rápido” é definido como < 200 ms ou < 1.000 ms. Contagem de “web” http_requests com uma duração menor ou igual a “0,2” segundos dividida pela contagem de todas as “web” http_requests Contagem de “web” http_requests com uma duração menor ou igual a “1,0” segundos dividida pela contagem de todas as “web” http_requests |
90% das requisições < 200 ms
99% das requisições < 1.000 ms |
| Pipeline de pontuação | ||
| Atualidade | A proporção de registros lidos da tabela de classificação que foram atualizados recentemente.
“Recentemente” é definido como dentro de 1 minuto ou dentro de 10 minutos. Utiliza métricas da API e do servidor HTTP: Contagem de todas as data_requests para “api” e “web” com atualidade menor ou igual a 1 minuto dividida pela contagem de todas as data_requests Contagem de todas as data_requests para “api” e “web” com atualidade menor ou igual a 10 minutos dividida pela contagem de todas as data_requests |
90% das leituras usam dados escritos no último minuto.
99% das leituras usam dados escritos nos últimos 10 minutos. |
| Correção | A proporção de registros injetados na tabela de estados por um verificador de correção que resulta na leitura correta dos dados da tabela de classificação.
Um verificador de correção injeta dados sintéticos, com resultados conhecidos e corretos, e exporta uma métrica de sucesso: Contagem de todas as data_requests que estavam corretas dividida pela contagem de todas as data_requests |
99,99999% dos registros injetados pelo verificador resultam na saída correta. |
| Integridade | A proporção de horas em que 100% dos jogos no banco de dados foram processados (nenhum registro foi ignorado).
Utiliza métricas exportadas pelo pipeline de pontuação: Contagem de todas as execuções do pipeline que processaram 100% dos registros dividida pela contagem de todas as execuções do pipeline |
99% das execuções do pipeline cobrem 100% dos dados. |
Justificativa
Os SLIs de disponibilidade e latência foram baseados na medição do período de 01-01-2018 a 28-01-2018. Os SLOs de disponibilidade foram arredondados para baixo para o percentual inteiro mais próximo, e os tempos dos SLOs de latência foram arredondados para cima para o múltiplo de 50 ms mais próximo. Todos os outros números foram escolhidos pelo autor e os serviços foram verificados para estar operando nos níveis ou acima desses níveis.
Ainda não foi feita uma tentativa de verificar se esses números se correlacionam fortemente com a experiência do usuário.
Error Budget
Cada objetivo tem um error budget separado, definido como 100% menos (–) a meta para esse objetivo. Por exemplo, se houve 1.000.000 de requisições ao servidor da API nas últimas quatro semanas, o error budget de disponibilidade da API é de 3% (100% – 97%) de 1.000.000: 30.000 erros.
Implementaremos a política de error budget (veja o Apêndice B) quando qualquer um de nossos objetivos tiver esgotado seu error budget.
Esclarecimentos e advertências
- As métricas de requisições são medidas no balanceador de carga. Esta medição pode não conseguir capturar com precisão os casos em que as requisições dos usuários não chegaram ao balanceador de carga.
- Contamos apenas os códigos de status HTTP 5XX como códigos de erro; tudo o mais é contado como sucesso.
- Os dados de teste usados pelo verificador de correção contêm aproximadamente 200 testes, que são injetados a cada 1 segundo. Nosso orçamento de erro é de 48 erros a cada quatro semanas.