🌻 Góc nhỏ chia sẻ những câu chuyện dở khóc dở cười mà tuôi gặp phải trong ngành IT 🌻
📌 Câu chuyện hôm nay: "SÁT NGÀY RELEASE, KHÁCH YÊU CẦU THAY ĐỔI LOGIC GỬI MAIL"
Dự án tôi phụ trách đang chạy cùng lúc rất nhiều modules, trong đó có 1 module làm về hệ thống booking khám bệnh.
Khi mọi thứ ở team offshore đã xong xuôi và khách hàng đã vào giai đoạn cuối UAT và chỉ cách ngày lên release lên production là 3 ngày.
Cứ ngỡ đâu mọi thứ đang suôn sẻ cho đến 2 ngày trước khi release , khách bất ngờ gửi một request cực gấp.
🚨 Khách: "YÊU CẦU LOGIC GỬI MAIL REMINDER!"
Ban đầu, hệ thống chỉ gửi một mail reminder trước thời gian khám bệnh là 2h.
Nhưng, sau khi xem xét feedback từ end-user thì khách muốn chia nhỏ ra nhiều lần theo rule mới:
📌 Gửi reminder trước 48h → chạy batch vào phút thứ 03.
📌 Gửi reminder trước 24h → chạy batch vào phút thứ 02.
📌 Gửi reminder trước 12h → chạy batch vào phút thứ 01.
Ủa??? Logic này hoàn toàn khác so với trước đây, mà ban đầu thật sự tôi cũng hoàn toàn không hình dung được là batch sẽ chạy như thế nào và phía QC sẽ test ra sao.
Với vai trò là người đứng giữa, tôi chủ động trao đổi với khách trước luôn là logic này khá phức tạp mà chỉ còn 2 ngày nữa là release, nếu bây giờ mà fix lại là sẽ tốn thêm thời gian và không kịp release.
Vậy nên xin phép dời ngày release sang một khung thời gian khác. Còn về schedule chi tiết thì sau khi confirm với team tôi sẽ báo cáo lại sau.
▼ Nội dung mail liên lạc (mang t/chat tham khảo)
今回ご要望いただいたリマインドメールのロジック変更についてですが、現在の仕様と比べると処理が複雑になるため、リリース直前のこのタイミングでの修正はスケジュールへの影響が大きいと考えております。
現時点でリリースまであと2日しかないため、修正作業を行うと追加の開発・テスト時間が必要になり、予定通りのリリースが難しくなる可能性が高いです。
そのため、リリース日程の変更をご検討いただけないでしょうか？
具体的なスケジュールについては、社内で調整後、改めてご報告いたします。何卒ご確認のほどよろしくお願いいたします。
Nhưng không được, khách kiên quyết là: Nhất định phải release tính năng đã hoàn tất + logic mới bổ sung này vào đúng 2 ngày sau.
絶対に予定通り、2日後にリリースしてください。新機能及び今回のロジック変更、両方とも含めて。
Tôi đọc tin nhắn xong kiểu : えっ…😨
==> Với sự kiên quyết này, có vẻ khó mà xin dời deadline được. Do đó, tôi cần phải nhanh chóng nhờ team xem xét thử với yêu cầu này thì cần bao nhiêu thời gian để hoàn thành ? và có phát sinh công số OT/残業 hay không.
💡 Comment của anh em trong team cho vụ này
✅ Dev A: "Thay đổi này làm tăng số lượng batch job chạy trong ngày. Nếu không tối ưu, có thể gây tải cao trên server."
✅ Dev B: "Batch hiện tại chỉ xử lý một lần cho mỗi lịch hẹn. Giờ phải tách ra thành ba job riêng biệt!"
✅ Tester: "Với nội dung CR này thì thời gian test cũng sẽ tăng lên rất nhiều"
==> Dựa trên tình hình hiện tại thì vấn đề OT không thể nào tránh khỏi
==> Lúc này lại cần kỹ năng communication đỉnh cao để khách có thể approve chi phí OT cho team nè
▼ Nội dung mail liên lạc (mang t/chat tham khảo)
お世話になっております。
今回のリマインドメールのロジック変更に関しまして、開発チーム内で詳細を検討した結果、以下の課題が発生しております。
バッチ処理の負荷増加
現在のバッチ処理は1回の実行で完了しますが、今回の変更により 1日3回の処理 が必要となります。
最適化が必要であり、そのまま実装するとサーバー負荷が高まる可能性があります。
開発工数の増加
現行のバッチ処理を3つの個別ジョブに分割するための 追加開発が発生 します。
テスト工数の増加
今回の変更により テストケースの見直し が必要となり、テスト期間が延びる見込みです。
また、リリースまでの時間が限られているため、このまま進める場合、開発・テストチームのOT（残業）対応が避けられない状況 です。
つきましては、本件にかかる追加工数およびOT費用について、お見積りのご相談をさせていただきたく存じます。
詳細なお見積りについては、社内で調整の上、改めてご連絡いたしますので、ご確認のほどよろしくお願いいたします。お手数ですが、本件のご確認およびご承認をいただけますでしょうか？
お急ぎのご対応となり恐縮ですが、〇月〇日までにご回答をいただけますと幸いです。何卒よろしくお願いいたします。
Nói chung là cũng xin được tiền OT cho team để team chạy xúc quần cho khách, và cũng kịp ngày release lên production.
Nhưng biến cố này chưa hết thì biến cố khác lại đến.
Do hệ thống này đã launch ra môi trường thực và có user thực dùng, nên khi release prod thì buộc phải tiến hành vào ban đêm.
Và đó là 1 đêm siêu siêu dài của tôi.
🚀 Quy trình release
✅ 12h đêm – Bắt đầu release lên production
✅ 1h30 sáng - 4h sáng: QC bên team + khách test song hành trên production
Schedule là đến 4h xong, nhưng đúng 4:05 phút khách báo vẫn chưa nhận được mail reminder 24h và 48h. Lúc này là mệt muốn sỉu up sỉu down rồi. Chỉ có ai release xuyên đêm mới thấu được cảm giác này.
🔎 Điều tra lỗi trên production
📌 Prod và staging thường sẽ có config khác nhau, tuy nhiên Ở staging, data test được tạo liên tục nên luôn tồn tại data booking trong tương lai (luôn có case để batch xử lý).
👉 Nhưng trên production, event booking thực tế của user thường không trải dài đều, mà có ngày ít, ngày nhiều.
🔍 Batch job trên production chỉ lấy booking trong khoảng thời gian cụ thể. Nhưng vì cách query trên prod chưa được tối ưu, batch lại bị miss những appointment có thời gian không nằm đúng "rìa" của các mốc 24h và 48h.
Nói dễ hiểu hơn là:
✅ Mail 12h gửi được vì batch luôn get appointment trong ngày hôm đó.
❌ Mail 24h, 48h bị bỏ sót vì batch chỉ lấy appointment từ đúng ngày hôm đó trở đi, mà không quét ngược lại.
Dev và QC thay phiên nhau trực, một người fix, một người test.
Còn đứa đứng giữa như tôi thì không chuẩn bị phương án backup trước nên tôi trực liên tục từ 12h đêm đến 17h chiều hôm sau, vì khách cứ 2 tiếng lại hỏi "XONG CHƯA?!" 😭
⏳ Sau gần 17 tiếng không ngủ, cuối cùng batch chạy đúng, bug được fix, hệ thống ổn định.
🌟 Một đêm release nhớ mãi trong đời. 🌟
Và cách khách hàng cảm ơn chúng tôi là chúng tôi đã được "thưởng nóng" trong tháng đó.
Nói chung là cũng bực bội nhưng thấy khách hàng cũng đáng yêu cũng dễ thương đó ^^.
Câu chuyện tới đây là hết rồi.