Go-Live and Cutover
Giai đoạn chuyển từ hệ thống cũ sang hệ thống mới trong đời thật: kế hoạch cắt chuyển theo mốc giờ, tiêu chí go hoặc no-go, phương án quay đầu và những tuần chăm sóc đặc biệt sau đó.
Định nghĩa
Mọi thứ trước đó đều có thể làm lại. Đêm cắt chuyển thì không. Đó là lúc dữ liệu thật, người dùng thật và tiền thật chuyển sang hệ thống mới, trong khung giờ hẹp giữa đêm, với danh sách việc phải chạy đúng thứ tự. Vai trò BA ở đây ít ai nói tới, nhưng thiếu bạn thì không ai trả lời câu hỏi nghiệp vụ lúc 2 giờ sáng.
Kế hoạch cắt chuyển tốt được đo bằng một thứ: đến phút thứ 200, có ai phải ứng biến không.
Ba kiểu chuyển
- Cắt một lần — tắt hệ cũ, bật hệ mới. Nhanh, rẻ, rủi ro dồn vào một đêm.
- Cuốn chiếu — theo chi nhánh hoặc nhóm nghiệp vụ. Kéo dài, phải chịu cảnh hai hệ cùng sống.
- Chạy song song — nhập liệu hai lần rồi đối chiếu. An toàn nhất, tốn nhân lực gấp đôi.
Chọn kiểu nào là quyết định của cả dự án, vì nó đổi luôn kế hoạch nhân sự và đào tạo.
Cutover plan gồm gì
Bản kế hoạch dùng được là một bảng theo mốc giờ, mỗi dòng có người làm và điều kiện xác nhận xong. Trước đó một tuần là mốc đóng băng thay đổi:
| Giờ | Việc | Người | Xác nhận xong |
|---|---|---|---|
| T-1 ngày | Diễn tập chuyển dữ liệu trên bản sao | Dev | Số dòng khớp báo cáo |
| 22:00 | Khoá nhập liệu hệ cũ | Vận hành | Ảnh chụp màn hình khoá |
| 22:30 | Sao lưu hệ cũ | DevOps | Backup mở kiểm tra được |
| 23:00 | Chạy chuyển dữ liệu | Dev | Log không lỗi |
| 01:00 | Đối chiếu số liệu | BA, kế toán | Bảng đối chiếu ký nhận |
| 02:00 | Kiểm thử nhanh luồng chính | QC, BA | 12 kịch bản pass |
| 03:00 | Chốt go hoặc no-go | Sponsor | Quyết định ghi vào nhóm chat |
Hai dòng quan trọng nhất là đối chiếu số liệu và chốt go hoặc no-go. Đối chiếu phải do người nghiệp vụ ký, đừng để lập trình viên nhìn log rồi bảo ổn.
Rollback: viết tiêu chí trước, đừng quyết lúc 3 giờ sáng
Phương án quay đầu cần ba thứ, cả ba viết ra từ trước:
- Tiêu chí quay đầu, cụ thể tới mức khỏi tranh luận: chênh lệch công nợ trên 0,1%, luồng thanh toán không chạy sau hai lần thử, hoặc quá 4 giờ sáng chưa xong đối chiếu.
- Các bước quay đầu, có người phụ trách từng bước, đã diễn tập ít nhất một lần.
- Ai có quyền hô quay đầu. Một người, có tên, có số điện thoại, và phải thức.
Điều tệ nhất là 3 giờ sáng mới ngồi bàn xem thế nào là đủ tệ để dừng. Lúc đó ai cũng mệt, ai cũng đã bỏ ra hai tháng, và tâm lý chung là ráng thêm chút nữa.
Đêm go-live, BA làm gì
Bạn không chạy lệnh, không deploy. Việc của bạn:
- Cầm bảng đối chiếu nghiệp vụ. Tổng công nợ, số dư, số đơn treo, số khách đang hoạt động. Chốt cách lấy số ở cả hai hệ thống từ trước.
- Trực câu hỏi nghiệp vụ. Chuyển dữ liệu luôn lòi ra bản ghi rác: khách trùng mã, đơn từ 2019 chưa đóng, giá trị âm. Ai đó phải quyết ngay bỏ, giữ hay để lại sau.
- Giữ nhật ký giờ: mốc thời gian thật của từng bước và mọi việc phát sinh, rất quý cho đợt cuốn chiếu sau.
- Soạn sẵn hai bản thông báo: một khi thành công, một khi hoãn. Viết lúc đầu óc còn tỉnh.
Ví dụ thực tế
Chuỗi bán lẻ 60 cửa hàng thay hệ thống bán hàng, cắt một lần vào đêm chủ nhật vì không thể chạy hai bảng giá song song.
Khoá hệ cũ lúc 22:00. Chuyển 1,2 triệu dòng công nợ và tồn kho hết 2 giờ 40 phút, lâu hơn bản diễn tập 40 phút vì dữ liệu phát sinh trong tuần cuối.
Lúc 1:30, tồn kho lệch ở 3 cửa hàng do có phiếu chuyển kho nội bộ chưa duyệt lúc khoá. BA cho lệch tạm và đưa vào danh sách xử lý tay sáng thứ hai, vì tiêu chí quay đầu đã ghi ngưỡng chấp nhận là dưới 5 cửa hàng và dưới 50 triệu.
Chốt go lúc 3:00. Cửa hàng mở cửa 8:00 với 6 người trực hỗ trợ. Ngày đầu nhận 118 cuộc gọi, 71 cuộc trong đó là hỏi cách thao tác chứ không phải lỗi.
Hypercare
Hai tới bốn tuần sau go-live: kênh hỗ trợ riêng, họp 15 phút mỗi sáng đọc sự cố qua đêm, một người có quyền quyết tại chỗ. Phân loại phản hồi thành ba nhóm — lỗi thật, thao tác sai do chưa quen, và yêu cầu mới. Nhóm thứ hai chiếm phần lớn tuần đầu, và nó chỉ ra tài liệu hướng dẫn thiếu chỗ nào. Nhóm thứ ba gom vào backlog đợt hai. Đặt lời nhắc ở mốc 90 ngày để quay lại đo xem hệ thống mới có mang lại con số đã hứa hay không.
