Alice ghét phải chờ đợi

• Ngay cả khi thời gian yêu cầu trung bình của dịch vụ là 100ms và MTTR dưới 1 phút, người dùng vẫn cảm nhận thời gian chờ trung bình dài hơn rất nhiều vì họ bị mắc kẹt lâu hơn trong các yêu cầu dài và sự cố kéo dài
• Người vận hành tổng hợp yêu cầu và sự cố theo từng sự kiện, nhưng người dùng như Alice và Alex lại tính thời gian chờ bằng thời gian cảm nhận theo giây và phút
• Sự khác biệt này xuất phát từ nghịch lý kiểm tra (inspection paradox), và phân phối mà người dùng trải nghiệm không phải là phân phối độ trễ gốc f(t) mà là phân phối được gán trọng số theo t
• Trong phân phối lognormal có thời gian khôi phục trung vị là 30 phút và p99 là 600 phút, ngay cả khi MTTR chỉ nhỉnh hơn 1 giờ, thời gian khôi phục trung bình mà khách hàng cảm nhận vẫn có thể tăng lên khoảng 6 giờ
• Độ trễ đuôi và thời gian khôi phục dài có thể chi phối trải nghiệm khách hàng, và trimmed mean có nguy cơ bỏ đi thông tin quan trọng ở phần đuôi phải

---

Khoảng cách giữa trung bình theo từng yêu cầu và trung bình người dùng cảm nhận

• Alice sử dụng một dịch vụ web và, giống như hầu hết mọi người, cảm nhận thời gian theo giây và phút
• Người vận hành thấy rằng một yêu cầu trung bình hoàn tất trong 100ms, nhưng thời gian chờ trung bình của Alice có thể là 1 giây
• Sự khác biệt tương tự cũng xuất hiện với sự cố
  • Người vận hành có thể nói MTTR là dưới 1 phút
  • Thời gian sự cố trung bình mà Alex cảm nhận có thể là 1 giờ
• Cả hai cách đo này đều có thể đúng cùng lúc
  • Một yêu cầu dài hoặc một sự cố kéo dài chỉ là một sự kiện trong thống kê của người vận hành
  • Nhưng trong thời gian của người dùng, nó chiếm trọng số lớn hơn tương ứng với độ dài tồn tại của nó

Phân phối có trọng số theo t do nghịch lý kiểm tra tạo ra

• Hiện tượng này có thể được xem là nghịch lý kiểm tra
• Người dùng không trải nghiệm chính phân phối độ trễ f(t), mà là một phiên bản được gán trọng số theo t
• Khi MTTR hoặc thời gian yêu cầu trung bình là E[X], giá trị trung bình mà người dùng trải nghiệm là:
  • E_a[X] = E[X²] / E[X]
  • E_a[X] = E[X] + Var(X) / E[X]
• Phương sai càng lớn thì giá trị trung bình mà người dùng cảm nhận càng tách xa khỏi trung bình trong chỉ số vận hành

Ví dụ với trung vị 30 phút và p99 là 600 phút

• Nếu đưa vào độ trễ trung vị hoặc thời gian khôi phục trung vị cùng giá trị phân vị 99, ta có thể khớp một phân phối lognormal và so sánh chỉ số dịch vụ với giá trị khách hàng cảm nhận
• Các giá trị ví dụ như sau
  • TTR trung vị: 30 phút
  • TTR p99: 600 phút, tức là cứ 100 sự kiện thì có 1 sự kiện mất 10 giờ để khôi phục
• Trong trường hợp này, MTTR chỉ hơn 1 giờ một chút, nhưng thời gian khôi phục trung bình mà khách hàng trải nghiệm lại vào khoảng 6 giờ

Cạm bẫy của độ trễ đuôi và trimmed mean

• Có nhiều lý do cần hiểu độ trễ đuôi và thời gian khôi phục dài, và multiple samples là một trong số đó
• Với thời gian phục vụ, timeout-and-retry có thể che giấu một phần độ trễ
  • Tuy nhiên, điều này chỉ đúng khi yêu cầu đang chạy không giữ lock hay các tài nguyên độc quyền khác
