Nâng cấp load balancer an toàn: runbook giảm rủi ro vận hành
Một thay đổi ở load balancer có thể tác động đồng thời đến routing, TLS, session, health check và khả năng quan sát. Runbook tốt biến việc nâng cấp thành chuỗi giả định có thể kiểm tra và có đường quay lại rõ ràng.
Ngày đăng:
Load balancer thường bị xem là một thành phần hạ tầng ở giữa, nên thay đổi cấu hình dễ bị đánh giá thấp: đổi certificate, chỉnh health check, thêm rule routing hoặc nâng version. Nhưng nó đứng ngay trên đường đi của gần như mọi request. Một lỗi nhỏ có thể không làm backend chết, nhưng vẫn khiến người dùng nhận redirect lặp, mất session, gặp lỗi CORS, bị chặn bởi header mới hoặc đi tới một nhóm server chưa sẵn sàng. Vì vậy, nâng cấp load balancer không nên là một thao tác “đổi xong rồi xem”; nó là một thay đổi sản phẩm có ảnh hưởng trực tiếp đến trải nghiệm khách hàng.
Runbook an toàn không bắt đầu bằng danh sách lệnh. Nó bắt đầu bằng bối cảnh: lưu lượng nào đang đi qua thành phần này, ai phụ trách ứng dụng phía sau, điều kiện nào được coi là thành công, và tiêu chí nào buộc phải quay lại. Khi những câu trả lời này rõ, đội ngũ có thể tiến hành thay đổi có kiểm soát thay vì phải suy đoán dưới áp lực.
Lập inventory của đường đi request trước khi chạm vào cấu hình
Hãy mô tả request từ góc nhìn người dùng: domain, DNS, CDN hoặc WAF, load balancer, listener, rule, target group, ứng dụng, dependency và response. Ghi lại protocol, port, certificate, redirect, header được thêm hoặc bỏ, timeout, giới hạn kích thước request, sticky session và cơ chế health check. Một thay đổi tưởng như chỉ ở listener có thể làm hỏng upload nếu giới hạn body khác nhau, hoặc làm API không hoạt động nếu header proxy bị đổi.
Inventory cũng cần chỉ ra owner cho từng route. Các route admin, webhook, API public, static asset và callback từ đối tác có thể có hành vi rất khác. Nếu không biết lưu lượng nào sử dụng một rule hiếm, đội ngũ có thể chỉ phát hiện ra sau khi một integration quan trọng ngừng hoạt động. Hãy xem access log và telemetry một khoảng thời gian đủ đại diện, bao gồm giờ cao điểm, để biết route, method, response code, host header và loại client thực tế.
Thiết lập baseline có thể so sánh, không chỉ một ảnh chụp cấu hình
Trước thay đổi, ghi lại các chỉ số người dùng cảm nhận được: tỷ lệ 2xx, 4xx, 5xx, latency theo route, tỷ lệ connection error, số backend healthy, thời gian TLS handshake nếu có và tỷ lệ login hoặc form submit thành công. Bổ sung baseline từ ứng dụng như throughput, saturation và error theo dependency. Đây là mốc để biết một thay đổi có tạo hồi quy hay không; một load balancer “healthy” vẫn có thể chuyển lỗi sang tầng ứng dụng.
Baseline cần đi kèm smoke test thật. Chọn các đường đi đại diện: mở trang chủ, gọi API quan trọng, đăng nhập nếu phù hợp, gửi form trong môi trường kiểm thử, tải asset, kiểm tra redirect và callback có thể mô phỏng. Mỗi test cần có expected result rõ. Đừng dựa vào một request curl duy nhất rồi kết luận traffic thực sẽ an toàn; browser, cache, cookie, HTTP/2, TLS và client cũ có thể làm hành vi khác đáng kể.
Thiết kế thay đổi nhỏ, có canary và có cửa dừng
Chia thay đổi lớn thành các bước độc lập khi có thể. Chẳng hạn, triển khai certificate mới trước nhưng chưa đổi policy routing; thêm target group mới rồi đưa một phần rất nhỏ traffic qua; thay đổi health check sau khi đã xác minh endpoint. Mỗi bước cần có một điều kiện tiếp tục, một điều kiện dừng và một người có quyền quyết định. Canary không chỉ là một tỷ lệ traffic. Nó là cách kiểm tra một giả định với phạm vi tác động đủ nhỏ để quay lại bình tĩnh.
Đối với route nhạy cảm, có thể canary theo host, đường dẫn, nhóm người dùng nội bộ hoặc header thử nghiệm thay vì ngẫu nhiên toàn bộ khách hàng. Điều này giúp đội ngũ quan sát các protocol và payload cụ thể. Khi không có hạ tầng để tách traffic, hãy chọn khung thời gian ít rủi ro hơn, thông báo owner phụ thuộc và tăng giám sát. Thay đổi không thể canary không đồng nghĩa không thể làm, nhưng cần một mức chuẩn bị và rollback cao hơn.
Kiểm tra những điểm thường gây lỗi âm thầm
Health check phải phản ánh khả năng phục vụ, không chỉ việc process đang mở port. Nếu endpoint trả 200 khi database không hoạt động, load balancer có thể tiếp tục gửi traffic vào backend không thể hoàn thành request. Tuy nhiên, một health check quá nặng lại có thể tự tạo tải. Hãy xác định rõ khác biệt giữa liveness, readiness và test sâu hơn, rồi chọn mục tiêu phù hợp cho routing.
Session persistence cần được kiểm tra khi thay đổi cookie name, timeout, domain, SameSite hoặc cách backend mã hóa session. TLS cần được kiểm tra với certificate chain, SNI, cipher policy và các client còn được hỗ trợ. Header forwarding cần rõ ràng để ứng dụng không tin vào IP giả hoặc tạo redirect sai scheme. Timeout giữa client, load balancer và backend cần nhất quán; nếu một lớp timeout ngắn hơn bất hợp lý, người dùng sẽ thấy lỗi ngắt quãng rất khó tái hiện.
Quan sát xuyên suốt và rollback theo tín hiệu
Trong cửa sổ thay đổi, đừng chỉ nhìn dashboard load balancer. Theo dõi cùng lúc lỗi và latency ở edge, ứng dụng, database hoặc dependency quan trọng; đồng thời xem log có correlation ID. Khi lỗi tăng, cần biết request bị chặn ở đâu và nhóm người dùng nào bị ảnh hưởng. Một dashboard tổng hợp tốt hiển thị sự khác biệt trước và sau thay đổi, chứ không chỉ hiển thị một con số hiện tại.
Rollback phải là thao tác đã được chuẩn bị, không phải ý tưởng sau khi xảy ra lỗi. Xác nhận cấu hình trước đó, artifact hoặc template có thể áp dụng, DNS hoặc routing có thời gian hội tụ ra sao, ai phê duyệt và dữ liệu session nào có thể bị tác động. Đặt ngưỡng rollback trước khi bắt đầu: chẳng hạn một mức tăng lỗi liên tục, một flow quan trọng thất bại, health của backend giảm hoặc observability không còn đáng tin. Khi ngưỡng đạt, ưu tiên đưa dịch vụ về trạng thái đã biết thay vì tranh luận thêm về nguyên nhân.
Kết thúc thay đổi bằng bằng chứng và cải tiến
Sau khi traffic ổn định, chạy lại bộ smoke test, so sánh baseline, kiểm tra certificate và route hiếm, rồi xác nhận với owner ứng dụng. Lưu lại thay đổi, version, thời điểm, người phê duyệt, phát hiện và những việc cần làm sau đó. Nếu có incident nhỏ hoặc near miss, hãy xem đó là dữ liệu cải tiến: thiếu test nào, metric nào phát hiện muộn, rule nào quá phức tạp, hay dependency nào chưa có owner?
Một lộ trình hợp lý là chuẩn hóa inventory và baseline cho load balancer quan trọng trước, sau đó xây smoke test lặp lại và cơ chế canary, cuối cùng là diễn tập rollback. Thành công không được đo bằng việc thay đổi “không có ai phàn nàn” trong một lần. Nó được đo bằng việc đội ngũ có thể giải thích tác động, phát hiện hồi quy sớm và quay về trạng thái an toàn với ít hoảng loạn nhất.