ทำไม Staging Environment ถึงโกหกคุณ? ปัญหา Environment Drift
เจาะลึกปัญหา Environment Drift ที่ทำให้ระบบทดสอบกับระบบจริงไม่ตรงกัน สาเหตุหลักที่ทำให้การขึ้นระบบล่ม และแนวทางแก้ไขเพื่อกู้คืนความมั่นใจในการ Deploy
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Environment Drift เกิดจากระบบทดสอบและระบบจริงค่อยๆ คลาดเคลื่อนกันทีละน้อยจนไม่เหมือนกันอีกต่อไป
- ปัญหาซ่อนเร้นนี้มักนำไปสู่ระบบล่ม การแก้ปัญหาหน้างานตอนดึก และทีมงานสูญเสียความมั่นใจในการปล่อยฟีเจอร์
- สาเหตุหลักมาจากแพทช์เร่งด่วน การใช้ไลบรารีคนละเวอร์ชัน โครงสร้างพื้นฐานต่างกัน และชุดข้อมูลที่ไม่สมจริง
- การแก้ไขทำได้โดยใช้ Container, Infrastructure as Code, CI/CD และการจัดการ Config ให้เป็นศูนย์กลาง
ลองนึกภาพคืนวันพฤหัสบดี การปล่อยโค้ดขึ้นระบบผ่านพ้นไปด้วยดีหลังจากการรัน CI ที่สะอาดหมดจด ทุกคนกำลังปิดแล็ปท็อปเพื่อเตรียมตัวกลับบ้าน แต่แล้วสัญญาณเตือนก็ดังขึ้น ระบบชำระเงินพังทั้งที่หน้าจอ Staging ดูสมบูรณ์แบบไร้ที่ติ และมีคนพิมพ์ประโยคคลาสสิกในช่องแจ้งเหตุว่า "แต่ตอนรันใน Dev มันก็ปกตินี่นา" ความจริงอันเจ็บปวดก็คือ ระบบ Staging ไม่ได้ตั้งใจจะกลั่นแกล้งคุณ แต่มันหยุดเหมือนกับระบบจริงมานานแล้วโดยที่ไม่มีใครสังเกตเห็น ช่องว่างนี้เรียกว่า Environment Drift และมันอยู่เบื้องหลังเหตุการณ์ระบบล่มมากกว่าที่ทีมส่วนใหญ่ยอมรับ
ไม่มีใครเขียนคำว่า Environment Drift ลงในรายงานหลังเกิดเหตุ (Postmortem) มันมักถูกบันทึกไว้เป็นปัญหาอื่นแทน ในขณะเดียวกันความเสียหายที่แท้จริงก็สะสมเพิ่มขึ้นเรื่อยๆ มีคนต้องคอยตรวจสอบระบบจริงด้วยมือซ้ำๆ ก่อนการ Deploy ทุกครั้ง วิศวกรต้องเสียเวลาครึ่งวันไปกับการไล่ล่าหาบั๊กที่มีอยู่เฉพาะบนเซิร์ฟเวอร์จริง ความถี่ในการปล่อยโค้ดลดลงจากทุกสัปดาห์เหลือเดือนละครั้งเพราะทีมเคยบาดเจ็บมาแล้ว พนักงานใหม่ต้องใช้เวลาหลายสัปดาห์เพื่อทำความเข้าใจว่า Build ในเครื่องตัวเองมีความหมายอะไรบ้าง และตั๋วแจ้งปัญหาก็พอกพูนขึ้นเรื่อยๆ ในขณะที่วิศวกรยังคงยืนยันว่าปัญหานี้ "ไม่ควรจะเกิดขึ้นได้"
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ทีละน้อย ผู้คนเริ่มหยุดเชื่อมั่นในกระบวนการปล่อยโค้ดของตัวเอง นั่นคือส่วนที่มีราคาแพงที่สุดแต่มันไม่เคยปรากฏขึ้นบนหน้า Dashboard เลยแม้แต่น้อย มันเกือบจะไม่ใช่ความผิดพลาดครั้งใหญ่โตอันเดียว แต่เป็นการสะสมของการตัดสินใจเล็กๆ ที่ดูสมเหตุสมผลจากคนธรรมดาที่พยายามแก้ไขปัญหาให้รวดเร็วที่สุด
- การแก้ไขเฉพาะหน้าตอนเที่ยงคืน: มีคนแก้เซิร์ฟเวอร์จริงด้วยมือเพื่อหยุดระบบล่ม แล้วไม่มีใครจดบันทึกไว้ เดือนต่อมาแอปพลิเคชันต้องพึ่งพาการแก้นั้นโดยเงียบๆ แต่ไม่มีสภาพแวดล้อมอื่นที่มีการแก้นี้เลย
- เวอร์ชันที่ไม่ตรงกัน: ไลบรารีได้รับการอัปเกรดในเครื่องท้องถิ่น แต่ยังคงล็อกเวอร์ชันเก่าไว้ในระบบจริง ภายใต้การใช้งานจริงจึงทำให้พฤติกรรมของระบบแตกต่างกัน
- รูปร่างของโครงสร้างพื้นฐานที่ต่างกัน: Dev เป็นแล็ปท็อปที่รันคอนเทนเนอร์เดียว แต่ระบบจริงมีโหลดบาลานเซอร์ โซนความพร้อมใช้งานหลายโซน และระบบจัดการคอนเทนเนอร์ที่มีความพิเศษเฉพาะตัว
Environment Drift เป็นปัญหาคลาสสิกทางวิศวกรรมซอฟต์แวร์ที่อธิบายไว้ในแนวคิด The Twelve-Factor App มานานแล้ว ความท้าทายหลักอยู่ที่กาลเวลา คน และเครื่องมือที่แยกขาดระหว่างการพัฒนาและการใช้งานจริง เมื่อระบบมีความซับซ้อนและมีบริการย่อย (Microservices) มากขึ้น ช่องว่างเหล่านี้จึงขยายตัวเงียบๆ ได้ง่ายขึ้นโดยที่เครื่องมือตรวจจับอัตโนมัติอาจมองไม่เห็น จนกว่าจะเกิดโหลดจริงจากผู้ใช้งานจำนวนมาก
นี่คือแนวทางในการปิดช่องว่างเหล่านี้โดยไม่ต้องสร้างระบบใหม่ทั้งหมด:
- รันแอปพลิเคชันด้วย Container: สร้างอิมเมจขึ้นมาครั้งเดียวพร้อมกับ dependencies ที่แน่นอน แล้วรันอิมเมจเดียวกันนั้นในทุกสภาพแวดล้อม
- วางโครงสร้างพื้นฐานในรูปแบบโค้ด: ใช้ Terraform หรือ Pulumi เพื่อให้ทุกสภาพแวดล้อมถูกสร้างมาจากชุดคำสั่งที่มีการรีวิวและจัดเก็บเวอร์ชันแล้ว
- automatate เส้นทางการ Deploy: ทุกขั้นตอนที่ทำด้วยมือคือช่องทางของความคลาดเคลื่อน การมีระบบ CI/CD ที่เหมาะสมหมายความว่าโค้ดที่ผ่านการทดสอบคือสิ่งเดียวกับที่ส่งถึงผู้ใช้งานจริง
- รวมศูนย์ความลับและการกำหนดค่า: ใช้ Vault หรือ AWS Secrets Manager แทนการใช้ไฟล์หลายไฟล์ที่อาจอัปเดตไม่ตรงกัน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น