การแก้ไขปัญหาใน Linux: คู่มือฉบับสมบูรณ์และใช้งานได้จริง

อินฟอร์เมเทค ดิจิตอล » Recursos » การแก้ไขปัญหาใน Linux: คู่มือฉบับสมบูรณ์และใช้งานได้จริง

หากคุณใช้ Linux เป็นประจำทุกวัน ไม่ช้าก็เร็วคุณจะต้องเจอปัญหาแปลกๆ บ้าง เช่น ระบบบูตไม่ติด บริการบางอย่างหยุดทำงานโดยไม่มีสาเหตุชัดเจน Wi-Fi หลุดบ่อย หรือฮาร์ดไดรฟ์ส่งเสียงดังผิดปกติ ปัญหาเหล่านี้ไม่ใช่เรื่องร้ายแรง แต่เป็นโอกาสที่ดีในการเรียนรู้การทำงานภายในของระบบ และพัฒนาระบบการวินิจฉัยปัญหา Linux ที่มีประสิทธิภาพ

แตกต่างจากระบบอื่นๆ ที่เน้นการทำงานอัตโนมัติ (เช่น เครื่องมือแก้ไขปัญหาของ Windows หรือคำสั่งต่างๆ เช่น DISM/SFC) Linux นำเสนอระบบนิเวศที่ทรงพลังของเครื่องมือวินิจฉัย บันทึกรายละเอียด และยูทิลิตี้การตรวจสอบ สิ่งสำคัญไม่ใช่แค่การท่องจำคำสั่ง แต่เป็นการเข้าใจกระบวนการ: วิธีการรวบรวมข้อมูล วิธีการตีความข้อมูล และวิธีการดำเนินการโดยไม่ทำให้สถานการณ์แย่ลง

แนวทางทั่วไปในการวินิจฉัยปัญหาในระบบปฏิบัติการลินุกซ์

การแก้ไขปัญหาใน Linux ไม่ควรเป็นแบบ "ลองดูว่าจะเกิดอะไรขึ้นถ้าฉันไปแตะตรงนี้" แต่ควรเป็นกระบวนการที่เป็นระเบียบและทำซ้ำได้ โดยอาศัยตรรกะและการสังเกต ยิ่งคุณทำอย่างเป็นระบบมากเท่าไหร่ คุณก็จะยิ่งค้นพบสาเหตุที่แท้จริงได้เร็วขึ้น และโอกาสที่จะทำให้ระบบเสียหายระหว่างทางก็จะยิ่งน้อยลงเท่านั้น

หลักการพื้นฐานข้อแรกคือ การรวบรวมข้อมูลเกี่ยวกับข้อผิดพลาดให้ได้มากที่สุดก่อนที่จะลงมือทำอะไร ซึ่งหมายถึงการจดบันทึกข้อความแสดงข้อผิดพลาดอย่างละเอียด เวลาที่ปรากฏ และสิ่งที่คุณกำลังทำอยู่ก่อนหน้านั้นรายละเอียดต่างๆ เช่น "เริ่มเกิดขึ้นหลังจากอัปเดต" "เกิดขึ้นเฉพาะกับโปรแกรมนี้" หรือ "เกิดขึ้นเมื่อฉันเชื่อมต่ออุปกรณ์ USB นี้" ล้วนมีค่าอย่างยิ่งสำหรับการวินิจฉัยปัญหา

สิ่งสำคัญอีกอย่างคือต้องพิจารณาว่าปัญหานั้นเกิดขึ้นซ้ำได้เสมอหรือไม่ หรือเกิดขึ้นเป็นครั้งคราวการรู้ว่าคุณสามารถทำให้เกิดข้อผิดพลาดได้โดยเจตนาหรือไม่จะช่วยให้คุณทดสอบวิธีการแก้ไขได้อย่างเป็นระบบ และยืนยันได้ว่าวิธีการเหล่านั้นได้ผลจริงหรือไม่

ขณะรวบรวมข้อมูล จำเป็นอย่างยิ่งที่จะต้องเปิดใช้งานด้านการสังเกตของคุณให้มากที่สุด: ข้อความบนหน้าจอ ไฟแสดงสถานะการวินิจฉัยของเมนบอร์ด เสียงผิดปกติจากดิสก์หรือพัดลม กลิ่นไหม้ บริเวณที่ร้อนจัดเมื่อสัมผัส... ประสาทสัมผัสของคุณ (การมองเห็น การได้ยิน การดมกลิ่น และการสัมผัส) ก็เป็นส่วนหนึ่งของชุดเครื่องมือวินิจฉัยเช่นกัน โดยเฉพาะอย่างยิ่งเมื่อคุณสงสัยว่ามีปัญหาเกี่ยวกับฮาร์ดแวร์ทางกายภาพ

เมื่อได้ข้อมูลเบื้องต้นมาแล้ว ขั้นตอนต่อไปที่สมเหตุสมผลคือการจำกัดขอบเขตของปัญหา : ปัญหาเกิดจากซอฟต์แวร์ (เคอร์เนล ระบบไฟล์ บริการ แอปพลิเคชัน) การกำหนดค่า (เครือข่าย สิทธิ์ ไดรเวอร์) หรือฮาร์ดแวร์ (RAM ดิสก์ อุณหภูมิ แหล่งจ่ายไฟ การ์ดเครือข่าย การ์ดจอ ฯลฯ)? การจำแนกประเภทนี้จะช่วยนำทางคุณไปยังเครื่องมือที่เหมาะสมในแต่ละกรณี

หลักการสำคัญของการแก้ปัญหาในลินุกซ์

การวินิจฉัยที่ดีนั้นอาศัยหลักการสำคัญไม่กี่ข้อที่ควรทำความเข้าใจให้ถ่องแท้โดยเร็วที่สุด ข้อแรกคือการรวบรวมข้อมูลอย่างเป็นระบบ : การบอกแค่ว่า "Wi-Fi ของฉันใช้งานไม่ได้" นั้นไม่เพียงพอ คุณต้องรู้ว่ามีการขัดข้องหรือไม่ ปัญหาอยู่ที่อุปกรณ์ของคุณเท่านั้นหรือไม่ ส่งผลกระทบต่อบริการเฉพาะหรือการเชื่อมต่อทั้งหมด บันทึกระบบบอกอะไรบ้าง มีข้อผิดพลาดของไดรเวอร์หรือไม่ เป็นต้น

