รายการตรวจสอบการดูแลรักษา Linux Server

การดูแลรักษาเซิร์ฟเวอร์ Linux ที่แท้จริงคืออะไร

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

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

คำสั่งที่ระบุไว้ที่นี่เป็นเพียงตัวอย่างและควรทำความเข้าใจก่อนนำไปใช้งานจริง ให้เปรียบเทียบผลลัพธ์กับเซิร์ฟเวอร์ของคุณ เนื่องจากค่าที่เหมาะสมสำหรับพื้นที่ว่างหรือจำนวน process ขึ้นอยู่กับหน้าที่ของเครื่องนั้นๆ ในกรณีที่การตรวจสอบแตกต่างกันไปตาม distribution เนื้อหาจะระบุไว้ให้ ตัวอย่างใช้ Debian และ Ubuntu ร่วมกับ apt สำหรับตระกูล RHEL เครื่องมือที่ใช้คือ dnf และมี path บางรายการที่แตกต่างกัน

วิธีเลือกความถี่ในการบำรุงรักษาเซิร์ฟเวอร์ Linux ที่คุณทำได้จริง

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

การตรวจสอบรายเดือนครอบคลุมการเสื่อมสภาพที่เกิดขึ้นช้าๆ เช่น ใบรับรองที่ใกล้หมดอายุ, บัญชีผู้ใช้ที่ไม่มีใครลบออก, เคอร์เนลที่สะสมอยู่ใน /boot หรือไฟล์ log ที่มีขนาดใหญ่เกินกว่ากฎการหมุนไฟล์ (rotation rule) ที่อาจหยุดทำงานไปแล้ว สิ่งเหล่านี้อาจไม่พังในวันพรุ่งนี้ แต่ทั้งหมดจะพังในที่สุด

การตรวจสอบตามรุ่นที่ปล่อยออกมา (Release checks) ขึ้นอยู่กับปฏิทิน การออกรุ่นของดิสทริบิวชันเป็นรายการบำรุงรักษาเดียวที่มีกำหนดเวลาจากภายนอก เพราะการสนับสนุนเวอร์ชันปัจจุบันของคุณจะสิ้นสุดลงไม่ว่าคุณจะพร้อมหรือไม่ก็ตาม

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

รายสัปดาห์: การอัปเดตถูกติดตั้งจริงหรือไม่

การเปิดใช้งาน unattended-upgrades ไม่ได้หมายความว่าการอัปเดตนั้นทำงานจริง บริการอาจถูก masked, การตั้งค่าอาจจำกัดอยู่เพียงแหล่งที่มาที่คุณไม่ได้ใช้งาน และแพ็กเกจที่ถูก held ไว้หนึ่งรายการอาจทำให้การทำงานในครั้งถัดไปทั้งหมดล้มเหลว การติดตั้งครอบคลุมอยู่ใน การอัปเดตความปลอดภัยอัตโนมัติบน Ubuntu งานรายสัปดาห์คือการพิสูจน์ว่าสิ่งที่คุณติดตั้งไปนั้นทำงานได้จริง

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable คือตัวชี้วัดที่ตรงไปตรงมาที่สุด เพราะเป็นการรายงานสถานะปัจจุบันแทนที่จะเป็นเพียงความตั้งใจ หากยังมีการอัปเดตความปลอดภัยค้างอยู่ในรายการนั้น แสดงว่าระบบอัตโนมัติไม่ได้ทำงานตามที่ควรจะเป็น ดังนั้นโปรดอ่าน log ก่อนที่จะสรุปว่าเครื่องได้รับการแพตช์แล้ว แพ็กเกจที่ถูก pinned ด้วย apt-mark hold จะถูกข้ามไปตลอดกาลและไม่มีการรายงานผลใดๆ ซึ่งเป็นเหตุผลว่าทำไม apt-mark showhold จึงควรถูกรวมอยู่ในขั้นตอนเดียวกัน

ความล้มเหลวที่กระบวนการนี้ช่วยป้องกันได้คือ: การรันแพ็กเกจที่มีช่องโหว่เป็นเวลาหลายเดือนทั้งที่เชื่อว่าการอัปเดตทำงานโดยอัตโนมัติแล้ว

