Alice tidak suka menunggu

• Meski waktu permintaan rata-rata layanan adalah 100ms dan MTTR kurang dari 1 menit, pengguna merasakan waktu tunggu rata-rata jauh lebih lama karena mereka terjebak lebih lama dalam permintaan panjang dan gangguan yang berlangsung lama
• Operator mengagregasikan permintaan dan gangguan per insiden, tetapi pengguna seperti Alice dan Alex menghitung waktu tunggu berdasarkan waktu yang dirasakan per detik dan menit
• Perbedaan ini terjadi karena paradoks inspeksi (inspection paradox), dan distribusi yang dialami pengguna bukan distribusi latensi asli f(t), melainkan distribusi yang dibobot dengan t
• Dalam distribusi log-normal dengan median waktu pemulihan 30 menit dan p99 600 menit, meski MTTR hanya sedikit di atas 1 jam, rata-rata waktu pemulihan yang dirasakan pelanggan bisa membengkak hingga sekitar 6 jam
• Latensi ekor dan waktu pemulihan yang panjang dapat mendominasi pengalaman pelanggan, dan trimmed mean berisiko membuang informasi penting pada ekor kanan

---

Kesenjangan antara rata-rata per permintaan dan rata-rata yang dirasakan pengguna

• Alice menggunakan layanan web dan, seperti kebanyakan orang, merasakan waktu dalam detik dan menit
• Operator melihat bahwa rata-rata permintaan selesai dalam 100ms, tetapi waktu tunggu rata-rata Alice bisa menjadi 1 detik
• Perbedaan yang sama juga muncul pada gangguan
  • Operator bisa mengatakan MTTR kurang dari 1 menit
  • Rata-rata durasi gangguan yang dirasakan Alex bisa mencapai 1 jam
• Kedua pengukuran ini bisa sama-sama benar
  • Permintaan panjang atau gangguan panjang dihitung sebagai satu insiden dalam agregasi operator
  • Dalam waktu pengguna, kejadian itu mendapat bobot lebih besar sesuai lamanya berlangsung

Distribusi berbobot t yang dibentuk oleh paradoks inspeksi

• Fenomena ini dapat dipandang sebagai paradoks inspeksi
• Pengguna tidak mengalami distribusi latensi f(t) itu sendiri, melainkan versi yang dibobot dengan t
• Saat MTTR atau waktu permintaan rata-rata adalah E[X], rata-rata yang dialami pengguna adalah sebagai berikut
  • E_a[X] = E[X²] / E[X]
  • E_a[X] = E[X] + Var(X) / E[X]
• Semakin besar varians, semakin jauh rata-rata yang dirasakan pengguna menyimpang di atas rata-rata metrik operasional

Contoh median 30 menit dan p99 600 menit

• Dengan memasukkan latensi median atau waktu pemulihan dan nilai persentil ke-99, kita bisa menyesuaikan distribusi log-normal dan membandingkan metrik layanan dengan nilai yang dirasakan pelanggan
• Nilai contoh adalah sebagai berikut
  • Median TTR: 30 menit
  • p99 TTR: 600 menit, artinya 1 dari 100 peristiwa membutuhkan 10 jam untuk pulih
• Dalam kasus ini, MTTR hanya sedikit di atas 1 jam, tetapi rata-rata waktu pemulihan yang dialami pelanggan menjadi sekitar 6 jam

Jebakan latensi ekor dan trimmed mean

• Ada berbagai alasan mengapa kita perlu memahami latensi ekor dan waktu pemulihan yang panjang, dan multiple samples adalah salah satunya
• Pada waktu layanan, timeout-and-retry dapat menyembunyikan sebagian latensi
  • Namun, ini hanya berlaku jika permintaan yang sedang berjalan tidak memegang lock atau sumber daya eksklusif lainnya
