เซิร์ฟเวอร์ล่ม: ต้องตรวจอะไรก่อน และตามลำดับไหน

คู่มือนี้พูดถึงตัวเซิร์ฟเวอร์เอง: VPS, dedicated หรือเซิร์ฟเวอร์ cloud ที่คุณดูแล หากเว็บไซต์เดียวล้มเหลวและทุกอย่างอื่นบนเครื่องทำงานปกติ หรือเว็บไซต์ของคุณอยู่บน shared hosting ให้เริ่มจากคู่มือเว็บไซต์ล่ม: ต้องทำอย่างไรแทน ที่นี่เราดูที่ตัวเครื่อง: ตอบหรือไม่ เข้าได้ไหม และอะไรหยุด

ขั้นที่ 1: อะไรล่มกันแน่

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

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

อ่านผลรวมกัน:

• ไม่ตอบ ping ไม่มี SSH ไม่มีพอร์ตเว็บ: เครื่องปิดอยู่ ค้าง หรือเครือข่ายด้านหน้าล่ม ไปที่ขั้นที่ 2
• ตอบ ping แต่ไม่มี SSH: เครื่องทำงานอยู่ แต่ SSH ถูกบล็อก หยุด หรือเซิร์ฟเวอร์โหลดหนักเกินกว่าจะตอบ ไปที่ขั้นที่ 3
• SSH ใช้ได้ แต่เว็บไซต์ไม่ได้: เซิร์ฟเวอร์ปกติ บริการหนึ่งไม่ปกติ ไปที่ขั้นที่ 4

บางเซิร์ฟเวอร์ทิ้ง ping โดยตั้งใจ หาก ping ไม่เคยใช้ได้ ให้พึ่งการทดสอบพอร์ต

ขั้นที่ 2: ไม่มีอะไรตอบ

เปิดแผงควบคุมหรือ cloud console ของผู้ให้บริการก่อนทำอย่างอื่น สามคำถามตัดสินได้เกือบทุกกรณีในหนึ่งนาที:

1. เซิร์ฟเวอร์ทำงานอยู่ไหม อินสแตนซ์ที่หยุด บัญชีที่ถูกระงับ หรือการชำระเงินที่ล้มเหลว ดูเหมือนระบบล่มจากภายนอกทุกประการ
2. มีเหตุขัดข้องที่ทราบแล้วไหม ตรวจหน้าสถานะของผู้ให้บริการสำหรับภูมิภาคหรือดาต้าเซ็นเตอร์ของคุณ
3. console แสดงอะไร console แบบเว็บหรือ serial แสดงหน้าจอของเครื่องแม้ไม่มีเครือข่าย kernel panic, “Out of memory: Killed process” วนซ้ำ หรือการบูตที่ค้างที่การตรวจระบบไฟล์ แต่ละอย่างบอกว่าปัญหาอยู่ที่ไหน

หากเครื่องค้าง การรีบูตจาก console มักทำให้กลับมา ก่อนรีบูต ให้แคปหน้าจอ console: เมื่อรีสตาร์ทแล้ว หลักฐานก็หายไป หากบูตไม่ได้ ผู้ให้บริการส่วนใหญ่มีระบบ rescue ที่คุณเมานต์ดิสก์ อ่าน log และซ่อม /etc/fstab หรือการตั้งค่าเครือข่ายที่เสียได้

ขั้นที่ 3: ตอบ ping แต่ไม่มี SSH

เครื่องยังมีชีวิต สาเหตุจึงอยู่บนเครื่อง ใช้ console เข้าสู่ระบบ แล้วตรวจผู้ต้องสงสัยทั่วไป:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

กฎไฟร์วอลล์ที่เพิ่มอย่างรีบร้อน ที่อยู่ IP ของคุณเองที่ถูกแบนหลังใส่รหัสผ่านผิดสองสามครั้ง หรือการเปลี่ยนการตั้งค่า SSH ที่ไม่ผ่านการทดสอบ คือสาเหตุที่พบบ่อยที่สุด ปลดแบนที่อยู่ของคุณด้วย sudo fail2ban-client set sshd unbanip YOUR_IP และรัน sudo sshd -t ก่อนรีสตาร์ท SSH เสมอ หาก SSH ทำงานแต่ช้ามาก เซิร์ฟเวอร์โหลดหนักเกินไป: ไปที่ขั้นที่ 4