รายสัปดาห์: พื้นที่ว่างของดิสก์และ inode

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

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i คือส่วนที่คนส่วนใหญ่มักมองข้าม Inode คือโครงสร้างที่มีจำนวนจำกัดซึ่งใช้เก็บ metadata ของไฟล์ ระบบไฟล์อาจมี inode ไม่เพียงพอในขณะที่ df -h ยังคงรายงานว่ามีพื้นที่ว่างเหลืออยู่หลายกิกะไบต์ การเขียนข้อมูลจะล้มเหลวพร้อมข้อความ No space left on device ปรากฏขึ้นข้างผลลัพธ์ที่แสดงพื้นที่ว่าง ซึ่งมักทำให้เสียเวลาตรวจสอบนานนับชั่วโมงในการพบครั้งแรก สาเหตุส่วนใหญ่มักเกิดจากไฟล์ขนาดเล็กจำนวนหลายล้านไฟล์ เช่น คิวอีเมลที่ค้างอยู่หรือไดเรกทอรี session ที่ไม่มีการล้างข้อมูล

du -xh จะตรวจสอบเฉพาะระบบไฟล์เดียว ซึ่งเป็นสิ่งที่คุณต้องการสำหรับเซิร์ฟเวอร์ที่มีการทำ bind mounts หรือเชื่อมต่อ storage ภายนอก สำหรับ Docker host คำตอบมักจะอยู่ที่ image layers และ volume ที่ไม่ได้ใช้งาน ซึ่งสามารถล้างข้อมูลได้ตามที่อธิบายไว้ใน การล้างข้อมูลดิสก์ Docker บน VPS

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

รายสัปดาห์: มีบริการใดหยุดทำงานโดยไม่แจ้งเตือนหรือไม่?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Unit ที่เกิดการ crash และถึงขีดจำกัดการ restart จะค้างอยู่ในสถานะ failed โดยไม่มีการแจ้งเตือนใดๆ list-timers เป็นเครื่องมือที่มีประโยชน์มากกว่า โดยจะแสดงเวลาที่ timer แต่ละตัวทำงานครั้งล่าสุดและเวลาที่จะทำงานในครั้งถัดไป ดังนั้นหากค่า LAST เก่ากว่าช่วงเวลาที่กำหนดไว้ของ timer แสดงว่างานนั้นไม่ได้ทำงานเลย

ให้อ่าน log ใน journal ของ unit นั้นก่อนที่จะทำการ restart ด้วยคำสั่ง journalctl -u <unit> -n 100 --no-pager การสั่ง restart จะเป็นการลบอาการที่เกิดขึ้น ทำให้คุณไม่มีเหตุผลที่จะตรวจสอบอีกจนกว่าเหตุการณ์เดิมจะเกิดขึ้นซ้ำในช่วงเวลาที่แย่กว่าเดิม

การตรวจสอบนี้ช่วยป้องกันความล้มเหลวในกรณีที่ monitoring agent, queue worker หรือ backup service หยุดทำงานไปตั้งแต่เหตุการณ์ memory spike เมื่อสามสัปดาห์ก่อน

รายสัปดาห์: งานสำรองข้อมูลเสร็จสมบูรณ์จริงหรือไม่?

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

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

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

หากสคริปต์ของคุณมีการส่งข้อมูล (pipe) จากการ dump ไปยังโปรแกรมบีบอัดข้อมูล ให้เพิ่ม set -o pipefail ไว้ที่ส่วนบนของสคริปต์ หากไม่มีคำสั่งนี้ สถานะการทำงานของ pipeline จะอ้างอิงตามโปรแกรมบีบอัดข้อมูล ซึ่งโปรแกรมบีบอัดข้อมูลมักจะทำงานสำเร็จเสมอแม้ว่าจะบีบอัดได้เพียงข้อความแจ้งข้อผิดพลาดก็ตาม ส่งผลให้งานสำรองข้อมูลรายงานว่าสำเร็จทุกคืนในขณะที่เขียนไฟล์เก็บถาวรที่ไม่มีข้อมูลจริงอยู่ข้างใน

รายเดือน: กู้คืนข้อมูลสำรองในเครื่องอื่น

