Chuyển tới nội dung chính

Runbook xử lý sự cố mạng — SCID ITOps

Nguồn sự thật cho phần "Quy trình xử lý" trong email cảnh báo Grafana. Email chỉ trỏ link tới đúng mục ở đây — sửa quy trình thì sửa 1 chỗ này, không sửa email/code.

⚠️ Các bước dưới đây đang là NHÁP do dựng khung tự động — đội IT (Yến/Đạt) rà lại và sửa theo quy trình THẬT của SCID: ai xử lý, gọi ai, công cụ nội bộ nào, ngưỡng leo thang. Xoá dòng cảnh báo này ở từng mục khi đã xác nhận.

Mỗi mục ứng với 1 rule trong alert-rules.yaml (uid ghi ở tiêu đề). Cột "Nơi xem" bám đúng dashboard đang chạy (SCID ITOps — Giám sát mạng).

🔴 Hạ tầng LÕI mất kết nối (scid-core-down)​

Nghĩa là: một thiết bị lõi (firewall / core switch / hypervisor / router) không còn ping/Kuma với tới → khẩn cấp.

Nơi xem: Dashboard → mục Tổng quan + Sức khỏe mạng: bảng "⚠ Thiết bị KHÔNG tới được" (biết site/loại) + panel Uptime + KPI "Hạ tầng LÕI mất".

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Xác định thiết bị + site từ email/bảng trên dashboard.
  2. Kiểm nhanh cả site: các thiết bị khác cùng site có mất không? → nếu nhiều con cùng mất, nghi mất điện/WAN cả site (xem mục Thiết bị mất).
  3. Ping/console thiết bị; kiểm nguồn điện + cổng uplink.
  4. Firewall/core treo → khởi động lại theo quy trình (dùng agent fortigate-vm04 / palo-alto-scid để chẩn đoán trước).
  5. Nghi hỏng phần cứng → báo nhà thầu.

Leo thang: (TODO: tên người trực + SĐT + sau bao lâu chưa xử lý xong thì gọi ai)

🔴 Tunnel VPN site-to-site DOWN (scid-tunnel-down)​

Nghĩa là: một tunnel IPsec từ FortiGate hub (VM04) tụt SA → site có thể mất kết nối nội bộ về DC.

Nơi xem: Dashboard → bảng "Tunnel VPN site-to-site" (tunnel nào DOWN).

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Xác định tunnel từ email (tên tunnel).
  2. Kiểm WAN của site còn không (ping IP public site) — WAN chết thì báo ISP.
  3. Trên FortiGate hub: kiểm phase1/phase2, bounce tunnel để ép đàm phán lại.
  4. Kiểm đầu site (Palo/Forti) tương ứng.

Leo thang: (TODO)

🔴 Collector giám sát ĐỨNG (scid-collector-dead)​

Nghĩa là: trong 10 phút qua không có một điểm dữ liệu nào chảy vào InfluxDB (đo bằng số điểm icmp-perf). Nghĩa là LibreNMS/collector hoặc InfluxDB đã chết. ⚠️ Đây là cảnh báo về chính hệ giám sát: khi nó nổ, mọi cảnh báo khác đang IM LẶNG (các rule kia đặt noData=OK để tránh nhiễu) — tức là ta đang mù, không biết thiết bị nào thật sự down.

Nơi xem: không phải sự cố của 1 thiết bị mà của cả hệ thu thập. SSH VM it-ops (nội bộ):

  • docker ps | grep -E 'influxdb|librenms' — các container còn Up không?
  • docker logs --tail 50 itops-librenms — poller còn chạy, có lỗi kết nối InfluxDB không?
  • Mọi dashboard Grafana sẽ đứng số (không có điểm mới sau mốc chết).

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. SSH VM it-ops (nội bộ), chạy docker ps — khoanh vùng: InfluxDB chết hay LibreNMS chết (hay cả VM).
  2. Container Exited → docker start <tên> (hoặc docker compose up -d trong thư mục stack).
  3. Còn Up nhưng vẫn không có data → xem log LibreNMS (poller/dispatcher) và log InfluxDB; kiểm đĩa VM còn chỗ không (df -h) — InfluxDB đầy đĩa sẽ ngừng nhận ghi.
  4. Khôi phục xong: đợi ~2–3 phút, xác nhận dashboard có điểm mới trở lại → cảnh báo tự tắt (email "✅ ĐÃ HẾT").
  5. Trong lúc collector chết, đừng tin sự "im lặng" của các cảnh báo khác — kiểm thủ công thiết bị trọng yếu (firewall/core/tunnel) qua agent hoặc console.

