Pilih spesifikasi SLI dan sempurnakan menjadi implementasi SLI untuk perjalanan pengguna lain yang lebih

kompleks.
Kembangkan penerapan SLI yang mencakup perjalanan pengguna ini demi kepuasan Anda. Membenarkan:

Definisi Anda tentang "peristiwa yang baik" dan "peristiwa yang valid" dalam implementasi Anda.
Metode pengukuran yang digunakan, dan pertukarannya.
Setiap bagian dari perjalanan yang telah Anda pilih untuk dibiarkan terbuka.
Pengguna mengklik daftar produk. Ini akan memanggil API yang akan mendapatkan daftar SKU. Di sini kita bisa
mengukur GETSKU. Akan ada permintaan detail SKU yang akan ditanggapi oleh play store. Dari sana pengguna
akan memilih produk melalui ID produk dan mendapatkan ketersediaan dan harganya. SLI di sini adalah
ketersediaan GETSKU.
Bagaimana kita bisa melakukan itu:
Kami dapat mengukur jumlah permintaan sukses GETSKU yang mengembalikan daftar. Di sana kita dapat
memiliki batas respons minimal hingga 300 kode respons.
Ini akan memicu alur penagihan.
Kami juga dapat mengukur latensi. Ini akan dilakukan melalui batas waktu respon terhadap query. Artinya
GETSKU akan memiliki respon berupa daftar produk. Daftar ini harus tersedia dalam waktu terbatas yang tidak
boleh melebihi 10 detik. Setelah 10 detik, sebuah membatalkan skrip harus bertindak dan membatalkan
permintaan dan pengguna akan mengirim permintaan baru.
SLI positif akan diukur berdasarkan jumlah permintaan yang berhasil atas jumlah kueri pengguna. Persentase
sekarang akan menunjukkan kepada kita apakah kita memiliki waktu latensi yang baik atau tidak.
Jadi SLI kita disini yang kita ukur adalah availability dan latency.
Ketersediaan akan diukur dari jumlah tanggapan tidak kurang dari 300 kode tanggapan setelah GETSKU.
Latensi akan diukur melalui jumlah permintaan yang berhasil (dalam 10 detik) dibandingkan jumlah total kueri
pengguna GETSKU.

Tingkat kebahagiaan pengguna bergantung pada:

Keakuratan produk yang ditampilkan dari daftar SKU (ketersediaan pembelian dalam game, respon jika ada
yang sudah dimiliki)
Latensi /api/completePurchase untuk menyelesaikan pembelian, memverifikasi token, dan memperbarui akun
Ketepatan produk yang dibeli

Definisi sukses - Kode status sukses untuk pembaruan akun

Kami akan menetapkan spesifikasi SLI untuk keaktualan, kebenaran, cakupan, dan throughput dari proses
memperbarui akun setelah pembelian serta respons setelah alur penagihan selesai.

Acara yang Sah:

Dapatkan daftar SKU di server, kembalikan daftar ke detail SKU klien ke Play Store dan kembalikan detail ke
aliran Penagihan klien ke Play Store - kode status, ID pesanan, token pembelian ke API klien untuk
menyelesaikan pembelian ke server Server Verifikasi Token Pembelian ke Play Store > Kode Status kembali ke
Akun Pembaruan Server di Server > Kode Status ke Klien

Acara Bagus:
Berhasil menampilkan ID SKU yang tersedia di klien ^buy stuff^ UI Setelah mengirim /api/SKUs, ia
mengembalikan SKU dari area rilis baru untuk pembelian ^Int OK^ kode respons penagihan dari playstore
setelah meluncurkan alur penagihan Google Play merespons saat Anda berhasil membeli barang. Responsnya
menyertakan string JSON
Latensi /api/completePurchase ke server
Permintaan Kode Status berhasil diverifikasi ke server web
Akun berhasil diperbarui di server dengan kode status ke klien
Metode pengukuran yang digunakan, dan pertukarannya.

Kesegaran - Proporsi data yang valid (kode status berhasil setelah memperbarui akun di server) diperbarui x
jumlah detik setelah permintaan ke /api/completePurchase dikirim dari klien ke server.

Ketepatan - Proporsi data yang valid (Parse data JSON dari Play Store) yang menghasilkan keluaran yang
benar. Ukur keluaran yang benar dengan menggunakan ^data masukan emas^ dengan keluaran yang diketahui
baik. Bandingkan keluaran data untuk mengukur apakah benar/berhasil.

Cakupan - Proporsi data valid yang berhasil diproses. Ukur latensi api klien ke server/permintaan pembelian
lengkap yang menghasilkan kode status berhasil setelah memperbarui akun.

Throughput - proporsi waktu di mana kecepatan pemrosesan data lebih cepat dari ambang batas.
SLI untuk rilis area baru - 10 pembelian per detik tidak melebihi x byte per detik
SLI biasanya - 1 pembelian per detik tidak melebihi y byte per detik

Setiap bagian dari perjalanan yang telah Anda pilih untuk dibiarkan terbuka.

Permintaan dan respons detail SKU ke Play Store dan kembali ke klien. Karena Play Store bersifat eksternal dan
respons detail SKU melewati server dan langsung menuju ke klien.

Acara yang baik adalah acara yang memenuhi persyaratan SLI/ Acara yang valid adalah acara yang berhasil
disajikan.
Saya memilih untuk mengukur kode respons di sever karena play store akan mengirimkan kode respons, server
memperbarui akun, mengirim kode respons ke klien.

SLI: Proporsi permintaan id sku atau id pesanan yang memiliki kode respons 0x00000000 yang diukur di server.

Saya memilih server karena selama proses pembelian menggunakan onPurchaseUpdate() yang menangani
kode respons juga pada akhir pembelian pengguna yang berhasil, server menghasilkan token pembelian untuk
memvalidasi kesuksesan.

Jenis SLI: Latensi

Spesifikasi SLI: Proporsi permintaan halaman yang disajikan dalam < 200 md (Di atas, ^[permintaan halaman]
yang disajikan dalam <200 md^ adalah pembilang dalam Persamaan SLIE, dan ^ permintaan halaman^ adalah
penyebutnya.)

Implementasi SLI:
Proporsi permintaan halaman yang disajikan dalam waktu < 200 md, yang diukur dari kolom 'latensi' log server.
(Pro/Kontra: Pengukuran ini akan melewatkan permintaan yang gagal mencapai backend.)

Proporsi permintaan halaman beranda yang disajikan dalam waktu < 200 md, yang diukur dengan pemeriksaan
yang mengeksekusi JavaScript di browser yang berjalan di mesin virtual.
(Pro/Kontra: Ini akan mendeteksi kesalahan saat permintaan tidak dapat menjangkau jaringan kami, tetapi
mungkin melewatkan masalah yang hanya memengaruhi sebagian pengguna.)

SLO: 99% permintaan halaman beranda dalam 28 hari terakhir disajikan dalam waktu <200 md.