นี่คือขั้นตอนที่คนส่วนใหญ่มักข้ามไป แต่เป็นขั้นตอนที่ตัดสินว่ารายการที่เหลือทั้งหมดนั้นมีความหมายหรือไม่

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

เครื่องมือจัดการ Repository มีการตรวจสอบของตนเอง โดย restic check --read-data-subset=5% และ borg check --verify-data จะอ่านข้อมูลที่จัดเก็บไว้โดยตรงแทนการอ่านจากดัชนี ให้รันคำสั่งเหล่านี้และถือว่าเป็นการทดสอบเบื้องต้น (smoke test) ไม่ใช่การทดสอบแทนการกู้คืนจริง การตรวจสอบ (verification) ยืนยันว่าข้อมูลไบต์ยังคงอยู่ แต่การกู้คืน (restore) ยืนยันว่าข้อมูลไบต์เหล่านั้นเป็นสิ่งที่แอปพลิเคชันของคุณต้องการใช้งานจริง

มีรายละเอียด 2 ประการที่คนมักเรียนรู้จากประสบการณ์ที่ยากลำบาก ประการแรก ให้ทดสอบรหัสผ่านสำหรับถอดรหัส (decryption passphrase) บนเครื่องที่ไม่มีกุญแจอยู่ใน agent เพราะข้อมูลสำรองที่คุณไม่สามารถถอดรหัสได้นั้นไม่ใช่ข้อมูลสำรอง ประการที่สอง ให้จับเวลาในการกู้คืน เพราะระยะเวลาดังกล่าวคือเวลาในการกู้คืนระบบจริงของคุณ และช่วงเวลาที่มักจะพบว่าใช้เวลานานเกินไปคือช่วงที่ระบบล่มจริง

รายเดือน: ใบรับรองใดกำลังจะหมดอายุ?

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

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

แฟล็ก -servername ใช้สำหรับตั้งค่า SNI (server name indication) ซึ่งจำเป็นสำหรับทุกแอดเดรสที่โฮสต์มากกว่าหนึ่งเว็บไซต์ มิฉะนั้นคุณจะได้รับใบรับรองเริ่มต้นแทนที่จะเป็นใบรับรองของคุณ หากติดตั้ง certbot ผ่าน snap ตัวตั้งเวลาจะมีชื่อเรียกที่แตกต่างออกไป ดังนั้นให้ค้นหาจากคำสำคัญแทนการระบุชื่อ unit ที่คุณคาดเดาเอาเอง

อย่าลืมใบรับรองที่ไม่มีระบบอัตโนมัติรองรับ เช่น เมลเซิร์ฟเวอร์, VPN หรือ certificate authority ภายใน ใบรับรองเหล่านี้มักจะหมดอายุในช่วงวันหยุดสุดสัปดาห์ และเบราว์เซอร์หรือไคลเอนต์จะปฏิเสธการเชื่อมต่อทันทีโดยไม่แสดงคำเตือน

รายเดือน: ผู้ใช้งาน, สิทธิ์ sudo และ SSH keys

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T จะแสดงการตั้งค่าที่ใช้งานจริงหลังจากรวม Include ทุกรายการเข้าด้วยกันแล้ว ซึ่งเป็นสิ่งที่ daemon จะนำไปใช้จริง อิมเมจ Ubuntu รุ่นใหม่ๆ จะมีไฟล์เสริมใน /etc/ssh/sshd_config.d/ ซึ่งสามารถเขียนทับไฟล์หลักได้ ดังนั้นการอ่านเพียง sshd_config อาจทำให้ได้ข้อมูลที่ไม่ถูกต้อง สำหรับตระกูล RHEL กลุ่มผู้ดูแลระบบคือ wheel ไม่ใช่ sudo ดังนั้นให้ปรับแก้บรรทัด getent ให้เหมาะสม

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

สำหรับการตรวจสอบประวัติการเข้าใช้งาน journalctl -t sshd --since "30 days ago" | grep -i accepted จะจับคู่กับตัวระบุ syslog แทนที่จะเป็นชื่อ unit ซึ่งเป็นเรื่องสำคัญเพราะ Ubuntu 24.04 จะเปิดใช้งาน SSH ผ่าน socket ทำให้การเชื่อมต่อแต่ละครั้งถูกบันทึกภายใต้ unit ที่สร้างขึ้นใหม่ตามการเชื่อมต่อนั้นๆ ดังนั้นการใช้คำสั่ง journalctl -u ssh เพียงอย่างเดียวอาจทำให้พลาดข้อมูลเหล่านี้ไปได้

