Cơn ác mộng lúc 2 giờ sáng: Khi “mọi thứ đều sập”
Đó là lúc 2:14 sáng ngày thứ Ba khi điện thoại của tôi bắt đầu reo inh ỏi. Cảnh báo từ PagerDuty rất ngắn gọn: CRITICAL - Database Connection Timeout (Lỗi nghiêm trọng – Hết thời gian kết nối cơ sở dữ liệu). Cho đến khi tôi mở laptop lên, kênh Slack xử lý sự cố đã là một mớ hỗn độn với những tin nhắn @channel đầy hoảng loạn. Một đợt triển khai microservice mới dường như đã làm mất kết nối hoàn toàn giữa tầng ứng dụng và các instance RDS trong subnet riêng của chúng tôi.
Adrenaline chỉ giúp bạn đi xa đến thế. Khi bạn quá mệt mỏi, não bộ sẽ ngừng xử lý các phép tính nhị phân một cách tin cậy. Tôi thấy mình bắt đầu nghi ngờ những logic mạng cơ bản nhất. Liệu 10.0.32.0/20 có bao gồm 10.0.48.5 không? Có phải script Terraform của chúng tôi đã vô tình làm trùng lặp một khối CIDR từ VPC cũ? Khi hệ thống production đang gặp sự cố, bạn không có thời gian để phác thảo các dải IP ra khăn giấy.
Nguyên nhân gốc rễ: Mối nguy tiềm ẩn của việc trùng lặp Subnet
Sau khi SSH vào một jump box, tôi bắt đầu thực hiện các bước chẩn đoán cơ bản. Ứng dụng đang cố gắng kết nối tới cơ sở dữ liệu, nhưng các gói tin (packet) đều biến mất. Tôi kiểm tra bảng routing và nhận thấy một điều khả nghi. Gần đây chúng tôi đã peering một VPC mới cho dự án phân tích dữ liệu. Các khối CIDR trông có vẻ gần nhau một cách nguy hiểm.
# Kiểm tra bảng routing hiện tại
ip route show
# Xung đột nằm ngay tại đây
default via 10.0.0.1 dev eth0
10.0.16.0/20 dev eth1 proto kernel scope link src 10.0.17.5
10.0.32.0/20 via 10.0.0.1 dev eth0 # Tuyến đường này đang chiếm quyền điều hướng traffic của DBThủ phạm chính là một sai lầm kinh điển trong mạng máy tính: trùng lặp subnet. Tuyến đường (route) từ VPC peering mới đã che lấp đường dẫn đến cơ sở dữ liệu của chúng tôi. Để khắc phục, tôi phải tính toán lại không gian IP còn trống và gán lại một dải IP không xung đột với 12 subnet hiện có. Tính toán thủ công lúc này là một rủi ro cực lớn. Chỉ cần sai một bit, bạn có thể cô lập một nửa hạ tầng của mình.
Tại sao tính toán thủ công thường thất bại dưới áp lực
Tôi đã chứng kiến những kỹ sư kỳ cựu tài năng cố gắng nhẩm tính subnet mask trong đầu khi xảy ra sự cố. Nó hầu như luôn dẫn đến “lỗi lệch một đơn vị” (off-by-one errors). Bạn cần xác định IP khả dụng đầu tiên, IP khả dụng cuối cùng và địa chỉ broadcast ngay lập tức. Nếu bạn đang làm việc với IPv6, độ phức tạp sẽ trở nên quá tải.
Tôi đã học được một bài học xương máu: đừng đoán mò. Hãy sử dụng các công cụ chuyên dụng để xác thực kiến trúc mạng của bạn trước khi nhấn nút “Apply” cho một thay đổi cấu hình. Khi tôi đang ở trong tâm điểm của việc sửa lỗi production, tôi cần một nguồn thông tin chuẩn xác mà không phụ thuộc vào bộ não đang thiếu ngủ của mình.
Cách khắc phục: Chia Subnet nhanh và xác thực IP
Để giải quyết sự trùng lặp, tôi cần một khối /22 sạch trong dải 10.0.0.0/16 đã cấp phát. Khối này không được xung đột với năm VPC peering khác. Tôi thường rất khắt khe về quyền riêng tư với các công cụ này. Tôi không thích dán sơ đồ mạng nội bộ vào các trang web lưu trữ dữ liệu trên máy chủ từ xa. Đó là một rủi ro bảo mật tiềm tàng khi bị kiểm toán.
Hiện tại tôi sử dụng Công cụ tính Subnet của ToolCraft cho các tình huống này. Lý do rất đơn giản: nó hoạt động 100% ở phía client (client-side). Mọi thứ chạy ngay trong trình duyệt của bạn. Các dải IP nội bộ không bao giờ rời khỏi máy tính của bạn. Nó là cứu cánh khi bạn cần hình dung ranh giới của một khối CIDR mà không lo rò rỉ dữ liệu.
Các bước phục hồi từng bước
- Xác định xung đột: Nhập các subnet hiện có vào công cụ tính để xem chính xác điểm bắt đầu và kết thúc của chúng.
- Tìm vùng trống: Thử nghiệm các khối CIDR mới tiềm năng, như
10.0.128.0/22, để đảm bảo chúng cung cấp đủ 1,022 host mà không chồng lấn với dải10.0.32.0/20. - Xác thực bộ chuyển đổi IP: Nếu log lỗi trả về một IP dạng thập phân (như 167772165), hãy chuyển đổi nó lại dạng dotted-decimal để tìm chính xác node đang bị lỗi.
Sử dụng IP Subnet Calculator, tôi nhận ra khối “mới” của mình đang lấn vào dải dành riêng cho VPN gateway. Tôi đã chuyển dải này lên một ngưỡng cao hơn an toàn, cập nhật các biến Terraform và kích hoạt triển khai mục tiêu.
Xác minh bằng các công cụ DNS và CLI
Khi các tuyến đường đã được sửa xong, tôi phải đảm bảo endpoint DNS của cơ sở dữ liệu phân giải đúng IP. Cache DNS là một vấn đề cực kỳ đau đầu. Ngay cả khi mạng đã được sửa, ứng dụng của bạn vẫn có thể cố gắng kết nối tới một địa chỉ cũ đã hỏng.
Tôi đã chạy lệnh dig để kiểm tra các bản ghi ngay lập tức:
# Kiểm tra phân giải DNS nội bộ
dig +short production-db.internal.company.com
# Nếu kết quả trả về IP cũ, hãy xóa cache cục bộ
sudo systemd-resolve --flush-cachesNếu bạn không thể chạy dig cục bộ, một công cụ tra cứu DNS trực tuyến là lựa chọn tốt nhất tiếp theo. Nó giúp bạn xác minh bản ghi trông như thế nào từ bên ngoài mạng nội bộ. Điều này xác nhận liệu TTL đã hết hạn chưa và liệu thay đổi đã thực sự lan truyền khắp môi trường của bạn hay chưa.
Quy trình làm việc chuyên nghiệp: CLI + Công cụ riêng tư
Bí quyết để sống sót qua một đợt sự cố không chỉ là biết các câu lệnh. Đó là biết nên chọn công cụ nào đầu tiên. Bộ công cụ cá nhân của tôi hiện đã được tinh chỉnh để đảm bảo tốc độ và an toàn:
- CLI (ip, dig, traceroute): Dùng để xác minh tức thời, cục bộ những gì máy chủ nhìn thấy.
- Công cụ trực tuyến phía Client: Tôi sử dụng ToolCraft để lập kế hoạch và tính toán. Nó xử lý các tác vụ nặng—như chuyển đổi IP và tính toán subnet—mà không làm ảnh hưởng đến bảo mật.
- Infrastructure as Code (IaC): Đảm bảo bản sửa lỗi là vĩnh viễn, được lập tài liệu và được đồng nghiệp xem xét.
Tại sao quyền riêng tư là không thể thương lượng
Nhiều kỹ sư coi các trang web “định dạng” ngẫu nhiên như một tờ nháp. Tuy nhiên, các IP nội bộ là siêu dữ liệu (metadata) phác họa toàn bộ hạ tầng của bạn. Nếu một trang web lưu lại dữ liệu bạn nhập, bạn đã tạo ra một lỗ hổng bảo mật. Đây là lý do tại sao tôi ưu tiên các công cụ hoạt động offline sau khi trang đã tải xong. Đó là tiêu chuẩn vàng cho các công cụ tiện ích trong môi trường doanh nghiệp.
Lời kết
Đến 3:30 sáng, traffic đã bắt đầu lưu thông trở lại. Các lỗi kết nối cơ sở dữ liệu biến mất và các biểu đồ độ trễ cuối cùng đã đi ngang ổn định. Bản thân việc sửa lỗi không quá phức tạp, nhưng áp lực của sự cố khiến các công cụ phù hợp trở nên không thể thiếu. Cho dù bạn đang tính toán subnet mask hay giải mã một JWT, việc sở hữu một bộ công cụ đáng tin cậy và riêng tư sẽ giúp bạn tránh được những sai lầm nghiêm trọng khi bạn quá mệt mỏi để suy nghĩ sáng suốt.
Lần tới khi bạn đang nhìn chằm chằm vào bảng routing giữa đêm khuya, hãy nhớ: đừng tự mình làm toán. Hãy sử dụng công cụ chia subnet, xác minh bằng dig và luôn kiểm tra kỹ các trường hợp trùng lặp.
