Claude Code cho điều tra hiệu năng: một quy trình đo lường

Tại sao công việc hiệu năng sai lầm nếu không đo lường

Lỗi hiệu năng dẫn đến phỏng đoán. Ai đó nhận ra một trang có cảm giác chậm hoặc API bị timeout, và động thái nhanh nhất là "dọn dẹp" code, thêm cache, hoặc viết lại một vòng lặp. Vấn đề là "cảm thấy chậm" không phải là một metric, và "gọn gàng hơn" không đồng nghĩa với nhanh hơn.

Không đo lường, đội ngũ tiêu tốn giờ thay đổi chỗ không đúng. Đường nóng có thể nằm ở cơ sở dữ liệu, mạng, hoặc một cấp phát bất ngờ, trong khi nhóm mài giũa mã chạy hầu như không phải là nút thắt. Tệ hơn, một thay đổi có vẻ thông minh có thể làm hiệu năng tệ hơn: logging thêm trong vòng lặp chật, cache làm tăng áp lực bộ nhớ, hoặc công việc song song gây tranh chấp lock.

Phỏng đoán còn làm rủi ro hỏng hành vi. Khi bạn thay code để tăng tốc, bạn có thể thay đổi kết quả, xử lý lỗi, thứ tự xử lý, hoặc cơ chế retry. Nếu không kiểm tra lại đúng/sai cùng với tốc độ, bạn có thể "thắng" benchmark trong khi lén lút đưa một bug vào.

Hãy coi hiệu năng như một thí nghiệm, không phải một cuộc tranh luận. Vòng lặp đơn giản và có thể lặp lại:

• Chọn một metric đại diện cho vấn đề (độ trễ, thông lượng, CPU, bộ nhớ, thời gian DB).
• Lấy một baseline dưới cùng điều kiện.
• Thay đổi một điều nhỏ.
• Đo lại và so sánh.

Nhiều chiến thắng là khiêm tốn: bớt 8% p95, giảm đỉnh bộ nhớ 50 MB, hoặc cắt một truy vấn DB. Những chiến thắng đó vẫn quan trọng, nhưng chỉ khi chúng được đo, xác thực và có thể lặp lại.

Quy trình: đo → giả thuyết → thay đổi → đo lại

Cách này hiệu quả nhất khi là một vòng lặp, không phải một yêu cầu "làm nhanh hơn" một lần. Vòng lặp giữ bạn trung thực vì mọi hành động liên kết với bằng chứng và một con số bạn có thể theo dõi.

Một trình tự rõ ràng:

• Đo: chọn một metric và ghi baseline.
• Giả thuyết: giải thích phần bạn nghĩ là chậm và tại sao.
• Thay đổi: thực hiện điều nhỏ nhất có thể để kiểm tra giả thuyết.
• Đo lại: chạy phép đo giống hệt và so sánh.

Mỗi bước bảo vệ bạn khỏi một kiểu tự lừa khác nhau. Đo trước ngăn bạn "sửa" thứ không phải vấn đề thật. Một giả thuyết viết ra ngăn bạn thay năm thứ cùng lúc rồi đoán cái nào quan trọng. Thay đổi tối thiểu giảm rủi ro phá vỡ hành vi hoặc thêm nút thắt mới. Đo lại phát hiện các chiến thắng placebo (ví dụ lần chạy nhanh hơn do cache ấm) và lộ các thoái lui.

"Xong" không phải là cảm giác. Đó là kết quả: metric mục tiêu di chuyển theo hướng đúng, và thay đổi không gây thoái lui rõ rệt (lỗi, bộ nhớ cao hơn, p95 tệ hơn, hay các endpoint lân cận chậm hơn).

Biết khi nào dừng cũng là một phần của quy trình. Dừng khi lợi ích phẳng lại, khi metric đã đủ tốt cho người dùng, hoặc khi ý tưởng tiếp theo cần refactor lớn cho lợi ích nhỏ. Công việc hiệu năng luôn có chi phí cơ hội; vòng lặp giúp bạn dành thời gian ở nơi có lợi nhất.

Chọn metric và khóa một baseline

Nếu bạn đo năm thứ cùng lúc, bạn sẽ không biết cái nào cải thiện. Chọn một metric chính cho cuộc điều tra này và coi mọi thứ khác là tín hiệu phụ. Với nhiều vấn đề hướng tới người dùng, metric đó là độ trễ. Với công việc theo lô có thể là thông lượng, thời gian CPU, bộ nhớ, hoặc thậm chí chi phí cloud cho mỗi lần chạy.

