Lỗi trên môi trường Staging mà không ai chịu sửa đến cùng

Chuyện là đợt vừa rồi team mình có một số đợt golive lớn, mỗi lần golive đều phải cần testing trên môi trường Staging thì mới đảm bảo chất lượng để lên Production.

Nhưng lạ thay mỗi lần QC tải bản app staging về để test thì đều bị lỗi ở bước nào đó, loay hoay mãi cũng không thể vào được app để check chức năng, thế là coi như bypass bước test trên Staging, chấp nhận sẽ verify lại chức năng trên Production.

Làm ăn lôm côm được một lần thì sẽ được hai lần, và cho tới lần tiếp theo khi làm chức năng liên quan đến đối tác ngân hàng chiến lược của tập đoàn, thì không thể bypass vô tội vạ như thế được nữa.

QC kêu lỗi không vào được app, block luồng, không trust device được, không xác thực sinh trắc học được, không ekyc được, không NFC được, ối giời ơi các kiểu kêu….

Lúc này mình phải đứng ra tìm cách xử lý lần lượt các issue trên staging.

Mục Lục

1 Môi trường Staging là gì
2 Tại sao lỗi trên Staging không ai sửa đến cùng?
3 Và rồi ai sẽ là người sửa?
4 Kết

Môi trường Staging là gì

Với nhiều người (chắc là các PM hoặc những sếp ít rành kỹ thuật chẳng hạn?), môi trường Staging là một nơi gì đó… mờ mờ ảo ảo. Nghe tên thì có vẻ quan trọng, nhưng chắc chỉ cần biết Dev, UAT, và Production “oách xà lách” là đủ rồi nhỉ? Staging à? Kệ đi!

Về lý thuyết, trong nhiều công ty tài chính thì Staging là môi trường gần giống Production nhất, dùng để mô phỏng và kiểm thử toàn bộ hành vi hệ thống trước khi chính thức release.

Thông thường sẽ là kiểm thử những chức năng quan trọng liên quan giao dịch tài chính, tiền nong, nạp rút, thanh toán, liên kết bank, sẽ cần phải kiểm tra trước trên môi trường Staging này thì mới yên tâm.

Staging có đầy đủ dữ liệu thật, cấu hình thật, hành vi thật, database thật với môi trường Production.

Quan trọng như thế nhưng mà nó lại thường xuyên… chết thật. Chết ở đây cụ thể là: login không được, không quét ekyc được, không nfc được, không gửi notification được, block luồng không vào được những menu chức năng chính để kiểm thử.

Tức là đáng lẽ Staging phải là môi trường đáng tin cậy cuối cùng trước khi go live, thì thực tế lại trở thành cái “hố sâu không đáy” chứa đủ loại bug bị lãng quên. Mỗi lần cần test là bắt đầu quay xổ số kiểu: “Hôm nay Staging sống hay chết, có test được không?”

Tại sao lỗi trên Staging không ai sửa đến cùng?

Môi trường Staging có nhiều lỗi nhưng mọi người trong team không chịu sửa đến cùng có nhiều nguyên nhân khác nhau, nhưng mình liệt kê được một số nguyên nhân chính bên dưới:

Không phải bug của tôi: người tạo ra lỗi thì nghĩ lỗi đó không phải của mình, chắc là do lỗi của người khác, mặc kệ không thèm kiểm tra và xử lý, QC thì cứ chờ xem cuối cùng đã thông luồng chưa, đã xử lý chưa để còn tiếp tục test, cơ mà có ai xử lý đâu mà test????
Không ảnh hưởng Production mà, vội gì?: có bug tồn đọng từ trước nhưng không được xử lý dẫn tới càng ngày staging càng nhiều lỗi mà vẫn được bỏ qua, lâu dần lỗi đã trở thành 1 phần tất yếu trên staging
Staging chỉ test mấy cái chính thôi mà: việc ngầm định chỉ test những chức năng quan trọng như giao dịch tài chính thì mới đưa lên trên staging dẫn tới một hệ trạng chênh lệch code nghiêm trọng giữa hai môi trường: Staging vs Production
Staging là môi trường test mà, lỗi tí có sao đâu: chính sự dễ dãi này là nền tảng cho chất lượng yếu kém trên Production, rồi lại hotfix liên tục

