Đừng nhìn vào phần trăm uptime nữa — hãy nói bằng số giờ chết dịch vụ

Khi mọi thứ đều có thể "sập", việc đọc trang trạng thái dịch vụ đã trở thành thói quen hằng ngày của không chỉ dân vận hành hệ thống. Và cách các trang này hiển thị độ tin cậy bằng phần trăm uptime đang bộc lộ một vấn đề lớn về giao diện.

Sập nguồn đã trở thành chuyện thường ngày

Jim Nielsen, tác giả bài viết gốc trên blog cá nhân, mở đầu bằng một quan sát khá quen thuộc với bất kỳ ai làm việc trong ngành công nghệ: anh ngày càng gặp nhiều "thời gian chết" hơn trong công việc thường nhật.

GitHub sập. CI sập. AI sập. Slack sập.

Anh viết: "Downtime đang trở thành chuyện phổ thông!" Và càng ngày anh càng phải ghé thăm các trang trạng thái dịch vụ, nơi anh đối mặt với một bức tường màu sắc và những con số như thế này:

• 100%
• 99,72%
• 99,09%
• 98,98%

Thoạt nhìn, những con số này chẳng khác nhau là mấy. Nhưng Nielsen nhắc lại một điểm quan trọng từ bài viết "Bức tường đối diện với tính tự chủ đáng tin cậy của các coding agent" của Jason Gorman:

Hành trình từ 90% lên 99% độ tin cậy cũng khó khăn y hệt như việc đạt được mức 90% ban đầu. Và từ 99% lên 99,9% lại khó khăn lần nữa.

Nói cách khác, những con số gần 100% không hề tuyến tính về mặt ý nghĩa. Chúng giống như thang đo cường độ động đất hơn là điểm số thời đi học.

Vấn đề của thang đo phần trăm

Ở trường học, 98,98% và 99,99% đều là điểm A. Ai cũng vui. Nhưng trong thế giới hạ tầng hệ thống, khoảng cách giữa chúng là rất lớn: 99,99% có nghĩa là thời gian chết ít hơn gấp 10 lần so với 99,9%.

Ví dụ về hiển thị uptime trên trang trạng thái

Dân vận hành hạ tầng hiểu rõ điều này. Họ thậm chí có cách nói tắt riêng: two nines (hai số 9), three nines (ba số 9), four nines (bốn số 9). Nhờ sống trong những con số này mỗi ngày, họ nắm bắt được sự khác biệt theo bản năng.

Nhưng khán giả của các trang trạng thái dịch vụ không còn chỉ là dân hạ tầng nữa. Giờ đây, nó là tất cả mọi người.

Toán học đơn giản, nhưng giao diện thì tệ

Nielsen thừa nhận phép toán đằng sau phần trăm uptime rất đơn giản và đây là chỉ số tốt cho những người trong ngành. Nó chuẩn hóa, đáng tin cậy, dễ tuân thủ quy định.

Nhưng theo anh, đó là một giao diện tồi đối với những người không quan tâm đến việc đo lường độ tin cậy của hạ tầng theo cách chuẩn mực nhất.

Và các trang trạng thái chính là giao diện công khai để hiểu về độ tin cậy của một dịch vụ. Người dùng bình thường chỉ muốn biết: "Này, dạo này dịch vụ sập nhiều không? Có vẻ hơi nhiều đấy…"

Đề xuất: nói bằng giờ, đừng nói bằng phần trăm

Nielsen đưa ra một gợi ý đơn giản nhưng đáng suy nghĩ. Thay vì hiển thị:

GitHub Actions: 98,31% uptime

Chúng ta có thể viết:

GitHub Actions: bị ảnh hưởng 12 giờ trong 30 ngày qua (98,31% uptime)

Sự khác biệt nằm ở chỗ: một bên đòi hỏi bạn phải hiểu ý nghĩa phi tuyến tính của các con số gần 100%. Bên còn lại chỉ cần bạn biết một giờ là bao lâu.

Với người dùng Việt Nam — những người dùng GitHub Actions để chạy CI/CD, dùng Google Cloud hay AWS để vận hành sản phẩm, hay đơn giản là dùng Slack để làm việc — việc hiểu "dịch vụ này chết 12 tiếng trong tháng qua" trực quan hơn nhiều so với "98,31% uptime". Con số giờ gắn liền với trải nghiệm thực tế: những buổi sáng deploy thất bại, những deadline bị trễ vì pipeline không chạy, những cuộc họp bị gián đoạn vì công cụ liên lạc sập.

Góc nhìn rộng hơn về giao diện dữ liệu

Vấn đề Nielsen nêu ra không chỉ giới hạn ở uptime. Nó phản ánh một bài học rộng hơn trong thiết kế sản phẩm: dữ liệu chính xác chưa chắc đã là dữ liệu hữu ích.

Một chỉ số có thể hoàn hảo cho mục đích kỹ thuật, tuân thủ và so sánh nội bộ, nhưng lại thất bại khi trở thành giao diện công khai cho số đông. Việc thêm một đơn vị trực quan như "số giờ bị ảnh hưởng" bên cạnh con số phần trăm không làm mất đi độ chính xác — nó chỉ làm cho thông tin trở nên dễ tiếp cận hơn với đúng đối tượng đang đọc.

Trong bối cảnh các dịch vụ đám mây và công cụ phát triển ngày càng trở thành hạ tầng thiết yếu của mọi doanh nghiệp, việc cải thiện cách truyền đạt độ tin cậy là một bước nhỏ nhưng có ý nghĩa lớn. Bởi cuối cùng, điều người dùng cần biết không phải là một con số gần 100%, mà là: dịch vụ này đã làm gián đoạn công việc của tôi bao nhiêu lần, và trong bao lâu.