612 lần đăng nhập sai trong một giờ: đọc Event ID 4625 để phân biệt tấn công và… máy cũ
Không phải cứ log đỏ là bị tấn công. Cách SOC phân loại đăng nhập thất bại trên Windows: trường nào cần xem, khi nào là brute force, khi nào là mật khẩu cũ.
Database, mạng, kiến trúc — giải thích bằng ví dụ. · 11 bài
Không phải cứ log đỏ là bị tấn công. Cách SOC phân loại đăng nhập thất bại trên Windows: trường nào cần xem, khi nào là brute force, khi nào là mật khẩu cũ.
Một mảng bit nhỏ trong RAM giúp RocksDB, Cassandra bỏ qua hàng loạt lần đọc đĩa vô ích — đổi lại thỉnh thoảng báo nhầm.
Dữ liệu không mất — chỉ là bạn đang đọc từ một bản sao chưa kịp cập nhật. Cách xử lý gọn nhất: read-your-writes.
Request đầu 160ms, request sau chỉ 80ms dù server trả lời tức thì. Thủ phạm là màn chào hỏi SYN / SYN-ACK / ACK.
12 client cùng retry một lúc đánh sập server 6 chỗ. Backoff quyết định chờ bao lâu, jitter quyết định server có sống hay không.
Ack đã trả đủ 6 bản ghi nhưng bảng mới cập nhật 3 — mất điện vẫn không mất dòng nào, nhờ ghi log trước, cập nhật bảng sau.
Service chết mà mỗi lần gọi vẫn phải đợi 1000ms mới nhận lỗi. Circuit breaker đếm lỗi, ngắt mạch và trả lỗi ngay.
Producer đẩy 3 msg/s, consumer xử lý 1 msg/s. Không có backpressure, queue phình tới hết bộ nhớ. Có backpressure, consumer cầm nhịp.
CDN chỉ gửi vài bản gốc, phần còn lại trình phát của người xem tự chuyền cho nhau — và quay về CDN ngay khi có người rời đi.
Query chỉ 12ms mà API vẫn chậm? Thủ phạm thường là chi phí mở kết nối. Pool xoá khoản đó — nhưng khi quá tải, request phải xếp hàng.
Browser, CDN, Redis, Database xếp chồng. Request dừng ở tầng nào thì trả giá tới tầng đó — và mỗi lần miss, các tầng tự học.
Thử từ khoá khác hoặc bỏ bộ lọc chủ đề.
Theo dõi binhAI qua RSS (Feedly, Inoreader, Slack…) để nhận bài mới ngay khi đăng.