Cụ thể về kịch bản. "API chậm" quá mơ hồ. "POST /checkout với giỏ hàng điển hình 3 món" thì có thể đo. Giữ input ổn định để các số có ý nghĩa.

Viết baseline và chi tiết môi trường trước khi đụng vào code: kích thước dataset, loại máy, chế độ build, feature flags, concurrency, và warmup. Baseline này là mỏ neo của bạn. Không có nó, mọi thay đổi có thể trông như tiến bộ.

Với độ trễ, dựa vào phân vị, không chỉ trung bình. p50 cho thấy trải nghiệm điển hình, trong khi p95 và p99 lộ phần đuôi đau đớn mà người dùng phàn nàn. Một thay đổi cải thiện p50 nhưng làm p99 tệ hơn vẫn có thể cảm giác chậm hơn.

Quyết định trước thế nào là "có ý nghĩa" để bạn không ăn mừng nhiễu:

• Độ trễ: cải thiện p95 ít nhất 10% (hoặc ngưỡng cố định như 50 ms)
• Thông lượng: tăng ít nhất 5% requests/s cùng tỉ lệ lỗi
• CPU hoặc bộ nhớ: giảm đủ để tránh scale hoặc crash
• Chi phí: giảm có thể đo được cho mỗi lần chạy hoặc mỗi 1.000 request

Khi những quy tắc này đã đặt ra, bạn có thể thử ý tưởng mà không dời mục tiêu.

Thu thập bằng chứng bằng profiling và metric đơn giản

Bắt đầu với tín hiệu đơn giản nhất bạn có thể tin tưởng. Một thời gian đo duy nhất quanh một request có thể cho biết bạn có vấn đề thật hay không, và mức độ khoảng bao nhiêu. Dành profiling sâu hơn khi bạn cần giải thích vì sao nó chậm.

Bằng chứng tốt thường đến từ hỗn hợp nguồn:

• Log ứng dụng (thời gian request, tỉ lệ lỗi, endpoint chậm nhất)
• APM traces (thời gian phân bố qua các service)
• Kết quả profiler hoặc flame graph (hàm nóng và call stack)
• Thống kê DB (truy vấn chậm, chờ lock, tỉ lệ cache hit)
• Metric hạ tầng (CPU, bộ nhớ, mạng, container restart)

Dùng metric đơn giản khi câu hỏi là "nó có chậm hơn và chậm bao nhiêu?" Dùng profiling khi câu hỏi là "thời gian đang đi đâu?" Nếu p95 gấp đôi sau deploy, bắt đầu với timing và log để xác nhận thoái lui và khoanh vùng. Nếu timing cho thấy phần lớn độ trễ nằm trong code app (không phải DB), thì một profiler CPU hoặc flame graph có thể chỉ ra hàm chính xác tăng thời gian.

Giữ việc đo an toàn. Thu thập những gì cần để debug hiệu năng, không phải nội dung người dùng. Ưu tiên tổng hợp (durations, counts, sizes) hơn payload thô, và redact định danh theo mặc định.

Nhiễu có thật, nên lấy nhiều mẫu và ghi ra ngoại lệ. Chạy cùng request 10–30 lần, và ghi median và p95 thay vì một lần chạy tốt nhất.

Viết lại chính xác kịch bản thử nghiệm để có thể lặp: môi trường, dataset, endpoint, kích thước body, mức concurrency, và cách bạn ghi nhận kết quả.

Biến bằng chứng thành một giả thuyết rõ ràng

Bắt đầu với một triệu chứng bạn có thể đặt tên: "p95 latency nhảy từ 220 ms lên 900 ms trong giờ cao điểm", "CPU đứng ở 95% trên hai lõi", hoặc "bộ nhớ tăng 200 MB mỗi giờ." Triệu chứng mơ hồ như "cảm thấy chậm" dẫn tới thay đổi ngẫu nhiên.

Tiếp theo, chuyển những gì bạn đo thành khu vực nghi ngờ. Một flame graph có thể cho thấy phần lớn thời gian ở JSON encoding, một trace có thể cho thấy một đường gọi chậm, hoặc thống kê DB có thể cho thấy một truy vấn chiếm phần lớn thời gian. Chọn phần nhỏ nhất giải thích phần lớn chi phí: một hàm, một câu SQL, hoặc một cuộc gọi ngoài.

Một giả thuyết tốt là một câu, có thể kiểm tra và gắn với một dự đoán. Bạn đang xin phép thử một ý tưởng, không yêu cầu công cụ làm tất cả nhanh hơn phép thuật.

Mẫu giả thuyết đơn giản

