Nhận diện sức ép phải thay đổi
Các dấu hiệu đáng chú ý gồm thời gian xử lý sự cố kéo dài, phát hành phiên bản khó dự đoán, thiếu người hiểu công nghệ cũ, tích hợp mới tốn nhiều công sức hoặc hạ tầng không còn được hỗ trợ. Một dấu hiệu riêng lẻ chưa đủ để quyết định; mức độ lặp lại và ảnh hưởng đến hoạt động mới là căn cứ quan trọng.
Gợi ý: lập danh sách vấn đề theo bốn nhóm gồm gián đoạn vận hành, rủi ro bảo mật, chi phí duy trì và hạn chế phát triển. Với mỗi vấn đề, ghi tần suất, bộ phận bị ảnh hưởng, cách xử lý tạm thời và hậu quả nếu trì hoãn. Cách này giúp tránh hiện đại hóa chỉ vì công nghệ đang dùng bị xem là lỗi thời.
Xác định đích đến trước công nghệ
Hướng dẫn kiến trúc Azure của Microsoft xem độ tin cậy, bảo mật, chi phí, vận hành và hiệu năng là các khía cạnh cần cân bằng theo yêu cầu kinh doanh. Tài liệu cũng lưu ý ứng dụng đám mây không bắt buộc phải dùng microservices; lựa chọn kiến trúc cần dựa trên yêu cầu kinh doanh, đặc điểm của khối lượng công việc và khả năng của nền tảng đám mây. [1]
Gợi ý thiết kế: chuyển mục tiêu chung thành tiêu chí kiểm chứng được, chẳng hạn rút ngắn thời gian khôi phục, giảm thao tác thủ công hoặc cho phép triển khai từng phần độc lập. Không nên chọn container, microservices hay cơ sở dữ liệu mới trước khi biết chúng giải quyết hạn chế nào của hệ thống hiện tại.
Chọn mức hiện đại hóa phù hợp
Doanh nghiệp có thể giữ nguyên hệ thống nhưng thay hạ tầng, nâng cấp một số thành phần, tách dần chức năng, thay thế bằng sản phẩm khác hoặc xây dựng lại. Mỗi phương án tạo ra mức thay đổi khác nhau đối với dữ liệu, tích hợp, quy trình vận hành và năng lực của đội ngũ.
Gợi ý: ưu tiên phạm vi có giá trị rõ và ranh giới tương đối độc lập. Trước khi tách một chức năng, cần làm rõ quyền sở hữu dữ liệu, giao diện tích hợp, cách xử lý lỗi và khả năng quay lại phiên bản cũ. Việc chia nhỏ chỉ hữu ích khi trách nhiệm vận hành cũng được xác định rõ.
Đưa bảo mật vào kế hoạch
NIST mô tả SSDF là tập hợp thực hành phát triển phần mềm an toàn cần được tích hợp vào vòng đời phát triển. Khung này hướng tới giảm lỗ hổng, giảm tác động của lỗ hổng chưa được phát hiện và xử lý nguyên nhân gốc; cách áp dụng cần điều chỉnh theo rủi ro, nguồn lực, chi phí và tính khả thi. [2]
Gợi ý: khi hiện đại hóa, kiểm kê tài khoản dịch vụ, bí mật, thư viện phụ thuộc, luồng dữ liệu và quyền truy cập trước khi di chuyển. Bổ sung kiểm tra mã, rà soát phụ thuộc, nhật ký và quy trình xử lý lỗ hổng theo mức rủi ro. Những biện pháp này giúp kiểm soát rủi ro nhưng không bảo đảm an toàn tuyệt đối.
Thử nghiệm bằng một lát cắt nhỏ
Gợi ý: chọn một quy trình có dữ liệu đại diện, nhóm người dùng được xác định rõ và tác động có thể đo lường. Thiết lập chỉ số ban đầu, chạy song song trong thời gian phù hợp, kiểm tra tính đúng của dữ liệu và chuẩn bị phương án quay lui. Kết quả thử nghiệm nên được dùng để điều chỉnh kiến trúc, ngân sách và thứ tự triển khai.
Ví dụ: hệ thống đơn hàng khó tích hợp có thể được hiện đại hóa trước ở chức năng tra cứu trạng thái qua API, thay vì viết lại toàn bộ. Nhóm dự án đo thời gian phản hồi, tỷ lệ lỗi và công sức vận hành trước khi quyết định mở rộng sang tạo hoặc cập nhật đơn hàng.