Tôi đo khoảng cách giữa lúc dịch vụ bắt đầu hỏng và lúc người trực ban biết. Với cấu hình Prometheus phổ biến (for: 2m), chuông reo sau 2 phút 43 giây — gấp 11 lần cấu hình nhanh nhất. Và có một cái sàn 14,6 giây không luật nào rút ngắn được, vì nó không nằm ở đó.
Thông báo lỗi sinh ra để giúp lập trình viên — và khi hiện cho người dùng, nó giúp luôn kẻ tấn công. Tôi đo lượng thông tin rò ở chế độ debug so với production: gấp ~700 lần, và một lỗi SQL nguyên văn phơi cả tên bảng lẫn câu truy vấn. Bài học: thông báo chung ra ngoài, log chi tiết vào trong.
Tôi dựng một 'ngân hàng' có phiên thật, một trang tấn công ở tên miền khác và một Chromium thật ở giữa, rồi đo: SameSite=Lax một mình chặn CSRF cho POST không cần token, nhưng một route GET đổi trạng thái vẫn mất 500 đồng ngay cả với Lax. Token và SameSite cắt ở hai mắt xích khác nhau, và bạn nên có cả hai.
CORS không phải lớp bảo mật thêm vào — nó là cơ chế nới lỏng same-origin policy, và cấu hình sai mở toang cánh cửa vốn được khoá. Tôi đo bằng Chromium thật: cấu hình phản chiếu Origin cho trang evil đọc trọn dữ liệu có credentials, trong khi '*' bị chuẩn chặn và danh sách trắng thì an toàn. Kèm một hiểu lầm cần gỡ: 'Failed to fetch' không có nghĩa request bị chặn.
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'.
Tôi cho một tiến trình ghi 300.000 dòng đánh số rồi chạy logrotate ở giữa. copytruncate làm mất 4.317 dòng, im lặng tuyệt đối; đổi tên file thì không mất dòng nào nhưng cả luồng log chảy vào chỗ không ai đọc. Hai cách xoay vòng, hai kiểu hỏng, không cái nào kêu lên.