Leo thang: (TODO: ai chịu trách nhiệm VM itops; SLA khôi phục giám sát)

🟡 Thiết bị mất kết nối (scid-any-down)​

Nghĩa là: một thiết bị (không thuộc hạ tầng lõi) không với tới được.

Nơi xem: Dashboard → bảng "⚠ Thiết bị KHÔNG tới được" + "Sức khỏe theo Site".

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Ping thiết bị từ máy cùng mạng.
  2. Kiểm switch/port nơi thiết bị cắm.
  3. Xác nhận có phải tắt máy/bảo trì theo kế hoạch không.

Leo thang: (TODO)

🟡 CPU cao (scid-cpu-high)​

Nghĩa là: CPU trung bình 10 phút của thiết bị SNMP vượt 90%.

Nơi xem: Dashboard → mục Hiệu suất → panel "CPU theo thiết bị".

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Xem tiến trình/phiên bất thường trên thiết bị.
  2. Kiểm có bị quét/tấn công (traffic tăng đột biến) — đối chiếu panel Lưu lượng + Phiên đang mở.
  3. Firewall: số phiên cao → soi policy/DDoS.
  4. Cao thường xuyên → cân nhắc nâng cấp phần cứng.

Leo thang: (TODO)

🟡 RAM cao (scid-ram-high)​

Nghĩa là: bộ nhớ đang dùng vượt 90%.

Nơi xem: Dashboard → mục Hiệu suất → panel "Bộ nhớ đang dùng (%)".

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Xem tiến trình ngốn RAM.
  2. Kiểm rò rỉ bộ nhớ của dịch vụ.
  3. Khởi động lại dịch vụ/thiết bị vào giờ thấp điểm nếu cần.

Leo thang: (TODO)

🟡/🔴 Đĩa gần đầy (scid-disk-high 90% · scid-disk-critical 95%)​

Nghĩa là: một phân vùng vượt ngưỡng dung lượng. Hai mức: warning ở >90% (còn kịp dọn) và critical ở >95% (sắp hết chỗ — dịch vụ ghi đĩa như log/DB có thể ngừng). Critical gửi cả Đạt lẫn Yến.

Nơi xem: Dashboard → panel "Đĩa đầy nhất (%)".

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Dọn log / file tạm.
  2. Kiểm cấu hình xoay vòng log.
  3. Mở rộng dung lượng nếu mức dùng tăng đều.

Leo thang: (TODO)

🟡 Độ trễ cao (scid-latency-high)​

Nghĩa là: ping trung bình 10 phút vượt 150ms.

Nơi xem: Dashboard → panel "Độ trễ theo thiết bị".

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Kiểm tải/nghẽn đường truyền tới thiết bị.
  2. Ping nhiều mốc trung gian để khoanh đoạn chậm.
  3. Xem WAN/ISP; kiểm QoS nếu có.

Leo thang: (TODO)

🟡 Mất gói ping cao (scid-packet-loss)​

Nghĩa là: thiết bị vẫn tới được nhưng rớt >30% gói ping trong 10 phút. Đường truyền chập chờn — thường là dấu hiệu SỚM trước khi mất hẳn kết nối (cáp lỏng, WAN quá tải, wifi nhiễu, duplex mismatch). Thiết bị mất hẳn (rớt 100%) đã có cảnh báo mất kết nối lo, không lặp ở đây.

