Với cửa sổ TCP cố định, thông lượng tỉ lệ nghịch với RTT: RTT gấp đôi thì tốc độ còn một nửa, bất kể băng thông rộng bao nhiêu. Nới cửa sổ gỡ được trần đó (nhanh gấp 40 lần), nhưng RTT vẫn phạt bạn qua slow-start. Đo thật bằng netem, kèm cái bẫy đo-quá-ngắn.
Cho đúng một chặng giữa chuỗi quên chuyển tiếp header traceparent, cái cây trace tách làm hai — mà không dịch vụ nào báo lỗi, cả hai mảnh đều 'khoẻ mạnh'. Cộng lấy mẫu 10%, tỷ lệ yêu cầu có trace đầy đủ rơi từ 9,93% xuống 1,01%. Mỗi chỗ gãy không cộng chi phí, nó nhân.
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.
Mỗi bảng điều khiển đang mở là một chuỗi truy vấn lặp lại mà không con số chi phí nào hiện lên màn hình người đang nhìn. Tôi đo trên Prometheus 21.563 chuỗi: gộp bằng sum by chỉ cắt phần trả về chứ không cắt phần đọc (nhanh hơn vỏn vẹn 1,88 lần), cái nó thật sự cứu là trình duyệt; bước là đòn bẩy lớn nhất; và chi phí nhân thẳng với số người đang mở — mười người là hơn một nhân trọn vẹn.
Nếu chính hệ giám sát chết, bạn biết bằng cách nào? Tôi giết lần lượt exporter, Prometheus, Alertmanager và đo cái nào thật sự kêu. Luật ngưỡng bạn viết (dich_vu_hong > 0) im lặng khi exporter biến mất; chỉ up==0 và absent() bắt được. Và dead man's switch qua Alertmanager có khoảng mù 3 phút.
Session fixation lật ngược mọi thứ bạn biết về trộm phiên: kẻ tấn công tự chọn ID phiên rồi gieo cho nạn nhân, nên HttpOnly và HTTPS đều vô dụng — không có gì bị đánh cắp cả. Tôi đo cuộc tấn công thật và cách chặn nó bằng đúng một dòng: cấp ID mới khi đăng nhập.