ขั้นตอนต่อไปคือการวิเคราะห์ข้อมูลที่รวบรวมได้โดยใช้เครื่องมือที่เหมาะสม Linux มีบันทึกระบบที่ละเอียดมาก คำสั่งตรวจสอบทรัพยากร และยูทิลิตี้เฉพาะด้านเครือข่ายและฮาร์ดแวร์เป็นเรื่องปกติที่จะใช้แหล่งข้อมูลหลายแหล่งร่วมกัน เช่น ใช้journalctlและdmesgเพื่อตรวจสอบข้อความเคอร์เนลและบริการใช้ top หรือ htopเพื่อตรวจสอบภาระงานของระบบ และใช้เครื่องมือเครือข่าย เช่นping, ss หรือ tcpdumpเพื่อดูว่าเกิดอะไรขึ้นกับการเชื่อมต่อ

เมื่อคุณมีสมมติฐานที่สมเหตุสมผลแล้ว ก็ถึงเวลาทดสอบวิธีแก้ปัญหาอย่างรอบคอบ ซึ่งหมายถึงการเปลี่ยนแปลงทีละอย่าง ตรวจสอบผลลัพธ์ และย้อนกลับการเปลี่ยนแปลงหากไม่ได้ผลคุณไม่ควรทำการเปลี่ยนแปลงหลายอย่างพร้อมกัน เพราะหากปัญหาหายไป คุณจะไม่รู้ว่าการเปลี่ยนแปลงใดแก้ปัญหาได้ และหากปัญหาแย่ลง คุณก็จะไม่รู้ว่าอะไรเป็นสาเหตุ

อีกหนึ่งเสาหลักสำคัญที่มักถูกมองข้ามคือ การจัดทำเอกสาร การจดบันทึกคำสั่งที่คุณใช้ ไฟล์ที่คุณแก้ไข และผลลัพธ์ที่คุณได้รับ จะช่วยให้คุณสามารถทำซ้ำวิธีแก้ปัญหาที่ประสบความสำเร็จ แบ่งปันกับผู้อื่น และหลีกเลี่ยงการเสียเวลาค้นคว้าเรื่องเดียวกันอีกครั้งในอีกหลายสัปดาห์ต่อมานอกจากนี้ คุณยังช่วยสนับสนุนชุมชน Linux โดยการแบ่งปันบันทึกของคุณในฟอรัมหรือวิกิอีกด้วย

สุดท้ายนี้ โปรดจำกฎแห่งความเรียบง่ายไว้ ยิ่งระบบซับซ้อนมากเท่าไหร่ มีบริการ โปรแกรมเบื้องหลัง และชั้นของนามธรรมอยู่ทุกหนทุกแห่ง โอกาสที่จะเกิดข้อผิดพลาดก็ยิ่งมากขึ้นเท่านั้น เมื่อใดก็ตามที่เป็นไปได้ให้รักษาระบบของคุณให้เรียบง่ายและสะอาดที่สุดเท่าที่จะทำได้ : ลดบริการที่ไม่จำเป็น ลดซอฟต์แวร์ที่ซ้ำซ้อน และลดชั้นที่ซับซ้อน การทำเช่นนี้จะช่วยลดพื้นที่ที่ปัญหาอาจเกิดขึ้นและทำให้การวินิจฉัยง่ายขึ้นมาก

เตรียมระบบให้พร้อมก่อนเริ่มดำเนินการใดๆ: การสำรองข้อมูลและการอัปเดต

ก่อนที่คุณจะเริ่มแก้ไขการตั้งค่า ซ่อมแซมระบบไฟล์ หรืออัปเดตเคอร์เนล คุณควรตรวจสอบให้แน่ใจว่าหากเกิดข้อผิดพลาด คุณจะสามารถกู้คืนข้อมูลของคุณได้ การสำรองข้อมูลใน Linux เปรียบเสมือนตาข่ายนิรภัยของคุณโดยเฉพาะอย่างยิ่งเมื่อคุณกำลังจะทำงานกับพาร์ติชั่น ดิสก์ หรือบริการที่สำคัญ

วิธีที่ยืดหยุ่นมากอีกวิธีหนึ่งคือการใช้rsyncสำหรับการสำรองข้อมูลแบบเพิ่มทีละส่วน โดยทั่วไปจะใช้ร่วมกับตัวเลือกต่างๆ เช่น-a (โหมดไฟล์ รักษาการอนุญาต เจ้าของ และวันที่) -v (เอาต์พุตแนวตั้ง) และพารามิเตอร์ความคืบหน้าเพื่อติดตามความคืบหน้าของการสำรองข้อมูล สิ่งสำคัญคือต้องมีไดเร็กทอรีปลายทางที่เข้าถึงได้และมีพื้นที่เพียงพอ โดยควรอยู่บนไดรฟ์ภายนอกหรือพาร์ติชันที่แยกต่างหากจากระบบ

หากคุณต้องการรวมทุกอย่างไว้ในไฟล์เดียว คุณสามารถใช้คำสั่งtarโดยใช้พารามิเตอร์ต่างๆ เช่น-cเพื่อสร้างไฟล์เก็บถาวร, -zเพื่อบีบอัดด้วย gzip, -vเพื่อดูความคืบหน้า และ-fเพื่อระบุชื่อไฟล์ที่ได้ หลังจากนั้น ควรตรวจสอบความถูกต้องของไฟล์สำรองโดยการแสดงรายการเนื้อหาด้วยคำสั่ง tar เอง เพื่อให้แน่ใจว่าไฟล์สำรองไม่เสียหาย

สำหรับปลายทางของการสำรองข้อมูล สิ่งสำคัญคือการสำรองข้อมูลไม่ควรอยู่บนดิสก์เดียวกันกับระบบที่คุณต้องการปกป้องไดรฟ์ USB ภายนอก พื้นที่จัดเก็บข้อมูลบนคลาวด์ผ่านเครื่องมืออย่าง rclone หรือพาร์ติชั่นแยกต่างหากล้วนเป็นตัวเลือกที่เหมาะสม แนวคิดก็คือ หากดิสก์หลักของคุณเสียหายหรือระบบใช้งานไม่ได้ คุณก็ยังมีสิ่งที่สามารถกู้คืนได้

