Nhắc đến migration, người ta thường nhớ đến maintenance window. Một tối cuối tuần, một Change Request đã được approve, vài engineer ngồi trước màn hình, vendor online, checklist mở sẵn và đồng hồ bắt đầu chạy.
Nhưng sau nhiều lần tham gia và lead những thay đổi Infrastructure, mình thấy cutover chỉ là phần dễ nhìn thấy nhất. Một migration tốt thường đã được quyết định phần lớn từ nhiều ngày, thậm chí nhiều tuần trước đó.
Không phải lúc bắt đầu gõ command. Mà từ lúc team bắt đầu hiểu hệ thống đang phụ thuộc vào điều gì, điều gì tuyệt đối không được mất, và bằng chứng nào sẽ cho phép mình nói rằng migration đã thành công.
Thiết bị cũ và thiết bị mới chỉ là hai đầu của câu chuyện
Khi thay một platform, câu hỏi dễ nhất thường là: cấu hình cũ sẽ chuyển sang thiết bị mới như thế nào?
Nhưng configuration mapping chỉ là một phần. Một firewall còn có routing, NAT, VPN, authentication, security policy, logging, HA, management plane và những application nằm phía sau. Một Load Balancer còn có virtual service, health check, persistence, certificate và dependency với application. Một IPS đặt inline lại có thêm câu hỏi khó hơn: nếu policy mới chặn nhầm thì business flow nào sẽ bị ảnh hưởng?
Vì vậy, trước khi nghĩ đến cutover, mình thường muốn hiểu traffic path và dependency trước. Không phải để tạo ra một diagram thật đẹp, mà để biết khi một thứ thay đổi thì mình phải nhìn ở đâu.
Migration không phải là chuyển configuration từ A sang B. Migration là thay đổi một phần của hệ thống mà vẫn giữ được những service mà hệ thống đó đang phục vụ.
FDD hữu ích nhất khi nó buộc mình phải suy nghĩ trước
Trong một số project mình từng lead, FDD là nơi architecture, configuration logic, migration sequence và những assumption bắt đầu được đặt cạnh nhau. Giá trị của nó không nằm ở số trang.
Giá trị nằm ở những câu hỏi xuất hiện trong lúc viết: interface nào đang thực sự carrying traffic? Route nào là static, route nào học động? HA sẽ chuyển role ra sao? Có dependency nào đi qua một policy tưởng như không liên quan? Nếu rollback, trạng thái nào phải được phục hồi trước?
Nhiều vấn đề nếu phát hiện ở FDD chỉ là một dòng cần sửa. Nếu phát hiện giữa maintenance window, nó có thể trở thành một incident.
UAT không nên được viết sau khi đã biết hệ thống chạy
Mình thích xác định UAT trước cutover, vì lúc đó success criteria chưa bị ảnh hưởng bởi tâm lý muốn kết thúc maintenance.
Ở project External Firewall migration từ Palo Alto PA-3050 sang PA-3410 tại THP, validation không chỉ là HA đã hình thành hay policy đã migrate. Checklist còn phải đi qua public application, IPSec VPN, SSL Decryption, reporting và GlobalProtect VPN Pre-logon cho laptop công ty.
Pre-logon là một ví dụ mình nhớ khá lâu. Nhìn từ phía firewall, migration có thể hoàn toàn “xanh”. Nhưng một laptop đang ở ngoài văn phòng cần tự hình thành VPN về Head Office trước khi user có thể làm việc bình thường theo policy. Nếu flow đó không được kiểm tra, vấn đề có thể chỉ xuất hiện khi một người đang đi công tác ở múi giờ khác mở máy nhiều giờ sau maintenance window.
Đó là lúc mình thấy rõ sự khác nhau giữa device validation và service validation.
Rollback Plan không phải phần dành cho trường hợp thất bại
Có một nghịch lý nhỏ: càng tự tin vào migration, người ta càng dễ xem rollback như phần phụ. Nhưng với mình, một rollback plan rõ ràng lại làm team tự tin hơn khi quyết định đi tiếp.
Rollback cần trả lời ít nhất ba chuyện: khi nào quay lại, quay lại bằng cách nào, và sau khi quay lại thì kiểm chứng trạng thái cũ đã thực sự ổn bằng gì.
Quan trọng nhất là rollback trigger. Nếu không xác định trước, khi maintenance bắt đầu kéo dài, team rất dễ rơi vào trạng thái “thử thêm một chút nữa”. Mỗi thay đổi nhỏ tiếp theo lại làm trạng thái hệ thống xa baseline ban đầu hơn và recovery khó hơn.
Rollback vì vậy không phải dấu hiệu của một migration thất bại. Nó là một phần của controlled change.
Cutover là lúc thực thi những quyết định đã được chuẩn bị
Đến maintenance window, mình muốn phần lớn câu hỏi lớn đã có câu trả lời. Ai thực hiện bước nào. Ai quan sát. Vendor phụ trách phần nào. Khi nào pause. Khi nào validate. Khi nào rollback.
Điều đó không có nghĩa production sẽ không có bất ngờ. Production luôn có khả năng đưa ra một dependency mà tài liệu không thể hiện hết. Nhưng preparation tốt giúp team phân biệt được đâu là expected behavior, đâu là anomaly, và đâu là tín hiệu phải dừng.
Trong các migration như Peplink, Palo Alto, FortiGate hay IPS mà mình từng tham gia, maintenance window có công nghệ khác nhau, nhưng logic mình ngày càng giữ ổn định hơn:
Baseline → Change → Technical Validation → Service Validation → Observe → Close hoặc Rollback.
Migration kết thúc sau Cutover, không phải tại Cutover
Một trong những sai lầm dễ gặp là xem thời điểm traffic đã chuyển sang platform mới như vạch đích.
Thực tế, đó là lúc một giai đoạn khác bắt đầu. Monitoring sau thay đổi giúp nhìn ra những thứ UAT ngắn không thể hiện: error tăng chậm, session behavior bất thường, một traffic flow ít dùng, performance khác baseline hoặc một dependency chỉ xuất hiện theo lịch business.
Với Security Infrastructure, chuyện này càng rõ. Khi triển khai IPS, chẳng hạn, việc đưa thiết bị inline chưa phải mục tiêu cuối. Observation, policy tuning và quá trình đi từ Detection đến Prevention mới quyết định control đó có thực sự phù hợp với production hay không.
Một migration chỉ thật sự hoàn tất khi platform mới không chỉ chạy, mà đã được chứng minh là vận hành đúng trong context của hệ thống.
Điều mình học được sau nhiều maintenance window
Ngày trước, khi nhìn một migration plan, mình thường chú ý nhiều đến phần execution: bao nhiêu bước, command nào, thời gian từng bước và sequence ra sao.
Những thứ đó vẫn quan trọng. Nhưng càng làm lâu, mình càng dành nhiều thời gian hơn cho những câu hỏi xảy ra trước và sau execution.
Dependency nào mình chưa thấy? Failure domain nằm ở đâu? Success được định nghĩa bằng device status hay bằng business service? Nếu phải quay lại, điểm quay lại an toàn nhất là đâu? Và sau tất cả, evidence nào chứng minh hệ thống thực sự ổn?
Có lẽ vì vậy mà những migration mình nhớ nhất không phải những đêm cutover kéo dài bao lâu. Điều còn lại là cách cả team chuẩn bị để khi maintenance window bắt đầu, chúng mình không phải vừa thay đổi hệ thống vừa tìm hiểu xem hệ thống đang hoạt động như thế nào.
Cutover là một thời điểm. Migration là cả một quá trình.
Ghi lại từ những trải nghiệm thực tế của mình trong quá trình làm Infrastructure — những câu chuyện vẫn còn tiếp tục.
Đọc tiếp theo chủ đề: Một số dấu mốc Engineering 2023–2026 · High Availability không bắt đầu từ thiết bị thứ hai · Resilience không chỉ là Uptime · Hệ thống vẫn chạy tốt, tại sao vẫn phải thay?