Chuyển đến nội dung
Tất cả bài viết
Blog & hướng dẫn/Giải pháp Proxy
Giải pháp Proxy

Giải pháp chuyển nhà cung cấp proxy có phương án rollback

Đổi proxy không nên là thay một biến rồi chạy toàn hệ thống. Hai cấu hình có phiên bản, thử nghiệm nhỏ và rollback rõ ràng giúp kiểm soát rủi ro chuyển tuyến.

Giải pháp chuyển nhà cung cấp proxy có phương án rollback
NỘI DUNG BÀI VIẾTHướng dẫn chi tiết từ ProxySmart

Chuyển nhà cung cấp proxy có thể thay đổi xác thực, vị trí IP, thời gian kết nối và cách xử lý DNS. Dịch vụ mới trả được một trang web không có nghĩa mọi tác vụ đã tương thích. Một phương án chuyển tuyến cần có cấu hình cũ còn dùng được, kiểm thử trên dữ liệu giả và quyền quyết định quay lại khi kết quả chưa đạt.

Xác định phạm vi thay đổi trước khi chuyển

Lập bảng giao thức, ứng dụng, đích được phép, phiên cần ổn định và cách tính lưu lượng. Kiểm tra nhà cung cấp mới có đáp ứng từng mục hay không, không suy từ tên gói. Đặc biệt phân biệt địa chỉ endpoint với IP đầu ra mà website nhìn thấy.

Không đổi proxy đồng thời với phiên bản ứng dụng, timeout và chính sách retry. Nếu nhiều yếu tố thay cùng lúc, khó biết nguyên nhân lỗi. Thỏa thuận cửa sổ thay đổi và người có quyền dừng triển khai; không để một kiểm tra tự phát biến thành thay đổi production không được phê duyệt.

Giữ hai cấu hình có phiên bản

Cấu hình A là tuyến đang chạy, B là tuyến ứng viên. Mỗi cấu hình có mã phiên bản, endpoint, giao thức và tham chiếu bí mật riêng. Tác vụ được gắn phiên bản khi bắt đầu, tránh chuyển giữa chừng trong một chuỗi thao tác có trạng thái. Không in hai bộ thông tin xác thực vào bảng so sánh.

Trước canary, xác nhận A chưa hết hạn hoặc bị thu hồi. Có bản sao cấu hình không đồng nghĩa có đường rollback hoạt động. Thử quay lại A trong staging và kiểm tra kết nối mới thực sự dùng A, thay vì còn đi qua pool cũ.

Kiểm thử staging và kết nối tái sử dụng

Kiểm tra phân giải hostname, chứng chỉ TLS, IP đầu ra, xác thực, timeout và kích thước dữ liệu đại diện. Bắt đầu với thao tác đọc không gây tác dụng phụ trên dịch vụ được phép. Sau đó dùng sandbox cho những thao tác ghi cần nghiệm thu.

Tài liệu curl về connection reuse cho biết kết nối có thể được tái sử dụng giữa các lần truyền. Vì vậy cần tách pool theo cấu hình và kiểm tra cả kết nối mới lẫn kết nối đang mở. Sửa endpoint trong cấu hình không bảo đảm các socket hiện tại đổi tuyến ngay.

Canary theo nhóm tác vụ được phê duyệt

Google SRE về canary trình bày cách so sánh nhóm ứng viên với nhóm đối chứng để hạn chế phạm vi tác động. Áp dụng nguyên tắc này cho proxy: chọn một nhóm nhỏ có đặc điểm đại diện, giữ số liệu riêng cho A và B, rồi mới quyết định mở rộng.

Ví dụ giả định: sau staging, 5% tác vụ đọc được phép dùng B trong 30 phút, phần còn lại dùng A. Những con số này chỉ minh họa, không phải ngưỡng an toàn chung. Mẫu phải đủ để xem loại tác vụ thực tế; nhóm quá nhỏ có thể chưa gặp lỗi hiếm hoặc tải cao.

Ví dụ tiêu chí dừng và rollback

Giả sử đội dự án đặt tiêu chí trước thử: không có lỗi TLS mới, không sai nội dung, tỷ lệ hoàn thành không giảm quá mức đã thỏa thuận và thời gian p95 nằm trong giới hạn nghiệp vụ. Nếu B vi phạm, dừng giao tác vụ mới cho B, giữ bằng chứng đã che bí mật và đưa tác vụ mới về A.

Với tác vụ đang chạy, quyết định chờ hoàn tất, hủy hoặc đối soát tùy tính chất. Không phát lại tự động lệnh tạo đơn chỉ vì client nhận timeout. AWS về timeout và retry lưu ý timeout không chứng minh thao tác chưa xảy ra và retry có thể tăng tải. Rollback tuyến không hoàn tác dữ liệu đã ghi.

Checklist nghiệm thu sau chuyển tuyến

  • Đo riêng nhóm A, B theo cùng loại tác vụ và cùng khoảng thời gian.
  • Kiểm tra DNS, TLS và IP đầu ra từ đích kiểm thử do mình kiểm soát.
  • Phiên đăng nhập thử không bị đổi tuyến ngoài chính sách đã chọn.
  • Rollback đưa kết nối mới về A, không tạo bản sao tác vụ ghi.
  • Nhật ký xác định được phiên bản cấu hình và không lộ mật khẩu.

Chỉ thu hồi A sau khi B đã qua thời gian theo dõi được duyệt và không còn phụ thuộc vào đường cũ. Cập nhật tài liệu, kiểm soát ngân sách hai tuyến và lưu kết quả nghiệm thu. Tham khảo quy trình kiểm thử proxy trước production để xây dựng bộ kiểm tra riêng.

Câu hỏi thường gặp

Có nên gửi cùng yêu cầu qua cả hai proxy?

Chỉ cân nhắc với thao tác đọc được phép. Không nhân đôi thao tác ghi, gửi tin hay thanh toán để so sánh.

Quay lại proxy cũ có khôi phục phiên không?

Không được bảo đảm. Phiên có thể đã hết hạn hoặc bị hệ thống đích yêu cầu xác thực lại; cần xử lý theo chính sách của ứng dụng.

Kết luận

Chuyển proxy an toàn cần hai cấu hình kiểm chứng được, thử nghiệm có phạm vi và kế hoạch đối soát tác dụng phụ. Canary giúp giảm rủi ro, nhưng quyết định triển khai vẫn phải dựa trên tiêu chí nghiệp vụ và kết quả thực tế.