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

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

วิศวกรคนนี้กำลังทำงานโดยตรงกับฐานข้อมูลโปรดักชันโดยไม่มี staging environments หรือการสำรองข้อมูลที่ได้รับการยืนยัน เมื่อพยายามแก้ไขปัญหาโปรไฟล์ผู้ใช้ของลูกค้า การดำเนินการลบแบบง่ายๆ ได้กระตุ้นให้เกิดการลบแบบ cascading ที่ลบข้อมูลลีดที่ประมวลผลมาแล้วสามเดือนทิ้งไป เนื่องจากสถาปัตยกรรม Row Level Security (RLS) ของฐานข้อมูล บริษัทรอดมาได้เพียงเพราะการสำรองข้อมูลอัตโนมัติของ Supabase แต่สูญเสียข้อมูลไป 22 ชั่วโมง

ปัญหาทางเทคนิคหลักที่ระบุได้:

• การพัฒนาโดยตรงบนฐานข้อมูลการผลิตโดยไม่มีสภาพแวดล้อมสำหรับทดสอบ
• ไม่มีกลยุทธ์การสำรองข้อมูลที่ได้รับการยืนยัน (พึ่งพาการสำรองข้อมูลของ Supabase free tier ที่ไม่ทราบแน่ชัด)
• การกำหนดค่า CASCADE delete บน foreign keys ที่สำคัญ
• สถาปัตยกรรม Row Level Security (RLS) ที่สร้างการพึ่งพาอาศัยกัน
• การใช้งาน Supabase free tier สำหรับ production workloads

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

การวิพากษ์วิจารณ์จากชุมชนเกี่ยวกับแนวทางปฏิบัติการพัฒนา

การตอบสนองของชุมชนเทคโนโลยีได้วิพากษ์วิจารณ์แนวทางปฏิบัติด้านวิศวกรรมที่อธิบายไว้อย่างท่วมท้น นักพัฒนาหลายคนแสดงความตกใจต่อการผสมผสานของการทำงานโดยตรงกับฐานข้อมูลโปรดักชัน การขาด staging environments และการไม่มีขั้นตอนการตรวจสอบการสำรองข้อมูล การวิพากษ์วิจารณ์รุนแรงขึ้นเมื่อผู้อ่านทราบว่าทีมกำลังใช้งาน Supabase ในแพ็คเกจฟรีสำหรับงานโปรดักชัน

วิศวกรที่มีประสบการณ์หลายคนแบ่งปันเรื่องสยองขวัญของตนเอง แต่เน้นย้ำว่าเหตุการณ์เช่นนี้มักเกิดขึ้นในช่วงต้นของอาชีพหรือที่บริษัทที่มีแนวทางปฏิบัติด้านโครงสร้างพื้นฐานที่แย่ ฉันทามติของผู้วิพากษ์วิจารณ์คือมาตรการความปลอดภัยพื้นฐาน เช่น staging environments และการตรวจสอบการสำรองข้อมูล ต้องใช้การลงทุนด้านเวลาเพียงเล็กน้อยเมื่อเปรียบเทียบกับความสูญเสียร้ายแรงที่อาจเกิดขึ้น

จนกว่าคุณจะได้เห็นการกู้คืนจากการสำรองข้อมูลที่สำเร็จด้วยตัวเอง คุณไม่มีการสำรองข้อมูล คุณมีเพียงความหวังและการอธิษฐานว่าคุณมีการสำรองข้อมูล

การถกเถียงเรื่องความเร็วของสตาร์ทอัพเทียบกับความปลอดภัย

เหตุการณ์นี้ได้จุดประกายการถกเถียงที่ดำเนินมาอย่างต่อเนื่องเกี่ยวกับการสร้างสมดุลระหว่างการพัฒนาอย่างรวดเร็วกับแนวทางปฏิบัติด้านวิศวกรรมที่เหมาะสมในสภาพแวดล้อมของสตาร์ทอัพ ผู้สนับสนุนปรัชญา move fast and break things โต้แย้งว่าบริษัทในช่วงเริ่มต้นต้องให้ความสำคัญกับความเร็วในการเข้าสู่ตลาดมากกว่ามาตรการความปลอดภัยที่ครอบคลุม พวกเขาอ้างว่าการใช้เวลาหลายสัปดาห์ในการตั้งค่า CI/CD pipelines และระบบสำรองข้อมูลอาจเป็นอันตรายถึงชีวิตเมื่อทรัพยากรมีจำกัด

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

แนวทางปฏิบัติที่ดีที่ชุมชนแนะนำ:

• ใช้สภาพแวดล้อมการทดสอบ (staging/development environments) สำหรับการทดสอบ
• นำระบบสำรองข้อมูลและการกู้คืนที่ผ่านการตรวจสอบแล้วมาใช้
• หลีกเลี่ยงการลบแบบ CASCADE บน foreign keys ที่สำคัญ
• ใช้ soft deletes หรือ NULL constraints แทน
• ดำเนินการฐานข้อมูลภายใต้ transactions
• ไม่ควร deploy ในเย็นวันศุกร์หากไม่มีทีมสนับสนุนในช่วงสุดสัปดาห์

บทเรียนทางเทคนิคและแนวทางปฏิบัติที่ดี

นอกเหนือจากการถกเถียงเชิงปรัชญา เหตุการณ์นี้ได้จุดประกายการถกเถียงทางเทคนิคที่มีค่าเกี่ยวกับการออกแบบฐานข้อมูลและความปลอดภัยในการดำเนินงาน การกำหนดค่า CASCADE delete เดิมที่ทำให้เกิดการสูญเสียข้อมูลอย่างกว้างขวางได้ถูกระบุว่าเป็นความผิดพลาดทางเทคนิคที่สำคัญ ผู้เชี่ยวชาญฐานข้อมูลหลายคนแนะนำให้ใช้ soft deletes หรือ NULL constraints แทนการดำเนินการ CASCADE สำหรับ foreign keys ที่สำคัญ

ชุมชนยังเน้นย้ำความสำคัญของการดำเนินงานแบบ transaction-based และการออกแบบ database schema ที่เหมาะสม นักพัฒนาหลายคนสังเกตว่า PostgreSQL รองรับการเปลี่ยนแปลง schema ภายใน transactions ซึ่งสามารถป้องกันภาวะหายนะแบบ cascading ได้ เหตุการณ์นี้เป็นการเตือนใจในทางปฏิบัติว่าการดำเนินงานฐานข้อมูลควรได้รับการวางแผนและทดสอบอย่างรอบคอบ โดยไม่คำนึงถึงขนาดบริษัทหรือข้อกำหนดด้านความเร็วในการพัฒนา

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

อ้างอิง: How I Dropped the Production Database on a Friday Night