Nơi xem: Dashboard → panel "Độ trễ theo thiết bị" (con hay rớt thường kèm độ trễ giật cục). Đối chiếu panel lỗi cổng nếu là thiết bị nối trực tiếp.

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Ping liên tục thiết bị từ máy cùng mạng để xác nhận mức rớt gói.
  2. Nếu qua WAN/VPN: kiểm tải đường truyền + chất lượng tuyến ISP.
  3. Nếu trong LAN: kiểm cáp/đầu bấm, cổng switch (đối chiếu lỗi cổng), thử đổi cổng.
  4. Wifi: kiểm nhiễu kênh / khoảng cách / số client.

Leo thang: (TODO)

🟡 Cổng mạng nhiều lỗi (scid-port-errors)​

Nghĩa là: một cổng switch/router có >5 lỗi/giây (trung bình 10 phút, gộp in+out). Thường do cáp/đầu bấm kém, duplex mismatch, hoặc cổng flap (chập chờn lên/xuống). ⚠️ Đây không phải "cổng down" — InfluxDB không có trạng thái up/down của cổng, nên cổng tắt hẳn phải xem ở LibreNMS. Cảnh báo này bắt cổng đang lỗi trong khi vẫn hoạt động. (Đã lọc bỏ cổng ảo wifi radio/ssid và các đỉnh rate giả do counter reset khi thiết bị reboot.)

Nơi xem: LibreNMS → mở thiết bị → tab Ports → cổng có ifName trong email; xem cột lỗi (In/Out errors) tăng. Đối chiếu lưu lượng cổng nếu có panel.

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Xác định thiết bị + cổng (ifName) từ email.
  2. Kiểm cáp/đầu bấm; thử đổi cổng switch hoặc đổi dây.
  3. Kiểm cấu hình speed/duplex 2 đầu (mismatch gây lỗi liên tục).
  4. Cổng flap: xem log thiết bị (link up/down lặp) — có thể thiết bị đầu kia đang reboot lặp.

Leo thang: (TODO)

🟡 Phiên firewall Palo tăng bất thường (scid-palo-sessions)​

Nghĩa là: số phiên (session) hiện tại của một Palo Alto vượt >5 lần mức bình thường (trung vị 6 giờ) của chính con đó. Vì mỗi Palo có mức phiên rất khác nhau (vài trăm → vài chục nghìn) nên dùng tỉ lệ so chính nó, không phải ngưỡng cố định. Nghi quét cổng/DDoS hoặc rò rỉ phiên (session leak). ⚠️ Ngưỡng 5× là khởi điểm — theo dõi vài ngày rồi tinh chỉnh (nâng nếu nhiễu, hạ nếu bỏ sót).

Nơi xem: Palo Alto → Monitor → Session Browser (xem phiên đang mở, nguồn tạo nhiều nhất) + Threat log (dấu hiệu quét/tấn công). Dùng agent palo-alto-scid để chẩn đoán nhanh (read-only).

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Xác định Palo nào từ email + xem mức tăng (×N).
  2. Session Browser: lọc theo source IP tạo nhiều phiên nhất — 1 IP tạo hàng loạt = nghi quét/bot.
  3. Đối chiếu Threat log: có signature quét/flood không.
  4. Nếu là tấn công: chặn source (dùng agent/console), báo đội an ninh.
  5. Nếu phiên tăng đều không rõ nguồn: nghi rò rỉ phiên của ứng dụng — soi app tạo phiên.

Leo thang: (TODO)

🟡 Thiết bị vừa reboot (scid-reboot)​

Nghĩa là: một thiết bị có uptime dưới 15 phút — vừa khởi động lại.

Nơi xem: Dashboard → panel "Uptime thiết bị" (con vừa reboot ở đầu).

Quy trình xử lý (⚠️ NHÁP — đội IT xác nhận):

  1. Xác nhận có kế hoạch bảo trì/khởi động lại không.
  2. Nếu KHÔNG: kiểm nguồn/UPS + log crash của thiết bị.
  3. Reboot lặp lại nhiều lần → nghi hỏng phần cứng/nguồn.

Leo thang: (TODO)