Báo cáo tổng hợp diễn biến sự cố từ khi khách hàng log ticket ngày 2026-05-12 đến hiện tại 2026-05-21. Bao gồm timeline điều tra, các hướng đi sai, root cause được xác định, fix đã apply trên UAT, và kế hoạch xử lý tận gốc.
Khách hàng Yamanaka log ticket LRCC-2417 ngày 2026-05-12, gộp 2 issue notification phát hiện trên production.
End-user orthodox_paradox@icloud.com phản ánh: notification về creator "れちゃん" cập nhật WAVE video xuất hiện với số lần bất thường trong thanh thông báo LOVEREC. Khả năng bug, hoặc third-party thao tác xấu.
→ Yêu cầu: verify fact-finding sự thật, đếm số lần notification thực sự được gửi.
Khách hàng Yamanaka tự kiểm tra account @pz9ve9Zyd6 và phát hiện: email notification đã được gửi, nhưng in-app notification không xuất hiện. Theo spec, 2 kênh này phải đi chung 1 trigger.
→ Yêu cầu: tìm root cause spec violation này.
Khách dùng từ "本番環境のクレーム" (complaint trên production environment) → SLA cao, ưu tiên xử lý nhanh. Yêu cầu cụ thể: fact-finding cho Issue A + xác định root cause Issue B, cả 2 cùng 1 ticket.
Từ ngày khách hàng log bug tới khi fix được apply trên UAT.
phuong.nguyen+1userprd cho thấy notification setting = OFF → kết luận đây là nguyên nhân không nhận in-app notification.
@pz9ve9Zyd6 (Google login, plan 通常). Trên CMS thấy:
LRC-14126):
Phát hiện trong quá trình replicate trên UAT với 10k follower.
Code xử lý gửi email cho follower khi publish video không được thiết kế để handle scale lớn. Khi số lượng follower cao (≥ 5,000):
Điều tra UAT đồng thời lộ ra nhiều vấn đề khác không trực tiếp gây bug observed, nhưng tiềm ẩn nguy cơ tương tự:
| Vấn đề | Loại | Tác động | Trạng thái |
|---|---|---|---|
| Code fire-and-forget enqueue 10k email không await | Code | Email bị huỷ khi instance kill | FIXED (LRC-14126) |
| Auto-scale CPU/RAM target 70% quá nhạy với bursty workload | Infra | Kill task ngay sau burst, mất Promise in-flight | PENDING — plan hôm nay |
| CPU/RAM allocation cho video-service task quá thấp | Infra | Spike chạm threshold dễ hơn cần thiết | PENDING — plan hôm nay |
deleteMessageBatch dùng callback-style fire-forget |
Code | SQS retry nếu instance kill trước khi delete confirmed | CHƯA FIX — không kích hoạt sau fix #1 |
UPSERT logic cho PUBLIC_VIDEO_FOR_FOLLOWER bị comment out |
Code | Amplify duplicate khi có retry | CHƯA FIX — không kích hoạt sau fix #1 |
Backend outputObject.forEach(async) race condition |
Code (backend) | Race condition tiềm ẩn, chưa thấy kích hoạt | CHƯA FIX — preventive |
Nhiều vấn đề phụ kể trên thực ra chỉ kích hoạt khi vấn đề chính (fire-and-forget + scale) xảy ra. Khi team fix vấn đề chính (chunking + concurrency limit), instance không còn bị kill mid-flight → các vấn đề phụ tự động không còn ảnh hưởng dù code path vẫn nguyên.
→ Team chọn fix targeted (chỉ 1 phần code) thay vì fix tất cả → vẫn đáp ứng được yêu cầu khách hàng (10k follower test pass), giảm risk regression khi deploy nhiều thay đổi cùng lúc.
Commit LRC-14126 trên branch UAT — chunking + bounded concurrency.
Các query với IN([10k IDs]) được tách thành nhiều chunk 500 IDs.
Tránh max_allowed_packet limit, query plan của MySQL tối ưu hơn, latency mỗi query thấp hơn.
Thay vì fire 10,000 Promise cùng lúc, chỉ 20 song song mỗi đợt, dùng await Promise.all cho từng batch.
Function đợi từng batch enqueue xong rồi mới sang batch tiếp. Không còn fire-and-forget. Smooth CPU load profile.
Mỗi SQS message chứa max 50 memberIds thay vì 1 message với 10k IDs.
Payload SQS nhỏ hơn nhiều lần, consumer dễ xử lý, ít risk message body limit.
Sau fix, test UAT publish video với 10k follower không cần auto-scale vẫn xử lý bình thường trong ~10 phút. CPU/RAM smooth, không spike đột ngột, không cần thêm task. Điều này confirm:
NumberOfMessagesSent = số email cần gửi (không mất message)Hôm nay team lên detail plan cho 3 hạng mục.
3 scaling policy hiện tại (CPU 70%, RAM 70%, BacklogPerTask 100) quá nhạy với bursty workload. Cần tune:
Task hiện tại được cấp tài nguyên thấp. Bursty workload publish video cần more headroom để xử lý smooth. Khuyến nghị:
Sau fix, bottleneck CPU còn lại chủ yếu là format() HTML template (~50% CPU work khi gửi email burst). Options:
publicVideoForSubscribers)Cần follow-up với khách hàng Yamanaka về 2 issue ban đầu.
Trong quá trình điều tra hôm qua, phát hiện vấn đề duplicate notification ở scale lớn → giải thích được hiện tượng "lặp bất thường" mà end-user phản ánh.
Action: comtor relay tới khách hàng:
Issue B (account @pz9ve9Zyd6) cùng nguyên nhân với bug scale chính: in-app notification path bị kill mid-flight do auto-scale, trong khi email path đôi khi vẫn sống sót (vì 1 Promise duy nhất nhanh hơn 10k Promise burst).
Action: comtor relay tới khách hàng:
Khi report lại cho khách hàng Yamanaka (qua comtor), focus 3 điểm:
Có thể đính kèm timeline + result test UAT làm evidence.
Round 1 (5/14) đi sai hướng do investigate sai account → khách hàng push back → mất 5 ngày trước khi tìm đúng vấn đề. Lesson: comtor cần confirm rõ với khách hàng về thông tin user/account (forward đầy đủ context cho đội phát triển VN) trước khi deep dive technical.
Trong khoảng 5/14 — 5/18, team đã sửa code và verify UAT thành công nhưng chỉ test với data nhỏ (vài trăm follower). Bug thực sự chỉ kích hoạt khi scale ≥ 5k follower → fix không đủ → KH claim lần nữa ngày 5/19.
Hậu quả: mất thêm 1 tuần investigation, KH mất niềm tin, ticket bị reopened. UAT cần có data scale tương đương PRD (vd: account test với 10k+ follower bot accounts) để catch scale-dependent bug.
Điều tra phát hiện 6+ vấn đề, nhưng chỉ cần fix 1 vấn đề chính là đáp ứng. Tránh deploy nhiều thay đổi cùng lúc → giảm risk regression.
Code fire-and-forget + auto-scale aggressive = combo nguy hiểm. Bài học: review pattern code khi setup auto-scale, hoặc ngược lại.