First Go-Live: เช่า VPS จด Domain และมีเว็บไซต์ของตัวเองครั้งแรก

ผมทำงานพัฒนาซอฟต์แวร์มาหลายสิบปี แต่ที่ผ่านมาส่วนใหญ่คือการทำงานในบริบทขององค์กร ที่มีโครงสร้างพื้นฐาน มีงบประมาณ มีทีมงาน และมีระบบรองรับไว้ให้อยู่แล้ว

แต่วันที่ 6–8 มิถุนายน 2026... ความรู้สึกมันต่างออกไป เพราะนี่คือ “ครั้งแรกในการทำโปรเจกต์ส่วนตัว” ของผม:

1. ควักกระเป๋าตัวเองจดชื่อโดเมนสำหรับโปรเจกต์ส่วนตัว (sabayjaibuddy.app)
2. เช่า VPS ขนาดเล็กเพื่อรันระบบของตัวเอง (Hostinger Ubuntu 24.04)
3. และกำลังจะมีหน้าเว็บไซต์และระบบบอทของตัวเองจริง ๆ ขึ้นสู่อินเทอร์เน็ต
4. และที่สำคัญ... ต้องขึ้นระบบด้วย Docker ให้สำเร็จด้วยตัวเองจริง ๆ โดยไม่มีน้อง ๆ หรือทีม Infra คอยดูแลให้

ไม่มีทีมอื่นคอยจัดการโครงสร้างพื้นฐานให้ ไม่มีน้อง ๆ ในทีมให้หันไปขอแรง มีแค่ผมคนเดียวที่นั่งทำร่วมกับ AI เพื่อพาระบบเล็ก ๆ ที่เราเฝ้าพัฒนาขึ้นสู่โลกจริง

1. Localhost ไม่ใช่โลกจริง: ก้าวสู่ VPS และ Domain ของตัวเอง

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

แต่สำหรับคนสายระบบ เรารู้อยู่เสมอว่า “รันผ่านในเครื่อง ไม่ได้แปลว่าจะรอดบนเซิร์ฟเวอร์จริง”

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

• ต้องเตรียม VPS และตั้งทางเข้าให้บริการต่าง ๆ ติดต่อกันได้
• ต้องเชื่อมโดเมน sabayjaibuddy.app เข้ากับเซิร์ฟเวอร์ที่เตรียมไว้
  (ณ เวลานั้น ความตั้งใจของผมคือการสร้างตัวแอป SabayJai Buddy ขึ้นมาเป็นหลัก จึงจดโดเมนชื่อ sabayjaibuddy.app สำหรับโปรเจกต์นี้โดยตรง ก่อนที่ในเวลาต่อมา เมื่อมีโปรเจกต์อื่น ๆ ตามมาอย่างเกม Tuajun คอนเซปต์จึงค่อย ๆ ขยับขยายสู่การเป็นบ้านรวมของหลายแอป จนนำมาสู่การจด sabayjai.net ในภายหลัง)
• ต้องทำให้ LINE ติดต่อกับระบบบนเซิร์ฟเวอร์ได้อย่างถูกต้อง

หลังจากปิดงานบน Localhost ในคืนนั้น ผมจึงเริ่มขั้นตอนแรกทันที: แพ็กระบบทั้งหมดลง Docker Compose

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

แต่วันนี้บริบทเปลี่ยนไปแล้วครับ ในห้องนี้ไม่มีน้อง ๆ ในทีมให้หันไปพึ่ง มีแค่ผมกับ AI เท่านั้น ถ้าผมไม่ทำเอง ระบบนี้ก็ไม่มีวันได้ออกไปสู่โลกจริง

2. การเตรียมความพร้อมบน Test (7 มิถุนายน)

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

ก. แยก Test Environment ตามสัญชาตญาณ Enterprise Architecture

ด้วยความที่ผมทำงานสายพัฒนาซอฟต์แวร์และอยู่กับ Enterprise Architecture มานาน สัญชาตญาณมันบอกทันทีว่า ยังไงก็ต้องแยก Test ออกจาก Production วันนั้นที่ตัดสินใจแยก เพราะคิดง่าย ๆ แค่ว่า "มันควรต้องแยก" ตามมาตรฐานที่ดี:

• แยกสภาพแวดล้อมทดสอบออกจาก Production และใช้ LINE OA สำหรับทดสอบ เพื่อไม่ให้การทดลองปะปนกับข้อมูลจริง

ข. ขั้นตอนการซ้อมรัน (AI จัดการให้)

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

ค. เสริมความปลอดภัย (เมื่อคนสาย App Layer ได้ AI ช่วยทำ Infra)