อีกขั้นตอนเบื้องต้นที่แนะนำอย่างยิ่งคือการอัปเดตระบบปัญหาหลายอย่างจะหายไปได้ง่ายๆ เพียงแค่ติดตั้งแพ็กเกจและเคอร์เนลเวอร์ชันที่ถูกต้อง ใน Debian/Ubuntu วิธีปฏิบัติทั่วไปคือการเรียกใช้คำสั่งอัปเดตรายการแพ็กเกจ ตามด้วยการอัปเดตแพ็กเกจที่ติดตั้งไว้ และตรวจสอบผลลัพธ์เพื่อหาข้อผิดพลาด ใน Fedora และระบบปฏิบัติการที่พัฒนาต่อยอดจาก Fedora คำสั่งอัปเดตแพ็กเกจก็ทำหน้าที่คล้ายกัน และเช่นเดียวกันกับคำสั่ง ` pacman -Syu`ใน Arch Linux ซึ่งการรักษาระบบให้ทันสมัยอยู่เสมอนั้นมีความสำคัญเป็นพิเศษเนื่องจากรูปแบบการปล่อยเวอร์ชันแบบต่อเนื่อง (rolling release)

การตรวจสอบฮาร์ดแวร์ขั้นพื้นฐาน: CPU, RAM, ดิสก์ และเซ็นเซอร์

เมื่อระบบทำงานช้ามาก ค้างแบบสุ่ม หรือรีสตาร์ทโดยไม่มีสาเหตุชัดเจน อย่าเพิ่งคิดว่าเป็นความผิดของซอฟต์แวร์ทันที บ่อยครั้ง ต้นตอของปัญหาอาจอยู่ที่ฮาร์ดแวร์ที่เสื่อมสภาพ อุณหภูมิสูงเกินไป หรือโมดูลหน่วยความจำที่ชำรุด

เพื่อให้ได้ภาพรวมของฮาร์ดแวร์ คุณสามารถใช้คำสั่งต่างๆ เช่น`lshw` (ข้อมูลอุปกรณ์โดยละเอียด), `lsblk` (รายการดิสก์และพาร์ติชั่น) หรือยูทิลิตี้เฉพาะ เช่น`dmidecode`ซึ่งดึงข้อมูลจาก BIOS/UEFI ตัวอย่างเช่น ` dmidecode -t memory`จะให้ข้อมูลเกี่ยวกับโมดูล RAM ที่ติดตั้ง (ประเภท DDR ความจุ ฯลฯ) ในขณะที่ ` dmidecode -t 16`จะแสดงความจุหน่วยความจำสูงสุดที่เมนบอร์ดรองรับสำหรับข้อมูลเพิ่มเติมเกี่ยวกับการจัดการหน่วยความจำ โปรดดูที่ การจัดการหน่วยความจำใน Linux

หากคุณต้องการดูภาพรวมอย่างรวดเร็วของส่วนประกอบหน่วยความจำ คำสั่ง`lshw -short -C memory`จะให้ข้อมูลสรุปที่กระชับ และคำสั่ง`dmidecode --type memory | grep -E "Speed|Configured Clock Speed"`จะช่วยให้คุณเปรียบเทียบความเร็วที่ระบุของโมดูลกับความเร็วที่กำหนดค่าโดยชิปเซ็ต นี่เป็นวิธีที่ดีในการค้นพบ ตัวอย่างเช่น โมดูลที่รองรับ 3200 MT/s ทำงานที่ 2400 MT/s เนื่องจากใช้ช่องสัญญาณร่วมกับโมดูลที่ช้ากว่า

การตรวจสอบอุณหภูมิเป็นอีกแง่มุมที่สำคัญมาก ด้วย แพ็กเกจ lm-sensorsคุณสามารถอ่านค่าอุณหภูมิและแรงดันไฟฟ้าจาก CPU และเซ็นเซอร์อื่นๆ บนเมนบอร์ดได้ หลังจากติดตั้งแล้ว แนะนำให้เรียกใช้คำสั่ง `sudo sensors-detect`เพื่อตรวจจับและเปิดใช้งานเซ็นเซอร์ทั้งหมดที่มีอยู่ จากนั้นใช้คำสั่งเช่น`watch -n 2 sensors`เพื่อตรวจสอบแบบเรียลไทม์ว่า CPU หรือ RAM ร้อนเกินไปหรือไม่

สำหรับฮาร์ดไดรฟ์ (SATA HDD หรือ SSD) โปรแกรมอย่างhddtempช่วยให้คุณอ่านอุณหภูมิของอุปกรณ์ได้ ในขณะที่ แพ็กเกจ psensorหรือเครื่องมือแบบกราฟิกอย่างxsensorsจะแสดงอุณหภูมิในรูปแบบกราฟและประวัติการใช้งาน การที่ SSD ทำงานที่ขีดจำกัดของช่วงอุณหภูมิสูงสุดอยู่ตลอดเวลา แสดงให้เห็นอย่างชัดเจนว่ามีบางอย่างผิดปกติกับการระบายความร้อนหรือภาระการทำงาน

การวินิจฉัยสถานะของดิสก์และระบบไฟล์

ความล้มเหลวของดิสก์และข้อผิดพลาดของระบบไฟล์เป็นสาเหตุของปัญหามากมาย ตั้งแต่ไฟล์เสียหายไปจนถึงระบบที่ไม่สามารถบูตได้ Linux มีเครื่องมือหลายอย่างที่ใช้ตรวจสอบสถานะทางกายภาพของดิสก์และความสมบูรณ์เชิงตรรกะของระบบไฟล์

เริ่มต้นด้วยการแสดงรายการอุปกรณ์จัดเก็บข้อมูลที่เชื่อมต่อโดยใช้คำสั่งเช่น`lsblk -fm`หรือ`fdisk -l`โดยสามารถกรองไดรฟ์เสมือนแบบ loopback ออกได้หากต้องการ วิธีนี้ช่วยให้คุณตรวจสอบได้ว่าระบบรู้จักดิสก์และพาร์ติชันใดบ้าง ระบบไฟล์ และจุดเชื่อมต่อ (mount point) ของดิสก์และพาร์ติชันเหล่านั้น

ชุดเครื่องมือ smartmontools (พร้อมคำสั่ง smartctl) เป็นสิ่งจำเป็นสำหรับการใช้ประโยชน์จากเทคโนโลยี SMART ที่ติดตั้งอยู่ในฮาร์ดไดรฟ์สมัยใหม่ ขั้นแรก คุณต้องตรวจสอบให้แน่ใจว่าได้เปิดใช้งาน SMART บนไดรฟ์แล้วโดยใช้คำสั่งเปิดใช้งานที่ถูกต้อง จากนั้น คุณสามารถตรวจสอบคุณสมบัติต่างๆ เช่นPower_On_Hoursเพื่อดูว่าไดรฟ์ทำงานมานานกี่ชั่วโมง หรือเรียกใช้smartctl -Hเพื่อประเมินสถานะของอุปกรณ์อย่างรวดเร็ว

