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

อัปเกรดทุกอย่างให้ใหม่เสมอ ไม่ได้แปลว่าระบบดีขึ้นเสมอ

โดยคนชงกาแฟ · อ่านประมาณ 6 นาที · ลาเต้ร้อนหนึ่งแก้ว

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

🔥 ถ้วยนี้: LTS คือเพื่อนแท้ของคนดูแลระบบ

ผมเชื่อว่าเครื่องที่ทำงานจริง เช่น เซิร์ฟเวอร์เมล เครื่องเก็บไฟล์ หรือเครื่องที่คุมระบบ Wi‑Fi ของหอพัก ควรใช้ดิสโทรรุ่นที่สนับสนุนระยะยาว (LTS) เกือบทุกกรณี เหตุผลไม่ซับซ้อนเลย ระบบแบบนี้มีหน้าที่ “อยู่เฉย ๆ แล้วทำงานไป” ไม่ใช่ที่ทดลองของใหม่

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

ระบบที่ดีที่สุดคือระบบที่เราไม่ต้องนึกถึงมันเลยทั้งเดือน

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

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

🔧 ซ่อมอะไรไปสัปดาห์นี้: ดิสก์เต็มเพราะ log ไม่ถูกหมุน

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

ขั้นแรกคือหาว่าอะไรกินพื้นที่ คำสั่งที่ผมใช้ประจำคือ

df -h
sudo du -xh /var --max-depth=2 | sort -h | tail -n 15
journalctl --disk-usage

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

sudo truncate -s 0 /var/log/myapp/app.log

จากนั้นแก้ต้นเหตุด้วยการเพิ่มไฟล์ตั้งค่า logrotate และจำกัดขนาด journal ของ systemd

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
    copytruncate
}

# /etc/systemd/journald.conf
SystemMaxUse=1G

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

☕ กาแฟกับเคอร์เนล: เลือกเคอร์เนลแบบไหนดี

เคอร์เนลลีนุกซ์มีหลายสาย ที่คนทั่วไปควรรู้จักคือรุ่น mainline ที่ออกใหม่เป็นระยะ, รุ่น stable ที่แก้บั๊กต่อจาก mainline และรุ่น longterm ที่ได้รับการดูแลนานหลายปี ดิสโทรส่วนใหญ่จะเลือกเคอร์เนลให้เราแล้ว และเพิ่มแพตช์ของตัวเองเข้าไป

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

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

📅 ปฏิทินชุมชน (ตัวอย่าง)

วันที่กิจกรรม
14 พ.ย. (ตัวอย่าง)มีตอัปคนใช้ลีนุกซ์ กรุงเทพฯ
28 พ.ย. (ตัวอย่าง)เวิร์กช็อปโฮมแล็บออนไลน์

ก่อนกาแฟหมดแก้ว

ถ้ามีเรื่องที่อยากให้คุยในฉบับหน้า หรืออยากเถียงกับคอลัมน์ “ถ้วยนี้” ตอบกลับอีเมลนี้ได้เลยครับ ผมอ่านทุกฉบับ แล้วเจอกันอีกสองสัปดาห์ ดูแลระบบให้ดี และอย่าลืมพักดื่มกาแฟบ้าง

— คนชงกาแฟ, linuxcup.com