Câu chuyện thẳng thắn của một kỹ sư phần mềm về việc vô tình xóa sạch toàn bộ cơ sở dữ liệu production của startup đã châm ngòi cho một cuộc tranh luận sôi nổi trong cộng đồng công nghệ về việc cân bằng giữa thực tiễn phát triển phù hợp và tốc độ của startup. Sự cố này xảy ra tại một startup AI bất động sản của Pháp, đã chia rẽ các lập trình viên giữa những người coi đây là bài học kinh nghiệm quý giá và những người khác xem đây là câu chuyện cảnh báo về kỹ thuật thiếu thận trọng.
Kỹ sư này đang làm việc trực tiếp trên cơ sở dữ liệu production mà không có môi trường staging hoặc bản sao lưu đã được xác nhận khi họ cố gắng khắc phục vấn đề hồ sơ người dùng của khách hàng. Một thao tác xóa đơn giản đã kích hoạt chuỗi xóa liên tục làm mất sạch ba tháng dữ liệu leads đã được xử lý do kiến trúc Row Level Security (RLS) của cơ sở dữ liệu. Công ty chỉ được cứu nhờ tính năng sao lưu tự động của Supabase, nhưng vẫn mất 22 giờ dữ liệu trong quá trình này.
Các Vấn Đề Kỹ Thuật Chính Được Xác Định:
- Phát triển trực tiếp trên cơ sở dữ liệu production mà không có môi trường staging
- Không có chiến lược sao lưu đã được xác minh (dựa vào các bản sao lưu không rõ ràng của gói miễn phí Supabase)
- Cấu hình xóa CASCADE trên các khóa ngoại quan trọng
- Kiến trúc Row Level Security (RLS) tạo ra các phụ thuộc
- Vận hành trên gói miễn phí Supabase cho khối lượng công việc production
 |
|---|
| Bài đăng blog kể lại trải nghiệm nghiêm trọng của một kỹ sư phần mềm khi vô tình xóa sạch cơ sở dữ liệu production của một startup, nhấn mạnh tầm quan trọng của việc thực hành kỹ thuật cẩn thận |
Phản ứng dữ dội của cộng đồng về thực tiễn phát triển
Phản ứng của cộng đồng công nghệ đã vô cùng chỉ trích các thực tiễn kỹ thuật được mô tả. Nhiều lập trình viên bày tỏ sự sốc trước sự kết hợp của việc làm việc trực tiếp trên cơ sở dữ liệu production, thiếu môi trường staging và không có quy trình sao lưu đã được xác minh. Sự chỉ trích càng tăng cao khi độc giả biết được đội ngũ đang vận hành trên gói miễn phí của Supabase cho khối lượng công việc production.
Một số kỹ sư giàu kinh nghiệm đã chia sẻ những câu chuyện kinh hoàng của riêng họ, nhưng nhấn mạnh rằng những sự cố như vậy thường xảy ra vào đầu sự nghiệp hoặc tại các công ty có thực tiễn cơ sở hạ tầng kém. Sự đồng thuận giữa những người chỉ trích là các biện pháp an toàn cơ bản như môi trường staging và xác minh sao lưu chỉ cần đầu tư thời gian tối thiểu so với những tổn thất thảm khốc có thể xảy ra.
Cho đến khi bạn cá nhân đã chứng kiến việc khôi phục thành công từ bản sao lưu, thì bạn không có bản sao lưu. Bạn chỉ có hy vọng và lời cầu nguyện rằng mình có bản sao lưu.
Cuộc tranh luận giữa tốc độ startup và an toàn
Sự cố này đã làm bùng phát lại cuộc tranh luận đang diễn ra về việc cân bằng giữa phát triển nhanh chóng với các thực tiễn kỹ thuật phù hợp trong môi trường startup. Những người ủng hộ triết lý di chuyển nhanh và phá vỡ mọi thứ lập luận rằng các công ty giai đoạn đầu phải ưu tiên tốc độ ra thị trường hơn các biện pháp an toàn toàn diện. Họ cho rằng việc dành hàng tuần để thiết lập pipeline CI/CD và hệ thống sao lưu có thể gây chết người khi tài nguyên bị hạn chế.
Tuy nhiên, những người chỉ trích mạnh mẽ phản bác lý luận này, chỉ ra rằng các chiến lược sao lưu cơ bản và môi trường phát triển chỉ cần thời gian thiết lập tối thiểu. Nhiều người lập luận rằng lý do startup không thể biện minh cho những sơ suất cơ bản có thể phá hủy nhiều tháng công việc và dữ liệu khách hàng. Cuộc thảo luận đã làm nổi bật sự chia rẽ thế hệ trong cộng đồng công nghệ về mức độ rủi ro có thể chấp nhận được trong các hệ thống production.
Các Thực Hành Tốt Nhất Được Cộng Đồng Khuyến Nghị:
- Sử dụng môi trường staging/development để kiểm thử
- Triển khai các quy trình sao lưu và khôi phục đã được xác minh
- Tránh sử dụng CASCADE deletes trên các khóa ngoại quan trọng
- Sử dụng soft deletes hoặc ràng buộc NULL thay thế
- Thực hiện các thao tác cơ sở dữ liệu trong transactions
- Không bao giờ triển khai vào tối thứ Sáu mà không có hỗ trợ cuối tuần
Bài học kỹ thuật và thực tiễn tốt nhất
Ngoài các cuộc tranh luận triết học, sự cố này đã khơi dậy những thảo luận kỹ thuật có giá trị về thiết kế cơ sở dữ liệu và an toàn vận hành. Cấu hình CASCADE delete ban đầu gây ra việc mất dữ liệu trên diện rộng đã được xác định là một sai lầm kỹ thuật chính. Nhiều chuyên gia cơ sở dữ liệu khuyến nghị sử dụng soft delete hoặc ràng buộc NULL thay vì các thao tác CASCADE cho các khóa ngoại quan trọng.
Cộng đồng cũng đã nhấn mạnh tầm quan trọng của các thao tác dựa trên transaction và thiết kế schema cơ sở dữ liệu phù hợp. Một số lập trình viên lưu ý rằng PostgreSQL hỗ trợ thay đổi schema trong transaction, điều này có thể đã ngăn chặn thảm họa liên tục. Sự cố này đóng vai trò như một lời nhắc nhở thực tế rằng các thao tác cơ sở dữ liệu nên được lên kế hoạch và kiểm tra cẩn thận, bất kể quy mô công ty hay yêu cầu tốc độ phát triển.
Câu chuyện kết thúc với việc startup triển khai môi trường phát triển local phù hợp và cải thiện quy trình sao lưu, mặc dù nhiều người trong cộng đồng đặt câu hỏi liệu những bài học này có đến với cái giá quá cao cho cả công ty và khách hàng của họ hay không.
Tham khảo: How I Dropped the Production Database on a Friday Night