Alegeți specificațiile SLI și rafinați-le în implementări SLI pentru o altă călătorie mai complexă a utilizatorului.

Dezvoltați implementări SLI care acoperă această călătorie a utilizatorului spre satisfacția dvs. Justifica:

Definițiile dvs. pentru "evenimente bune" și "evenimente valide" în implementările dvs.

Metodele de măsurare utilizate și compromisurile pe care le implică.
Orice părți ale călătoriei pe care ați ales să le lăsați descoperite.
Utilizatorul face clic pe o listă de produse. Aceasta va apela un API care va primi lista SKU. Aici putem măsura
GETSKU. Va exista o solicitare de detalii SKU care va duce la un răspuns din partea magazinului de jocuri. De
acolo, utilizatorul va alege produsul prin ID-ul produsului și va obține disponibilitatea și prețul. SLI aici va fi
disponibilitatea GETSKU.
Cum putem face asta:
Putem măsura numărul de cereri reușite GETSKU care returnează o listă. Acolo putem avea o limită minimă de
răspuns la codul de răspunsuri 300.
Acest lucru va declanșa fluxul de facturare.
De asemenea, putem măsura latența. Acest lucru se va face până la limita de timp pentru răspunsul la o
interogare. Acesta este un GETSKU va avea un răspuns care este o listă de produse. Această listă ar trebui să
fie disponibilă este un timp limitat care nu trebuie să depășească 10 secunde. După 10 secunde, un script de
anulare ar trebui să acționeze și să anuleze cererea și utilizatorul va trimite o nouă solicitare.
Un SLI pozitiv va fi măsurat în funcție de numărul de solicitări reușite față de numărul de interogări ale
utilizatorilor. Procentul ne va arăta acum dacă avem un timp bun de latență sau nu.
Deci SLI-ul nostru aici pe care l-am măsurat sunt disponibilitatea și latența.
Disponibilitatea va fi măsurată în funcție de numărul de răspunsuri nu mai mic de 300 de coduri de răspuns după
un GETSKU. Latența va fi măsurată prin numărul de solicitări reușite (în 10 sec) peste numărul total de interogări
ale utilizatorilor GETSKU.

Nivelul de fericire al utilizatorului depinde de:

Acuratețea produselor afișate din lista SKU (disponibilitatea achizițiilor în joc, răspunsul dacă ceva este deja
deținut)
Latența /api/completePurchase pentru finalizarea achiziției, verificarea tokenului și actualizarea contului
Corectitudinea produsului achiziționat

Definiția succesului - Cod de stare de succes pentru actualizarea contului

Vom stabili specificațiile SLI pentru prospețimea, corectitudinea, acoperirea și debitul procesului de actualizare a
contului după achiziție, precum și răspunsul după finalizarea fluxului de facturare.

Evenimente valide:

Obțineți lista SKU-urilor pe server, returnați lista clientului SKU Detalii pentru Magazin Play și returnați detaliile
clientului Fluxul de biliard către Magazinul Play - codul de stare, ID-ul comenzii, tokenul de achiziție către API-ul
clientului pentru a finaliza achiziția pe server Verificați tokenul de achiziție în Magazinul Play > codul de stare
înapoi la Server Actualizați contul de pe server > codul de stare la client

Evenimente bune:
Afișarea cu succes a ID-urilor SKU disponibile în client ^buy stuff^ UI După trimiterea /api/SKUs, returnează
SKU-ul noii zone lansate pentru cumpărare ^Int OK^ codul de răspuns la facturare din playstore după lansarea
fluxului de facturare Google Play răspunde atunci când ați achiziționat cu succes un articol. Răspunsul include
un șir JSON
Latența /api/completePurchase to server
Solicitarea codului de stare a fost verificată cu succes pe serverul web
Cont actualizat cu succes pe server cu codul de stare la client
Metodele de măsurare utilizate și compromisurile pe care le implică.

Prospețime - Proporția de date valide (codul de stare reușit după actualizarea contului pe server) actualizate x
numărul de secunde după solicitarea către /api/completePurchase trimisă de la client la server.

Corectitudine - Proporția datelor valide (analizați datele JSON din Magazinul Play) care produc rezultate corecte.
Măsurați ieșirea corectă utilizând ^date de intrare aurii^ cu ieșiri bune cunoscute. Comparați datele rezultate
pentru a măsura dacă sunt corecte / reușite.

Acoperire - Proporția datelor valide procesate cu succes. Măsurați latența solicitărilor API client la server /
completePurchase, ceea ce duce la un cod de stare reușit după actualizarea contului.

Debit - proporția de timp în care rata de procesare a datelor este mai rapidă decât un prag.
SLI pentru noua versiune de zonă - 10 achiziții pe secundă nu depășesc x octeți pe secundă
SLI în mod normal - 1 achiziții pe secundă nu depășește y octeți pe secundă

Orice părți ale călătoriei pe care ați ales să le lăsați descoperite.

SKU detaliază solicitarea și răspunsul la Magazinul Play și înapoi la client. Deoarece Play Store este extern și
SKU detaliază răspunsul ocolește serverul și merge direct la client.

Un eveniment bun a fost un eveniment care a îndeplinit cerințele SLI / Un eveniment valid a fost unul care a fost
servit cu succes.
Am ales să măsor codurile de răspuns la sever, deoarece magazinul de jocuri va trimite un cod de răspuns,
sever, actualiza contul, trimite un cod de răspuns clientului.

SLI: proporția solicitării de identificare SKU sau de comandă care au un cod de răspuns 0x00000000 măsurată la
server.

Am ales sever deoarece în timpul procesului de cumpărare utilizează onPurchaseUpdate () care gestionează
codurile de răspuns, de asemenea, la sfârșitul achiziției cu succes a utilizatorului, serverul generează un jeton de
achiziție pentru a valida succesul.

Tip SLI: Latență

Specificație SLI: Proporția cererilor de pagină care au fost servite în < 200ms (Mai sus, ^[cereri de pagină] servite
în <200ms^ este numărătorul în SLIEquation, iar ^ cereri de pagină^ este numitorul.)

Implementări SLI:
Proporția solicitărilor de pagini servite în < 200ms, măsurată din coloana "latență" din jurnalul serverului.
(Pro/Contra: Această măsurătoare va rata solicitările care nu ajung în backend.)

Proporția solicitărilor de pe pagina de pornire servite în < 200ms, măsurată prin sonde care execută JavaScript
într-un browser care rulează într-o mașină virtuală.
(Pro/Contra: Acest lucru va detecta erorile atunci când solicitările nu pot ajunge la rețeaua noastră, dar pot rata
probleme care afectează doar un subset de utilizatori.)

SLO: 99% din solicitările de pe pagina principală din ultimele 28 de zile au fost difuzate în < 200ms.