Dùng định dạng này:

• Bởi vì (bằng chứng), (điểm nghi ngờ) đang gây ra (triệu chứng).
• Nếu ta thay (hành vi cụ thể), thì (metric) sẽ cải thiện khoảng (xấp xỉ bao nhiêu).
• Ta sẽ biết nó hiệu quả nếu (kết quả đo lại).

Ví dụ: "Bởi vì profile cho thấy 38% CPU nằm trong SerializeResponse, cấp phát buffer mới mỗi request đang gây spike CPU. Nếu ta tái sử dụng buffer, p95 latency nên giảm khoảng 10–20% và CPU nên giảm 15% dưới cùng tải."

Giữ trung thực bằng cách đặt tên các giải thích thay thế trước khi chạm code. Có thể phần chậm thực ra là dependency upstream, contention lock, thay đổi tỉ lệ cache miss, hoặc một rollout làm tăng kích thước payload.

Viết ra 2–3 giải thích thay thế, sau đó chọn cái bằng chứng ủng hộ nhất. Nếu thay đổi không di chuyển metric, bạn đã có giả thuyết tiếp theo sẵn sàng.

Dùng Claude Code mà không bị trôi vào phỏng đoán

Claude hữu ích nhất trong công việc hiệu năng khi bạn đối xử nó như một nhà phân tích thận trọng, không phải một nhà tiên tri. Giữ mọi đề xuất gắn với những gì bạn đo, và đảm bảo mỗi bước có thể bị bác bỏ.

Cho nó đầu vào thực, không mô tả mơ hồ. Dán bằng chứng nhỏ, tập trung: tóm tắt profiling, vài dòng log quanh request chậm, một query plan, và đường dẫn code cụ thể. Bao gồm số "trước" (p95 latency, thời gian CPU, thời gian DB) để nó biết baseline của bạn.

Hỏi nó giải thích dữ liệu gợi ý gì và không gợi ý gì. Rồi ép xuất các giải thích cạnh tranh. Một prompt hữu ích kết thúc bằng: "Cho tôi 2–3 giả thuyết, và với mỗi giả thuyết, nói cách bác bỏ nó." Điều đó ngăn việc dính vào câu chuyện hợp lý đầu tiên.

Trước khi thay gì, hỏi cho thử nghiệm nhỏ nhất có thể xác thực giả thuyết hàng đầu. Giữ nó nhanh và có thể hoàn tác: thêm một timer quanh hàm, bật một flag profiler, hoặc chạy một câu truy vấn với EXPLAIN.

Nếu bạn muốn cấu trúc chặt cho đầu ra, hãy yêu cầu:

• Điều bằng chứng chỉ ra (và độ tự tin)
• 2–3 giả thuyết với bài kiểm tra bác bỏ
• Thay đổi nhỏ nhất về code hoặc config để kiểm tra giả thuyết hàng đầu
• Chính xác metric cần đo lại và hướng mong đợi

Nếu nó không thể nêu metric cụ thể, vị trí, và kết quả mong đợi, bạn lại đang đoán mò.

Thực hiện thay đổi tối thiểu và có thể hoàn tác

Sau khi có bằng chứng và giả thuyết, kìm ham muốn "dọn dẹp mọi thứ." Công việc hiệu năng dễ tin nhất khi thay đổi nhỏ và dễ hoàn tác.

Thay một điều tại một thời điểm. Nếu bạn chỉnh query, thêm cache, và refactor loop trong cùng một commit, bạn sẽ không biết cái nào có tác dụng (hoặc gây hại). Thay đổi đơn biến khiến phép đo tiếp theo có ý nghĩa.

Trước khi chạm code, viết ra mong đợi bằng số. Ví dụ: "p95 latency giảm từ 420 ms xuống dưới 300 ms, và thời gian DB giảm khoảng 100 ms." Nếu kết quả không đạt, bạn nhanh chóng biết giả thuyết yếu hoặc thiếu.

Giữ thay đổi có thể hoàn tác:

• Ưu tiên diff nhỏ có thể revert sạch
• Đặt thay đổi sau một flag để tắt nhanh
• Tránh refactor tàm tạm đổi tên, format và logic cùng lúc
• Giữ scope chặt: một endpoint, một hot path, một cuộc gọi tốn kém
• Thêm ghi chú ngắn trong commit mô tả metric trước/sau mong đợi

"Tối thiểu" không có nghĩa là "tầm thường." Nó có nghĩa là tập trung: cache một hàm tốn kém, loại bỏ một cấp phát lặp trong vòng chặt, hoặc dừng làm việc cho các request không cần.

