GitHub chuẩn bị từ tháng 7/2022 để chuyển toàn bộ đội máy chủ MySQL (hơn 1.200 máy, trên 50 cụm, trên 300 TB) từ 5.7 sang 8.0 mà không vi phạm cam kết dịch vụ. Điểm đáng học không nằm ở công nghệ mà ở cách quản lý: danh mục kiểm tra sẵn sàng, đưa 8.0 vào CI, nâng cấp từng bước và luôn giữ khả năng quay về 5.7.
Với hơn 50 cụm, không thể có một "đêm chuyển đổi" duy nhất. GitHub chia thay đổi thành các bước nhỏ, mỗi bước đều có điểm quay lui: nâng replica trước, rồi chuyển primary bằng failover có kiểm soát chứ không nâng tại chỗ. Mỗi thay đổi được xem xét về tác động lên cam kết dịch vụ trước khi triển khai — đúng tinh thần kiểm soát thay đổi tích hợp, nơi rủi ro được cân nhắc theo từng đợt chứ không theo cả dự án.
Nhiều dự án chuyển đổi ghi "có thể rollback" trong kế hoạch nhưng không kiểm chứng. Ở đây đội dự án thử quay lui thật ở staging và phát hiện ngay đường lui bị gãy. Nhờ vậy họ sửa cấu hình ký tự, điều chỉnh phân quyền tạm thời, soạn hướng dẫn cấu hình kết nối đồng nhất cho các ứng dụng. Giá trị của việc kiểm thử cutover nằm ở chỗ nó biến giả định thành bằng chứng.
GitHub thêm MySQL 8.0 vào CI của mọi ứng dụng, chạy song song 5.7 và 8.0 để lộ sớm từ khoá mới, cấu hình không còn được hỗ trợ; đồng thời cung cấp cụm phát triển 8.0 và container dựng sẵn trong Codespaces. Đây là cách phân tán việc kiểm thử tích hợp cho các đội ứng dụng thay vì dồn về đội hạ tầng. Giới hạn: CI không bắt được lỗi truy vấn cỡ lớn, nên cần thêm lấy mẫu truy vấn ở môi trường thật.
Việc nâng cấp đòi hỏi cả đội cơ sở dữ liệu lẫn đội ứng dụng cùng hành động. GitHub theo dõi bằng lịch cuốn chiếu trên GitHub Projects, dùng mẫu issue có checklist cho từng bên, và ghi lại các phát hiện thành hướng dẫn chung. Đó là Manage Project Knowledge trong thực tế: bài học từ cụm đầu được đưa vào danh mục kiểm tra cho cụm sau.
Trước mỗi cụm, PM thống nhất với đội kỹ thuật và chủ sở hữu dịch vụ bộ tiêu chí để quyết định tiếp tục hay dừng:
Replica 8.0 đã chạy ổn trong ít nhất một chu kỳ tải đầy đủ, độ trễ và chỉ số truy vấn trong ngưỡng, đường lui sao chép về 5.7 đã được thử.
Có lệch nhỏ (ví dụ một truy vấn chậm hơn) nhưng đã có người chịu trách nhiệm, hạn xử lý và cửa sổ quay lui còn đủ dài.
Sao chép ngược gãy, độ trễ vượt ngưỡng hoặc vi phạm SLO; không chuyển primary cho tới khi nguyên nhân được xử lý và duyệt lại.
Bắt đầu bằng cụm ít quan trọng để rút kinh nghiệm, dành cụm lõi cho sau; tránh trùng với các thay đổi lớn khác của công ty bằng lịch thay đổi chung. Cắt dự án thành các giai đoạn có kết quả đo được giúp ban lãnh đạo thấy tiến độ mà không phải chờ ngày hoàn tất.
Chỉ tắt máy 5.7 khi cụm mới đã chạy thành công ít nhất một chu kỳ 24 giờ của lưu lượng thật. Việc đóng giai đoạn cần có xác nhận chính thức của chủ sở hữu dịch vụ, tránh tình trạng "coi như xong" khi vẫn còn phụ thuộc chưa biết.
Chuyển đổi hệ thống lớn thành công nhờ chia nhỏ thay đổi, kiểm chứng đường lui bằng thử thật và cho phép mỗi đội thấy rủi ro của mình sớm. Một kế hoạch cutover tốt không hứa "sẽ không lỗi" mà trả lời được câu hỏi: nếu lỗi, ta quay về bằng cách nào và trong bao lâu.
Bạn chọn phương án nào?