Công cụ ứng phó khủng hoảng cho Linux

Công cụ khủng hoảng cho Linux

• Cung cấp danh sách các "công cụ khủng hoảng" nên được cài đặt mặc định trên máy chủ Linux cùng tên gói (Ubuntu) có chứa các công cụ đó.
• Bao gồm các công cụ cho thống kê cơ bản, nhật ký hệ thống, thông tin thiết bị, thống kê thiết bị, công cụ mạng, thống kê NUMA, network sniffer, profiler và thống kê PMU.
• bpfcc-tools (bcc) và bpftrace cung cấp các công cụ eBPF; bcc có nhiều tính năng hơn còn bpftrace có thể chỉnh sửa theo thời gian thực.
• Tùy theo máy chủ, cũng nên cài sẵn các công cụ phân tích bộ tăng tốc cụ thể hoặc công cụ gỡ lỗi.
• Các công cụ phân tích thiết yếu này không thay đổi thường xuyên nên chỉ cần cập nhật vài năm một lần.

Tầm quan trọng của việc cài công cụ khi xảy ra khủng hoảng

• Giải thích bằng ví dụ các vấn đề có thể phát sinh khi cài phần mềm trong tình huống khủng hoảng ở môi trường production.
• Hệ thống có thể chậm khiến việc cài các công cụ cần thiết mất nhiều thời gian, và việc cài đặt cũng có thể khó khăn do nhiều vấn đề cấu hình hoặc chính sách bảo mật.
• Để chẩn đoán và xử lý sự cố nhanh chóng trong tình huống khủng hoảng, nên cài sẵn các công cụ khủng hoảng từ trước.

Ý kiến của GN⁺

• Bài viết này cung cấp thông tin rất hữu ích cho quản trị viên hệ thống hoặc SRE (kỹ sư độ tin cậy hệ thống). Bài viết nhấn mạnh tầm quan trọng của việc chuẩn bị trước để có thể nhanh chóng sử dụng các công cụ cần thiết trong tình huống khủng hoảng thực tế.
• Việc cài sẵn công cụ khủng hoảng góp phần nâng cao tính sẵn sàng và khả năng phục hồi của hệ thống, đồng thời giúp giảm thiểu thời gian ngừng hoạt động tiềm ẩn của hệ thống.
• Tuy nhiên, điều quan trọng là phải tìm được sự cân bằng giữa bảo mật và hiệu năng. Ví dụ, nếu các công cụ không cần thiết được cài trên hệ thống thì kẻ tấn công có thể lợi dụng chúng.
• Các bản phân phối Linux có thể cân nhắc tích hợp sẵn công cụ khủng hoảng để phù hợp với môi trường doanh nghiệp, nhưng điều này có thể khác nhau tùy theo chính sách bảo mật và nhu cầu của từng tổ chức.
• Trong cộng đồng mã nguồn mở đã có sẵn nhiều công cụ giám sát và phân tích hiệu năng; ví dụ, các công cụ như Prometheus và Grafana được sử dụng rộng rãi để giám sát hiệu năng hệ thống. Nếu tích hợp và sử dụng các công cụ này cùng với công cụ khủng hoảng, việc quản trị hệ thống có thể hiệu quả hơn.

[GN⁺]

Ý kiến Hacker News

• 4:07pm cài đặt gói thất bại, không thể phân giải kho lưu trữ. Có vấn đề với cấu hình /etc/apt…

  • Môi trường cloud có nhược điểm, nhưng lại hữu ích trong những tình huống như thế này. Thay vì sửa chữa phức tạp, có thể giải quyết bằng cách tắt máy gặp sự cố hoặc loại nó khỏi pool rồi dùng máy mới.

• Có nhiều máy chủ được container hóa, nhưng vẫn còn những thách thức.

  • Nhiều công cụ trong image Docker bị các công cụ quét bảo mật đánh dấu là yếu tố rủi ro. Những công cụ như gdb là đối tượng đáng lo ngại, nhưng nhiều công cụ khác thì không.
  • Để tránh điều này, người ta đặt công cụ dưới dạng binary tĩnh trên một volume riêng, hoặc biên dịch và cài đặt bằng cách dùng đường dẫn mount làm tiền tố cài đặt. Khi cần debug, đội vận hành sẽ tạm thời mount volume ở chế độ chỉ đọc.

• Nếu có công cụ debug cần bật một số tính năng kernel cụ thể, sẽ có lo ngại về ảnh hưởng tới các container khác đang chạy trên cùng host.

• Trên hệ thống FreeBSD có thư mục /rescue/, cung cấp một file binary liên kết tĩnh duy nhất khoảng 17MB, kết hợp khoảng 150 công cụ quan trọng.

• Khi làm việc tại Netflix, Brendan và nhóm của anh ấy đã cài sẵn khắp nơi các công cụ debug như bpftrace, bcc và perf hoạt động tốt, và chúng đã nhiều lần cứu nguy.

• Ngạc nhiên vì strace không có trong danh sách. Đây là công cụ đặc biệt hữu ích khi chương trình trả về thông báo lỗi vô dụng hoặc sai lệch.

• Khi phỏng vấn các vị trí kiểu SRE, họ luôn đề cập đến những công cụ này. Điều được coi trọng không phải là ứng viên nhớ chính xác lệnh nào, mà là họ hiểu có thể làm gì, có những loại công cụ nào và cách sử dụng chúng.

• Trong tình huống khẩn cấp không thể cài công cụ, có thể chạy nhiều utility qua Docker. Ví dụ, có thể build và chạy một container Docker để chạy tcpdump trong khi kết nối vào host network.

• yum install vẫn được ưu tiên, nhưng nếu Docker khả dụng thì đây vẫn là một phương án thay thế khả thi dù cần thêm ánh xạ. Cách này có thể không hoạt động trong cấu hình rootless/podman.

• Không thấy nhắc đến nmap, netstat và nc. Những công cụ này đã nhiều lần giúp giải quyết sự cố.

• Có thể lấy được quyền root không? Muốn làm gì cũng phải gửi ticket cho quản trị viên hệ thống.

• Điều tôi muốn bổ sung là nmap. Vấn đề kết nối mạng trong một số ứng dụng có thể không biểu hiện rõ ràng.