Escolha as especificações de SLI e refine-as em implementações de SLI para outra jornada de usuário mais

complexa.
Desenvolva implementações de SLI que cubram essa jornada do usuário para sua satisfação. Justificar:

Suas definições de "bons eventos" e "eventos válidos" em suas implementações.

Os métodos de medição utilizados e os trade-offs que envolvem.
Todas as partes da viagem que você escolheu deixar descobertas.
O usuário clica em uma lista de produtos. Isso chamará uma API que obterá a lista de SKU. Aqui podemos
medir o GETSKU. Haverá uma solicitação de detalhes de SKU que levará à resposta da loja de jogos. A partir
daí o usuário escolherá o produto através do ID do produto e obterá a disponibilidade e o preço. O SLI aqui
estará disponível do GETSKU.
Como podemos fazer isso:
Podemos medir o número de solicitações bem-sucedidas GETSKU que retornam uma lista. Lá podemos ter um
limite mínimo de resposta para 300 respostas de código.
Isso acionará o fluxo de faturamento.
Também podemos medir a latência. Isso será feito através do limite de tempo de resposta a uma consulta. Ou
seja, um GETSKU terá uma resposta que é uma lista de produtos. Esta lista deve estar disponível é um tempo
limitado que não deve exceder 10 segundos. Após 10 segundos, um script de cancelamento deve agir e
cancelar a solicitação e o usuário enviará uma nova solicitação.
Um SLI positivo será medido de acordo com o número de solicitações bem-sucedidas sobre o número de
consultas do usuário. A porcentagem agora nos mostrará se temos um bom tempo de latência ou não.
Então, nosso SLI aqui que medimos são disponibilidade e latência.
A disponibilidade será medida a partir do número de respostas não inferior a 300 códigos de resposta após um
GETSKU. A latência será medida através do número de solicitações bem-sucedidas (em 10 segundos) sobre o
número total de consultas do usuário GETSKU.

O nível de felicidade do usuário depende de:

Precisão dos produtos exibidos a partir da lista de SKU (disponibilidade de compras no jogo, resposta se algo já
é possuído)
Latência de /api/completePurchase para concluir a compra, verificar o token e atualizar a conta
Exatidão do produto adquirido

Definição de sucesso - Código de status bem-sucedido para atualização de conta

Definiremos as especificações SLI para atualização, correção, cobertura e taxa de transferência do processo
para atualizar a conta após a compra, bem como a resposta após a conclusão do fluxo de faturamento.

Eventos válidos:

Obter lista de SKUs no servidor, retornar lista para o cliente Detalhes da SKU para a Play Store e retornar
detalhes para o cliente Fluxo de faturamento para a Play Store - código de status, ID do pedido, token de
compra para a API do cliente para concluir a compra no servidor Servidor Verificar Token de compra para Play
Store > Código de status voltar para o servidor Atualizar conta no servidor > Código de status para cliente

Bons Eventos:
Exibição bem-sucedida de IDs de SKU disponíveis no cliente ^buy stuff^ UI Depois de enviar /api/SKUs, ele
retorna o SKU da nova área liberada para compra ^Int OK^ código de resposta de faturamento da playstore
após iniciar o fluxo de faturamento O Google Play responde quando você comprou um item com êxito. A
resposta inclui uma cadeia de caracteres JSON
Latência de /api/completePurchase para o servidor
Solicitação de código de status verificada com êxito para o servidor Web
Conta atualizada com êxito no servidor com código de status para cliente
Os métodos de medição utilizados e os trade-offs que envolvem.

Atualização - A proporção de dados válidos (código de status bem-sucedido após a atualização da conta no
servidor) atualizados x quantidade de segundos após a solicitação para /api/completePurchase enviada do
cliente para o servidor.

Correção - Proporção de dados válidos (Analisar dados JSON da Play Store) produzindo saída correta. Meça a
saída correta usando ^golden input data^ com saídas em boas condições. Compare a saída de dados para
medir se ela está correta/bem-sucedida.

Cobertura - Proporção de dados válidos processados com sucesso. Meça a latência de solicitações
api/completePurchase do cliente para o servidor, o que resulta em um código de status bem-sucedido após a
atualização da conta.

Taxa de transferência - proporção de tempo em que a taxa de processamento de dados é mais rápida do que
um limite.
SLI para nova versão de área - 10 compras por segundo não excede x bytes por segundo
SLI normalmente - 1 compras por segundo não excede y bytes por segundo

Todas as partes da viagem que você escolheu deixar descobertas.

Solicitação de detalhes de SKU e resposta para a Play Store e de volta para o cliente. Como a Play Store é
externa e a resposta de detalhes do SKU ignora o servidor e vai diretamente para o cliente.

Um bom evento foi um evento que atendeu aos requisitos de SLI / Um evento válido foi aquele que foi servido
com sucesso.
Eu optei por medir os códigos de resposta no sever, uma vez que a Play Store enviará um código de resposta o
sever atualizar a conta o enviar um código de resposta para o cliente.

SLI: A proporção de sku id's ou solicitação de order id que têm um código de resposta 0x00000000 medida no
servidor.

Eu escolhi o sever porque durante o processo de compra ele utiliza o onPurchaseUpdate() que lida com os
códigos de resposta também no final da compra bem-sucedida do usuário o servidor gera um token de compra
para validar o sucesso.

Tipo de SLI: Latência

Especificação SLI: Proporção de solicitações de página que foram atendidas em < 200ms(Acima, ^[solicitações
de página] atendidas em <200ms^ é o numerador no SLIEquation e ^solicitações de página^ é o denominador.)

Implementações de SLI:
A proporção de solicitações de página atendidas em < 200ms, medida a partir da coluna 'latência' do log do
servidor.
(Prós/Contras: essa medida perderá solicitações que não chegarem ao back-end.)

A proporção de solicitações de home page atendidas em < de 200ms, medida por testes que executam
JavaScript em um navegador em execução em uma máquina virtual.
(Prós/Contras: Isso detectará erros quando as solicitações não puderem chegar à nossa rede, mas poderá
perder problemas que afetam apenas um subconjunto de usuários.)

SLO: 99% das solicitações de home page nos últimos 28 dias atendidas em < de 200ms.