นอกจากการตรวจสอบทันทีแล้ว smartctl ยังช่วยให้คุณเรียกใช้การทดสอบวินิจฉัยอัตโนมัติได้อีกด้วย : การทดสอบแบบสั้นสำหรับการตรวจสอบอย่างรวดเร็ว และการทดสอบแบบยาวหรือแบบขยายสำหรับการตรวจสอบที่ละเอียดถี่ถ้วนยิ่งขึ้น หลังจากนั้น คุณสามารถตรวจสอบผลลัพธ์และคุณลักษณะโดยละเอียดด้วยคำสั่งที่แสดงข้อมูลดิสก์ทั้งหมด หากคุณตรวจพบเซกเตอร์ที่ถูกจัดสรรใหม่ ข้อผิดพลาดที่เพิ่มขึ้น หรือสถานะ "ก่อนล้มเหลว" ก็ถึงเวลาที่คุณควรพิจารณาเปลี่ยนดิสก์นั้นแล้ว

เครื่องมือสำคัญอีกอย่างคือfsckซึ่งใช้ตรวจสอบและแก้ไขข้อผิดพลาดเชิงตรรกะในระบบไฟล์ การเรียกใช้ fsck บนพาร์ติชั่นมีความเสี่ยงหากพาร์ติชั่นนั้นมีข้อมูลสำคัญ ดังนั้นการสำรองข้อมูล จึงเป็นสิ่งจำเป็น คุณสามารถใช้ร่วมกับbadblocksเพื่อค้นหาและทำเครื่องหมายเซกเตอร์เสีย เพื่อให้ระบบหลีกเลี่ยงการใช้งานเซกเตอร์เหล่านั้นในอนาคต อย่างไรก็ตาม หากพบ bad block จำนวนมาก ควรเปลี่ยนฮาร์ดดิสก์ใหม่

ในการวินิจฉัยปัญหาพื้นที่จัดเก็บข้อมูล คำสั่ง`df -h`จะแสดงการใช้งานพาร์ติชันในหน่วยกิกะไบต์ ในขณะที่`df -i`จะแสดงเปอร์เซ็นต์ของ inode ที่ถูกใช้งาน เป็นไปได้ที่จะมีพื้นที่ว่างหลายกิกะไบต์ แต่ inode ถูกใช้งานไป 100% ซึ่งจะทำให้เกิดข้อผิดพลาดเมื่อสร้างไฟล์ใหม่ แม้ว่าจะมีพื้นที่ว่างอยู่ก็ตามนี่เป็นสถานการณ์ทั่วไปบนเซิร์ฟเวอร์ที่จัดการไฟล์ขนาดเล็กจำนวนหลายล้านไฟล์

การวิเคราะห์หน่วยความจำ: ข้อผิดพลาด ECC การทดสอบ และความเสถียร

หน่วยความจำ RAM ที่ชำรุดอาจทำให้เกิดอาการต่างๆ มากมาย ตั้งแต่การหยุดทำงานแบบสุ่มไปจนถึงการเสียหายของข้อมูลโดยไม่แสดงอาการ หากระบบของคุณใช้หน่วยความจำ ECC ฮาร์ดแวร์เองสามารถแก้ไขข้อผิดพลาดบางอย่างได้ แต่ไม่ได้หมายความว่าคุณจะลืมปัญหาไปได้: การแก้ไขข้อผิดพลาดเป็นสัญญาณบ่งบอกว่าโมดูลเริ่มมีปัญหาแล้ว

ระบบลินุกซ์สามารถแสดงข้อมูลนี้ได้ผ่านทาง ระบบย่อย EDACหากคุณติดตั้งโมดูลที่เกี่ยวข้อง คุณจะเห็นข้อความในบันทึกระบบที่แยกแยะระหว่างข้อผิดพลาดที่แก้ไขแล้ว (CE) และข้อผิดพลาดที่ไม่สามารถแก้ไขได้ (UE) ข้อผิดพลาดแบบแรกบ่งชี้ว่าฮาร์ดแวร์สามารถซ่อมแซมบิตที่เสียหายได้แล้ว ในขณะที่ข้อผิดพลาดแบบหลังมักจะทำให้เคอร์เนลหยุดทำงานทันทีเพื่อป้องกันไม่ให้ข้อมูลที่เสียหายถูกเขียนลงดิสก์

วิธีง่ายๆ ในการตรวจสอบว่าเคอร์เนลได้บันทึกข้อผิดพลาด EDAC หรือไม่ คือการตรวจสอบผลลัพธ์ของคำสั่ง`dmesg | grep EDAC`หากคุณพบข้อผิดพลาด EDAC ซ้ำๆ ในโมดูลเดียวกัน นั่นจะบอกคุณได้อย่างชัดเจนว่าคุณควรเปลี่ยนหน่วยความจำส่วนใดก่อนที่ข้อผิดพลาดเหล่านั้นจะแก้ไขไม่ได้ สำหรับเทคนิคและเครื่องมือขั้นสูง โปรดดูคู่มือนี้เกี่ยวกับการดีบักหน่วยความจำใน Linux

สำหรับการทดสอบที่ละเอียดถี่ถ้วนยิ่งขึ้น นิยมใช้โปรแกรมภายนอก เช่นmemtest86ซึ่งทำงานจากไดรฟ์ภายนอก (USB หรืออุปกรณ์ที่คล้ายกัน) เครื่องมือเหล่านี้จะทำการอ่าน/เขียนข้อมูลใน RAM อย่างเข้มข้นเพื่อตรวจจับข้อผิดพลาดที่อาจไม่ถูกตรวจพบเป็นเวลาหลายเดือนภายใต้การใช้งานปกติแนะนำให้ทำการทดสอบหลายๆ รอบเพื่อให้แน่ใจได้ในระดับหนึ่ง