รายเดือน: เคอร์เนลเก่าและพาร์ทิชัน /boot ที่เต็ม

/boot มักเป็นพาร์ทิชันแยกที่มีขนาดเพียงไม่กี่ร้อยเมกะไบต์ในอิมเมจ VPS มาตรฐาน การอัปเดตเคอร์เนลแต่ละครั้งจะเพิ่มไฟล์อิมเมจและ initramfs ลงไป เมื่อพาร์ทิชันนี้เต็ม การอัปเกรดครั้งถัดไปจะล้มเหลวระหว่างดำเนินการและทิ้งแพ็กเกจที่ยังไม่ได้ตั้งค่าไว้ ซึ่งเป็นสถานะที่ไม่ควรพบเจอโดยไม่คาดคิดในวันศุกร์

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r ต้องทำเป็นอันดับแรกเสมอ เพราะคำสั่งนี้จะระบุชื่อเคอร์เนลที่คุณกำลังใช้งานอยู่ ซึ่งเคอร์เนลดังกล่าวจะต้องถูกเก็บไว้ไม่ว่าคุณจะลบไฟล์ใดออกก็ตาม apt autoremove สามารถจัดการกรณีทั่วไปบน Debian และ Ubuntu ได้ เนื่องจากเคอร์เนลจะถูกทำเครื่องหมายว่าติดตั้งโดยอัตโนมัติและเคอร์เนลปัจจุบันจะได้รับการป้องกันไว้ ส่วนกรณีพิเศษ เช่น การติดตั้งเคอร์เนลด้วยตนเอง หรือกรณีที่ /boot เต็มจนขัดขวางการทำงานของ apt เองนั้น ได้อธิบายไว้ใน การล้างเคอร์เนลเก่าบน Ubuntu

รายเดือน: การเพิ่มขึ้นของ log และ systemd journal

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug เป็นการทดสอบการทำงานโดยไม่เขียนข้อมูลจริง จึงปลอดภัยที่จะใช้บนเซิร์ฟเวอร์ที่กำลังทำงานอยู่ การรันคำสั่งนี้มีประโยชน์เนื่องจากกฎการหมุนเวียนไฟล์ (rotation rules) อ้างอิงตาม path หากแอปพลิเคชันเปลี่ยนตำแหน่งที่เก็บ log ระหว่างการอัปเกรด กฎเดิมจะไม่ครอบคลุมไฟล์นั้นอีกต่อไป และไฟล์ดังกล่าวจะขยายขนาดขึ้นเรื่อยๆ จนเต็มพื้นที่จัดเก็บข้อมูล

ขนาดของ journal ถูกจำกัดโดย systemd ตามสัดส่วนของระบบไฟล์แทนที่จะเป็นตัวเลขที่คุณกำหนดเอง หากต้องการกำหนดเพดานขนาดที่แน่นอน ให้ตั้งค่า SystemMaxUse= ใน /etc/systemd/journald.conf แล้วรีสตาร์ท systemd-journald ส่วน sudo journalctl --vacuum-time=14d จะเป็นการคืนพื้นที่จัดเก็บข้อมูลทันที ซึ่งเป็นการดำเนินการแบบครั้งเดียวไม่ใช่การกำหนดนโยบายถาวร ดังนั้นควรใช้ควบคู่ไปกับการแก้ไขไฟล์ตั้งค่า

ต่อการปล่อยเวอร์ชัน: การรีบูตที่คุณผัดวันประกันพรุ่ง

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

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

