ควรระบุตำแหน่งปัญหาเครือข่ายทีละชั้น ได้แก่ ลิงก์ทางกายภาพ การส่งต่อข้อมูลในชั้น 2 เส้นทาง IP และบริการแอปพลิเคชัน เราเตอร์ สวิตช์ เซิร์ฟเวอร์ และตัวรับส่งสัญญาณต่างทำหน้าที่แตกต่างกัน จึงไม่สามารถจัดการทุกอย่างด้วยการ “ลองรีสตาร์ตดูก่อน” ให้บันทึกขอบเขตและเวลาที่เกิดผลกระทบก่อน แล้วจึงใช้การทดสอบเฉพาะจุด เพื่อหลีกเลี่ยงการเข้าใจผิดว่าปัญหาแอปพลิเคชันเกิดจากสายใยแก้วนำแสงหรืออุปกรณ์เสีย
คำถามแรก: ใครได้รับผลกระทบ และเริ่มเกิดขึ้นเมื่อใด
เมื่อมีอุปกรณ์ปลายทางผิดปกติเพียงเครื่องเดียว แนวทางตรวจสอบย่อมต่างจากกรณีที่ผิดปกติทั้งชั้นหรือทั้งสถานที่ เปรียบเทียบจุดเชื่อมต่อเครือข่ายของอุปกรณ์ที่ทำงานปกติและผิดปกติ และสอบถามว่ามีการเปลี่ยนแปลงสายสัญญาณ แหล่งจ่ายไฟ การกำหนดค่า หรือซอฟต์แวร์หรือไม่ บันทึกอาการ ข้อความแสดงข้อผิดพลาด และเวลา ข้อมูลเหล่านี้ช่วยระบุโหนดที่เกี่ยวข้องร่วมกัน
อย่ารีสตาร์ตอุปกรณ์ทั้งหมดซ้ำ ๆ ก่อนเก็บหลักฐาน การรีสตาร์ตอาจล้างตัวนับหรือซ่อนปัญหาไว้ชั่วคราว แต่ไม่สามารถอธิบายสาเหตุได้ สำหรับระบบที่ใช้งานจริง ต้องประเมินผลกระทบก่อน เก็บรักษาการกำหนดค่าและบันทึกที่มีอยู่ แล้วจึงวางแผนดำเนินการที่จำเป็น
ชั้นกายภาพ: แหล่งจ่ายไฟและลิงก์สามารถทำงานได้อย่างเสถียรหรือไม่
ตรวจสอบแหล่งจ่ายไฟ พอร์ต สายเครือข่าย และโมดูลใยแก้วนำแสงของอุปกรณ์ปลายทางและอุปกรณ์เครือข่าย ไฟแสดงสถานะลิงก์ที่ไม่ติดอาจเกิดจากสายสัญญาณ พอร์ตที่ถูกปิดใช้งาน ความเร็วไม่ตรงกัน หรือไฟเลี้ยงที่ปลายทางขาดหาย ไม่ได้หมายความว่าสวิตช์เสียเสมอไป เมื่อลิงก์หลุดและเชื่อมต่อใหม่บ่อยครั้ง ให้บันทึกตัวนับข้อผิดพลาดและสถานะแหล่งจ่ายไฟ และใช้สายหรือพอร์ตที่ยืนยันแล้วว่าใช้งานได้ดีในการเปลี่ยนทดแทนตามแผน
ตัวแปลงสัญญาณใยแก้วนำแสงยังต้องตรวจสอบความเข้ากันได้ระหว่างชนิดซิงเกิลโหมดกับมัลติโหมด ความยาวคลื่น ทิศทางส่งและรับ และระดับกำลังแสงที่อนุญาตด้วย ไฟพอร์ตใยแก้วนำแสงที่ติดไม่ได้หมายความว่าบริการ IP ทำงานแล้ว และไม่ได้หมายความว่ากำลังแสงมีระยะเผื่อเพียงพออย่างแน่นอน ตรวจสอบหน้าสัมผัสปลายใยแก้วก่อนทำความสะอาด และอย่ามองเข้าไปในพอร์ตใยแก้วนำแสงโดยตรง เปลี่ยนเงื่อนไขครั้งละอย่างเท่านั้น เพื่อให้ตัดสินได้ง่ายขึ้นว่าการเปลี่ยนแปลงใดส่งผล
ชั้น 2: อุปกรณ์ปลายทางเข้าสู่เครือข่ายที่ถูกต้องหรือไม่
ตรวจสอบว่าพอร์ตอยู่ใน VLAN ที่คาดไว้หรือไม่ อัปลิงก์อนุญาตให้ VLAN นั้นผ่านหรือไม่ และการเรียนรู้ MAC เป็นปกติหรือไม่ ข้อผิดพลาด CRC ในสถิติอินเทอร์เฟซอาจบ่งชี้ถึงปัญหาการส่งสัญญาณทางกายภาพ และการทิ้งแพ็กเก็ตอาจเกี่ยวข้องกับความคับคั่งด้วย ไม่ควรอธิบายการเพิ่มขึ้นของตัวนับทุกประเภทว่าเกิดจากสาเหตุเดียวกัน
ลูปอาจทำให้การบรอดคาสต์ผิดปกติและรายการในตาราง MAC สลับไปมาระหว่างพอร์ต เมื่อพบปรากฏการณ์นี้ ให้แยกลิงก์ที่มีปัญหาตามแผนที่กำหนดไว้ล่วงหน้า และตรวจสอบโปรโตคอลป้องกันและโทโพโลยี แทนที่จะเสียบสายเพิ่มต่อไป ข้อผิดพลาดในการกำหนดค่า VLAN อาจแสดงอาการเป็นไฟพอร์ตปกติ แต่อุปกรณ์ปลายทางไม่สามารถค้นหากันพบ
ชั้น 3: ที่อยู่และเส้นทางสอดคล้องกันหรือไม่
ตรวจสอบ IP มาสก์ เกตเวย์ และความขัดแย้งของที่อยู่ของอุปกรณ์ปลายทาง ตรวจสอบเครือข่ายภายในก่อน แล้วจึงตรวจสอบเส้นทางข้ามส่วนเครือข่าย เส้นทาง นโยบายการเข้าถึง หรือการแปลงที่อยู่ของเราเตอร์ล้วนส่งผลต่อการสื่อสารในทิศทางใดทิศทางหนึ่งได้ การเข้าถึงได้ในทิศทางหนึ่งไม่ได้รับประกันว่าเส้นทางย้อนกลับจะถูกต้องด้วย
การ Ping ไม่สำเร็จอาจเกิดจากทราฟฟิกทดสอบถูกจำกัดตามนโยบายด้วย จึงไม่สามารถตัดสินได้ทันทีว่าอุปกรณ์ออฟไลน์ ให้ประเมินร่วมกันจากตารางอุปกรณ์ข้างเคียง เส้นทาง บันทึกของอุปกรณ์ และการทดสอบบริการทางธุรกิจที่ได้รับอนุญาต เมื่อ DNS ผิดปกติ การเข้าถึงด้วยชื่อโดเมนอาจล้มเหลว ขณะที่การใช้ที่อยู่โดยตรงอาจสำเร็จ แต่ยังจำเป็นต้องยืนยันว่าแอปพลิเคชันพึ่งพาชื่อโดเมนหรือใบรับรองหรือไม่
แอปพลิเคชัน: เซิร์ฟเวอร์กำลังให้บริการจริงหรือไม่
เซิร์ฟเวอร์อาจตอบสนองต่อการตรวจสอบผ่านเครือข่ายได้ แต่แอปพลิเคชันอาจยังไม่ได้เริ่มทำงาน อาจรอรับการเชื่อมต่อบนที่อยู่ผิด อาจมีทรัพยากรไม่เพียงพอ หรืออาจพึ่งพาฐานข้อมูลที่ขัดข้อง ตรวจสอบสถานะบริการ พอร์ต บันทึก และการใช้ทรัพยากร เครือข่ายมีหน้าที่เพียงส่งข้อมูลไปตามเส้นทาง และจะไม่แก้ไขข้อผิดพลาดภายในแอปพลิเคชันให้โดยอัตโนมัติ
หลังจากกู้คืนการทำงานแล้ว ให้ตรวจสอบการใช้งานจริงของผู้ใช้ ไม่ใช่เพียงการเชื่อมต่อ บันทึกสาเหตุ วิธีจัดการ และผลการทดสอบซ้ำในรายงานการบำรุงรักษา และเก็บข้อมูลอ้างอิงขณะทำงานปกติไว้ เมื่อต้องเปลี่ยนเส้นทาง ไฟร์วอลล์ หรือการกำหนดค่าระบบที่ใช้งานจริง ให้สำรองข้อมูลก่อนและเตรียมแผนย้อนกลับ อย่าเปิดการเข้าถึงทั้งหมดโดยไม่มีเงื่อนไขเพียงเพื่อ “ให้ใช้งานได้”
หากปัญหาเกิดขึ้นเฉพาะเมื่อมีโหลดสูง ให้เปรียบเทียบกราฟทราฟฟิกและทรัพยากร แทนที่จะทดสอบเฉพาะช่วงที่ไม่มีโหลด และต้องไม่ปล่อยทราฟฟิกทดสอบเข้าสู่เครือข่ายที่ใช้งานจริงโดยไม่มีการควบคุม ให้กำหนดขอบเขตและอัตราเพื่อป้องกันไม่ให้การวินิจฉัยเองเป็นสาเหตุของความคับคั่ง
แปลจากบทความทางเทคนิคภาษาจีน ต้นฉบับเผยแพร่ครั้งแรก: 2020-05-20 ต้นฉบับแก้ไขล่าสุด: 2026-10-13T23:18:15+08:00. อ่านต้นฉบับภาษาจีน