ตลอดชีวิตการทำงาน ผมทำแต่ฝั่ง Application Layer มาโดยตลอด เรื่องการคอนฟิกเน็ตเวิร์กลึก ๆ สคริปต์สำรองข้อมูลเซิร์ฟเวอร์ หรือการเซ็ตอัป Reverse Proxy ไม่ใช่สิ่งที่ผมเชี่ยวชาญเลย

แต่พอมาทำโปรเจกต์นี้ร่วมกับ AI ในช่วงบ่ายวันที่ 7 มิถุนายน (ประมาณ 14:39 น.) เราสามารถบอกความต้องการให้ AI ช่วยจัดการให้ได้:

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

นี่คือประโยชน์อย่างมากของการทำงานร่วมกับ AI: มันช่วยเติมเต็มช่องว่างด้าน Infrastructure และ DevOps ให้กับคนสาย App Layer อย่างผม ทำให้เราสามารถวางโครงสร้างความปลอดภัยเบื้องต้นและงานระบบได้อย่างรัดกุมขึ้นด้วยตัวคนเดียว

3. เช้ามืด 8 มิถุนายน: ส่งระบบขึ้น Production ก่อนไปทำงาน (ตีสามถึงหกโมงครึ่ง)

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

ผมตื่นมาตั้งแต่ตีสามกว่า มานั่งหน้าคอมพิวเตอร์ ค่อย ๆ ตรวจทานและส่งงานขึ้น GitHub ทีละขั้นผ่าน Pull Request ไล่เก็บงานตั้งแต่การตั้งท่อส่งงาน CI/CD, ปรับแต่งหน้าตาเว็บ, จัดการหน้าล็อกอิน ไปจนถึงการตรวจเช็กคอนเทนเนอร์บนเซิร์ฟเวอร์จริง

จนกระทั่งเวลา หกโมงครึ่งพอดี โค้ดชุดสมบูรณ์ก็ถูกส่งขึ้นสู่ Production บน VPS สำเร็จ:

• PostgreSQL และ Strapi Backend เชื่อมต่อพร้อมทำงาน
• LINE Bot Service พร้อมรับ Webhook
• Web Service หน้าเว็บเปิดต้อนรับการใช้งาน

ทุกคอนเทนเนอร์รายงานสถานะพร้อมทำงาน ก่อนที่ผมจะต้องเตรียมตัวออกไปทำงานประจำในเช้าวันนั้น

4. ทดสอบระบบจริง: เชื่อมต่อ Webhook และข้อความแรก

ขั้นตอนสำคัญถัดมาคือการยืนยันการเชื่อมต่อจริง:

1. เชื่อมต่อ LINE Webhook:
   ผมตั้งค่า Webhook ของระบบจริงและทดสอบการเชื่อมต่อจน LINE ติดต่อกับเซิร์ฟเวอร์ได้
2. ทดสอบส่งข้อความแรกผ่าน LINE:
   ผมเปิดแอป LINE ในโทรศัพท์ เข้าไปยังห้องแชทของ SabayJai Buddy บน Production แล้วพิมพ์ข้อความทดสอบ:

   “วิ่งตอนเช้า 5 กิโลเมตร ใช้เวลา 30 นาที สบายใจมาก”

   ระบบรับข้อความ เรียก AI ช่วยสกัดข้อมูล บันทึกข้อมูลการวิ่ง และส่งคำตอบกลับมายังโทรศัพท์ได้
3. ทดสอบเปิดหน้าเว็บไซต์ของตัวเอง:
   ผมเปิดหน้าเว็บของระบบและตรวจว่าล็อกอินกับข้อมูลที่เชื่อมต่อด้านหลังทำงานได้

ณ วินาทีนั้น ระบบรุ่น v0.1.0 ถือว่าขึ้นสู่ Production อย่างสมบูรณ์ มันคือระบบเล็ก ๆ ที่ยังไม่มีฟีเจอร์ซับซ้อน แต่สิ่งที่สำคัญคือ: โครงสร้างพื้นฐานทั้งหมดทำงานได้จริงบนเซิร์ฟเวอร์และโดเมนของตัวเอง

5. บทเรียนจากการทำ First Go-Live

สิ่งที่ตกผลึกจากการส่งมอบระบบในครั้งนี้:

ก. การก้าวทีละจุดตรวจสอบ (Progressive Checkpoints)

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

1. ปิดงานและเทสต์ผ่านบน Localhost
2. แพ็กใส่ Docker และทดสอบบนเครื่อง
3. ซ้อมรันบน Blank Database ในสนามทดสอบ (Test Rehearsal)
4. วางมาตรการป้องกันและสคริปต์สำรองข้อมูล (Production Hardening)
5. ส่งขึ้น Production จริงทีละขั้นตอนผ่าน Pull Request

ข. การปรับปรุงแผนงานตามข้อเท็จจริง (Revisit)

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

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