นอกจากนี้ คุณยังสามารถทดสอบระบบด้วยการใช้โปรแกรมต่างๆ เช่น โปรแกรมทดสอบความเครียด (stress test ) ซึ่งจะโหลด CPU, I/O และหน่วยความจำในช่วงเวลาที่กำหนด แล้วสังเกตว่าเกิดการขัดข้อง ข้อผิดพลาดของเคอร์เนล หรืออาการผิดปกติใดๆ หรือไม่ หากระบบล้มเหลวซ้ำๆ ภายใต้ภาระงานหนัก แสดงว่าอาจมีปัญหาเกี่ยวกับฮาร์ดแวร์ (อุณหภูมิ แหล่งจ่ายไฟ RAM) หรือความไม่เสถียรในเคอร์เนลหรือไดรเวอร์

การตรวจสอบระบบ: CPU, กระบวนการทำงาน, อินพุต/เอาต์พุต และ GPU

เพื่อให้เข้าใจว่าเกิดอะไรขึ้นกับเครื่องของคุณในแต่ละช่วงเวลา คุณจำเป็นต้องมีเครื่องมือตรวจสอบที่ดี ลินุกซ์มีโปรแกรมยูทิลิตี้หลายตัวที่ช่วยให้คุณเห็นได้อย่างรวดเร็วว่ากระบวนการใดใช้ CPU, หน่วยความจำ, การอ่าน/เขียนดิสก์ หรือ GPU มากที่สุด

คำสั่งคลาสสิกอย่าง`top`หรือเวอร์ชันที่ใช้งานง่ายกว่าอย่าง`htop`จะแสดงกระบวนการที่กำลังทำงานอยู่ การใช้งาน CPU การใช้งานหน่วยความจำ และภาระงานเฉลี่ย สำหรับการตรวจสอบกิจกรรมดิสก์ต่อกระบวนการโดยเฉพาะ`iotop`มีประโยชน์มาก ในขณะที่`nmon`ให้ภาพรวมที่ครอบคลุมของระบบย่อยหลายระบบ (CPU หน่วยความจำ เครือข่าย ดิสก์) ในอินเทอร์เฟซข้อความที่สมบูรณ์มาก

ในด้านกราฟิก การใช้งาน GPU อาจกลายเป็นคอขวดในระบบที่ใช้งานแอปพลิเคชันที่ใช้กราฟิกสูงหรือประมวลผลแบบเร่งความเร็ว สำหรับการ์ด Intel แพ็กเกจ intel-gpu-toolsมีคำสั่งต่างๆ เช่นintel_gpu_topซึ่งแสดงภาระการทำงานของ GPU คิวการประมวลผล และการใช้งานหน่วยความจำแบบเรียลไทม์

หากคุณใช้งานการ์ดกราฟิก NVIDIA คุณสามารถใช้เครื่องมือ Python เช่นgpustatหรือโปรแกรมตรวจสอบทั่วไปอย่างGlances (โดยเปิดใช้งานการสนับสนุน GPU) ซึ่งจะแสดงการใช้หน่วยความจำวิดีโอ การใช้งาน GPU และกระบวนการที่ใช้งานอยู่ สำหรับ GPU AMD Radeon นั้น โปรแกรมอย่างradeontopก็มีฟังก์ชันที่คล้ายกัน โดยแสดงแถบการใช้งานสำหรับหน่วยภายในต่างๆ ของชิป

หากคุณสงสัยว่าไดรเวอร์การ์ดจอเป็นสาเหตุของปัญหา (เช่น ข้อผิดพลาดในการเข้าสู่สภาพแวดล้อมกราฟิก การหยุดทำงานขณะใช้คอมโพสิเตอร์ ฯลฯ) ขอแนะนำให้ตรวจสอบฮาร์ดแวร์วิดีโอที่ติดตั้งไว้ด้วยคำสั่งต่างๆ เช่น`lspci -vnn | grep VGA -A 12` , `lshw -C display`หรือ`inxi -G`และตรวจสอบว่าคุณกำลังใช้ไดรเวอร์แบบโอเพนซอร์ส ไดรเวอร์กรรมสิทธิ์ หรือไดรเวอร์ที่ล้าสมัย ในระบบปฏิบัติการอย่าง Ubuntu คุณสามารถเปิดใช้งานที่เก็บไดรเวอร์กราฟิกเฉพาะ (เช่น สำหรับ Radeon) และอัปเดตเป็นเวอร์ชันใหม่กว่าที่เหมาะสมกับ GPU ของคุณได้

การวินิจฉัยเครือข่าย: การ์ดเครือข่าย (NIC), การสูญหายของแพ็กเก็ต และการกำหนดค่า

ปัญหาเครือข่ายอาจมีตั้งแต่ "ฉันไม่มีการเชื่อมต่อ" ไปจนถึง "ทุกอย่างช้าหมด ยกเว้นบริการนี้" เพื่อหลีกเลี่ยงความสับสน ขั้นตอนแรกคือการตรวจสอบว่าปัญหาอยู่ที่เครื่องของคุณ เครือข่ายภายใน หรืออินเทอร์เน็ต Linux มีเครื่องมือหลายระดับสำหรับการทดสอบการเชื่อมต่อ การดูสถิติ NIC และการตรวจจับการสูญหายของแพ็กเก็ต และ คู่มือการวินิจฉัยเครือข่าย IP และ DNSนี้จะเจาะลึกถึงการตรวจสอบและวิธีแก้ไข

คำสั่งพื้นฐานอย่างpingช่วยให้คุณตรวจสอบว่าคุณสามารถเข้าถึงโฮสต์ที่ระบุได้หรือไม่ (เช่น เราเตอร์ของคุณหรือโดเมนภายนอก) ในขณะที่traceroute จะแสดงเส้นทางที่แพ็กเก็ตใช้ไปยังปลายทาง ซึ่งมีประโยชน์สำหรับการดูว่าแพ็กเก็ตสูญหายที่จุดใด ส่วนคำสั่ง ss นั้น เป็นคำสั่งที่ทันสมัยกว่า netstat สำหรับการดูว่าพอร์ตใดเปิดอยู่และกระบวนการใดกำลังใช้งานอยู่โดยมีตัวเลือกในการแสดงรายการการเชื่อมต่อ TCP/UDP ที่ใช้งานอยู่

