Tech Lead lập kế hoạch cho tăng trưởng người dùng 10 lần ra sao?

Question

IT Interview Practice · Accepted Answer

Ở vai trò Tech Lead, tôi sẽ chuyển **“người dùng tăng 10 lần” thành cách sử dụng dự kiến, mục tiêu dịch vụ và kế hoạch team thực hiện được**. Số tài khoản đăng ký chưa cho biết có bao nhiêu request ở thời điểm đông nhất.

Giả sử doanh nghiệp chuẩn bị chiến dịch cho nền tảng đặt hàng. Điều cần bảo đảm là khách vẫn xem hàng, mua và nhận xác nhận được trong chiến dịch, với thời gian và ngân sách hiện có.

## 1. Chuyển tăng trưởng thành workload

Hỏi phía sản phẩm khi nào người dùng tới và họ sẽ làm gì. Tăng dần trong một năm khác với chiến dịch kéo mọi người vào cùng lúc.

Ví dụ minh họa: 100.000 tài khoản với 1% hoạt động đồng thời là 1.000 người cùng dùng. Nếu tỷ lệ là 5%, con số thành 5.000. Đây là giả định ví dụ, không phải tỷ lệ mặc định. Vẫn cần ước lượng tần suất request và công việc mỗi request gây ra.

Liệt kê tải chiến dịch tạo ra:

- Request xem và tìm hàng, kể cả các sản phẩm nổi bật.
- Ghi đơn và thanh toán lúc cao điểm.
- Dung lượng dữ liệu tăng và lịch sử phải giữ.
- Công việc nền như thông báo và báo cáo.

Nhờ đó có workload cụ thể để thử, thay vì yêu cầu chung chung là nhân số server lên mười lần.

## 2. Thống nhất điều gì phải được giữ tốt

Xác định thời gian phản hồi, tỷ lệ lỗi và mức hoàn tất chấp nhận được của các luồng quan trọng. Đặt yêu cầu độ mới dữ liệu và khôi phục ở nơi cần thiết. Báo cáo trễ có thể chấp nhận, còn mua hàng thất bại thì không.

```text
[Campaign assumptions] -> [Expected workload] -> [Service targets]
                                                   |
                                            [Acceptance tests]
```

Các mục tiêu nối công việc kỹ thuật với kết quả của khách hàng. Chúng giúp quyết định cải thiện đã đủ chưa và phần nào được phép giảm chất lượng khi quá tải.

## 3. Đo giới hạn hiện tại trước khi chọn thay đổi

Dùng quan sát production và load test đại diện. Kiểm tra query chậm, kết nối database, CPU, RAM, tuổi công việc trong queue và quota dịch vụ ngoài. Có cả tải lệch vào mặt hàng nổi bật, không chỉ request ngẫu nhiên.

Nếu giới hạn nằm ở kết nối database, thêm node ứng dụng có thể tăng tranh chấp. Nếu giới hạn là quota nhà cung cấp thanh toán, ứng dụng nhanh hơn không làm quota đó tăng.

Thử cả cache lạnh và mất một instance bên cạnh vận hành bình thường. Hệ thống cần đủ khả năng phục hồi trong chiến dịch, không chỉ vừa đủ vượt qua một lần thử lý tưởng.

## 4. Chuyển kết quả đo thành công việc có người phụ trách

| Phát hiện | Hướng xử lý | Bằng chứng cần có |
| --- | --- | --- |
| Nhiều lần đọc lặp tốn kém | Sửa query hoặc cache kết quả phù hợp | Giảm việc ở database với độ mới chấp nhận được. |
| Tác vụ nền tranh tài nguyên với mua hàng | Giới hạn hoặc tách năng lực xử lý | Checkout vẫn tốt khi có tải nền. |
| Quota dịch vụ phụ thuộc chưa đủ | Xin tăng hoặc kiểm soát nhận việc | Quota được xác nhận và hành vi sát giới hạn đã được thử. |
| Sau sửa nhỏ vẫn thiếu năng lực | Đánh giá mở rộng hoặc thay đổi thiết kế lớn hơn | Lợi ích đo được, kế hoạch chuyển đổi và chi phí. |

Mỗi việc cần người phụ trách, ngân sách, phụ thuộc, hạn hoàn thành và bài kiểm tra chấp nhận. Tính cả triển khai, huấn luyện vận hành và chuẩn bị trực sự cố, không chỉ phần code.

Ưu tiên theo tác động khách hàng và rủi ro giao hàng. Viết lại hệ thống hoặc sharding cần lý do đã chứng minh và đủ thời gian chuyển đổi, kiểm chứng.

## 5. Diễn tập chiến dịch và tăng tải từng bước

Phát hành thay đổi theo phần dễ kiểm soát và thử các luồng dự kiến cùng nhau. Xác định lúc nào tăng traffic, dừng tăng hoặc rollback. Thay đổi định dạng dữ liệu có thể cần sửa tiến thay vì quay về phiên bản cũ đơn giản.

Chuẩn bị giảm tải có kiểm soát: trì hoãn export không cấp thiết, giới hạn việc nền hoặc từ chối phần vượt khả năng để giữ hoạt động chính. Kiểm tra những biện pháp này thực sự giảm tải và khách nhận kết quả rõ ràng.

Nếu mục tiêu vượt thời gian hoặc ngân sách, đưa phương án cụ thể cho phía sản phẩm: chia đợt thu hút khách, giảm tính năng tốn kém hoặc đầu tư vào điểm nghẽn đã đo. Giải thích tác động khách hàng và phần chưa chắc chắn của từng phương án.

**Cách nhớ:** giả định tăng trưởng → mục tiêu dịch vụ → giới hạn đo được → kế hoạch có người chịu trách nhiệm → rollout đã diễn tập. Tech Lead bàn giao kế hoạch năng lực có cả con người, chi phí và phục hồi.

Phát hiện	Hướng xử lý	Bằng chứng cần có
Nhiều lần đọc lặp tốn kém	Sửa query hoặc cache kết quả phù hợp	Giảm việc ở database với độ mới chấp nhận được.
Tác vụ nền tranh tài nguyên với mua hàng	Giới hạn hoặc tách năng lực xử lý	Checkout vẫn tốt khi có tải nền.
Quota dịch vụ phụ thuộc chưa đủ	Xin tăng hoặc kiểm soát nhận việc	Quota được xác nhận và hành vi sát giới hạn đã được thử.
Sau sửa nhỏ vẫn thiếu năng lực	Đánh giá mở rộng hoặc thay đổi thiết kế lớn hơn	Lợi ích đo được, kế hoạch chuyển đổi và chi phí.

1. Chuyển tăng trưởng thành workload

2. Thống nhất điều gì phải được giữ tốt

3. Đo giới hạn hiện tại trước khi chọn thay đổi

4. Chuyển kết quả đo thành công việc có người phụ trách

5. Diễn tập chiến dịch và tăng tải từng bước

Câu hỏi liên quan