ขั้นที่ 4: เข้ามาแล้ว อ่านสี่ตัวเลข

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• โหลด (uptime): สูงกว่าจำนวนคอร์ CPU มาก หมายความว่าเครื่องโหลดหนักเกินไป top หรือ htop แสดงว่าโพรเซสใดเป็นต้นเหตุ
• หน่วยความจำ (free -m): ไม่มีหน่วยความจำว่างและไม่มี swap พร้อม “Killed process” ใน dmesg หมายความว่าเคอร์เนลหยุดโพรเซสเพื่อให้ยังรอดอยู่ มักเป็นฐานข้อมูลหรือ PHP
• ดิสก์ (df -h): ดิสก์เต็มเป็นสาเหตุที่พบบ่อยที่สุดของปัญหาเซิร์ฟเวอร์ ฐานข้อมูลหยุดเขียน log หยุด เซสชันล้มเหลว df -i ตรวจ inode: ดิสก์อาจ “เต็ม” ทั้งที่ว่างหลายกิกะไบต์ หากไฟล์เล็กหลายล้านไฟล์ใช้ inode จนหมด
• ข้อผิดพลาด I/O หรือระบบไฟล์แบบอ่านอย่างเดียว ใน dmesg: ตัวดิสก์มีปัญหา หยุดเขียน สำรองข้อมูลหากยังทำได้ และติดต่อผู้ให้บริการของคุณ

เพื่อเพิ่มพื้นที่ว่างอย่างปลอดภัย เริ่มจาก system journal และไฟล์เก็บถาวรเก่า:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

ห้ามลบไฟล์ฐานข้อมูลหรือไฟล์เว็บไซต์เพื่อเอาที่ว่าง

ขั้นที่ 5: บริการใดหยุด และเพราะอะไร

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed แสดงทุกบริการที่หยุดด้วยข้อผิดพลาด journal ของบริการนั้นบอกเหตุผล: พอร์ตถูกใช้อยู่แล้ว ข้อผิดพลาดไวยากรณ์ในไฟล์การตั้งค่า ใบรับรองหาย ไม่เหลือพื้นที่ ทดสอบการตั้งค่าก่อนรีสตาร์ททุกครั้ง (nginx -t, apachectl configtest, php-fpm -t) แล้วเริ่มด้วย sudo systemctl restart SERVICE การรีสตาร์ทโดยไม่ทดสอบอาจทำให้บริการที่ยังทำงานได้ครึ่ง ๆ กลางล่ม

ขั้นที่ 6: อะไรเปลี่ยนไป

ระบบล่มมีสาเหตุ และสาเหตุมักเป็นการเปลี่ยนแปลงล่าสุด ลองหา:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

อัปเดตอัตโนมัติ เคอร์เนลใหม่ที่รอรีบูต การ deploy cron job ที่ทำให้ดิสก์เต็มด้วยข้อมูลสำรอง ใบรับรองที่หมดอายุ หรือการแก้ไขการตั้งค่าโดยคนอื่น: หากรายการใดตรงกับเวลาที่ระบบล่มเริ่ม คุณก็ได้เบาะแสแล้ว

เมื่อปัญหาเซิร์ฟเวอร์เดิมกลับมา

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

เมื่อคุณไม่อยากทำเรื่องนี้ตอนตี 3

หากเซิร์ฟเวอร์ของคุณล่มและคุณอยากให้ซ่อมให้มากกว่าดีบักเอง Quick Fix จัดการสาเหตุที่พบบ่อยในราคาคงที่: รีสตาร์ทบริการที่หยุดหลังผ่านการทดสอบการตั้งค่า เพิ่มพื้นที่ว่างให้ดิสก์ที่เต็ม และต่ออายุใบรับรองที่หมดอายุ โดยสำรองไฟล์ไว้ก่อน เมื่อไม่พอ Deep Fix เข้าดูแลตลอด 24 ชั่วโมง คิดเป็นช่วงละ 15 นาที โดยแสดงราคาก่อนสั่งซื้อ ทั้งสองทำงานผ่าน Responder, SSH ในฐานะ root หรือการเข้าถึง SSH ในเว็บสเปซของคุณ รายละเอียดในหน้าซ่อมเซิร์ฟเวอร์ล่มและสนับสนุนเซิร์ฟเวอร์ฉุกเฉิน