Saas Deletion Process
I. Benefits
- Quy trình cho việc dọn dẹp cơ bản của một sản phẩm Saas
- Giảm dung lượng lưu trữ trên hệ thống
- Tăng tốc độ tìm kiếm thông tin và dễ quản lí thông tin trên hệ thống
II. Prerequisites
- Có tài khoản truy cập các tài nguyên trên hệ thống với đầy đủ quyền chỉnh sửa, xóa
- Có hiểu biết cơ bản về các nơi sẽ tiến hành dọn dẹp
III. Infomation Level
- infoLevel:3 (reader must be signed official employee's contract from at least junior grade)
- writingLevel:1 (only text without image/video)
IV. Main content:
Quy trình làm sạch và xóa dữ liệu trong hệ thống SaaS
Khi một khách hàng ngừng sử dụng một sản phẩm SaaS, việc xóa dữ liệu không đơn giản là chọn một tài khoản rồi nhấn Delete.
Trong thực tế, thông tin của một khách hàng thường được lưu ở nhiều nơi: hệ thống quản lý người dùng, dữ liệu nghiệp vụ, hệ thống tích hợp, cơ sở dữ liệu, nhật ký hoạt động và đôi khi cả các hệ thống bên thứ ba.
Nếu chỉ xóa ở một nơi, dữ liệu có thể vẫn còn tồn tại ở nơi khác. Ngược lại, nếu xóa mà không kiểm tra kỹ mối quan hệ giữa các dữ liệu, hệ thống có thể vô tình xóa nhầm dữ liệu của khách hàng khác.
Vì vậy, một quy trình làm sạch dữ liệu tốt nên được thực hiện theo nguyên tắc:
Xác định → Đối chiếu → Phân loại → Sao lưu → Xóa → Làm sạch dữ liệu liên quan → Kiểm tra → Ghi nhận
Quy trình dưới đây được thiết kế theo hướng tổng quát, có thể áp dụng cho nhiều loại sản phẩm SaaS có kiến trúc gồm nhiều hệ thống và cơ sở dữ liệu.
1. Xác định mục tiêu của việc làm sạch dữ liệu
Trước khi bắt đầu, cần xác định rõ tại sao dữ liệu cần được xóa hoặc làm sạch.
Thông thường có hai trường hợp chính:
Trường hợp 1: Khách hàng đã ngừng sử dụng
Khách hàng đã kết thúc hợp đồng, đóng tài khoản hoặc không còn sử dụng dịch vụ.
Mục tiêu là loại bỏ dữ liệu không còn cần thiết khỏi hệ thống theo chính sách lưu trữ của sản phẩm.
Trường hợp 2: Khách hàng vẫn đang sử dụng nhưng có quá nhiều dữ liệu
Không phải lúc nào dữ liệu lớn cũng đồng nghĩa với việc khách hàng phải bị xóa.
Ví dụ, một khách hàng vẫn đang hoạt động nhưng đã tích lũy hàng triệu bản ghi lịch sử.
Trong trường hợp này, có thể chỉ cần làm sạch dữ liệu cũ thay vì xóa toàn bộ khách hàng.
Ví dụ:
- Giữ dữ liệu trong 12 tháng gần nhất.
- Xóa lịch sử trước một thời điểm nhất định.
- Xóa các bản ghi không còn phục vụ nghiệp vụ.
- Giữ lại dữ liệu cần thiết cho báo cáo hoặc kiểm toán.
Mục tiêu tổng quát
Một quy trình làm sạch dữ liệu thường hướng tới:
- Giảm dữ liệu không còn giá trị.
- Giảm dung lượng lưu trữ.
- Giảm tải cho cơ sở dữ liệu.
- Giảm dữ liệu rác trong các hệ thống phụ trợ.
- Đảm bảo dữ liệu giữa các hệ thống không bị lệch.
- Giảm nguy cơ tài khoản hoặc dữ liệu cũ tiếp tục tồn tại ngoài ý muốn.
2. Lập danh sách các khách hàng cần xử lý
Không nên bắt đầu bằng việc xóa trực tiếp trên Database.
Bước đầu tiên là tạo một danh sách quản lý tập trung cho các khách hàng cần xem xét.
Danh sách này có thể được lưu trong spreadsheet, database quản lý nội bộ hoặc một hệ thống ticket.
Các thông tin nên có:
| Thông tin | Ý nghĩa |
|---|---|
| Customer Name | Tên khách hàng |
| Customer ID | Định danh chính |
| Tenant ID | Định danh tenant nếu hệ thống sử dụng multi-tenant |
| Domain | Domain hoặc workspace của khách hàng |
| Trạng thái | Đang sử dụng / đã ngừng / cần kiểm tra |
| Ngày ngừng sử dụng | Thời điểm khách hàng kết thúc |
| Dung lượng dữ liệu | Lượng dữ liệu khách hàng đang sử dụng |
| Số lượng user | Tổng số người dùng |
| Hệ thống liên quan | Các hệ thống đang lưu dữ liệu |
| Người phụ trách | Người thực hiện xử lý |
| Ngày backup | Thời điểm sao lưu |
| Ngày xóa | Thời điểm hoàn tất |
| Trạng thái xử lý | Chưa xử lý / đang xử lý / hoàn tất |
Tại sao bước này quan trọng?
Danh sách này đóng vai trò như một bảng điều khiển của toàn bộ quy trình.
Thay vì phải nhớ:
"Khách hàng A đã xóa ở đâu rồi?"
Có thể nhìn vào bảng và biết:
"Khách hàng A đã được backup, đã xóa khỏi hệ thống người dùng, nhưng Database vẫn chưa được xử lý."
Điều này đặc biệt quan trọng khi phải xử lý hàng chục hoặc hàng trăm khách hàng.
3. Xác định khách hàng trên tất cả các hệ thống
Một khách hàng trong SaaS thường không chỉ tồn tại ở một Collection trong Database.
Ví dụ một hệ thống có thể gồm:
Customer
│
┌────────────┼────────────┐
↓ ↓ ↓
Access System Customer User
│ Database Database
│ │ │
↓ ↓ ↓
Accounts Saved Contacts User Info
Info Activities
Vì vậy, cần xác định định danh của cùng một khách hàng trên từng hệ thống.
Có thể cần thu thập:
- Customer ID
- Tenant ID
- Workspace ID
- User ID
- Integration ID
- Domain
- Account ID
- Các ID liên quan khác
Nguyên tắc quan trọng
Không nên giả định rằng:
"Tên khách hàng giống nhau = cùng một khách hàng."
Tên có thể thay đổi hoặc bị trùng.
Thay vào đó, nên sử dụng ID duy nhất làm cơ sở xác định dữ liệu.
4. Đối chiếu dữ liệu giữa các hệ thống
Sau khi có các ID, cần kiểm tra xem khách hàng thực sự đang tồn tại ở đâu.
Ví dụ:
| Khách hàng | User System | Application | Database | Integration |
|---|---|---|---|---|
| Customer A | ✓ | ✓ | ✓ | ✓ |
| Customer B | ✓ | ✓ | ✓ | ✗ |
| Customer C | ✓ | ✗ | ✓ | ✗ |
Bảng này giúp phát hiện những tình huống bất thường.
Ví dụ:
- Tài khoản đã bị xóa nhưng Database vẫn còn dữ liệu.
- Database còn dữ liệu nhưng hệ thống chính không còn tenant.
- User vẫn tồn tại mặc dù khách hàng đã đóng tài khoản.
- Dữ liệu tích hợp vẫn còn dù integration đã bị xóa.
Mục tiêu
Tạo được một bức tranh đầy đủ về dữ liệu của khách hàng trước khi xóa.
Đây là bước rất quan trọng vì nó giúp tránh việc xóa theo kiểu "đoán".
5. Xác định khách hàng thực sự đủ điều kiện để xóa
Không phải khách hàng nào nằm trong danh sách cũng có thể xóa ngay.
Cần xác định trạng thái của khách hàng dựa trên các nguồn thông tin đáng tin cậy.
Ví dụ:
- Đã kết thúc hợp đồng.
- Đã đóng tài khoản.
- Đã được archive.
- Không còn hoạt động.
- Không còn nghĩa vụ lưu trữ dữ liệu.
- Đã hoàn tất các yêu cầu hỗ trợ liên quan.
- Không còn quy trình nghiệp vụ nào phụ thuộc vào dữ liệu.
Một nguyên tắc quan trọng
Không nên dùng một dấu hiệu duy nhất để quyết định xóa.
Ví dụ:
"Không đăng nhập trong 90 ngày" không nhất thiết có nghĩa là khách hàng đã ngừng sử dụng.
Nên kết hợp nhiều nguồn thông tin để xác định trạng thái.
6. Phân loại dữ liệu trước khi xóa
Trước khi thực hiện thao tác xóa, hãy chia dữ liệu thành các nhóm.
Nhóm 1: Dữ liệu chắc chắn cần xóa
Ví dụ:
- Tài khoản đã đóng.
- User không còn sử dụng.
- Dữ liệu nghiệp vụ của tenant đã kết thúc.
Nhóm 2: Dữ liệu cần giữ lại
Ví dụ:
- Dữ liệu phục vụ pháp lý.
- Dữ liệu cần cho kiểm toán.
- Dữ liệu cần cho báo cáo.
- Dữ liệu nằm trong thời gian lưu trữ bắt buộc.
Nhóm 3: Dữ liệu cần kiểm tra thêm
Ví dụ:
- Dữ liệu liên quan đến nhiều khách hàng.
- Dữ liệu không xác định được owner.
- Dữ liệu có quan hệ với một integration khác.
- Dữ liệu cũ nhưng chưa xác định được chính sách lưu trữ.
Không nên xóa nhóm 3 cho đến khi xác định rõ nguồn gốc và quan hệ của dữ liệu.
7. Sao lưu trước khi xóa
Trước khi thực hiện thao tác không thể hoàn tác, cần xác định:
"Nếu xóa nhầm thì có cách nào khôi phục không?"
Nếu câu trả lời là không, cần thực hiện backup hoặc snapshot phù hợp trước khi tiếp tục.
Backup có thể bao gồm:
- Database backup.
- Collection/table backup.
- Export dữ liệu.
- Snapshot storage.
- Backup cấu hình.
- Backup các thông tin định danh cần thiết.
Sau khi backup, nên ghi lại:
- Backup được tạo khi nào.
- Backup nằm ở đâu.
- Backup thuộc khách hàng nào.
- Backup có thể khôi phục hay không.
Đừng chỉ kiểm tra "backup đã chạy"
Nếu dữ liệu quan trọng, cần xác minh backup thực sự có thể sử dụng.
Một backup không thể restore về thực tế cũng không mang lại nhiều giá trị khi xảy ra sự cố.
8. Xóa tài khoản và dữ liệu trên các hệ thống phụ trợ
Sau khi xác định chắc chắn phạm vi xóa, có thể bắt đầu xử lý các hệ thống bên ngoài Database chính.
Ví dụ:
- Hệ thống quản lý tài khoản.
- Hệ thống xác thực.
- Hệ thống quản lý workspace.
- PBX hoặc hệ thống liên lạc.
- Hệ thống integration.
- File storage.
Mục tiêu là loại bỏ những thành phần không còn cần thiết.
Ví dụ
Một khách hàng đã ngừng sử dụng có thể còn:
Customer
├── Users
├── Authentication accounts
├── Workspace
├── Integrations
├── Communication accounts
└── Application data
Không nên chỉ xóa Customer rồi giả định mọi thứ khác tự biến mất.
Cần kiểm tra từng thành phần.
9. Làm sạch user không còn sử dụng
Ngay cả khách hàng đang hoạt động cũng có thể tồn tại những user dư thừa.
Ví dụ:
Application
├── User A ✓
├── User B ✓
└── User C ✗
Authentication System
├── User A ✓
├── User B ✓
├── User C ✓
└── User D ✗
Trong trường hợp này:
- User A: hợp lệ.
- User B: hợp lệ.
- User C: cần kiểm tra/xử lý.
- User D: có thể là tài khoản dư thừa.
Cách xử lý
- Lấy danh sách user từ hệ thống chính.
- Lấy danh sách user từ hệ thống xác thực.
- So sánh bằng ID hoặc định danh đáng tin cậy.
- Xác định user chỉ tồn tại ở một phía.
- Kiểm tra nguyên nhân.
- Chỉ xóa khi chắc chắn user không còn được sử dụng.
Tại sao không nên xóa ngay user "không tìm thấy"?
Có thể xảy ra trường hợp:
- Hai hệ thống đồng bộ không đồng thời.
- User vừa được tạo.
- User đang trong quá trình migration.
- User tồn tại dưới một ID khác.
Vì vậy, không tìm thấy dữ liệu ở một hệ thống chưa đủ để kết luận dữ liệu đó là rác.
10. Lập bản đồ dữ liệu trong Database
Đây là bước quan trọng khi một khách hàng có dữ liệu phân tán ở nhiều bảng hoặc collection.
Thay vì xóa trực tiếp, trước tiên hãy lập một bản đồ dữ liệu.
Ví dụ:
| Customer ID | Contacts | Activities | Calls | Users | Tickets |
|---|---|---|---|---|---|
| customer_001 | ✓ | ✓ | ✓ | ✓ | ✗ |
| customer_002 | ✓ | ✗ | ✓ | ✓ | ✓ |
| customer_003 | ✗ | ✗ | ✗ | ✓ | ✗ |
Bảng này trả lời câu hỏi:
"Dữ liệu của khách hàng này đang nằm ở đâu?"
Có thể hình dung như sau
Customer ID
│
┌────────────────┼────────────────┐
↓ ↓ ↓
Contacts Activities Users
│ │
↓ ↓
Calls Logs
│
↓
Integrations
Mỗi mũi tên đại diện cho một quan hệ giữa các dữ liệu.
Khi hiểu được quan hệ này, việc xóa sẽ an toàn hơn rất nhiều.
11. Xác định dữ liệu dư thừa
Sau khi lập bản đồ dữ liệu, bắt đầu tìm các ID hoặc record không còn được sử dụng.
Có thể gặp các trường hợp:
- ID không còn thuộc khách hàng nào.
- Record không còn tham chiếu đến dữ liệu chính.
- Dữ liệu được tạo bởi một tenant đã bị xóa.
- User đã bị xóa nhưng dữ liệu phụ vẫn còn.
- Integration đã bị xóa nhưng dữ liệu lịch sử vẫn tồn tại.
- Record cũ không còn được hệ thống sử dụng.
Tuy nhiên, cần phân biệt:
Không được tham chiếu ≠ chắc chắn có thể xóa.
Một record có thể không được tham chiếu trực tiếp nhưng vẫn cần thiết cho:
- Báo cáo.
- Audit.
- Lịch sử giao dịch.
- Khôi phục dữ liệu.
- Yêu cầu pháp lý.
Do đó, việc xác định dữ liệu rác cần dựa trên quan hệ dữ liệu + nghiệp vụ + chính sách lưu trữ.
12. Xóa dữ liệu trong Database
Khi phạm vi đã được xác định, có thể thực hiện xóa.
Một quy trình an toàn thường là:
Bước 1 — Xác định ID chính
Ví dụ:
Tenant ID = tenant_001
Bước 2 — Tìm các ID liên quan
Tenant
├── Users
├── Contacts
├── Activities
├── Calls
└── Integrations
Bước 3 — Xác định nơi lưu trữ
Ví dụ:
tenant_001
↓
Contacts
Activities
CallLogs
Users
Tickets
Bước 4 — Kiểm tra số lượng record
Trước khi xóa nên biết:
Contacts: 12,500
Activities: 83,200
Call Logs: 41,300
Users: 18
Việc này giúp phát hiện bất thường.
Ví dụ:
Dự kiến chỉ có 18 user nhưng truy vấn trả về 180.000 user.
Đó có thể là dấu hiệu truy vấn sai điều kiện.
Bước 5 — Xóa
Chỉ thực hiện sau khi xác nhận:
- Đúng tenant.
- Đúng ID.
- Đúng phạm vi.
- Đúng loại dữ liệu.
13. Xử lý khách hàng vẫn đang hoạt động nhưng có dữ liệu quá lớn
Deletion không chỉ dành cho khách hàng đã ngừng sử dụng.
Đối với khách hàng vẫn đang hoạt động nhưng dữ liệu tăng quá nhanh, có thể áp dụng data cleanup.
Ví dụ:
Customer A
│
├── Current data
│ ├── Users
│ ├── Contacts
│ └── Active records
│
└── Historical data
├── Activities > 2 years
├── Call Logs > 2 years
└── Old records
Thay vì xóa toàn bộ Customer A, chỉ xử lý phần dữ liệu lịch sử không còn cần thiết.
Một số chiến lược
Xóa theo thời gian
DELETE records
WHERE created_at < retention_date
Xóa theo loại dữ liệu
Ví dụ chỉ làm sạch:
- Activity.
- Log.
- Call history.
Trong khi vẫn giữ:
- User.
- Contact đang hoạt động.
- Cấu hình.
- Dữ liệu nghiệp vụ hiện tại.
Archive thay vì Delete
Nếu dữ liệu vẫn có giá trị nhưng không cần truy cập thường xuyên, có thể chuyển sang storage/archive rẻ hơn thay vì xóa hoàn toàn.
14. Kiểm tra sau khi xóa
Đây là bước thường bị bỏ qua nhưng rất quan trọng.
Sau khi xóa, không nên chỉ kiểm tra:
"Lệnh DELETE chạy thành công."
Cần kiểm tra:
Kiểm tra 1 — Dữ liệu chính đã biến mất chưa?
Ví dụ:
Customer ID = tenant_001
Users = 0
Contacts = 0
Activities = 0
Calls = 0
Kiểm tra 2 — Dữ liệu phụ còn tồn tại không?
Tìm các record vẫn chứa ID của khách hàng.
Kiểm tra 3 — Hệ thống có còn nhận diện khách hàng không?
Kiểm tra:
- User system.
- Application.
- Integration.
- Storage.
- Các hệ thống phụ trợ.
Kiểm tra 4 — Có xóa nhầm dữ liệu không?
So sánh số lượng record trước và sau khi xóa.
Ví dụ:
Trước:
Customer A → 150,000 records
Customer B → 120,000 records
Sau:
Customer A → 0 records
Customer B → 120,000 records
Nếu Customer B giảm dữ liệu, cần dừng quy trình và kiểm tra ngay.
15. Ghi nhận kết quả
Mỗi lần xử lý nên được ghi nhận lại.
Ví dụ:
| Customer | Backup | Account | Database | Cleanup | Verification | Status |
|---|---|---|---|---|---|---|
| Customer A | ✓ | ✓ | ✓ | ✓ | ✓ | Done |
| Customer B | ✓ | ✓ | ✓ | ✗ | ✗ | Processing |
| Customer C | ✓ | ✗ | ✗ | ✗ | ✗ | Pending |
Việc ghi nhận giúp:
- Biết khách hàng nào đã xử lý.
- Biết bước nào còn thiếu.
- Tránh thực hiện xóa hai lần.
- Dễ truy vết khi có sự cố.
- Có lịch sử phục vụ kiểm tra sau này.
16. Checklist tổng quát
- Xác định lý do cần làm sạch/xóa dữ liệu
- Lập danh sách khách hàng cần xử lý
- Xác định Customer/Tenant ID
- Xác định các ID liên quan
- Kiểm tra khách hàng trên tất cả hệ thống
- Xác định khách hàng có đủ điều kiện xóa hay không
- Phân loại dữ liệu cần xóa và cần giữ
- Kiểm tra chính sách lưu trữ dữ liệu
- Backup dữ liệu cần thiết
- Xác minh backup
- Xóa tài khoản và dữ liệu ở các hệ thống phụ trợ
- Đối chiếu user giữa các hệ thống
- Xóa user dư thừa nếu đủ điều kiện
- Lập bản đồ dữ liệu trong Database
- Xác định các record/ID dư thừa
- Kiểm tra số lượng dữ liệu trước khi xóa
- Xóa dữ liệu trong Database
- Làm sạch dữ liệu liên quan
- Kiểm tra dữ liệu sau khi xóa
- Kiểm tra nguy cơ xóa nhầm dữ liệu khác
- Ghi nhận ngày và trạng thái hoàn tất
17. Sơ đồ tổng quan của quy trình
Có thể minh họa toàn bộ quy trình bằng một sơ đồ như sau:
18. Một nguyên tắc quan trọng: Đừng bắt đầu bằng thao tác xóa
Điểm quan trọng nhất của toàn bộ quy trình là:
Xóa dữ liệu là bước cuối cùng, không phải bước đầu tiên.
Một quy trình tốt cần trả lời được bốn câu hỏi trước khi thực hiện Delete:
- Tôi đang xóa dữ liệu của ai?
- Dữ liệu của họ đang nằm ở đâu?
- Tôi chắc chắn dữ liệu này được phép xóa chưa?
- Nếu xóa nhầm, tôi có thể khôi phục không?
Chỉ khi cả bốn câu hỏi đều có câu trả lời rõ ràng, việc xóa mới nên được thực hiện.
Kết luận
Một hệ thống SaaS càng lớn thì dữ liệu của một khách hàng càng có khả năng được phân tán trên nhiều thành phần. Vì vậy, quy trình làm sạch dữ liệu không nên được xem đơn thuần là một thao tác Database.
Đó là một quy trình quản lý vòng đời dữ liệu:
Xác định khách hàng → Tìm toàn bộ dữ liệu → Kiểm tra quan hệ → Xác định dữ liệu cần giữ/xóa → Sao lưu → Xóa → Làm sạch dữ liệu liên quan → Kiểm tra → Ghi nhận.
Đối với khách hàng đã ngừng sử dụng, quy trình này giúp loại bỏ dữ liệu không còn cần thiết một cách có kiểm soát. Đối với khách hàng vẫn đang hoạt động, cùng nguyên tắc có thể được sử dụng để dọn dẹp dữ liệu lịch sử, giảm dung lượng và duy trì hiệu năng mà không ảnh hưởng đến dữ liệu hiện tại.
Điều quan trọng nhất không phải là xóa được bao nhiêu dữ liệu, mà là xóa đúng dữ liệu, đúng đối tượng và có thể chứng minh rằng hệ thống vẫn an toàn sau khi xóa.
Nếu bạn đang tìm một giải pháp tổng đài SIP có khả năng tích hợp CRM, quản lý cuộc gọi và mở rộng theo mô hình SaaS, bạn có thể bắt đầu bằng việc trải nghiệm demo thực tế trước khi triển khai toàn hệ thống.
Đăng ký dùng thử hệ thống tổng đài miễn phí tại đây: Đăng ký ngay!