• Với thời gian khôi phục, kiểu che giấu này là không thể, nên độ dày của phần đuôi bộc lộ trực tiếp hơn trong trải nghiệm khách hàng
• Các thước đo cắt bớt như trimmed mean có vấn đề là che khuất hình dạng phần đuôi phải, vốn chi phối trải nghiệm khách hàng
• Một lý do khác để không ưa các thước đo cắt bớt liên quan đến Little’s Law và mức sử dụng năng lực, như đã được bàn trong bài viết trước đó

Lưu ý khi sử dụng phân phối lognormal

• Phân phối lognormal được chọn để thuận tiện cho việc tính toán số học
• Nó có tính chất lognormal(μ, σ²) trở thành lognormal(μ + σ², σ²), và hoạt động tốt gần 0
• Không hẳn lognormal là một lựa chọn đặc biệt tốt cho các chỉ số độ trễ hay thời gian khôi phục
• Nhìn chung, những vấn đề như vậy nên được tiếp cận bằng phương pháp phi tham số

[GN⁺]

Ý kiến trên Lobste.rs

• Có lẽ nên đổi tiêu đề sang kiểu nhiều thông tin hơn như Latency and the inspection paradox
  Tiêu đề hiện tại thực tế gần như không truyền tải được chút thông tin nào 😅

  • Từ góc độ tác giả thì một tiêu đề hơi mơ hồ lại khá hữu ích
    Vì nó giúp giảm bớt các câu trả lời từ những người chỉ đọc tiêu đề mà không đọc nội dung

• Khá thú vị, nhưng tôi không hiểu rõ lắm vì tác giả không giải thích tại sao điều này đúng ngoài thuật ngữ t-weighted và công thức
  Giá mà có thể giải thích rõ hơn để cả những người đã quên từ lâu môn thống kê ở đại học cũng hiểu được thì tốt

  • Giả sử có một dashboard giám sát, thông thường ta sẽ coi mọi request là như nhau khi tính độ trễ trung bình

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

    Đây là E[X], và trọng số của mỗi request là 1/N
    Độ trễ mà Alice cảm nhận là theo thời gian, nên có lẽ từ đó mới xuất hiện cách gia quyền theo thời gian (t-weighted)
    Nếu Alice gửi M request có độ trễ là x_1, x_2, ..., x_M, ta có thể hỏi: “Nếu chọn ngẫu nhiên 1 giây trong toàn bộ thời gian chờ của Alice, thì độ trễ của request mà cô ấy đang chờ tại thời điểm đó là bao nhiêu?”
    Lúc này request i đóng góp x_i / (Σ_j x_j), nên request càng dài sẽ càng được phản ánh nhiều hơn
    Vì vậy trung bình gia quyền theo thời gian sẽ là

    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]  
    

    Ví dụ đơn giản, nếu có một request mất 1 giây và một request mất 10 giây thì trung bình thông thường là 5.5 giây, nhưng trung bình gia quyền theo thời gian sẽ là 1 * (1 / 11) + 10 * 10 / 11 = 9.18s

• Liên quan đến chủ đề này, The Inspection Paradox is Everywhere cũng đáng đọc

• Tôi cũng từng nghĩ theo hướng tương tự trong thực tế
  Tôi cho rằng ví dụ dễ hiểu nhất để nắm vấn đề này là khảo sát hành khách xe buýt xem trên xe có bao nhiêu người
  Khi đó bạn sẽ nhận được rất nhiều câu trả lời kiểu “xe buýt chật kín”, nhưng khi xe vắng thì lại chẳng có ai để hỏi cả
  Có thể tất cả các xe buýt đều trống và chỉ duy nhất một chiếc là đông nghịt
  Nếu mục tiêu là phân tích tình hình từ góc nhìn người dùng, thì tôi nghĩ thống kê này là đúng

  • Trong lý thuyết đồ thị cũng có một kết quả tương tự: gần như bạn bè của mọi người đều có nhiều bạn hơn chính họ
    Vì các node có nhiều kết nối xuất hiện trong adjacency list của node khác thường xuyên hơn các node ít kết nối

• Nếu bạn thấy chủ đề này đáng quan tâm, tôi rất khuyến nghị Gil Tene's "How not to measure latency"