Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
Tôi dựng TOTP thật rồi đo ba tính chất của nó: mã đổi mỗi 30 giây, cửa sổ chấp nhận ±31 giây, và tự nó KHÔNG chống phát lại. Nhưng điểm yếu chí mạng là phishing thời gian thực — thứ WebAuthn chặn được vì nó gắn chữ ký vào đúng tên miền. Hai công nghệ, hai triết lý.
Tôi dựng cùng một sự cố hai lần rồi tính SLI ba cách. Theo request: vi phạm nặng. Theo cửa sổ: y hệt nhau dù số người dính khác 3,6 lần. Theo độ trễ trung bình: 100% đạt, mù hoàn toàn. Câu hỏi trung tâm của SLO không phải 'đặt bao nhiêu' mà là 'tính SLI thế nào'.
Bài chốt sê-ri bảo mật web: tôi gom bốn lớp lỗ hổng khác hẳn nhau (chạy mã từ chuỗi, SQL injection, shell injection, YAML RCE) vào một phép đo — cách khuyến nghị chặn sạch cả bốn, cách opt-out lọt cả bốn. Công cụ hiện đại đã mặc định an toàn; lỗ hổng gần như luôn đến từ hành động chủ động gỡ lớp bảo vệ có sẵn, không phải từ việc thiếu một lớp mới.
Tôi cộng cả ba lớp quan sát trên cùng một dịch vụ và đo tổng: −12,9% thông lượng, +19,3% CPU, +45,8% bộ nhớ. Nhưng phát hiện quan trọng hơn con số tổng là mô hình chi phí — chỉ số giữ trạng thái gộp nên KHÔNG tỷ lệ với lưu lượng (1.312 byte dù 20 nghìn hay 20 triệu yêu cầu), còn log và trace ghi từng sự kiện nên phình tuyến tính. Cùng lượng việc, trace tốn gấp 1.540 lần chỉ số.
Bản thân cụm Kubernetes cũng là một nguồn phát chỉ số, và nó phát ngay cả khi bạn chưa triển khai gì. Tôi đo: 187 chuỗi/pod tuyến tính hoàn hảo, kể cả pod pause chẳng làm gì. Và một bất ngờ — xoá sạch một namespace để lại 4.580 chuỗi control plane không bao giờ co lại (nhưng nó bão hoà).
Nhúng trace_id vào mỗi dòng log tốn thêm 59,8% dung lượng. Đổi lại: khi có sự cố, số dòng bạn phải lọc để tìm đúng chuyện đã xảy ra giảm 12.000 lần. Thời gian máy chạy gần như không đổi — cái thay đổi là thời gian của con người lúc đang cháy nhà.