Tình huống
Dev A đang làm một dự án nhỏ, có quyền connect thẳng vào production. Trong lúc code, anh ấy mở DBeaver để thao tác với nhiều database cùng lúc. Và rồi trong một khoảnh khắc cuốn theo dòng đời, anh bấm nhầm query edit dữ liệu trực tiếp trên schema production.
Hệ quả: Khách hàng đang sử dụng bỗng thấy dữ liệu thay đổi bất thường → hoảng hốt báo gấp cho công ty. Sau điều tra, thủ phạm được tìm ra: chính là Dev A, với một dòng query ngây thơ nhưng sát thương cực mạnh. ⚡
Bối cảnh
Với dự án nhỏ, team thường “nới tay” trong việc quản lý database. Ai cũng có quyền connect production, nghĩ rằng “dữ liệu ít thôi, có gì đâu mà căng”. Và đó chính là mầm họa: chỉ cần một thao tác nhầm lẫn, dữ liệu thật của khách hàng bị thay đổi → mất uy tín, mất lòng tin.
Vấn đề
Sai lầm: Xem nhẹ việc bảo vệ database production. Production không quan tâm bạn là dev mới hay senior, nó chỉ biết rằng ai update nhầm thì dữ liệu bay màu.
Giải pháp
Để tránh lặp lại sai lầm này, team đã đưa ra các nguyên tắc:
-
Phân quyền:
- Chặn trực tiếp quyền
UPDATE,DELETEcho developer trên production. - Chỉ account DBA hoặc account CI/CD có quyền chạy migration.
- Chặn trực tiếp quyền
-
Cảnh báo trong tool:
- Bật tính năng highlight/cảnh báo đỏ khi connect vào production.
- Với DBeaver hay các tool tương tự, cấu hình màu sắc khác biệt cho từng môi trường (dev = xanh, staging = vàng, production = đỏ chói).
-
Dùng công cụ tách biệt:
- Dùng phần mềm riêng biệt cho dev/test, không dùng cùng tool để tránh nhầm lẫn.
- Hoặc setup connect string riêng biệt, khó nhầm lẫn.
-
Quy trình:
- Tất cả thay đổi data trên production phải thông qua script review + approval, tuyệt đối không cho run trực tiếp từ local.
Bài học
Dù dự án lớn hay nhỏ, production luôn phải được đối xử như “vùng cấm”. Một dòng query nhầm có thể làm rung chuyển niềm tin khách hàng. Và cái giá phải trả cho một cú click nhầm… đôi khi không chỉ là rollback. 😓
👉 Lời khuyên chân thành: Trên production, hãy run query với trái tim run rẩy, và càng run thì càng an toàn.