Vấn đề là: Một ứng dụng cơ sở dữ liệu là "ít". Đội mạng đổ lỗi cho đội máy chủ. Đội máy chủ đổ lỗi cho mạng. Trong khi đó, người dùng cảm thấy nản lòng, và họ lãng phí nhiều giờ để sửa đổi vòng tròn.
Giải pháp: Một cách tiếp cận có hệ thống, khoa học để tìm ra vấn đề sử dụng bằng chứng, chứ không phải giả định, để xác định nguyên nhân gốc.
Chi phí của việc bắn phá Haphazard: lãng phí thời gian, không chính xác sửa chữa những vấn đề thực sự, chỉ tay giữa các đội, và kinh nghiệm người dùng suy đồi.
Phát hiện vấn đề mạng cơ bản là một bài tập về phương pháp khoa học:
Bài này cung cấp một khuôn khổ có cấu trúc để ngăn ngừa những cạm bẫy thông thường như:
Trước khi thâm nhập vào các chẩn đoán kỹ thuật, hãy trả lời năm câu hỏi quan trọng này để thu hẹp phạm vi điều tra của bạn:
Thay đổi cấu hình? Phần cứng mới? Cập nhật phần mềm? Thay đổi đại học?
Một người dùng? Một tòa nhà? Mọi người? Chỉ ứng dụng cụ thể?
Chuyện này xảy ra suốt sao? Chỉ trong vài giờ? Xảy ra ngẫu nhiên?
Bạn có thể kích hoạt vấn đề theo yêu cầu?
Kiểm tra cả hai đầu của kết nối
Mô hình hệ điều hành cung cấp một khuôn khổ có cấu trúc cho việc giải quyết vấn đề. Làm việc từ lớp 1 (Physical) trở lên, hoặc từ lớp 7 (Apof) xuống, tùy theo triệu chứng.
Khi nào cần dùng: Mất kết nối hoàn toàn, không có ánh sáng liên kết, hay triệu chứng của lớp vật lý
show interfaces. ethtool eth0show mac address-table. show spanning-treeping. traceroute. show ip routetelnet host port. netstat -an, thu góinslookup. dig. curl -vKhi nào cần dùng: Name
Bắt đầu ở lớp 7 ( Dịch vụ Chia sẻ Điểm đang chạy? DNS quyết định sửa IP?) và chỉ làm việc khi cần thiết.
Sử dụng nhanh chóng cây chẩn đoán này để xác định lớp nào đang thất bại:
Hàng nóng không hoạt động được. Kiểm tra dịch vụ hệ điều hành, cài đặt lại các trình điều khiển mạng.
Tắt hệ thống NIC, trình điều khiển sai, chưa cắm dây cáp. Kiểm tra: ip link show hoặc bộ quản lý thiết bị
Kiểm tra: cáp vật lý, chuyển trạng thái cổng, bài tập VLAN, bàn ARP
Kiểm tra: bàn nướng, luật tường lửa, ACL. Dùng traceroute để tìm nơi gói dừng
Kiểm tra: thiết lập máy chủ DNS, máy phục vụ DNS sẵn sàng, tường lửa chặn cổng 53
Kiểm tra: tường lửa quy định, nhóm an ninh, dịch vụ nghe ở cổng.
Vấn đề là bản thân ứng dụng, xác thực hoặc cấu hình ứng dụng
Khi bạn có một giả thuyết về nguyên nhân gốc, sử dụng những kỹ thuật tách biệt này để xác nhận hoặc từ chối nó:
Bắt giữ giao thông tại nguồn, trung gian điểm, và đích để xác định nơi gói được thả hoặc sửa đổi:
# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com
# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com
# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue
Loại bỏ các biến bên ngoài bằng cách thử nghiệm kết nối trong một thiết bị:
# Test TCP stack without network
ping 127.0.0.1
# Test application listening locally
telnet localhost 80
# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing
So sánh cấu hình và hành vi với một hệ thống làm việc:
# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
<(ssh broken-switch "show run int gi1/0/1")
# Compare routing tables
diff <(ssh router1 "show ip route") \
<(ssh router2 "show ip route")
Tài liệu chính xác sẽ ngăn chặn việc gỡ lỗi vòng tròn nơi bạn thử làm điều tương tự nhiều lần mà không nhận ra.
Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01
Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds
Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found
Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Time to Resolution: 25 minutes
Ứng dụng co sở dữ liệu thời gian bị suy giảm từ <100mm đến 5 giây+. Đội ứng dụng đã đổ lỗi cho "sự khoan dung."
Bộ đệm đệm hệ thống máy phục vụ cơ sở dữ liệu quá nhỏ đối với sản phẩm bị hoãn Cửa sổ TCP sẽ đầy, buộc người gửi phải đợi.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Đừng cho là: "Slow" không phải lúc nào cũng có nghĩa là " network latency." Luôn luôn thu thập bằng chứng (để có sự nhượng bộ, thu thập các hành vi) trước khi đi đến kết luận.
Kết nối máy phục vụ sẽ giảm ngẫu nhiên, đặc biệt là khi bị tải. Đôi khi làm việc tốt, đôi khi hoàn toàn không hưởng ứng.
Việc thỏa thuận tự động bị lỗi. Máy chủ thương lượng toàn bộ sự phức tạp, công tắc rơi trở lại phân nửa. Các va chạm chỉ xảy ra khi cả hai bên cố gắng truyền tín hiệu cùng lúc.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Kiểm tra cả hai đầu: Trạng thái giao diện cho thấy thiết lập thương lượng. Đánh lạc hướng nghĩa là thương lượng tự động thất bại. Luôn luôn phân tích tốc độ/giải tích cứng cho máy chủ.
Người dùng có thể duyệt một số trang web (Google, Yahoo) nhưng không có trang khác ( website của Bank, cổng công ty). Các yêu cầu HTTP nhỏ hoạt động, trang lớn đã quá giờ.
ping -M do -s 1472 Thành công, ping -M do -s 1473 thất bạiĐường hầm VPN giảm xuống còn 1400, nhưng tường lửa đã chặn các tin nhắn "cần trục trặc". Đường chỉ dẫn cho sự khám phá (MTTTD) không thể hoạt động, tạo ra một lỗ đen đại học. Những gói nhỏ vừa vặn, những gói lớn có DF bit đã được âm thầm thả xuống.
! Implemented TCP MSS clamping on router
interface Tunnel0
ip tcp adjust-mss 1360
! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big
Vấn đề kích cỡ: Nếu những yêu cầu nhỏ có hiệu quả nhưng việc chuyển giao lớn thất bại, nghi ngờ là vấn đề về sự phản ứng nhanh. Sử dụng tín hiệu với DF bit để kiểm tra đường dẫn mU.
Tiếng nói có âm thanh lập dị, bỏ học gián đoạn. Chỉ xảy ra trong giờ làm việc (9m-5pm).
Chính sách QoS đã tồn tại nhưng định vị bandwid thứ ngược lại: nhà tù tốt nhất nhận được 60%, giọng nói nhận được 5%. Trong giờ làm việc, khi lượng dữ liệu gia tăng, các gói tin bằng giọng nói bị giảm do quá trình xếp hàng.
! Corrected QoS policy
policy-map WAN-QOS
class VOICE
priority percent 33
class VIDEO
bandwidth percent 25
class CRITICAL-DATA
bandwidth percent 20
class class-default
bandwidth percent 22
Vấn đề dựa trên thời gian = khả năng: Nếu vấn đề chỉ xảy ra trong giờ làm việc bận rộn, nó không phải là một thất bại khó khăn mà là một vấn đề về khả năng/QOS. Kiểm tra thống kê hàng đợi, không chỉ tổng số băng thông.
| Triệu chứng | Lớp | Lệnh cần chạy | Tìm gì? |
|---|---|---|---|
| Không có ánh sáng liên kết | Lớp 1 | show interfaces |
Trạng thái: xuống, không có nhà mang, cáp chưa cắm |
| Mất gói | Lớp 1/2 | show interfaces |
Lỗi CRC, chạy bộ, khổng lồ, va chạm, va chạm muộn |
| Không thể đánh tín hiệu cánh cổng | Lớp 2 | arp -a |
Không có mục nhập ARP, MAC không được học, chặn SP |
| Không thể tới mạng phụ từ xa | Lớp 3 | traceroute |
Mất đường, nhầm người, vòng thời gian |
| Kết nối bị từ chối | Lớp 4 | telnet host port |
Dịch vụ không lắng nghe, tường lửa, TCP RST |
| Hiệu suất chậm | Lớp 4+ | ping (RTT) |
Tần số cao, giới hạn băng thông, chuyển đổi TCP, không cửa sổ |
| Không thể giải quyết tên máy | Lớp 7 | nslookup |
Máy phục vụ DNS không thể tới, sai cấu hình DNS, NXDOMAIN |
| Name | Layer 1/2 | ping -f (flood) |
Sai lầm hai lần, cáp hỏng, việc nhận lại SP |
| Làm việc đôi khi, không phải người khác. | Nhiều | Extended ping |
Tải vấn đề cân bằng, đối xứng ECMP, bàn bang tràn ngập |
Biết khi nào để tăng lên để cung cấp cho TAC hoặc kỹ sư cao cấp. Cầu thang khi:
Mỗi phiên họp bắn súng là một cơ hội học tập. Xây dựng một nền tảng kiến thức cá nhân:
# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md # Index of all issues
# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation
Quản lý các lệnh thường xuyên được sử dụng bởi kịch bản cho tham khảo nhanh trong lúc bắn súng.
Thay đổi cấu hình mà không hiểu vấn đề thường làm vấn đề tệ hơn hoặc che giấu vấn đề thật sự.
Thường thì "các vấn đề làm việc" là ứng dụng, máy chủ, hoặc các vấn đề bên khách hàng. Thu thập bằng chứng trước khi nhận lỗi.
Bạn sẽ lãng phí thời gian lặp lại các xét nghiệm bạn đã làm, hoặc không thể giải thích cho đồng nghiệp những gì bạn đã cố gắng.
Những vấn đề nan giải thường là dấu hiệu báo trước về sự thất bại sắp xảy ra. Điều tra họ trước khi họ trở nên chỉ trích.
Khởi động lại một thiết bị có thể phục hồi dịch vụ, nhưng nếu bạn không tìm ra tại sao nó cần khởi động lại, vấn đề sẽ tái diễn.
Hệ thống tìm kiếm rắc rối là cả khoa học và nghệ thuật. Khoa học đang theo đuổi một phương pháp có hệ thống, sử dụng đúng các công cụ chẩn đoán, và hiểu các giao thức. Nghệ thuật là biết được thử nghiệm nào trước tiên dựa trên triệu chứng, nhận dạng các mẫu từ kinh nghiệm, và biết khi nào sẽ tăng lên.
Bằng cách làm theo cách tiếp cận có hệ thống được nêu ra trong bài này - hỏi đúng câu hỏi, làm việc một cách có phương pháp thông qua mô hình hệ điều hành, ghi lại các bước của bạn, và học hỏi từ mỗi vấn đề - bạn sẽ trở nên hiệu quả hơn trong việc bắn rắc rối và tránh những cạm bẫy chung dẫn đến lãng phí thời gian và sửa chữa sai lầm.
Hãy nhớ: Mục tiêu không chỉ là phục hồi dịch vụ, mà còn là để hiểu tại sao nó lại thất bại để ngăn nó xảy ra lần nữa.
Cập nhật cuối: ngày 2 tháng 2 năm 2026 Tác giả: Baud9600 kỹ thuật viên