6R là một bộ phân loại sáu cách xử lý từng ứng dụng khi doanh nghiệp chuyển lên đám mây: giữ lại (retain), loại bỏ (retire), mua dịch vụ thay thế (repurchase), chuyển nguyên trạng (rehost), sửa nhẹ nền tảng (replatform) và thiết kế lại (refactor). Giá trị của nó không nằm ở sáu cái tên mà ở chỗ buộc đội ngũ ra quyết định cho từng ứng dụng một, thay vì một khẩu hiệu "đưa tất cả lên đám mây".
Khung này có gốc từ mô hình 5R mà hãng nghiên cứu Gartner công bố năm 2010, sau đó được một nhà cung cấp đám mây lớn phổ biến thành 6R vào khoảng năm 2016; một số tài liệu về sau thêm R thứ bảy là "relocate", chuyển nguyên cả cụm máy ảo sang đám mây mà không đổi gì bên trong. Tên gọi giữa các tài liệu có xê dịch, nhưng logic chung giống nhau: càng sửa nhiều, càng tốn công trước mắt và càng hưởng lợi nhiều về sau.
Sáu cách xử lý và đánh đổi của từng cách
Thứ tự trong bảng đi từ ít thay đổi đến nhiều thay đổi. Cột "khi nào hợp" là gợi ý điển hình, không phải luật.
| Chiến lược | Làm gì | Công sức | Lợi ích đám mây thu được | Khi nào hợp |
|---|---|---|---|---|
| Retire (loại bỏ) | Tắt hẳn ứng dụng, lưu trữ dữ liệu cần giữ | Rất thấp | Không áp dụng, nhưng tiết kiệm ngay | Ứng dụng ít người dùng, chức năng trùng với hệ thống khác |
| Retain (giữ lại) | Để nguyên tại chỗ, xem lại sau | Không | Không | Mới nâng cấp, sắp hết vòng đời, ràng buộc pháp lý hoặc độ trễ |
| Repurchase (mua thay thế) | Bỏ phần mềm tự vận hành, chuyển sang dịch vụ SaaS | Trung bình, chủ yếu là chuyển dữ liệu và đào tạo | Cao về vận hành, thấp về khác biệt | Chức năng phổ thông: thư điện tử, nhân sự, CRM, kế toán |
| Rehost (chuyển nguyên) | Chuyển máy chủ thành máy ảo trên đám mây, không đổi mã | Thấp | Thấp; chủ yếu bỏ được trung tâm dữ liệu | Hạn chót rời trung tâm dữ liệu, ứng dụng ổn định ít sửa |
| Replatform (sửa nhẹ) | Giữ kiến trúc, thay một vài thành phần bằng dịch vụ quản lý, như cơ sở dữ liệu | Trung bình | Trung bình; giảm việc vá lỗi, sao lưu | Ứng dụng sống lâu, có phần vận hành tốn công |
| Refactor (thiết kế lại) | Viết lại theo kiến trúc dành cho đám mây | Cao | Cao: co giãn, triển khai nhanh, chi phí theo tải | Ứng dụng lõi tạo khác biệt cạnh tranh, đang gặp giới hạn mở rộng |
Một quy luật quan sát được ở nhiều dự án: danh mục ứng dụng của doanh nghiệp vừa thường có một phần đáng kể có thể retire hoặc repurchase, nhưng phần này hay bị bỏ qua vì đội ngũ kỹ thuật thích bàn về rehost và refactor hơn. Đếm và tắt được những ứng dụng không ai dùng là khoản tiết kiệm rẻ nhất của cả dự án.
Vì sao "chuyển nguyên trạng" vừa được chuộng vừa bị chê
Rehost, hay "lift and shift", là cách nhanh nhất để ra khỏi một trung tâm dữ liệu sắp hết hợp đồng hoặc sắp phải thay thiết bị lớn. Công cụ sao chép máy chủ đã khá trưởng thành, rủi ro chức năng thấp vì mã không đổi, và đội ngũ học được cách vận hành đám mây trên những ứng dụng quen thuộc. Với lãnh đạo, đây là cách có kết quả đo được trong vài tháng.
Lời chê cũng có cơ sở. Một ứng dụng được thiết kế cho máy chủ vật lý chạy suốt ngày đêm sẽ tiếp tục chạy suốt ngày đêm trên đám mây, và được tính tiền theo giờ cho công suất đã đặt cho tải đỉnh. Nếu đội ngũ chỉ sao chép đúng cấu hình cũ, hoá đơn hằng tháng có thể cao hơn chi phí khấu hao phần cứng trước đây. Đây là nguồn gốc của nhiều câu chuyện "lên đám mây xong lại đắt hơn".
Cách dùng rehost đúng là coi nó như bước một của hai bước: chuyển nguyên để rời trung tâm dữ liệu, rồi trong sáu đến mười hai tháng tiếp theo đo tải thật, thu nhỏ máy về đúng cỡ, tắt môi trường thử nghiệm ngoài giờ và replatform những thành phần tốn công vận hành nhất. Nếu kế hoạch không có bước hai, nên ghi rõ điều đó để lãnh đạo không kỳ vọng tiết kiệm.
Replatform và refactor: chỗ khác nhau thật sự
Ranh giới giữa hai chiến lược này hay bị nhoè. Một cách phân biệt dễ dùng: replatform thay thành phần, refactor thay kiến trúc. Chuyển cơ sở dữ liệu tự cài trên máy ảo sang dịch vụ cơ sở dữ liệu quản lý, đưa tệp tin tải lên vào kho lưu trữ đối tượng, đóng gói ứng dụng vào container mà không tách nhỏ: đó là replatform. Logic nghiệp vụ và cấu trúc mã gần như giữ nguyên, nên rủi ro chức năng vẫn thấp.
Refactor là khi bạn tách một khối ứng dụng lớn thành các dịch vụ nhỏ, chuyển phần xử lý theo sự kiện sang hàm chạy theo yêu cầu, thiết kế lại để không giữ trạng thái trên máy chủ, hoặc đổi mô hình dữ liệu. Lợi ích là ứng dụng co giãn theo tải và triển khai độc lập từng phần; cái giá là gần như một dự án phần mềm mới, với đủ rủi ro về tiến độ, chất lượng và kiến thức nghiệp vụ bị mất trong lúc viết lại.
Kinh nghiệm chung của ngành là chỉ refactor những ứng dụng mà doanh nghiệp sẽ còn đầu tư phát triển nhiều năm và đang gặp giới hạn thật: không chịu nổi tải mùa cao điểm, mỗi lần phát hành mất hàng tuần, hay một thay đổi nhỏ làm hỏng cả hệ thống. Refactor một ứng dụng ổn định, ít thay đổi chỉ vì "cho hiện đại" là cách đốt ngân sách phổ biến.
Cây quyết định cho từng ứng dụng
Áp dụng lần lượt cho từng dòng trong danh mục ứng dụng. Dừng ở câu đầu tiên có câu trả lời rõ.
- Có ai còn cần ứng dụng này không? Kiểm nhật ký truy cập ba đến sáu tháng. Không ai dùng hoặc chức năng đã có ở hệ thống khác: retire.
- Có lý do bắt buộc phải ở lại không? Ràng buộc pháp lý về vị trí dữ liệu, độ trễ với thiết bị tại chỗ, phần cứng chuyên dụng, hoặc vừa đầu tư lớn chưa khấu hao xong: retain và hẹn ngày xem lại.
- Chức năng có phổ thông và có dịch vụ thay thế tốt không? Nếu ứng dụng không tạo khác biệt cạnh tranh: cân nhắc repurchase.
- Ứng dụng có phải lõi tạo khác biệt và đang chạm giới hạn không? Nếu có và doanh nghiệp sẵn ngân sách cho một dự án phát triển thật sự: refactor, thường làm dần theo từng phần.
- Có thành phần nào tốn công vận hành mà có dịch vụ quản lý tương đương không? Nếu có: replatform phần đó.
- Còn lại: rehost, kèm kế hoạch tối ưu sau khi chạy ổn định.
Ghi lý do cho từng quyết định vào cùng một bảng. Sau hai năm, khi có người hỏi vì sao hệ thống này còn ở tại chỗ hay vì sao hệ thống kia bị viết lại, bảng lý do này tiết kiệm rất nhiều tranh luận.
Đánh giá danh mục: bước bị cắt nhiều nhất và đắt nhất khi bị cắt
Trước khi xếp ứng dụng vào R nào, phải biết mình có những gì. Ở nhiều doanh nghiệp Việt Nam đã vận hành mười đến hai mươi năm, danh mục ứng dụng chỉ tồn tại trong đầu vài người: một máy chủ chạy phần mềm chấm công do một nhân viên cũ viết, một cơ sở dữ liệu kho được ba hệ thống khác đọc trực tiếp, một tác vụ chạy đêm gửi tệp cho ngân hàng. Bỏ sót một mối phụ thuộc như vậy là nguyên nhân phổ biến của sự cố ngày cắt chuyển.
Một bản đánh giá đủ dùng ghi cho mỗi ứng dụng: chủ sở hữu nghiệp vụ, số người dùng, mức quan trọng, các hệ thống nó gọi và gọi nó, cơ sở dữ liệu và dung lượng, tải theo giờ, giấy phép phần mềm và điều khoản có cho chạy trên đám mây hay không. Dòng giấy phép hay bị quên: một số phần mềm thương mại tính phí theo nhân xử lý vật lý hoặc giới hạn quyền chạy trên hạ tầng thuê ngoài, khiến chi phí sau di chuyển tăng bất ngờ.
Từ bảng đánh giá, các ứng dụng phụ thuộc chặt vào nhau được gom thành làn sóng di chuyển. Làn đầu nên là vài ứng dụng ít rủi ro nhưng đủ đại diện để đội ngũ học quy trình; các hệ thống lõi để sau, khi đội đã quen công cụ và đã dựng xong nền tảng chung về mạng, danh tính, giám sát, sao lưu.
Đo thành công của một dự án di chuyển
Không chỉ đếm số máy đã chuyển. Số máy chủ đã lên đám mây là chỉ số tiến độ, không phải chỉ số giá trị. Một dự án chuyển xong toàn bộ nhưng hoá đơn cao hơn và tốc độ phát hành không đổi thì chưa thành công.
Chi phí trên một đơn vị nghiệp vụ. Chi phí hạ tầng trên mỗi đơn hàng, mỗi người dùng hoạt động hay mỗi giao dịch, so trước và sau, là thước đo trung thực hơn tổng hoá đơn, vì nó tách được ảnh hưởng của tăng trưởng.
Tốc độ và độ ổn định khi thay đổi. Tần suất phát hành, thời gian từ khi viết xong mã đến khi chạy thật, tỷ lệ phát hành gây lỗi và thời gian khôi phục là bốn chỉ số mà nghiên cứu DORA phổ biến; chúng đo đúng lợi ích mà replatform và refactor hứa hẹn.
Rủi ro đã giảm. Số hệ thống không còn được nhà sản xuất hỗ trợ, số máy chưa vá, khả năng khôi phục sau thảm hoạ đã được diễn tập: những thứ này khó quy ra tiền nhưng thường là lý do thật của dự án.
Năm sai lầm làm dự án di chuyển trễ hạn
Các báo cáo hậu kiểm dự án di chuyển, dù khác ngành, thường lặp lại cùng một nhóm nguyên nhân. Biết trước giúp bạn đưa chúng vào sổ rủi ro ngay từ đầu.
- Chọn một R cho cả danh mục. Quyết định "rehost hết cho nhanh" hoặc "refactor hết cho hiện đại" bỏ qua sự khác biệt giữa các ứng dụng; kết quả là hoặc hoá đơn cao, hoặc dự án kéo dài vô hạn.
- Ước thấp phần dữ liệu. Chuyển vài chục terabyte qua đường truyền văn phòng có thể mất nhiều ngày; dữ liệu thay đổi liên tục cần cơ chế đồng bộ chứ không chỉ sao chép một lần. Thời gian và phương án chuyển dữ liệu nên được thử thật trước khi chốt lịch.
- Quên kiểm thử hiệu năng ở môi trường mới. Độ trễ mạng, hiệu năng ổ đĩa và cách tính giới hạn tài nguyên trên đám mây khác máy vật lý; một báo cáo chạy mười phút tại chỗ có thể chạy một giờ nếu ổ đĩa được chọn sai loại.
- Để chủ nghiệp vụ đứng ngoài. Kỹ thuật biết máy nào chạy gì, nhưng chỉ người dùng biết chức năng nào quan trọng vào ngày chốt sổ hay ngày trả lương. Lịch cắt chuyển chọn sai ngày có thể làm đình trệ đúng nghiệp vụ nhạy cảm nhất.
- Không có kế hoạch quay lui. Mỗi làn sóng cần tiêu chí rõ ràng để quyết định quay về hệ thống cũ, cùng thời hạn giữ hệ thống cũ ở trạng thái chạy được. Tắt hệ thống nguồn quá sớm biến một sự cố nhỏ thành khủng hoảng.
Câu hỏi thường gặp
Nên di chuyển cơ sở dữ liệu trước hay ứng dụng trước?
Thường nên chuyển cùng nhau hoặc chuyển cơ sở dữ liệu cùng lúc với tất cả ứng dụng đọc ghi trực tiếp vào nó. Để ứng dụng một nơi, cơ sở dữ liệu một nơi sẽ chịu độ trễ mạng trên mỗi truy vấn, làm hệ thống chậm rõ rệt và đôi khi phát sinh phí truyền dữ liệu lớn.
Thời gian ngừng hệ thống khi cắt chuyển có tránh được không?
Có thể giảm xuống rất ngắn bằng cách sao chép dữ liệu liên tục sang đích, chạy song song và chỉ dừng ghi trong khoảng đổi kết nối. Không ngừng hoàn toàn thì khó và tốn kém; với đa số hệ thống nội bộ, một khoảng ngừng có kế hoạch vào cuối tuần là đánh đổi hợp lý.
Có nên thuê đối tác làm toàn bộ việc di chuyển?
Đối tác giúp đi nhanh ở phần đánh giá, dựng nền tảng và các làn đầu. Nhưng nếu đội nội bộ không tham gia, sau khi đối tác rời đi sẽ không ai hiểu môi trường mới. Cách an toàn là làm chung, với điều khoản chuyển giao kiến thức rõ ràng trong hợp đồng.
Repurchase có phải lúc nào cũng rẻ hơn tự vận hành?
Không chắc. Phí thuê bao theo người dùng cộng dồn nhiều năm có thể vượt chi phí tự vận hành, và chi phí chuyển dữ liệu, tuỳ biến, đào tạo lại thường bị ước thấp. Cần so tổng chi phí trong ba đến năm năm, kể cả chi phí rời khỏi dịch vụ đó sau này.
Landing zone là gì và có bắt buộc không?
Đó là nền tảng chung dựng trước khi chuyển ứng dụng: cấu trúc tài khoản, mạng, danh tính, nhật ký, giám sát, quy tắc gắn thẻ chi phí. Không bắt buộc về kỹ thuật, nhưng bỏ qua thì mỗi đội tự dựng một kiểu, và việc chuẩn hoá lại sau này tốn hơn nhiều so với làm từ đầu.