Bảo mật 02/09/2026 9 phút

Chạy danh sách kiểm bảo mật lên chính cái blog này: tám mục đạt, khoá xanh, header đầy đủ — và một dòng curl vẫn moi ra cookie phiên thiếu cờ Secure

Làm sao BIẾT một ứng dụng đã cấu hình đúng, không phải bằng cảm giác 'chắc ổn'? Tôi chạy một danh sách kiểm chỉ-đọc lên chính blog Spring Boot đang chạy: header đủ, actuator đóng kín, trang lỗi sạch — nhưng cookie JSESSIONID thiếu cờ Secure, đúng cái mục mà sự tự tin chung che mất. Danh sách kiểm biến 'có an toàn không' mơ hồ thành một bảng từng dòng đạt/không đạt.

DevOps 02/09/2026 9 phút

Tôi đoán hàm này ăn 70% CPU — chính tay tôi viết nó — hai phép đo nói 90,7% và 98,3%; và py-spy đo được điều đó gần như miễn phí

Lấy mẫu hồ sơ ngoài tiến trình ở 99 Hz gần như không tốn gì (−0,8%), nên bật được suốt ngày ở production; còn cProfile làm chương trình chậm gấp 2,06 lần và tự tạo sự cố hiệu năng. Nhưng bài học lớn nhất là con số tôi đoán sai về mã của chính mình — thời gian chạy không tỷ lệ với số dòng.

Mạng 02/09/2026 9 phút

Người nhận không đọc một byte nào, tôi vẫn send() được 1,5 MB — rồi mới hiểu vì sao write() đôi khi đứng khựng

send() nuốt được khoảng 1,5 lần tổng hai đệm socket rồi mới chặn, dù người nhận đứng hình không đọc byte nào. Đó không phải lỗi mà là kiểm soát luồng của TCP tự ghìm người gửi theo người nhận. Đo thật, kèm cú bẫy kernel âm thầm nhân đôi đệm.

Bảo mật 02/09/2026 8 phút

195 KB JSON làm sập cả tiến trình, còn giới hạn body 1 MB không cứu nổi — ba trục bùng nổ khi parse mà một cái trần không chặn hết

Kẻ tấn công parse không chỉ điều khiển kích thước dữ liệu mà cả cấu trúc của nó, và mỗi chiều đánh vào một tài nguyên khác nhau: JSON lồng sâu 100.000 cấp (195 KB) làm tràn stack, một số 100.000 chữ số đốt CPU O(n²), một mảng 5 triệu phần tử ngốn RAM. Tôi đo cả ba, và cho thấy vì sao giới hạn kích thước body — biện pháp phổ biến nhất — chỉ chặn được đúng một trục.

DevOps 02/09/2026 9 phút

Cùng một sự cố, ba cách tính SLI cho ba kết luận trái ngược: vi phạm SLO, đạt SLO, và 'không có chuyện gì xảy ra'

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'.

DevOps 02/09/2026 8 phút

Dịch vụ vừa hết công suất mà độ trễ và lỗi vẫn hoàn hảo — client tăng 8 lần, thông lượng chỉ +8%, còn p99 gấp 15,6 lần

Bốn tín hiệu vàng ai cũng nhắc, nhưng hiếm khi đo cạnh nhau trên cùng một sự cố. Tôi quét tải 1→64 client trên một dịch vụ 8 worker và đo cả bốn ở mỗi mức: saturation chạm trần ở đúng lúc độ trễ, lỗi và thông lượng còn đẹp — và định luật Little dự đoán độ trễ sau điểm bão hoà khớp trong 1,3%. Thứ tự bốn tín hiệu phản ứng mới là điều đáng nhớ.