เมื่อคุณสงสัยว่าปัญหาอยู่ที่การ์ดเครือข่ายเอง เครื่องมืออย่างethtoolจะมีประโยชน์อย่างมาก ด้วยคำสั่งที่แสดงสถิติโดยละเอียด คุณสามารถตรวจสอบข้อผิดพลาด RX/TX แพ็กเก็ตที่สูญหาย ปัญหาบัฟเฟอร์ หรือ FIFO ล้นได้แบบเรียลไทม์ โดยใช้ร่วมกับคำสั่ง`watch`เพื่อรีเฟรชผลลัพธ์อย่างต่อเนื่องและตรวจจับรูปแบบการสูญเสียแพ็กเก็ต

อีกวิธีหนึ่งที่เห็นได้ชัดคือการตรวจสอบตัวนับข้อผิดพลาดของอินเทอร์เฟซด้วยคำ สั่ง `netstat -ni` (หรือเครื่องมือที่ทันสมัยกว่าที่เทียบเท่า) คุณจะเห็นคอลัมน์ของแพ็กเก็ตที่รับและส่งสำเร็จ รวมถึงแพ็กเก็ตที่ถูกทิ้ง หากเปอร์เซ็นต์ของแพ็กเก็ตที่สูญหาย (RX-DRP/RX-OK หรือ TX-DRP/TX-OK คูณด้วย 100) เกินกว่าตัวเลขเล็กน้อย เช่น 0,2% ผลกระทบต่อประสิทธิภาพการเชื่อมต่ออาจรุนแรงมากทำให้ความเร็วลดลงครึ่งหนึ่งหรือแย่กว่านั้น

ไม่ใช่เรื่องแปลกที่จะพบว่าการ์ดเครือข่ายที่เพิ่งซื้อมาใหม่นั้น มีข้อบกพร่องจากโรงงานหรือความบกพร่องในการออกแบบ ทำให้มีอัตราข้อผิดพลาดที่ไม่สามารถยอมรับได้ การเปลี่ยนไปใช้รุ่นอื่นและทำการทดสอบซ้ำมักจะเป็นการยืนยันที่แน่ชัดว่าปัญหาอยู่ที่การ์ดเครือข่าย นั่นเป็นเหตุผลว่าทำไมการมีข้อมูลที่เป็นกลางเกี่ยวกับการสูญเสียสัญญาณและข้อผิดพลาด จึงมีความสำคัญมาก ก่อนที่จะไปโทษผู้ให้บริการอินเทอร์เน็ตหรือเราเตอร์

นอกจากนี้ ควรตรวจสอบสถานะของอุปกรณ์วิทยุ เช่น Wi-Fi หรือ Bluetooth ด้วยคำสั่งต่างๆ เช่น`rfkill`ซึ่งจะระบุว่าอุปกรณ์เหล่านั้นถูกบล็อกโดยซอฟต์แวร์หรือฮาร์ดแวร์หรือไม่ สำหรับข้อมูลโดยละเอียดเกี่ยวกับผู้ผลิต รุ่น และความสามารถของอินเทอร์เฟซเครือข่าย คำสั่ง`lshw -C network`หรือ`inxi -Nx`จะให้ข้อมูล ในขณะที่`ethtool interface_name | grep -i speed`จะบอกความเร็วในการเชื่อมต่อของการ์ด (10/100/1000 Mbps เป็นต้น)

บันทึกระบบและระดับความรุนแรงใน Linux

ไฟล์บันทึกระบบเปรียบเสมือนสมุดบันทึกประวัติของคุณ: ทุกสิ่งที่เกิดขึ้น (หรือเกือบทุกอย่าง) จะถูกบันทึกไว้ที่นั่น การเข้าใจวิธีการทำงานและวิธีการกรองข้อมูลจะช่วยประหยัดเวลาได้มาก ในระบบสมัยใหม่ที่ใช้ systemd นั้นjournalctlเป็นเครื่องมือหลักในการสอบถามข้อมูลจากไฟล์บันทึกแบบไบนารี ในขณะที่ในระบบแบบดั้งเดิม คุณจะยังคงพบไฟล์ข้อความอยู่ใน /var/ log

ไฟล์บันทึกข้อมูลที่พบบ่อยที่สุด ได้แก่/var/log/syslogและ/var/log/messagesซึ่งรวบรวมเหตุการณ์ทั่วไปของระบบ และ/var/log/auth.logสำหรับเรื่องที่เกี่ยวข้องกับการตรวจสอบสิทธิ์ คุณสามารถใช้เครื่องมืออย่างlessและgrepเพื่อกรองข้อมูลโดยใช้คำหลัก (error, fail, timeout เป็นต้น) เมื่อทำงานกับไฟล์บันทึกของ systemd คุณสามารถดูข้อความตั้งแต่การบูตครั้งล่าสุดโดยใช้ตัวเลือกเฉพาะ ตรวจสอบบันทึกจากบริการเฉพาะ หรือกรองตามช่วงเวลา (เช่น จากสองชั่วโมงที่ผ่านมา)

คำสั่ง`dmesg`แสดงบัฟเฟอร์ข้อความของเคอร์เนล ซึ่งมีประโยชน์มากในการตรวจจับปัญหาฮาร์ดแวร์ เช่น การยกเลิกการโหลดไดรเวอร์ ข้อผิดพลาดของบัส PCI คำเตือนเกี่ยวกับหน่วยความจำ และอื่นๆ พารามิเตอร์ `-T`จะแสดงเวลาที่อ่านได้ และการกรองตามระดับความรุนแรงจะช่วยให้คุณมุ่งเน้นไปที่ปัญหาที่สำคัญที่สุด นอกจากนี้ ` dmesg -w`ยังช่วยให้คุณเห็นข้อความที่กำลังถูกสร้างขึ้นแบบเรียลไทม์ ซึ่งมีประโยชน์มากเมื่อเชื่อมต่อ/ตัดการเชื่อมต่ออุปกรณ์ หรือเมื่อคุณสงสัยว่ามีข้อผิดพลาดที่นำไปสู่เคอร์เนลแพนิค

ข้อความต่างๆ จะถูกจัดหมวดหมู่ตามระดับความรุนแรง เพื่อช่วยให้คุณจัดลำดับความสำคัญ ระดับต่างๆ มีตั้งแต่0 (ฉุกเฉิน)ซึ่งบ่งชี้ถึงสถานการณ์ที่ร้ายแรงมาก อาจทำให้ระบบล่มหรือเกิดความไม่เสถียรอย่างรุนแรง ไปจนถึง1 (การแจ้งเตือน) 2 (วิกฤต)และ3 (ข้อผิดพลาดที่ไม่วิกฤต)รวมถึงคำเตือน (ระดับ 4) การแจ้งเตือนที่เห็นได้ชัด (ระดับ 5) ข้อความให้ข้อมูล (ระดับ 6) และข้อความสำหรับการแก้ไขข้อบกพร่อง (ระดับ 7) การทำความเข้าใจระดับเหล่านี้จะช่วยให้คุณกรองข้อมูลที่ไม่จำเป็นออกไปและมุ่งเน้นไปที่สิ่งที่สำคัญอย่างแท้จริงเมื่อบันทึกมีรายละเอียดมากเกินไป