ไฟล์ flag ดังกล่าวเป็นธรรมเนียมปฏิบัติของ Debian และ Ubuntu ซึ่งถูกเขียนขึ้นโดยสคริปต์ของแพ็กเกจ ระบบตระกูล RHEL จะไม่สร้างไฟล์นี้ขึ้นมา และคำถามในลักษณะเดียวกันนั้นจะถูกตอบโดย needs-restarting -r ซึ่งมาจาก dnf-utils ส่วน needrestart ซึ่งถูกติดตั้งมาเป็นค่าเริ่มต้นในอิมเมจของ Ubuntu server รุ่นใหม่ๆ จะตอบคำถามในระดับที่ต่ำกว่า kernel โดยมันจะแสดงรายการ process ที่ยังคงเรียกใช้ library ที่ถูกแทนที่บนดิสก์ไปแล้ว ซึ่งเป็นเหตุผลว่าทำไม OpenSSL ที่ถูกแพตช์แล้วจึงยังไม่มีผลจนกว่าบริการที่ใช้งานมันจะถูกรีสตาร์ท

จงวางแผนการรีบูตแทนที่จะหลีกเลี่ยง ใน /etc/apt/apt.conf.d/50unattended-upgrades นั้น Unattended-Upgrade::Automatic-Reboot "true"; และ Unattended-Upgrade::Automatic-Reboot-Time "03:00"; จะมอบอำนาจการตัดสินใจให้เป็นเวลาที่คุณเลือกเอง การรีบูตที่วางแผนไว้ยังเป็นการทดสอบเพียงวิธีเดียวที่จะยืนยันได้ว่าเครื่องจะกลับมาทำงานได้ตามปกติหรือไม่ เพราะรายการใน fstab ที่ผิดพลาดหรือบริการที่คุณไม่เคยเปิดใช้งาน จะปรากฏให้เห็นเฉพาะตอนบูตเครื่องเท่านั้นและไม่ปรากฏที่อื่นเลย

ต่อรุ่น: การวางแผนอัปเกรดรุ่นการจัดจำหน่าย

Ubuntu LTS มีระยะเวลาสนับสนุนมาตรฐาน 5 ปี ส่วนรุ่นระหว่างกาล (interim release) มีระยะเวลา 9 เดือน ดังนั้นการเลือกรุ่นจึงกำหนดภาระงานในการอัปเกรดของคุณไปอีกหลายปี การเปรียบเทียบข้อดีข้อเสียนี้อยู่ใน LTS เทียบกับรุ่นระหว่างกาลบนเซิร์ฟเวอร์

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade จะอ่านไฟล์ดังกล่าว และ Prompt=lts จะจำกัดการอัปเกรดเฉพาะการย้ายจาก LTS ไปยัง LTS เท่านั้น เส้นทางการอัปเกรดแบบ LTS ไปยัง LTS มักจะเปิดให้ใช้งานเมื่อมีการปล่อย point release แรกของเวอร์ชันใหม่ ไม่ใช่ในวันแรกที่เปิดตัว ดังนั้นให้ตรวจสอบสิ่งที่เครื่องของคุณได้รับข้อเสนอแทนที่จะวางแผนตามวันที่คุณคาดการณ์ไว้ กลไกของการอัปเกรดอยู่ใน การอัปเกรด Ubuntu 24.04 ไปยัง 26.04

ควรวางแผนเผื่อเวลาไว้ 3 เดือน ให้ทำ snapshot ที่คุณได้ทดสอบการกู้คืนแล้ว จดรายการ apt repository ของบุคคลที่สาม (กระบวนการอัปเกรดจะปิดการใช้งาน repository เหล่านี้ และแต่ละรายการจำเป็นต้องมีเป้าหมายใหม่สำหรับรุ่นใหม่) และตัดสินใจเกี่ยวกับแผนการย้อนกลับ (rollback) ก่อนเริ่มดำเนินการ ณ เดือนสิงหาคม 2026 Ubuntu 24.04 LTS จะได้รับการสนับสนุนมาตรฐานจนถึงเดือนเมษายน 2029 ดังนั้นนี่จึงเป็นเรื่องของการจัดตารางเวลา ไม่ใช่เหตุฉุกเฉิน

สิ่งที่ควรทำอัตโนมัติและสิ่งที่ควรทำด้วยตนเอง

