Luyện tập tư duy debug với câu chuyện encoding URL

I.Mở bài

Tiếp nối phần 1, định viết bài này sớm hơn cơ mà nay mới có thời gian để ngồi gõ chia sẻ. Hiện tại, mình đang tham gia dự án Creative-Tracking: quản lí các tài nguyên quảng cáo như creative, asset, text. Vào một ngày không đẹp trời lắm, dự án xảy ra một lỗi (bug) trên môi trường production mặc dù chức năng đó trước giờ đã được kiểm định và chạy rất ổn. Đúng là cuộc sống của developer không thoát khỏi đống bug yêu dấu mà. Thật may, team đã tìm ra và khắc phục ngay sau đó. Dù chả ai muốn nhưng thôi thì xem đây là 1 cơ hội luyện tập, 1 bài học cho các thành viên trẻ khoẻ trong team. Ở phần 2 này, mình sẽ chia sẻ vấn đề và áp dụng các bước ở phần 1. Các bạn nên đọc phần 1 trước nhé, zô thôi nào

II. Thân bài

Cùng nhìn qua sơ đồ hệ thống 1 tí

Service Backend: Tiếp nhận và phản hồi yêu cầu từ client
Service Master: Xử lí và lưu trữ các master data: Creative, Asset, Text

Overview chức năng xảy ra bug: Hệ thống CTX có API Get/Zip giúp người dùng tải Asset (Video, Image) gắn với 1 Creative về trong 1 file zip, dựa vào creativeId

Bối cảnh: Nhận được thông báo từ PO là khách đang dùng API GET_ZIP ở trên môi trường Production thấy báo lỗi network không mở được file zip

Bắt tay vào việc nào,
B1: Xác nhận tình trạng bug với PO.
– Sau khi đọc lời thông báo của PO và hình ảnh lỗi, team mình đã xin thông tin về api và thử lại thì đúng là xảy ra lỗi thật => OK team dev tái hiện được lỗi.
– Lỗi do đâu ? Đọc kĩ lại thông báo và nhìn hình ảnh thêm 1 lần nữa, ta thấy có cái gì sai sai: trong ảnh ta thấy thông báo Network error còn PO nói là không mở được file zip. Dev chúng ta chắc hẳn không lạ lẫm gì với việc thao tác các file ở định dạng nén như .rar hay .zip. Rõ ràng, PO đã thông báo lỗi không chính xác. Đó chính là sự khác nhau về kiến thức chuyên môn dẫn đến góc nhìn ở cùng 1 hiện trạng lại khác nhau. Nhiệm vụ của 1 developer là xác định lại đúng vấn đề và thông báo đến với PO. Dường như có vấn đề gì đó xảy ra trong quá trình tải file zip trên. Chốt kèo vấn đề nhé cả team.

B2: Đọc log
Rất tiếc ở bước này không có một log nào cả. Next tiếp vậy.

B3: Xem xét flow && data chức năng bị lỗi
– Xem xét flow nào

Nhìn ảnh chúng ta thấy có 6 bước nhỏ trong flow của chức năng. Nhiệm vụ lần này là cố gắng loại trừ để thu nhỏ phạm vi số bước có thể phát sinh lỗi, càng thu nhỏ phạm vi ta càng phát hiện nguyên nhân lỗi nhanh hơn.
Bước 1, 2, 3 để tổng hợp dữ liệu master data. Bước 4, 5 để lấy file từ S3 về. Bước 6 sẽ zip các file này lại. Có 1 điểm cần chú ý ở đây là ta có nhiều asset cần nén lại, quá trình này sẽ không hoạt động theo kiểu là lấy hết ảnh xong zip 1 cục mà là lấy cái nào thì sẽ zip luôn cái đó. Do vậy bước 4, 5 và bước 6 sẽ chạy đồng thời với nhau.
Loại trừ: Nếu có lỗi tại các bước 1, 2, 3 thì sẽ ăn ngay response là 1 mã 4xx hoặc 5xx gì đó, kèm theo thông báo lỗi mà chưa đến bước tải file zip. Do đó chỉ còn các bước 4, 5, 6 đáng nghi ngờ. Xem chi tiết từng bước và đưa ra phán đoán
Bước 4, 5: Trong quá trình tải file bị lỗi. Tư duy tiếp có 2 hướng, 1 là kết nối mạng với S3 có vấn đề, 2 là s3 url có vấn đề.
Bước 6: Vì lý do giời ơi gì đó zip file bị lỗi. Cái này chả đoán nổi vì lớn quá. Phán đoán lỗi không xác định.
Vậy là có 3 khả năng xảy ra, tìm ra 1 khả năng tiềm năng nhất để thử. Tránh việc đi qua tất cả khả năng sẽ rất mất thời gian. Khả năng 1, team có thử lại với 1 case khác thì tải được bình thường => Case được, case lỗi => Không phải lỗi do kết nối mạng mà là ở dữ liệu rồi. Sao lại trùng hợp với khả năng 2 vậy nhỉ => url ở case lỗi có vấn đề => Rất rất cao là sai S3 url. Đến đây tràn đầy hi vọng và tự tin không cần xem khả năng 3 vội.

– Xem xét data nào
Team lấy toàn bộ data creative được lấy ở bước 2, 3. Sau đó lọc chỉ lấy 2 trường là id và url được kết quả như sau

B4: Đưa ra dự đoán và kiểm chứng
Nhìn vào hình ảnh data trên, tập trung vào key field là url như chúng ta đã dự đoán ở trên, tách thành các nhóm dữ liệu để kiểm định. Ta thấy rằng url có thể gom thành 2 nhóm: chỉ chứa các kí tự Non-Japanese, chứa kí tự Japanese. Thử tải lại file zip với 1 url ở trong 2 nhóm thì thấy rằng: chỉ bị lỗi với url chứa kí tự Japanese. Chốt hạ nguyên nhân.
URL có chứa kí tự Japanese, tại sao lại lỗi nhỉ? Qua vài bước google và Stackoverflow ta thấy rằng để truyền được qua internet thì url chỉ chấp nhận các kí tự ASCII, các kí tự loại khác cần được mã hoá(encode) sang dạng đúng, ở đây là ký tự Japanese không được encode. Dẫn đến thư viện amazon cung cấp để tải file từ S3 gặp lỗi.
Thử encode toàn bộ url xem sao. Bingo, tất cả hoạt động trơn chu như mọi ngày đẹp trời.

B5: Không cần luôn

III. Kết bài

– Khi áp dụng đúng các bước trên ta có thể nhanh chóng khoanh vùng phạm vi bug. Từ đó, đưa ra được nguyên nhân và cách khắc phục đúng đắn, kịp thời. Ở trình độ developer càng cao thì thời gian nảy số các bước trên càng nhanh.
– Hi vọng bài chia sẻ này giúp các bạn có phương hướng để nâng cao kĩ năng debug của bản thân. Không thể đưa cách loại bỏ bug hoàn toàn, bug là 1 phần của cuộc sống rồi. Khi nó đến hãy mạnh mẽ và tự tin đối đầu tiêu diệt nó sớm nhất nhé.