การใช้grep เพื่อแยกบรรทัด จะช่วยให้คุณสามารถดึงเฉพาะบรรทัดจากระดับที่กำหนดในบันทึกข้อความธรรมดาได้ ในขณะที่เครื่องมือ systemd มีพารามิเตอร์เฉพาะสำหรับการกรองตามลำดับความสำคัญในบันทึก การใช้ตัวกรองเหล่านี้อย่างเชี่ยวชาญจะช่วยให้คุณค้นหาข้อความที่ให้เบาะแสที่คุณต้องการได้ในเวลาเพียงไม่กี่วินาที โดยไม่หลงทางในบรรทัดนับพัน

ประเภทของข้อผิดพลาดใน Linux: เคอร์เนล, ระบบไฟล์, เครือข่าย, แอปพลิเคชัน และฮาร์ดแวร์

เพื่อให้วินิจฉัยได้อย่างแม่นยำ สิ่งสำคัญคือต้องรู้ว่าคุณกำลังเห็นข้อผิดพลาดประเภทใด ปัญหาของ Linux สามารถแบ่งออกเป็นกลุ่มใหญ่ๆ ได้แก่ข้อผิดพลาดของเคอร์เนล ระบบไฟล์ เครือข่าย แอปพลิเคชัน และฮาร์ดแวร์แม้ว่าข้อผิดพลาดเหล่านี้มักจะเกี่ยวข้องกันก็ตาม

ข้อผิดพลาดของเคอร์เนลมีตั้งแต่คำเตือนธรรมดาไปจนถึงสถานการณ์วิกฤต เช่น เคอร์เนลอู๊ปส์และเคอร์เนลแพนิคเคอร์เนลอู๊ปส์คือความล้มเหลวร้ายแรงที่เคอร์เนลยุติกระบวนการที่ก่อให้เกิดข้อผิดพลาด แต่พยายามที่จะทำงานต่อไป อาจเป็นอาการของหน่วยความจำไม่เพียงพอ ไดรเวอร์ผิดพลาด ความไม่เข้ากัน ข้อมูลเสียหาย หรือบั๊ก หากปัญหานี้ส่งผลกระทบต่อระบบย่อยที่สำคัญ อู๊ปส์นั้นอาจลุกลามไปเป็นเคอร์เนลแพนิคซึ่งเทียบเท่ากับหน้าจอสีน้ำเงินแห่งความตาย (Blue Screen of Death) ในระบบอื่นๆ

Kernel panicคือ "hard panic": ระบบจะหยุดทำงานเกือบทั้งหมด ข้อความแสดงข้อผิดพลาด (มักจะเข้าใจยาก) จะปรากฏบนหน้าจอ และขึ้นอยู่กับการตั้งค่า อาจทำให้ระบบรีบูตอัตโนมัติ สาเหตุโดยทั่วไปเกิดจาก การเข้าถึงหน่วยความจำที่ไม่ถูกต้อง ไดรเวอร์ที่จำเป็นล้มเหลว พาร์ติชั่นรูทเข้าถึงไม่ได้ ปัญหา RAM ร้ายแรง ความล้มเหลวของกระบวนการ init ข้อผิดพลาดใน initramfs เคอร์เนลที่ติดตั้งไม่ถูกต้องหรือไม่รองรับ หรือแพตช์ที่ไม่เสถียร เคอร์เนลเองอาจทำการดัมพ์หน่วยความจำ (Kernel Crash Dump) เพื่อการวิเคราะห์ในภายหลัง

ข้อผิดพลาดของระบบไฟล์แสดงออกมาในรูปแบบของการไม่สามารถเมานต์พาร์ติชัน ข้อความแจ้งความเสียหาย ไฟล์อ่านไม่ได้ หรือข้อมูลสูญหาย การปิดเครื่องกะทันหัน ไฟฟ้าดับ เซกเตอร์เสีย หรือข้อบกพร่องในไดรเวอร์ระบบไฟล์อาจเป็นสาเหตุ ในกรณีเช่นนี้ คำสั่ง fsck, smartctl และการสำรองข้อมูลใดๆ ที่คุณทำไว้ก่อนทำการเปลี่ยนแปลงจะมีประโยชน์อย่างมาก

ในด้านเครือข่ายอาการที่เกิดขึ้นอาจมีตั้งแต่การตัดการเชื่อมต่อเป็นระยะ ความเร็วในการถ่ายโอนข้อมูลช้า ความหน่วงสูง หรือไม่สามารถเชื่อมต่อได้เลย สาเหตุอาจเกิดจากการตั้งค่าที่ไม่ถูกต้อง (IP, การกำหนดเส้นทาง, DNS, ไฟร์วอลล์) ไดรเวอร์ NIC ที่ผิดพลาด การรบกวนจาก Wi-Fi ข้อผิดพลาดของสายเคเบิล หรือความแออัดของเครือข่ายในบางจุด เครื่องมือวินิจฉัยเครือข่ายที่เราได้กล่าวถึงจะช่วยแยกแยะชั้นที่เกิดความล้มเหลวได้

ข้อผิดพลาดของแอปพลิเคชันมีตั้งแต่โปรแกรมปิดตัวลงอย่างไม่คาดคิด เริ่มต้นทำงานไม่ได้ แสดงข้อความว่าขาดไลบรารี หรือไม่ตอบสนอง สาเหตุส่วนใหญ่มักเกิดจากความสัมพันธ์ของไลบรารีที่เสียหาย เวอร์ชันไลบรารีที่ไม่เข้ากัน ข้อผิดพลาดในโค้ด สคริปต์ที่เขียนไม่ดี หรือสภาวะการแข่งขัน (race condition) เครื่องมืออย่างstrace (สำหรับติดตามการเรียกใช้ระบบ) หรือlsof (สำหรับดูไฟล์ที่เปิดอยู่และการเชื่อมต่อเครือข่ายของกระบวนการ) สามารถให้ข้อมูลที่เป็นประโยชน์ได้