จงทำสิ่งที่ตัดสินใจไปแล้วให้เป็นอัตโนมัติ เช่น การอัปเดตความปลอดภัย, การหมุนเวียน log, การต่ออายุใบรับรอง และงานสำรองข้อมูล รวมถึงการตั้งค่าการแจ้งเตือนด้วย เพราะการตรวจสอบที่ขึ้นอยู่กับว่าคุณจะจำได้หรือไม่นั้น คือการตรวจสอบที่จะไม่เกิดขึ้นจริงในช่วงเวลาตี 2 การใช้เครื่องมือตรวจสอบภายนอก เช่น การตรวจสอบสถานะแบบ self-hosted ด้วย Uptime Kuma จะช่วยตรวจจับสิ่งเดียวที่สคริปต์ภายในเครื่องไม่สามารถรายงานได้ นั่นคือการที่เซิร์ฟเวอร์ไม่สามารถเข้าถึงได้

ให้คงการทำงานสองอย่างไว้เป็นแบบ manual ได้แก่ การทดสอบการกู้คืนข้อมูล (restore test) และการตรวจสอบบัญชีผู้ใช้ (account audit) ทั้งสองอย่างนี้จำเป็นต้องมีบุคคลเป็นผู้ตัดสินใจว่าผลลัพธ์ที่ได้นั้นถูกต้องหรือไม่ หากคุณต้องการอ่านสถานะของเครื่องผ่านเบราว์เซอร์มากกว่าการใช้ terminal บทความ Cockpit เทียบกับ Webmin สำหรับการจัดการเซิร์ฟเวอร์ ได้เปรียบเทียบ web console ยอดนิยมทั้งสองตัวนี้ไว้ให้แล้ว

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

รายการตรวจสอบทั้งหมดในที่เดียว

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

ฉันควรบำรุงรักษาเซิร์ฟเวอร์ Linux บ่อยแค่ไหน?

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

ทำไมต้องทดสอบกู้คืนข้อมูลในเมื่อระบบสำรองข้อมูลแจ้งว่าสำเร็จ?

เพราะระบบแจ้งสถานะตาม exit status ของตัวมันเอง ซึ่งสถานะอาจเป็นจริงในขณะที่ไฟล์สำรองข้อมูลนั้นใช้งานไม่ได้ ตัวอย่างเช่น การ dump ข้อมูลผ่าน pipe ไปยังโปรแกรมบีบอัดโดยไม่มี set -o pipefail จะส่งคืนสถานะของโปรแกรมบีบอัด ดังนั้นหากการ dump ล้มเหลวและสร้างได้เพียงข้อความแสดงข้อผิดพลาด ระบบก็ยังคงส่งค่า exit status เป็นศูนย์และเขียนไฟล์ขนาดเล็กออกมาได้ ให้ทดสอบกู้คืนไปยังเครื่องอื่น เปิดดูข้อมูล และตรวจสอบความถูกต้อง การทดสอบกู้คืนยังช่วยวัดระยะเวลาที่ใช้จริง ซึ่งนั่นคือเวลาในการกู้คืนระบบของคุณ

ฉันจำเป็นต้องรีบูตเครื่องหลังการอัปเดต kernel ทุกครั้งหรือไม่?

คุณจำเป็นต้องรีบูตเพื่อให้ระบบเริ่มทำงานด้วย kernel ใหม่ สำหรับ Debian และ Ubuntu การมีอยู่ของไฟล์ /var/run/reboot-required บ่งบอกว่ามีแพ็กเกจต้องการการรีบูต และ /var/run/reboot-required.pkgs จะระบุว่าแพ็กเกจใดต้องการ สำหรับตระกูล RHEL จะไม่มีไฟล์ดังกล่าว แต่สามารถใช้คำสั่ง needs-restarting -r จาก dnf-utils เพื่อตอบคำถามเดียวกันได้ ควรตั้งค่าช่วงเวลาการรีบูตอัตโนมัติใน /etc/apt/apt.conf.d/50unattended-upgrades แทนการเลื่อนออกไปเรื่อยๆ เพราะเครื่องที่ไม่ได้รีบูตมาเป็นปีจะมีเส้นทางการบูตที่ไม่ได้ผ่านการทดสอบ รวมถึงใช้ kernel ที่ล้าสมัยด้วย

การตรวจสอบรายการใดบ้างที่สามารถทำเป็นอัตโนมัติได้อย่างปลอดภัย?

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