Checklist เตรียม Ubuntu Server ก่อนเปิดใช้งาน Production
ตรวจ user, SSH, firewall, HTTPS, secrets, process management, monitoring และ backup ให้ครบก่อนชี้โดเมนจริง เพื่อให้เซิร์ฟเวอร์ปลอดภัยและกู้คืนได้

ภาพรวม
Ubuntu Server ที่เพิ่งติดตั้งและเปิดเว็บได้จากเครื่องเรา ยังไม่เท่ากับพร้อมใช้งานจริงบน Production
ก่อนเปิดให้ผู้ใช้เข้ามา สิ่งที่ควรคิดไม่ใช่แค่ “เว็บขึ้นไหม” แต่คือ ถ้าเกิดพลาดขึ้นมา เรารู้ตัวเร็วไหม แก้ได้ไหม และข้อมูลหายหรือไม่ Checklist นี้ช่วยไล่ตรวจพื้นฐานที่ควรมี ก่อนชี้โดเมนจริงเข้ามาที่เซิร์ฟเวอร์ 🐧
-
อัปเดตระบบและสร้างผู้ใช้สำหรับดูแล รันอัปเดตแพ็กเกจให้เรียบร้อยก่อน เช่น apt update และ apt upgrade จากนั้นสร้าง user ปกติสำหรับใช้งานประจำ แล้วให้สิทธิ์ sudo เท่าที่จำเป็น ไม่ควรล็อกอินทำงานทุกอย่างด้วย root เพราะพิมพ์คำสั่งผิดครั้งเดียว ผลกระทบกว้างมาก ตั้งรหัสผ่านที่แข็งแรง และถ้าใช้ผู้ดูแลหลายคน ควรแยกบัญชีต่อคนเพื่อย้อนดูการใช้งานได้
-
ตั้งค่า SSH ให้เข้ายากขึ้น แต่กู้ทางเข้าไว้ก่อน ใช้ SSH key แทน password หากทำได้ และทดสอบล็อกอินด้วย key จากอีก terminal หนึ่ง ก่อนปิด PasswordAuthentication หรือปิด root login ต้องยืนยันว่าบัญชีใหม่เข้าได้จริง ไม่เช่นนั้นอาจล็อกตัวเองออกจากเครื่องทันที กำหนด AllowUsers เฉพาะผู้ที่จำเป็น และพิจารณาเปลี่ยนพอร์ตเป็นมาตรการลด bot scan ได้ แต่จำไว้ว่า การเปลี่ยนพอร์ตไม่ใช่การแทน SSH key หรือ firewall 🔐
-
เปิด firewall แบบ allow เฉพาะบริการ เริ่มจากดูว่าบริการใดกำลังฟังพอร์ตอยู่ด้วย ss -tulpn สำหรับเว็บทั่วไป ควรเปิดอย่างน้อย 80 และ 443 ให้สาธารณะ พอร์ต 22 ควรจำกัดตาม IP ของทีมถ้าสภาพงานเอื้อ หรืออย่างน้อยต้องใช้ key ที่ปลอดภัย ฐานข้อมูลอย่าง MySQL, PostgreSQL และ Redis ไม่ควรเปิดออกอินเทอร์เน็ตโดยไม่มีเหตุผล ใช้ UFW หรือ firewall ของ cloud กำหนด inbound rule ให้แคบที่สุด หลังเปลี่ยนกฎ firewall ให้ทดสอบจากภายนอก ไม่ใช่ดูแค่จากในเครื่อง
-
วาง HTTPS และโดเมนให้ครบเส้นทาง DNS ต้องชี้ A หรือ AAAA record ไปยัง IP ที่ถูกต้อง และเว็บเซิร์ฟเวอร์ต้องตอบ Hostname นั้น ใช้ Nginx หรือ Caddy เป็น reverse proxy หน้าแอป เพื่อรับ TLS และส่งต่อเข้า port ภายใน ออกใบรับรองด้วย Let's Encrypt และตั้งต่ออายุอัตโนมัติ ตรวจด้วย browser ว่า redirect จาก HTTP ไป HTTPS ทำงานจริง ไม่มี mixed content และ certificate ถูกโดเมน อย่าเพิ่งเปิด HSTS แบบยาวมากจนกว่าจะมั่นใจว่า HTTPS ทุก subdomain พร้อมแล้ว 🌐
-
แยก secrets ออกจากโค้ด ค่า DATABASE_URL, JWT secret, API key และรหัสผ่านต้องไม่ commit ลง Git เก็บไว้ใน environment file ที่จำกัด permission หรือใช้ secret manager ของ platform ไฟล์ .env ควรอ่านได้เฉพาะ user ที่รันแอป และต้องไม่ถูกเสิร์ฟออกจาก web root ถ้าเคยเผลอ push secret ขึ้น repository ให้ถือว่า secret นั้นรั่วแล้ว ต้อง rotate ไม่ใช่แค่ลบ commit ล่าสุด
-
ทำให้แอปรันต่อได้เมื่อ process ล่มหรือเครื่องรีบูต อย่ารัน node, Python หรือ PHP process ค้างไว้ใน SSH session แล้วหวังว่าจะอยู่ตลอด ใช้ systemd, Docker Compose หรือ process manager ที่มี restart policy กำหนด service ให้เริ่มหลัง network พร้อม และเปิด enable เพื่อกลับมาทำงานหลัง reboot ทดสอบจริงด้วยการ restart service และ reboot เครื่องในช่วงที่ควบคุมได้ จากนั้นดู journalctl หรือ log ของ container ว่าแอปกลับมารับ request ได้หรือไม่ ⚙️
-
ตรวจ log, health check และพื้นที่ดิสก์ ต้องรู้ว่าจะดู error ที่ไหนก่อนเกิดเหตุ ไม่ใช่ค่อยหาในคืนที่เว็บล่ม รวม access log, error log และ application log ในตำแหน่งที่ชัดเจน ทำ endpoint เช่น /healthz ที่ตรวจได้ว่าแอปตอบสนอง และถ้ามี database dependency ก็ควรออกแบบสถานะให้ชัด ตั้ง monitoring อย่างน้อยสำหรับ CPU, RAM, disk และ uptime disk เต็มจาก log หรือ backup มักทำให้ปัญหาเล็กกลายเป็นเว็บเขียนข้อมูลไม่ได้ได้ง่ายมาก ตั้ง log rotation และแจ้งเตือนก่อนพื้นที่ใกล้เต็ม 📈
-
Backup ที่กู้คืนได้เท่านั้นจึงเรียกว่า backup สำรอง database, ไฟล์อัปโหลด, configuration ที่จำเป็น และเก็บสำเนาออกจากเครื่อง production กำหนดรอบเวลาที่สัมพันธ์กับความสำคัญของข้อมูล เช่น รายวันหรือทุกชั่วโมง สำคัญที่สุดคือทดสอบ restore ไปยังเครื่องหรือฐานข้อมูลทดสอบ ไฟล์ backup ที่สร้างได้แต่ restore ไม่ผ่าน ไม่มีประโยชน์ในวันที่ต้องใช้ จดขั้นตอนกู้คืนและเวลาที่ใช้ไว้ เพื่อให้ทีมตัดสินใจได้เมื่อเกิด incident 💾
ก่อน go live ให้ลองจำลองสถานการณ์สั้น ๆ: รีสตาร์ตแอป, certificate หมดอายุ, database ต่อไม่ได้ และ disk ใกล้เต็ม ถ้าทีมรู้ว่าจะตรวจอะไร ใครรับผิดชอบ และย้อนกลับอย่างไร เว็บนั้นพร้อมกว่าเว็บที่ “เปิดหน้าแรกได้” มาก Production ที่ดีไม่ได้แปลว่าไม่มีปัญหา แต่แปลว่าปัญหาถูกจำกัด ตรวจพบ และฟื้นกลับได้อย่างมีระบบ ✅
แนวทางนำไปใช้
- นำแนวคิดจากโพสต์นี้ไปทดลองกับงานจริงของคุณ
- แยกเป็นขั้นตอนเล็ก ๆ แล้วทำทีละส่วน
- บันทึกผลลัพธ์และสิ่งที่เรียนรู้เพื่อต่อยอด
สรุป
ตรวจ user, SSH, firewall, HTTPS, secrets, process management, monitoring และ backup ให้ครบก่อนชี้โดเมนจริง เพื่อให้เซิร์ฟเวอร์ปลอดภัยและกู้คืนได้