สุดท้ายนี้ข้อผิดพลาดของฮาร์ดแวร์มีตั้งแต่ขั้วต่อหลวม สายเคเบิลเสียหาย พอร์ตชำรุด หรือสิ่งสกปรกสะสม ไปจนถึงความล้มเหลวทางอิเล็กทรอนิกส์ที่เกิดจากความร้อนสูงเกินไป ความชื้น หรืออายุการใช้งาน นอกจากนี้ยังรวมถึงความขัดแย้งระหว่างส่วนประกอบต่างๆ (IRQ, DMA เป็นต้น) และปัญหาด้านพลังงานหรือประสิทธิภาพ (การลดความเร็วเนื่องจากอุณหภูมิสูง หน่วยความจำ RAM ไม่เพียงพอ ซีพียูที่มีกำลังไฟต่ำเกินไป) อีกครั้ง การใช้ประสาทสัมผัสของคุณควบคู่ไปกับเครื่องมือตรวจสอบและการทดสอบความเครียดจะช่วยให้คุณระบุได้ว่าส่วนประกอบทางกายภาพใดกำลังทำงานผิดปกติ

ขั้นตอนปฏิบัติเพื่อกระบวนการวินิจฉัยที่เป็นระเบียบ

แม้ว่าปัญหาแต่ละอย่างจะไม่เหมือนกัน แต่คุณสามารถทำตามโครงร่างขั้นตอนพื้นฐานที่สามารถปรับใช้ได้กับเกือบทุกสถานการณ์ ขั้นตอนแรก ซึ่งได้กล่าวไปแล้ว คือการกำหนดปัญหาให้ชัดเจน : อะไรล้มเหลว ตั้งแต่เมื่อไหร่ ภายใต้เงื่อนไขใด และอะไรเปลี่ยนแปลงไปก่อนหน้านี้ (การติดตั้งซอฟต์แวร์ การอัปเดต การเปลี่ยนฮาร์ดแวร์ ฯลฯ) หากคุณสามารถจำลองความล้มเหลวได้อย่างน่าเชื่อถือ ก็ยิ่งดี

ขั้นตอนที่สองคือการตรวจสอบสถานะระบบและบันทึกต่างๆ: ใช้journalctlและdmesgเพื่อค้นหาข้อความที่เกี่ยวข้อง (โดยเฉพาะระดับข้อผิดพลาด วิกฤต หรือการแจ้งเตือน) ตรวจสอบโหลดด้วยtop/htop ตรวจสอบ หน่วยความจำที่ว่างด้วยคำสั่ง memory usage ตรวจสอบการใช้งานดิสก์ด้วย df และตรวจสอบบันทึกเฉพาะของบริการหรือแอปพลิเคชันที่ได้รับผลกระทบ การค้นหาคำหลักเช่น error, fail, panic หรือ timeoutมักจะให้เบาะแสอย่างรวดเร็ว

ประการที่สาม ขอแนะนำให้ตรวจสอบจากแหล่งข้อมูลภายนอก การค้นหาข้อความแสดงข้อผิดพลาดอย่างเป็นระบบ (เช่น "Ubuntu 20.04 wifi disconnects") มักจะนำคุณไปสู่กระทู้ในฟอรัม วิกิสำหรับระบบปฏิบัติการของคุณ หรือรายงานข้อบกพร่องที่ผู้ใช้รายอื่นเคยประสบปัญหาเดียวกันมาก่อน อย่าลืมศึกษาคู่มือการใช้งาน (man pages) เอกสารอย่างเป็นทางการ วิธีการใช้งาน และวิกิคำแนะนำที่ว่า "RTFM" ยังคงเป็นคำแนะนำที่ดีที่สุดเสมอ

เมื่อคุณมีสมมติฐานหลายข้อแล้ว คุณก็เข้าสู่ขั้นตอนการทดสอบ: การรีสตาร์ทบริการเฉพาะ การแก้ไขไฟล์การกำหนดค่าชั่วคราว (พร้อมสำรองข้อมูล) การปิดใช้งานโมดูลเคอร์เนล การบูตด้วยเคอร์เนลอื่นที่มีอยู่ในตัวจัดการการบูต การทดสอบกับอุปกรณ์ทางกายภาพอื่น ฯลฯ สิ่งสำคัญคือการเปลี่ยนแปลงที่สามารถย้อนกลับได้และควบคุมได้ทีละขั้นตอนและตรวจสอบหลังจากแต่ละขั้นตอนว่าปัญหายังคงอยู่หรือไม่

เมื่อคุณค้นพบวิธีแก้ไขที่ขจัดข้อผิดพลาดได้แล้ว ขั้นตอนสุดท้ายที่มักถูกมองข้ามมากที่สุดก็คือการตรวจสอบความเสถียรของวิธีการแก้ไขนั้นในระยะยาวและบันทึกสิ่งที่คุณทำลงไป โดยหลักการแล้ว คุณควรเริ่มต้นคอมพิวเตอร์ใหม่ (หากปัญหาเกิดขึ้นขณะเริ่มต้นระบบ) หรือปล่อยให้ระบบทำงานหนักสักพัก ตรวจสอบว่าไม่มีข้อผิดพลาดปรากฏขึ้นอีกในบันทึก และบันทึกวิธีแก้ไขลงในสมุดบันทึกทางเทคนิคของคุณเอง ประสบการณ์นี้จะช่วยให้คุณป้องกันไม่ให้ปัญหาเกิดขึ้นซ้ำอีก หรือแก้ไขปัญหาได้ในเวลาไม่กี่นาทีในครั้งต่อไป

ด้วยชุดความคิด เครื่องมือ และวิธีการทั้งหมดนี้ Linux จึงไม่ใช่กล่องดำลึกลับอีกต่อไป แต่กลายเป็นสภาพแวดล้อมที่คุณสามารถวินิจฉัยทุกอย่างได้อย่างแม่นยำ ตั้งแต่ข้อความบันทึกง่ายๆ ไปจนถึง kernel panic หรือ RAM ที่ล้มเหลวไม่ใช่เรื่องของการท่องจำคำสั่งนับพัน แต่เป็นการซึมซับวิธีการที่เป็นระบบ อาศัยเอกสารและชุมชน และไม่กลัวที่จะตรวจสอบ "เบื้องหลัง" เมื่อมีบางอย่างผิดพลาด