Vấn đề
TTMI vận hành một hệ thống ERP bán lẻ cho ~50 cửa hàng. Nhiều bug production chỉ tái hiện được với dữ liệu thật: sổ cái nhiều năm, đơn hàng kẹt ở trạng thái lạ, các dòng đã soft-delete nhưng vẫn ảnh hưởng. Database local thì trống hoặc cũ, và muốn có bản mới phải nhờ người có quyền truy cập cloud. Khi coding agent đảm nhận nhiều phần việc sửa lỗi hơn, chính agent cũng liên tục bị kẹt vì thiếu dữ liệu.
Đưa thẳng cho agent một bản dump production là cách dễ nghĩ ra nhất, và cũng là dấu hiệu đáng lo nhất. Dữ liệu production trên laptop là rủi ro về bảo vệ dữ liệu. Agent có công cụ database có thể restore nhầm vào database khác. Credential cloud nằm trên mọi máy làm blast radius rộng ra. Một bản dump áp dụng dở dang để lại database local trông như sẵn sàng nhưng lại đánh lừa người debug.
Không ai giao việc này. Tôi tự bắt đầu vì bước chuẩn bị dữ liệu cứ tốn thời gian của mình, và đặt một mục tiêu: đường an toàn phải là đường dễ đi nhất, còn mọi đường nguy hiểm đều phải fail closed.
Tôi đã làm gì
Model quyết định cần gì, script quyết định làm thế nào
Skill chia việc làm hai phần. Model quyết định vấn đề có thật sự do thiếu dữ liệu hay là bug về code, schema hoặc phân quyền, và cần dữ liệu của module nghiệp vụ nào. Các script tất định làm mọi bước rủi ro: kiểm tra, khởi chạy, tải về, xác thực và restore. An toàn không phụ thuộc vào việc model có đọc kỹ hướng dẫn hay không. Đánh đổi là kém linh hoạt hơn. Agent chọn trong một tập scope theo module cố định, còn scope tùy chỉnh thì cần mẫu tên bảng rõ ràng lấy từ chính task, không được đoán.
Không để credential cloud trên laptop
Laptop không bao giờ kết nối tới database production hay object storage bằng key của riêng nó. Helper khởi chạy một CI job bằng danh tính CI của chính developer. Job chạy dump theo scope trên cloud và chỉ trả về một đường link tải có thời hạn ngắn, và helper không bao giờ in link đó ra. Mỗi lần chạy đều bắt buộc tạo dump mới, nên agent không bao giờ debug trên bản cũ. Một lần làm mới mất vài phút và phụ thuộc vào CI. Đổi lại, quyền truy cập đi theo phân quyền repo sẵn có, và gỡ quyền một người chỉ cần đổi permission thay vì xoay vòng key.
Làm cho việc chọn nhầm đích thật khó xảy ra
Mỗi lần chạy phải ghi rõ một target alias. Agent được dặn không bao giờ tự suy ra alias và phải hỏi người dùng nếu thiếu. Mỗi alias trỏ tới đúng một kết nối local. Helper từ chối chạy tiếp nếu host không phải địa chỉ loopback, hoặc tên database trong config không khớp với tên mong đợi cho alias đó. Sau khi kết nối, nó kiểm tra tên lần thứ hai với tên do chính server báo về. Không có đường thoát nào để trỏ tới máy remote. Một lock cấp toàn máy ngăn hai phiên agent restore cùng lúc. Restore tự động còn cần một cờ opt-in do chủ máy bật trong config riêng tư, được kiểm tra trước khi khởi chạy bất cứ thứ gì.
Chỉ restore đúng scope, được ăn cả ngã về không
Bước restore chỉ thay dữ liệu trong những bảng có trong dump và để nguyên mọi bảng khác. Nó chạy trong một transaction, kiểm tra các foreign key bị ảnh hưởng ngay bên trong, và rollback khi có bất kỳ lỗi nào, nên dữ liệu local cũ vẫn còn nguyên. Nó không bao giờ chạy migration hay nới lỏng constraint để restore cho qua. Cái giá là restore theo scope có thể để lại tham chiếu xuyên module bị cũ. Khi kiểm tra foreign key thất bại, agent dừng lại và báo chính xác bước nào lỗi, thay vì nói database đã sẵn sàng.
Coi bản dump là đầu vào không đáng tin
Trước khi đụng tới database, helper kiểm tra định dạng archive và tính toàn vẹn của file nén, chỉ chấp nhận tên bảng khớp một mẫu allowlist chặt, và từ chối mọi câu lệnh plain SQL nằm ngoài dạng nạp dữ liệu mong đợi. Nếu schema trong dump đã lệch so với local, các thay đổi cột được suy ra từ một shadow database tạm dựng từ chính bản dump. Cách này tốn nhiều code hơn kiểu xóa rồi nạp lại, nhưng dump lỗi sẽ fail sớm với thông báo chính xác.
Kết quả
Coding agent gặp tình trạng thiếu dữ liệu giờ có thể tự lấy một lát dữ liệu production mới và đúng phạm vi, bỏ được bước chuẩn bị thủ công trước khi tái hiện bug. Các lần chạy nhắm sai đích hoặc gặp dump hỏng được thiết kế để fail closed: bị từ chối trước khi khởi chạy, hoặc rollback và giữ nguyên dữ liệu cũ. Bộ trích xuất schema có unit test, và skill được đóng gói kèm manifest kiểm tra toàn vẹn để developer khác có thể cài với danh tính CI và credential local của riêng họ. Tôi chưa có số liệu thời gian tiết kiệm, nên kết quả chỉ mô tả định tính.
Nếu làm lại
Lỗ hổng lớn nhất là dữ liệu cá nhân: phía client không che giấu gì cả, nên thông tin khách hàng và nhân viên nằm trên laptop nguyên trạng, và tôi sẽ pseudonymise các trường đó ngay trong job export. Template config cũng đang bật sẵn restore tự động, nên chính cờ đó mới là sự đồng ý thật sự cho các lần agent tự chạy; lẽ ra nó phải tắt mặc định. Dump tải về cũng chưa có checksum, nên tôi sẽ cho CI job công bố checksum và kiểm tra trước khi restore.