Thêm thời gian đo nhẹ quanh nút nghi ngờ để thấy điều gì di chuyển. Một timestamp trước và sau một call (log hoặc gửi làm metric) có thể xác nhận thay đổi đánh đúng chỗ hay chỉ chuyển thời gian sang chỗ khác.

Đo lại và quyết định bước tiếp theo

Sau thay đổi, chạy lại đúng kịch bản bạn dùng cho baseline: cùng input, môi trường, và hình dạng tải. Nếu test bạn lệ thuộc vào cache hoặc warm-up, ghi rõ (ví dụ: "lần chạy đầu cold, 5 lần sau warm"). Nếu không, bạn sẽ "tìm thấy" cải thiện chỉ do may mắn.

So sánh kết quả dùng cùng metric và cùng phân vị. Trung bình có thể che giấu vấn đề, nên theo dõi p95 và p99, cùng throughput và thời gian CPU. Chạy đủ số lặp để thấy con số ổn định.

Trước khi ăn mừng, kiểm tra các thoái lui không hiện trong một số headline:

• Độ đúng: response vẫn như mong đợi.
• Tỉ lệ lỗi: timeouts, 5xx, retry.
• Bộ nhớ: đỉnh cao hơn hoặc tăng đều qua các lần chạy.
• Đuôi độ trễ: p99 tệ hơn dù p50 tốt hơn.
• Chi phí tài nguyên: CPU hoặc tải DB tăng đột biến.

Rồi quyết định dựa trên bằng chứng, không phải hy vọng. Nếu cải thiện thật và không gây regressions, giữ thay đổi. Nếu kết quả lẫn lộn hoặc nhiễu, revert và lập giả thuyết mới, hoặc thu hẹp thay đổi hơn.

Nếu bạn làm việc trên nền tảng như Koder.ai, chụp snapshot trước khi thí nghiệm có thể biến rollback thành một bước duy nhất, làm cho việc thử ý tưởng táo bạo an toàn hơn.

Cuối cùng, viết ra những gì bạn học được: baseline, thay đổi, số mới, và kết luận. Bản ghi ngắn này tránh lặp lại cùng ngõ cụt ở vòng sau.

Những sai lầm thường gặp làm lãng phí thời gian

Công việc hiệu năng thường sai khi bạn đánh mất sợi chỉ giữa điều đo và điều thay. Giữ một chuỗi bằng chứng sạch để bạn có thể nói chắc chắn điều gì làm tốt hơn hoặc tệ hơn.

Những kẻ phạm tội lặp lại:

• Sửa mục tiêu sai: ăn mừng median (p50) nhanh hơn, nhưng độ trễ đuôi (p95/p99) vẫn tệ.
• Thay nhiều thứ cùng lúc: refactor, cache và tweak query cùng một commit khiến không biết gì hữu ích.
• Tin vào một lần chạy nhiễu: benchmark local dao động 20% giữa các lần chạy không phải là bằng chứng.
• Xem một profile như sự thật duy nhất: flame graph chỉ ra parsing JSON, nhưng request chất đống do DB chậm.
• So sánh táo với cam: dataset khác, feature flags khác, phần cứng khác, hoặc mức concurrency khác rồi vẫn rút kết luận.

Một ví dụ nhỏ: một endpoint trông chậm, bạn tinh chỉnh serializer vì nó nóng trong profile. Rồi bạn test lại với dataset nhỏ hơn và thấy nhanh hơn. Ở production p99 tệ hơn vì DB vẫn là nút thắt và thay đổi của bạn tăng kích thước payload.

Nếu dùng Claude Code để đề xuất sửa, xích nó sát lại. Yêu cầu 1–2 thay đổi tối thiểu phù hợp với bằng chứng bạn thu thập, và kiên quyết với kế hoạch đo lại trước khi chấp nhận patch.

Checklist nhanh trước khi tuyên bố "nhanh hơn"

Những tuyên bố tốc độ sụp đổ khi test mơ hồ. Trước khi ăn mừng, đảm bảo bạn có thể giải thích bạn đo gì, cách đo, và bạn thay gì.

Bắt đầu bằng việc đặt tên một metric và ghi baseline. Bao gồm các chi tiết làm thay đổi con số: loại máy, tải CPU, kích thước data, chế độ build (debug vs release), feature flags, trạng thái cache, và concurrency. Nếu bạn không thể tái tạo cấu hình ngày mai, bạn không có baseline.

Checklist:

• Metric và baseline được ghi với ghi chú môi trường (phần cứng, cấu hình, dữ liệu, cache ấm/lạnh).
• Các bước test được viết và có thể lặp lại.
• Bạn có một giả thuyết với dự đoán (ví dụ: "Nếu loại bỏ N+1 queries, p95 sẽ giảm ~30%").
• Bạn thực hiện một thay đổi nhỏ, có thể revert và ghi rõ file/hàm/query/cài đặt thay đổi.
• Bạn đo lại với nhiều mẫu và so sánh đúng với đúng (cùng input, cùng tải).

Sau khi số tốt hơn, làm một kiểm tra hồi quy nhanh. Kiểm tra đúng đắn (same outputs), tỉ lệ lỗi, và timeouts. Quan sát tác dụng phụ như bộ nhớ lớn hơn, spike CPU, khởi động chậm hơn, hoặc tải DB tăng. Thay đổi cải thiện p95 nhưng tăng gấp đôi bộ nhớ có thể là đánh đổi sai.

Ví dụ: điều tra từng bước một endpoint API chậm

Một nhóm báo rằng GET /orders ổn trong dev, nhưng chậm ở staging khi tải vừa phải. Người dùng phàn nàn timeouts, nhưng trung bình độ trễ vẫn trông "ổn", đây là cái bẫy kinh điển.

Đầu tiên, đặt baseline. Dưới một thử tải ổn định (cùng dataset, cùng concurrency, cùng thời lượng), bạn ghi:

• p95 latency: 1.8s (mục tiêu < 600ms)
• CPU API: ~70% với các spike thỉnh thoảng
• DB: một truy vấn mất 900–1100ms, và tổng thời gian query trên mỗi request ~1.3s

Bây giờ thu thập bằng chứng. Một trace nhanh cho thấy endpoint chạy một truy vấn chính cho orders, rồi lặp và fetch các item liên quan cho mỗi order. Bạn cũng thấy response JSON lớn, nhưng thời gian DB chiếm ưu thế.

Biến đó thành danh sách giả thuyết có thể kiểm tra:

• Truy vấn chậm cần index.
• N+1 queries đang nhân thời gian DB.
• Serialization chậm do payload lớn.
• Lock contention làm đọc trễ khi có ghi.

Yêu cầu một thay đổi tối thiểu phù hợp bằng chứng mạnh nhất: loại bỏ một cuộc gọi N+1 rõ ràng bằng cách fetch items trong một truy vấn duy nhất theo order IDs (hoặc thêm index nếu kế hoạch truy vấn cho thấy full scan). Giữ reversible và commit có scope rõ.

Đo lại với cùng thử tải. Kết quả:

• p95 latency: 1.8s → 720ms
• Tổng thời gian DB: ~1.3s → 420ms
• CPU: giảm nhẹ, nhưng vẫn còn spike

Quyết định: ship fix (clear win), sau đó bắt đầu vòng hai tập trung vào khoảng trống còn lại và spike CPU, vì DB không còn là giới hạn chính nữa.

Bước tiếp theo: biến workflow này thành thói quen

Cách nhanh nhất để làm tốt hơn trong điều tra hiệu năng là coi mỗi lần chạy như một thí nghiệm nhỏ có thể lặp lại. Khi quy trình nhất quán, kết quả dễ tin cậy, so sánh và chia sẻ hơn.

Một mẫu một trang đơn giản giúp:

• Metric + cách đo (tool, command, dataset)
• Baseline (số, môi trường, khi nào chụp)
• Giả thuyết (một câu, có thể kiểm tra)
• Thay đổi (diff nhỏ, chạm gì)
• Kết quả (trước/sau, và quyết định)

Quyết định nơi lưu các ghi chú này để không mất. Nơi chung quan trọng hơn công cụ hoàn hảo: một thư mục repo cạnh service, một tài liệu nhóm, hoặc ghi chú ticket. Điểm then chốt là dễ tìm. Ai đó nên có thể tìm "p95 latency spike sau thay đổi cache" vài tháng sau.

Biến các thí nghiệm an toàn thành thói quen. Dùng snapshot và rollback dễ để thử ý tưởng không sợ. Nếu bạn xây với Koder.ai, Planning Mode là nơi tiện để phác thảo kế hoạch đo, định nghĩa giả thuyết, và giữ scope trước khi sinh diff chặt và đo lại.

Đặt nhịp. Đừng chờ sự cố. Thêm kiểm tra hiệu năng nhỏ sau các thay đổi như truy vấn mới, endpoint mới, payload lớn hơn, hoặc nâng cấp dependency. Một check baseline 10 phút giờ có thể cứu bạn một ngày đoán mò sau đó.