Và rồi ai sẽ là người sửa?

Không ai thực sự muốn sửa, không ai thực sự muốn chịu trách nhiệm xử lý vấn đề đến cùng,….

Không ai sửa thì mình tìm cách sửa vậy, có gì đâu mà căng, ta không vào hố sâu biển lửa thì ai vào bây giờ?

Thế rồi mình debug, tái hiện, điều tra nguyên nhân, phối hợp thêm với devops xử lý, xin thêm quyền mở firewall, quyền restart service để chủ động xử lý, ghi lại nhật ký quá trình điều tra, nguyên nhân cốt lỗi, bài học rút ra.

Vụ lỗi confirmLivenessV2 thì có 2 lỗi xảy ra đồng thời, lỗi 1 là do code của anh em cũ đã nghỉ convert sai kiểu dữ liệu, lỗi 2 là do chưa cấp quyền truy cập cho việc ghi/tạo thư mục, lỗi này mình nhờ devops grant thêm quyền.

Mà buồn cười thật, trong quá trình xử lý mới phát hiện ra rất nhiều chức năng mọi người thực sự không test, không đưa lên trên Staging: ví dụ như hai service không gọi thông nhau, chưa mở firewall, chưa xin quyền readfile trên service, chưa khai báo domain config nội bộ, service chưa từng được deploy trên staging,…

Lỗi ở trên là do mình, bị miss mất 1 field config cho mobile app, không đưa lên môi trường Staging, thành ra app gọi api lấy cấu hình config bị lỗi nên không vào được app bản Staging, thế mới thấy không ai hoàn hảo cả mà, haha

một số lỗi trong quá trình mình tracing bug

Sau khi xử lý xong gần hết các issue trên môi trường Staging ở thời điểm chuẩn bị golive với đối tác SHB, mình tổng hợp lại 1 file excel những vấn đề đã xử lý, ngoài ra những vấn đề chưa thể xử lý được thì có điều tra nguyên nhân cụ thể và nhờ thêm sếp mình hỗ trợ.

Sau đoạn tin nhắn này thì ngay buổi chiều mình cùng anh Hoài (CTO) phối hợp với hạ tầng công nghệ xử lý luôn vấn đề

Kết

Lỗi ở môi trường Staging không nguy hiểm bằng lỗi trên Production, nhưng sự chủ quan trước những lỗi đó có thể dẫn đến rất nhiều tai hoạ thật sự.

Việc phát hiện được lỗi và xử lý sớm trên Staging sẽ đảm bảo rằng trên môi trường Production ít vấn đề hơn, ít hotfix hơn, khách hàng claim ít hơn.

Mỗi lỗi không được sửa đến cùng sẽ tạo thành tiền lệ: “Lỗi này ai cũng biết nhưng không ai sửa, nên tôi cũng khỏi sửa” Một hệ thống mà môi trường Staging không đáng tin cậy thì sớm muộn gì cũng tạo ra những bản phát hành kém chất lượng.

Làm kỹ thuật không chỉ là viết code cho chạy, mà còn là từ cái tâm, tinh thần dọn dẹp và duy trì hệ thống sạch sẽ từ gốc rễ. Sửa một lỗi trên Staging là đầu tư vào sự ổn định cho tương lai, một việc làm sexy, không nổi bật, nhưng cực kỳ cần thiết cho mỗi Engineer chân chính muốn làm tốt sản phẩm của mình, của team mình.

Xem thêm các bài viết nổi bật bên dưới:

Post Views: 240