Mở đầu — vì sao bài này quan trọng
Có một quan niệm sai lầm rất phổ biến trong giới Business Analyst (BA): "Performance là việc của DBA và lập trình viên, không phải của tôi." Nghe có vẻ hợp lý, vì BA đâu có viết code, đâu có chỉnh index, đâu có tune query. Nhưng đây chính là cái bẫy khiến nhiều dự án phải trả giá đắt.
Sự thật là phần lớn các vấn đề hiệu năng (performance) nghiêm trọng nhất không nằm ở dòng code, mà nằm ở những quyết định được đưa ra rất sớm — ở giai đoạn thu thập yêu cầu và thiết kế mô hình dữ liệu. Khi một mô hình dữ liệu đã được triển khai, hàng triệu bản ghi đã chảy vào, và hàng chục ứng dụng đã phụ thuộc vào nó, thì việc sửa một quyết định thiết kế sai lầm không còn là "fix một bug" nữa — nó là một dự án di trú (migration) tốn kém, rủi ro cao, có thể kéo dài hàng tháng.
BA là người đứng ở vị trí then chốt: bạn là người định nghĩa yêu cầu phi chức năng (Non-Functional Requirements — NFR), bạn là người hiểu khối lượng dữ liệu sẽ phát sinh, bạn là người biết người dùng kỳ vọng màn hình tải trong bao lâu. Nếu bạn không đặt đúng câu hỏi về performance ngay từ đầu, không ai khác sẽ làm thay. Bài này không biến bạn thành chuyên gia tối ưu cơ sở dữ liệu — mục tiêu là giúp bạn, với tư cách BA, biết phải quan tâm điều gì, hỏi điều gì, và đưa thông tin gì vào tài liệu để đội kỹ thuật có thể thiết kế đúng ngay từ ngày đầu.
Khái niệm cốt lõi
Performance dưới góc nhìn của BA
Khi nói "hệ thống nhanh hay chậm", chúng ta thực ra đang nói về một vài đại lượng đo được. BA không cần biết cách đo chúng bằng công cụ, nhưng cần hiểu chúng nghĩa là gì để diễn đạt yêu cầu cho rõ ràng.
- Response time (thời gian phản hồi): Mất bao lâu để hệ thống trả về kết quả sau khi người dùng nhấn nút. Ví dụ: "Màn hình tra cứu lịch sử giao dịch phải hiển thị trong vòng 2 giây."
- Throughput (thông lượng): Số lượng giao dịch hệ thống xử lý được trong một đơn vị thời gian. Ví dụ: "Cổng thanh toán phải xử lý được 500 giao dịch mỗi giây vào giờ cao điểm."
- Concurrency (số người dùng đồng thời): Bao nhiêu người dùng cùng thao tác một lúc. Một báo cáo chạy nhanh khi chỉ có bạn dùng, nhưng có thể sập khi 2.000 nhân viên cùng mở vào sáng thứ Hai.
- Data volume (khối lượng dữ liệu): Bảng có 10.000 dòng và bảng có 500 triệu dòng đòi hỏi cách thiết kế hoàn toàn khác nhau. Đây là biến số mà BA thường nắm rõ nhất qua tiếp xúc nghiệp vụ.
NFR — nơi performance chính thức trở thành trách nhiệm của BA
Performance không phải là "điều nên có", nó là một loại yêu cầu phi chức năng (NFR). Yêu cầu chức năng trả lời câu hỏi "hệ thống làm gì", còn NFR trả lời "hệ thống làm tốt đến mức nào". Một câu yêu cầu kiểu "Người dùng có thể xem báo cáo doanh thu" là chưa đủ. Câu đầy đủ phải là: "Người dùng có thể xem báo cáo doanh thu của 12 tháng gần nhất, với dữ liệu lên đến 5 triệu dòng hóa đơn, hiển thị trong vòng 3 giây, khi có tối đa 200 người dùng đồng thời."
Sự khác biệt giữa hai câu này quyết định toàn bộ kiến trúc dữ liệu phía sau. Câu thứ hai cho đội kỹ thuật biết họ cần index gì, có cần bảng tổng hợp (summary table) không, có cần tách cơ sở dữ liệu báo cáo riêng không. Viết NFR mơ hồ chính là đẩy quả bóng rủi ro về phía tương lai.
Vì sao thiết kế sai lại đắt — quy luật "chi phí nhân lên theo thời gian"
Trong kỹ thuật phần mềm có một nguyên lý kinh điển: chi phí sửa một lỗi tăng theo cấp số nhân qua từng giai đoạn dự án. Một quyết định mô hình dữ liệu sai phát hiện ở giai đoạn phân tích chỉ tốn vài giờ sửa tài liệu. Cũng lỗi đó phát hiện sau khi go-live, khi đã có 300 triệu bản ghi, có thể cần dừng hệ thống, viết script di trú, kiểm thử lại toàn bộ ứng dụng phụ thuộc — chi phí gấp hàng trăm lần. Đây chính là lý do BA phải tư duy về performance ngay từ những buổi phỏng vấn nghiệp vụ đầu tiên, chứ không đợi đến lúc "có gì chậm thì tính sau".
Những quyết định thiết kế ảnh hưởng performance mà BA cần nhận biết
BA không cần tự tay làm những việc dưới đây, nhưng cần nhận ra khi nào chúng liên quan để nêu vấn đề với đội kỹ thuật:
- Mức độ chuẩn hóa (normalization) so với phi chuẩn hóa (denormalization): Mô hình chuẩn hóa cao giúp dữ liệu sạch, nhưng truy vấn báo cáo phải join nhiều bảng nên có thể chậm. BA là người biết "báo cáo này chạy hàng ngày bởi 500 người" — thông tin quyết định liệu có nên phi chuẩn hóa hay không.
- Index (chỉ mục): Cột nào người dùng hay tìm kiếm, lọc, sắp xếp? Đó là gợi ý vàng để đội kỹ thuật biết nên đánh index ở đâu. BA chính là người nắm các mẫu truy vấn nghiệp vụ này.
- Khối lượng và tốc độ tăng trưởng dữ liệu: Bảng giao dịch tăng bao nhiêu dòng mỗi ngày? Dữ liệu cũ có cần lưu trữ vĩnh viễn hay được phép đẩy sang kho lưu trữ (archive)?
- Tách OLTP và OLAP: Hệ thống vận hành (xử lý giao dịch) và hệ thống báo cáo (phân tích) có nhu cầu performance đối nghịch nhau. BA cần nhận diện khi một yêu cầu báo cáo nặng có nguy cơ làm chậm hệ thống giao dịch.
Tình huống thực tế
Tình huống 1 — Sàn thương mại điện tử và cái bẫy báo cáo trên database chính
Một sàn thương mại điện tử tầm trung tại TP.HCM, gọi là ShopViet, ban đầu chạy rất ổn với khoảng 50.000 đơn hàng mỗi tháng. Đội phát triển dựng một màn hình "Dashboard doanh thu" cho phòng kinh doanh, truy vấn trực tiếp lên bảng orders của hệ thống bán hàng. Mọi thứ tải trong chưa đầy một giây — ai cũng hài lòng.
Mười tám tháng sau, ShopViet bùng nổ lên 1,2 triệu đơn mỗi tháng. Mỗi sáng, khi 40 nhân viên kinh doanh đồng loạt mở dashboard quét toàn bộ lịch sử đơn hàng để dựng biểu đồ, cơ sở dữ liệu chính bị khóa và treo. Hệ quả không chỉ là dashboard chậm — chính trang thanh toán của khách hàng cũng timeout, vì cùng một database vừa phải phục vụ giao dịch vừa phải gánh báo cáo nặng. Doanh thu thực tế bị mất trong những phút cao điểm đó.
Bài học: Vấn đề gốc không phải là code dở, mà là không ai đặt câu hỏi "báo cáo này sẽ chạy trên dữ liệu lớn cỡ nào, bao nhiêu người dùng, và có nên tách khỏi database giao dịch không". Nếu BA của ShopViet đã ghi vào NFR rằng "báo cáo doanh thu phải hỗ trợ tối thiểu 24 tháng dữ liệu, 50 người dùng đồng thời, và không được ảnh hưởng đến hệ thống bán hàng", thì ngay từ đầu đội kỹ thuật đã chọn giải pháp tách cơ sở dữ liệu báo cáo (read replica hoặc reporting database) riêng. Một dòng NFR đúng lúc đã có thể tiết kiệm hàng tháng khắc phục khủng hoảng.
Tình huống 2 — Ngân hàng và cột tìm kiếm không được lường trước
Một ngân hàng cổ phần triển khai hệ thống tra cứu khách hàng cho các giao dịch viên tại quầy. Trong tài liệu yêu cầu, BA mô tả chức năng: "Giao dịch viên có thể tìm khách hàng theo số CCCD." Đúng chức năng, nhưng thiếu một chi tiết: số lượng khách hàng sẽ lên đến 8 triệu người, và mỗi giao dịch viên thực hiện hàng trăm lượt tra cứu mỗi ngày.
Khi đưa vào vận hành với dữ liệu thật, mỗi lần tra cứu số CCCD mất 6-9 giây vì hệ thống phải quét toàn bộ bảng (full table scan) — cột CCCD chưa được đánh index. Tại quầy, mỗi khách hàng phải chờ thêm gần chục giây, hàng dài lên, khiếu nại tăng. Đội DBA sau đó phải thêm index khẩn cấp, nhưng việc thêm index trên bảng 8 triệu dòng đang vận hành lại đòi hỏi cửa sổ bảo trì ban đêm và kiểm thử cẩn thận để không khóa bảng.
Bài học: BA hoàn toàn có thể phòng ngừa việc này. Khi mô tả một chức năng tìm kiếm, hãy luôn ghi rõ "tìm theo cột nào" và "trên khối lượng dữ liệu bao nhiêu". Thông tin "tìm theo CCCD trên 8 triệu khách hàng, hàng trăm lượt/ngày/người" là tín hiệu rõ ràng để đội kỹ thuật biết cột này bắt buộc phải có index ngay từ thiết kế ban đầu, chứ không vá víu sau.
Tình huống 3 — Ứng dụng giao đồ ăn và quyết định phi chuẩn hóa đúng lúc
Một startup giao đồ ăn ở Đông Nam Á, tạm gọi là FoodNow, có màn hình danh sách nhà hàng mà người dùng cuộn xem liên tục. Mỗi thẻ nhà hàng cần hiển thị: tên, ảnh, điểm đánh giá trung bình và số lượt đánh giá. Mô hình chuẩn hóa ban đầu lưu từng đánh giá trong bảng reviews riêng; để tính điểm trung bình, hệ thống phải gom (aggregate) hàng nghìn dòng đánh giá mỗi lần render danh sách.
Với 3 triệu người dùng hoạt động hàng ngày, mỗi lần mở app là một loạt phép tính trung bình chạy đồng thời, khiến màn hình chủ tải chậm 4-5 giây — tỷ lệ người dùng rời app tăng vọt. Giải pháp: đội kỹ thuật thêm hai cột phi chuẩn hóa avg_rating và review_count ngay trên bảng restaurants, cập nhật chúng mỗi khi có đánh giá mới. Màn hình chủ tải gần như tức thì.
Bài học: Phi chuẩn hóa là con dao hai lưỡi — nó đánh đổi tính toàn vẹn dữ liệu lấy tốc độ. Quyết định này không nên do BA tự ý đưa ra, nhưng BA chính là người cung cấp dữ kiện then chốt để cân nhắc: "màn hình này được mở 3 triệu lần mỗi ngày, người dùng rời đi nếu chậm". Khi BA mô tả rõ tần suất truy cập và mức độ nhạy cảm với độ trễ, đội kỹ thuật mới có cơ sở để chọn đánh đổi đúng đắn.
Hướng dẫn từng bước
Đây là quy trình thực dụng để BA tích hợp tư duy performance vào công việc hàng ngày:
Bước 1 — Trong buổi phỏng vấn nghiệp vụ, luôn hỏi về "ba con số". Với mỗi chức năng quan trọng, hãy hỏi: (1) Khối lượng dữ liệu hiện tại và tốc độ tăng trưởng? (2) Bao nhiêu người dùng đồng thời vào giờ cao điểm? (3) Người dùng kỳ vọng thời gian phản hồi tối đa là bao nhiêu? Ba con số này là nền tảng của mọi NFR về performance.
Bước 2 — Xác định các mẫu truy cập (access patterns). Với mỗi thực thể dữ liệu, ghi lại người dùng thường tìm kiếm theo cột nào, lọc theo cột nào, sắp xếp theo cột nào, và join với bảng nào. Đây là tài liệu quý giá nhất bạn có thể trao cho đội kỹ thuật để họ thiết kế index hợp lý.
Bước 3 — Phân loại từng chức năng là OLTP hay OLAP. Hỏi: chức năng này phục vụ vận hành (ghi/đọc giao dịch lẻ, cần nhanh và nhất quán) hay phục vụ phân tích (đọc khối lớn, dựng báo cáo)? Đánh dấu rõ những chức năng báo cáo nặng có nguy cơ ảnh hưởng hệ thống vận hành.
Bước 4 — Viết NFR performance cụ thể, đo lường được. Tránh từ ngữ mơ hồ như "nhanh", "phản hồi tốt". Thay vào đó dùng con số: "≤ 2 giây", "500 TPS", "200 người dùng đồng thời". Một NFR tốt phải kiểm thử được.
Bước 5 — Phối hợp sớm với DBA và kiến trúc sư. Đưa tài liệu mẫu truy cập và NFR cho đội kỹ thuật ngay từ giai đoạn thiết kế mô hình, không đợi đến lúc kiểm thử hiệu năng (performance testing) cuối dự án. Đặt câu hỏi: "Với khối lượng và mẫu truy cập này, thiết kế hiện tại có chịu được không?"
Bước 6 — Đưa kịch bản tải vào kế hoạch kiểm thử (UAT). Đảm bảo đội kiểm thử mô phỏng dữ liệu thực tế (không phải vài chục dòng giả) và số người dùng đồng thời thực tế. Rất nhiều vấn đề performance chỉ lộ ra khi có dữ liệu lớn.
Lỗi thường gặp & mẹo
Lỗi 1 — Kiểm thử trên dữ liệu nhỏ rồi yên tâm. Hệ thống chạy mượt với 1.000 dòng dữ liệu test nhưng sập với 50 triệu dòng thật. Đây là cái bẫy phổ biến nhất. Mẹo: Luôn yêu cầu kiểm thử trên khối lượng dữ liệu mô phỏng tương đương mức dự kiến sau 2-3 năm vận hành.
Lỗi 2 — Viết NFR mơ hồ. "Hệ thống phải nhanh và ổn định" không có ý nghĩa kỹ thuật. Mẹo: Mỗi NFR phải có con số và điều kiện kiểm thử rõ ràng.
Lỗi 3 — Quên hỏi về tăng trưởng dữ liệu. BA thường chỉ hỏi khối lượng hiện tại mà quên tốc độ tăng. Một bảng tăng 2 triệu dòng/tháng sẽ rất khác sau hai năm. Mẹo: Luôn hỏi cả "bây giờ bao nhiêu" và "tăng bao nhiêu mỗi tháng".
Lỗi 4 — Để báo cáo nặng chạy chung với hệ thống vận hành. Như tình huống ShopViet. Mẹo: Bất cứ khi nào thấy một báo cáo quét dữ liệu lớn, hãy nêu vấn đề tách cơ sở dữ liệu báo cáo với đội kiến trúc.
Lỗi 5 — Tự ý đề xuất giải pháp kỹ thuật. BA nói "chỗ này phải thêm index" hay "phải phi chuẩn hóa" là vượt vai trò. Mẹo: Hãy cung cấp dữ kiện nghiệp vụ (khối lượng, tần suất, kỳ vọng) và để đội kỹ thuật chọn giải pháp. Vai trò của bạn là đặt đúng câu hỏi, không phải trả lời thay họ.
Mẹo vàng: Hãy xem mỗi NFR performance như một "hợp đồng" giữa nghiệp vụ và kỹ thuật. Nếu nó không đo được, không kiểm thử được, thì nó không phải là yêu cầu — nó chỉ là một mong muốn.
Bài tập thực hành
Bạn nhận được yêu cầu sau từ phòng nhân sự của một tập đoàn bán lẻ có 12.000 nhân viên: "Xây màn hình cho phép quản lý xem báo cáo chấm công của toàn bộ nhân viên theo tháng, có thể lọc theo chi nhánh và phòng ban."
- Viết lại yêu cầu này thành một NFR performance đầy đủ, có ít nhất ba con số đo lường được (gợi ý: khối lượng dữ liệu chấm công, số người dùng đồng thời, thời gian phản hồi mục tiêu).
- Liệt kê các mẫu truy cập (access patterns) bạn dự đoán cho màn hình này: người dùng sẽ lọc, tìm kiếm, sắp xếp theo những cột nào?
- Phân loại chức năng này là OLTP hay OLAP, và giải thích vì sao điều đó ảnh hưởng đến quyết định có nên tách cơ sở dữ liệu báo cáo riêng hay không.
- Soạn ba câu hỏi bạn sẽ đặt cho phòng nhân sự trong buổi phỏng vấn để làm rõ rủi ro performance.
Tóm tắt
Performance không phải là việc bạn "ném qua tường" cho DBA xử lý sau. Là một BA, bạn đứng ở thượng nguồn của mọi quyết định thiết kế dữ liệu, và chính những câu hỏi bạn đặt — hoặc quên đặt — ở giai đoạn phân tích sẽ quyết định hệ thống có chịu nổi tải thực tế hay không. Hãy nhớ ba điều cốt lõi: thứ nhất, performance là một NFR và phải được viết cụ thể, đo lường được; thứ hai, một quyết định mô hình dữ liệu sai phát hiện muộn tốn kém gấp hàng trăm lần so với sửa sớm; thứ ba, vai trò của bạn không phải là chọn giải pháp kỹ thuật, mà là cung cấp dữ kiện nghiệp vụ chính xác — khối lượng dữ liệu, tốc độ tăng trưởng, số người dùng đồng thời, mẫu truy cập và kỳ vọng thời gian phản hồi — để đội kỹ thuật thiết kế đúng. Khi bạn quen với việc hỏi "ba con số" và viết NFR đo được, bạn đã chuyển từ một BA chỉ mô tả chức năng thành một BA thực sự góp phần xây nên những hệ thống bền vững.