• Pada waktu pemulihan, penyamaran seperti ini tidak mungkin dilakukan sehingga ketebalan ekor tampak jauh lebih langsung dalam pengalaman pelanggan
• Nilai terpotong seperti trimmed mean memiliki masalah karena dapat menyamarkan bentuk ekor kanan yang mendominasi pengalaman pelanggan
• Alasan lain untuk tidak menyukai nilai terpotong berkaitan dengan Little’s Law dan pemakaian kapasitas, dan tulisan terkait ada di artikel yang pernah dibahas sebelumnya

Catatan tentang penggunaan distribusi log-normal

• Distribusi log-normal dipilih demi kemudahan perhitungan numerik
• Ada sifat bahwa lognormal(μ, σ²) menjadi lognormal(μ + σ², σ²), dan distribusi ini juga bekerja baik di dekat 0
• Sulit mengatakan bahwa distribusi log-normal adalah pilihan yang sangat baik khususnya untuk metrik latensi atau waktu pemulihan
• Untuk masalah seperti ini, pendekatan nonparametrik umumnya dianggap lebih baik

[GN⁺]

Opini Lobste.rs

• Mungkin lebih baik judulnya diubah menjadi sesuatu yang lebih informatif seperti Latency and the inspection paradox
  Judul yang sekarang praktis nyaris tidak menyampaikan informasi apa pun 😅

  • Dari sudut pandang penulis, judul yang agak ambigu justru cukup berguna
    karena itu mengurangi balasan dari orang-orang yang hanya membaca judul tanpa membaca isi

• Menarik, tetapi saya kurang paham karena penulis tidak menjelaskan mengapa ini benar selain dengan istilah t-weighted dan rumus
  Akan lebih baik jika dijelaskan lebih jelas agar orang yang sudah lama melupakan kuliah statistika juga bisa memahaminya

  • Misalkan ada dashboard pemantauan; biasanya semua request diperlakukan sama untuk menghitung rata-rata latensi

    mean = (sum of all latencies) / (number of requests)  
    

    Ini adalah E[X], dan bobot tiap request adalah 1/N
    Latensi yang dirasakan Alice berbasis waktu, jadi mungkin dari sinilah konsep time-weighted muncul
    Jika Alice mengirim M request dengan latensi x_1, x_2, ..., x_M, kita bisa bertanya, “Jika kita memilih 1 detik acak dari seluruh waktu tunggu Alice, berapa latensi request yang sedang ditunggu pada saat itu?”
    Dalam kasus ini, request i berkontribusi sebesar x_i / (Σ_j x_j), sehingga request yang lebih lama akan lebih banyak tercermin
    Jadi rata-rata berbobot waktu menjadi seperti berikut

    E_a[X] = Σ_i x_i (x_i / Σ_j x_j) = Σ_i x_i^2 / Σ_j x_j  
    = (Σ_i x_i^2 / N) / (Σ_j x_j / N)  
    = E[X^2] / E[X]  
    

    Sebagai contoh sederhana, jika ada satu request dengan latensi 1 detik dan satu request dengan latensi 10 detik, rata-rata biasa adalah 5,5 detik, tetapi rata-rata berbobot waktu menjadi 1 * (1 / 11) + 10 * 10 / 11 = 9.18s

• Terkait ini, The Inspection Paradox is Everywhere juga layak dibaca

• Saya juga pernah memikirkan hal serupa dalam praktik
  Menurut saya, contoh yang paling mudah untuk memahami masalah ini adalah survei kepada penumpang bus tentang berapa banyak orang yang ada di dalam bus
  Dengan begitu, Anda akan jauh lebih sering mendapat jawaban “busnya penuh”, tetapi saat bus kosong, tidak ada siapa pun yang bisa ditanya
  Bisa saja semua bus kosong dan hanya satu bus yang ramai
  Jika tujuannya adalah menganalisis situasi dari sudut pandang pengguna, saya rasa statistik ini memang tepat

  • Dalam teori graf ada hasil serupa: hampir semua orang memiliki teman yang jumlah temannya lebih banyak daripada dirinya
    karena node dengan banyak koneksi lebih sering muncul dalam adjacency list node lain dibanding node dengan sedikit koneksi

• Jika topik ini terasa relevan, saya sangat merekomendasikan Gil Tene's "How not to measure latency"