Chi phí thực sự của việc chuyển sang công cụ mới thường chỉ lộ rõ sau khi bắt đầu migration. Ánh xạ tài khoản, cấu hình môi trường, đầu ra mạng, quyền của nhóm và việc có giữ môi trường cũ hay không sẽ quyết định quá trình chuyển đổi diễn ra suôn sẻ hay phải làm lại.
Thoạt nhìn, đổi công cụ quản lý môi trường khá đơn giản: cài phần mềm và xuất dữ liệu.
Nhưng phần tốn thời gian nhất lại nằm ở những chi tiết thường ít được chú ý: có mang theo được quan hệ ánh xạ giữa hàng chục tài khoản và môi trường không, cấu hình môi trường có phải dựng lại từ đầu không, thói quen vận hành của nhóm còn áp dụng được không, và môi trường cũ có thể tắt ngay trong ngày hay không. Nếu chưa làm rõ những câu hỏi này ở giai đoạn ra quyết định, quá trình migration rất dễ biến thành một vòng làm lại.
Trước tiên, xác nhận tài khoản và môi trường vẫn có thể khớp đúng với nhau
Thứ cần chuyển không chỉ là tài khoản và mật khẩu, mà là toàn bộ ánh xạ: tài khoản nào chạy trong môi trường nào và môi trường đó đang gắn với đầu ra mạng nào. Nếu không thể xuất ánh xạ này, migration gần như đồng nghĩa với việc dựng lại thủ công. Khi số lượng tài khoản lên đến hàng chục hoặc hàng trăm, sai sót gần như không thể tránh khỏi.
Cách kiểm tra rất trực tiếp: mở chức năng xuất dữ liệu trong công cụ cũ và xem các trường xuất ra có mã nhận diện môi trường và cấu hình mạng hay không. Nếu chỉ xuất được tài khoản và mật khẩu thì về cơ bản vẫn là chưa đủ.
Cấu hình môi trường cần được dựng lại, không phải sao chép nguyên xi
Tham số fingerprint, múi giờ và ngôn ngữ, cùng đầu ra được gắn là những thành phần cốt lõi của môi trường. Tuy nhiên, hệ thống tham số giữa các công cụ không dùng chung một chuẩn. Cố chuyển từng tham số sang thường dẫn đến thiếu dữ liệu hoặc không khớp.
Cách thực tế hơn là xuất ý đồ cấu hình, chẳng hạn khu vực Hoa Kỳ, hệ điều hành Windows và một mức phần cứng nhất định, sau đó dựng lại môi trường trong công cụ mới theo ý đồ đó. Mục tiêu là một môi trường nhất quán và sử dụng được, không phải bản sao y hệt môi trường cũ.
Cookie và trạng thái đăng nhập
Với các tài khoản cần duy trì đăng nhập, việc có chuyển được trạng thái phiên hay không sẽ quyết định sau migration có phải đăng nhập lại toàn bộ hay không. Một điểm dễ bỏ qua là việc hàng chục tài khoản cùng đăng nhập lại trong một ngày tự thân đã là tín hiệu bất thường. Nên giãn nhịp chuyển đổi thay vì cắt toàn bộ trong một lần.
Cách gắn đầu ra mạng có tương thích không?
Nếu đầu ra được gắn theo môi trường, cần xác nhận công cụ mới hỗ trợ cùng giao thức và cách gắn. Nếu không, toàn bộ cấu hình mạng sẽ phải làm lại và khối lượng công việc này phải được tính từ trước.
Thói quen làm việc của nhóm có bị gián đoạn không?
Mô hình phân quyền có tương đương không? Thành viên có thể thao tác mà không cần bàn giao mật khẩu cho nhau không? Nhật ký thao tác còn xem được không? Ba điểm này quyết định nhóm sẽ phải học lại nhiều đến mức nào. Nhóm càng lớn thì chi phí càng cao.
Có nên giữ môi trường cũ thêm một thời gian?
Migration không nhất thiết phải hoàn tất trong một bước. Giữ môi trường cũ thêm vài tuần thường hữu ích hơn tưởng tượng: có thể đối chiếu với môi trường mới, xử lý các tài khoản gặp trục trặc giữa quá trình chuyển đổi và có điểm quay lại nếu công cụ mới phát sinh vấn đề bất ngờ.
Sắp xếp giai đoạn chuyển tiếp như thế nào
Trong một đến hai tuần đầu, hãy thử migration quy mô nhỏ với năm đến mười tài khoản ít quan trọng hơn và chạy trọn vẹn quy trình nghiệp vụ. Mục đích là kiểm tra công cụ mới có chịu được công việc thực tế hay không, chứ không phải danh sách tính năng dài đến đâu.
Tiếp theo là giai đoạn quan sát từ hai đến bốn tuần. Giữ thao tác vận hành gần với cách cũ và so sánh độ ổn định của tài khoản, tần suất kích hoạt xác minh và tỷ lệ hoàn thành tác vụ ở hai phía. Nếu môi trường mới rõ ràng kém hơn ở thời điểm này, chi phí rollback vẫn còn thấp.
Cuối cùng, chuyển theo từng đợt dựa trên mức độ quan trọng đối với nghiệp vụ. Không nên dồn việc đăng nhập lại của các tài khoản trong cùng một đợt vào cùng một thời điểm. Trong giai đoạn migration, cũng tránh thay đổi thêm các biến số khác như đồng thời đổi chiến lược nội dung, vì nếu xảy ra vấn đề sẽ rất khó xác định nguyên nhân.
Một số sai lầm đánh giá thường gặp
Quyết định migration chỉ dựa trên giá phần mềm là coi chi phí nhìn thấy được như toàn bộ chi phí. Nhân lực, biến động nghiệp vụ trong giai đoạn chuyển tiếp và khả năng mất tài khoản cộng lại thường vượt xa phần tiền tiết kiệm được từ phần mềm.
Một sai lầm khác là migration chỉ vì muốn migration. Nếu công cụ hiện tại vốn đã đáp ứng nhu cầu, đổi chỉ vì công cụ mới có nhiều tính năng hơn thường không đem lại bài toán kinh tế hợp lý. Hãy liệt kê cụ thể hiện tại đang vướng ở đâu rồi mới đánh giá công cụ mới có giải quyết được hay không.
Rủi ro nhất là chuyển tất cả tài khoản cùng lúc. Toàn bộ rủi ro bị dồn vào một thời điểm, và nếu có sự cố thì không còn đường lui.
Trước khi quyết định, hãy trả lời ba câu hỏi
Vấn đề cụ thể của công cụ hiện tại là gì? Cần mô tả đến từng tình huống thay vì chỉ nói cảm giác là khó dùng. Công cụ mới có chắc chắn giải quyết được các vấn đề đó không, tốt nhất là có thể kiểm chứng ngay trong giai đoạn thử nghiệm? Nếu migration thất bại, cái giá phải trả là gì, có thể rollback không và mất bao lâu?
Chỉ bắt đầu khi cả ba câu hỏi đều có câu trả lời rõ ràng.
