ทำไม Checklist สำหรับ Deploy ถึงมักจะยาวจนน่ากลัว
เวลาเราเขียนโปรแกรมเสร็จ เราต้องทำขั้นตอนที่เรียกว่า Deployment (การนำโค้ดที่เขียนเสร็จแล้วไปขึ้นระบบจริงเพื่อให้ผู้ใช้งานเข้าถึงได้) ซึ่งมือใหม่หลายคนมักจะสร้างรายการสิ่งที่ต้องตรวจสอบ หรือ Deployment Checklist (รายการตรวจสอบก่อนปล่อยงาน) ขึ้นมาเพื่อป้องกันความผิดพลาด
ปัญหาคือรายการพวกนี้มักจะยาวขึ้นเรื่อยๆ จนกลายเป็นหน้ากระดาษที่ไม่มีใครอยากอ่าน เพราะเราใส่ทุกอย่างที่กลัวพลาดลงไปหมด เช่น เช็คใบรับรองความปลอดภัย เช็คฐานข้อมูล เช็คคนเข้าใช้งาน ซึ่งสุดท้ายแล้วมันทำให้เราเหนื่อยและลืมเช็คจุดที่สำคัญจริงๆ ไป
ลองนึกภาพเหมือนคุณกำลังจะเดินทางไกล ถ้าคุณต้องจดรายการตรวจสอบของใช้ตั้งแต่วิธีสร้างรถยนต์ วิธีเติมน้ำมัน วิธีเช็คสภาพเครื่องยนต์ ไปจนถึงวิธีขับรถ คุณคงไม่ได้ออกเดินทางสักที เพราะมัวแต่ตรวจสอบสิ่งที่ควรเป็นหน้าที่ของรถ ไม่ใช่หน้าที่ของคุณ
แยกประเภทความเสี่ยงให้ออกก่อนเริ่มเช็ค
วิธีแก้ปัญหาที่ดีที่สุดคือการแบ่งรายการตรวจสอบออกเป็น 2 ฝั่ง คือ Application Risk (ความเสี่ยงที่เกิดจากโค้ดที่เราเขียนเอง) และ Infrastructure Risk (ความเสี่ยงที่เกิดจากระบบโครงสร้างพื้นฐานหรือตัวเครื่องเซิร์ฟเวอร์)
ฝั่งแรกคือสิ่งที่คุณต้องตัดสินใจเอง เพราะมีแค่คุณที่รู้ว่าโค้ดชุดนี้ทำงานอย่างไร เช่น ถ้าเปลี่ยนโครงสร้างฐานข้อมูล ข้อมูลเก่าจะหายไหม ส่วนฝั่งที่สองคือสิ่งที่ระบบควรดูแลตัวเองได้โดยอัตโนมัติ เช่น การเช็คว่าเซิร์ฟเวอร์เปิดอยู่ไหมหรือใบรับรองความปลอดภัยยังไม่หมดอายุ
จำไว้ว่าถ้าคุณต้องมานั่งเช็คด้วยตาตัวเองทุกครั้งว่า "เซิร์ฟเวอร์ทำงานปกติไหม" นั่นแปลว่าระบบของคุณยังไม่ได้มาตรฐาน Automation (การทำให้ระบบทำงานเองโดยไม่ต้องใช้คน) ที่ดีพอ ซึ่งเราควรเปลี่ยนจากการจดใส่กระดาษมาเป็นการเขียนโค้ดสั่งให้ระบบตรวจสอบตัวเองแทน
สร้างรายการจากประสบการณ์ที่เคยพลาดจริง
วิธีสร้างรายการตรวจสอบที่ได้ผลที่สุดคือการดู Incident History (ประวัติความผิดพลาดที่เคยเกิดขึ้นในอดีต) ของทีมคุณเอง ให้ไปดูว่า 10 ครั้งล่าสุดที่ระบบพัง มันพังเพราะอะไร แล้วเขียนสิ่งที่ต้องตรวจสอบเพื่อป้องกันไม่ให้เรื่องเดิมเกิดขึ้นอีก
อย่าพยายามเดาสิ่งที่จะพลาดในอนาคตจนรายการยาวเป็นหางว่าว ให้เน้นเฉพาะสิ่งที่เคยทำให้ระบบของคุณล่มจริงๆ เท่านั้น เพราะการมีรายการสั้นๆ ที่เช็คแล้วป้องกันปัญหาได้จริง ดีกว่ามีรายการยาวเหยียดที่คนทำอ่านผ่านๆ จนพลาดจุดสำคัญไป
ตัวอย่างเช่น ถ้าคุณเคยลืมตั้งค่า Environment Variable (ตัวแปรสภาพแวดล้อมที่ใช้เก็บค่าตั้งค่าสำคัญ เช่น รหัสผ่านฐานข้อมูล) จนระบบพัง คุณก็แค่เพิ่มข้อนี้เข้าไปในรายการ ถ้าคุณไม่เคยพลาดเรื่องนี้ ก็อย่าเพิ่งเอาใส่เข้าไปให้รกสายตา
ตัวอย่างการเช็คค่าตั้งค่าก่อน Deploy
# ตรวจสอบว่ามีค่าตั้งค่าที่จำเป็นในระบบหรือไม่
if [ -z "$DATABASE_URL" ]; then
echo "Error: ยังไม่ได้ตั้งค่า DATABASE_URL!"
exit 1 # สั่งหยุดการทำงานทันทีถ้าค่าไม่ครบ
fi
echo "ตรวจสอบการตั้งค่าผ่านเรียบร้อย"
อธิบายโค้ด:
[ -z "$DATABASE_URL" ]คือการตรวจสอบว่าตัวแปรนี้ว่างเปล่าหรือไม่echoคือการสั่งให้พิมพ์ข้อความแจ้งเตือนออกมาexit 1คือการบอกระบบว่าให้หยุดทำงานทันทีเพราะเกิดข้อผิดพลาด
ผลลัพธ์ที่ควรเห็น: ถ้าตั้งค่าไว้แล้ว จะได้ข้อความว่า "ตรวจสอบการตั้งค่าผ่านเรียบร้อย" แต่ถ้าลืมตั้งค่า จะได้ข้อความแจ้งเตือน "Error: ยังไม่ได้ตั้งค่า DATABASE_URL!" และโปรแกรมจะหยุดทำงานทันที
3 ความเสี่ยงของโค้ดที่มือใหม่มักมองข้าม
มีเรื่องสำคัญ 3 อย่างที่มักไม่อยู่ในรายการตรวจสอบ แต่ทำให้โปรแกรมเมอร์มือใหม่เจ็บหนักเสมอ อย่างแรกคือ Background Worker (โปรเซสที่ทำงานเบื้องหลัง) ที่อาจจะอ่านข้อมูลรูปแบบเก่าไม่ได้เมื่อเราอัปเดตโค้ดใหม่
อย่างที่สองคือ Database Migration (การปรับปรุงโครงสร้างฐานข้อมูล) ซึ่งถ้าคุณเปลี่ยนชื่อคอลัมน์โดยไม่เผื่อโค้ดเก่าไว้ ระบบจะพังทันที และอย่างที่สามคือ Rollback Trigger (เงื่อนไขที่ใช้ตัดสินใจว่าจะถอยกลับไปเวอร์ชันก่อนหน้าเมื่อไหร่) ที่ต้องตกลงกันให้ชัดเจนก่อนเริ่มปล่อยงาน
การแก้ไขเรื่องพวกนี้ไม่ใช่แค่การเขียนโค้ดให้ถูก แต่มันคือการวางแผนว่า "ถ้าพังจะถอยกลับอย่างไร" ให้ได้ภายใน 2 นาที เพราะถ้าคุณต้องใช้เวลาเป็นชั่วโมงในการกู้คืนระบบ ความเสียหายที่เกิดขึ้นกับผู้ใช้งานจะมหาศาลมาก
เปลี่ยนจาก "เช็คด้วยตา" เป็น "เช็คด้วยโค้ด"
สำหรับฝั่ง Infrastructure Risk ที่เคยบอกไว้ ให้คุณเอาออกจากรายการตรวจสอบของคน แล้วย้ายมันเข้าไปอยู่ใน CI/CD Pipeline (ชุดคำสั่งอัตโนมัติที่รันทุกครั้งที่ส่งโค้ด) แทน เพราะเครื่องมือพวกนี้ไม่มีวันเหนื่อยและไม่มีวันลืมเช็ค
ถ้าคุณต้องเช็คว่า Autoscaling (การเพิ่มจำนวนเซิร์ฟเวอร์อัตโนมัติเมื่อคนเข้าเยอะ) ทำงานถูกต้องไหม ให้เขียนคำสั่งตรวจสอบหรือใช้ Monitoring Tool (เครื่องมือเฝ้าระวังระบบ) แจ้งเตือนแทนการมานั่งกดดูเองในหน้าเว็บทุกครั้งก่อนกดปุ่ม Deploy
การทำให้รายการตรวจสอบสั้นลงจะช่วยให้ทีมมีสมาธิกับสิ่งที่สำคัญจริงๆ คือตัว Logic (ตรรกะการทำงาน) ของแอปพลิเคชัน ยิ่งรายการตรวจสอบสั้นและเป็นเรื่องที่ต้องใช้ความคิดของมนุษย์จริงๆ ทีมของคุณก็จะทำงานได้เร็วขึ้นและผิดพลาดน้อยลง
สรุป: เปลี่ยนรายการที่ยาวเหยียดให้เป็นระบบที่ไว้ใจได้
บทเรียนสำคัญที่สุดคือ Deployment Checklist ที่ดีไม่ใช่รายการที่ครอบจักรวาล แต่เป็นรายการที่รวบรวม "ประสบการณ์ความผิดพลาด" ของทีมคุณเอง และสิ่งไหนที่เป็นงานรูทีนที่เครื่องจักรทำแทนได้ ให้ยกให้เครื่องจักรทำไปเถอะ
เริ่มจากการเอา Checklist ปัจจุบันมากาง แล้วขีดฆ่าสิ่งที่เครื่องจักรทำแทนได้ออกไปให้หมด จากนั้นนำเหตุการณ์ที่ระบบเคยล่มมาใส่ไว้ในรายการแทน แล้วกำหนดวิธีทดสอบให้ชัดเจนว่าถ้าเจอเหตุการณ์แบบนี้อีก เราจะรับมืออย่างไร
ตัวอย่างการนำไปใช้: หากทีมของคุณเคยเจอปัญหาผู้ใช้เข้าเว็บไม่ได้เพราะ Database Migration พัง ให้เพิ่มข้อหนึ่งใน Checklist ว่า "ตรวจสอบว่าการเปลี่ยนแปลงฐานข้อมูลครั้งนี้ สามารถถอยกลับเป็นเวอร์ชันเดิมได้โดยไม่ทำให้ข้อมูลหาย" หากทำไม่ได้ ให้ทีมงานประชุมหาทางแก้ก่อนกด Deploy เสมอ
ที่มา: How to Build a Deployment Checklist That Actually Prevents Production Incidents — freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
