Tình huống triển khai AI
"Đang chạy nên đừng đụng vào". Một hệ thống bị nói như thế mãi, đến lúc nhận ra thì vẫn đang chạy ở trung tâm nội bộ y như 10 năm trước — hẳn nhiều doanh nghiệp thấy quen thuộc. Lần này là ghi chép thực tế về việc di chuyển một hệ thống quản lý dự án phát hành năm 2016, từ trạng tháivẫn được công khai lên Internet trên một OS đã hết hỗ trợ vào năm 2020và vẫn được sử dụng, sang môi trường mới nhất. 2 ngày làm việc thực tế.Chúng tôi đã kế thừa 3.623 ticket và 4,0 GB tệp đính kèm mà không mất mát dù chỉ một mục.
"Đang chạy nên không thể chạm vào" đã kéo dài suốt 10 năm.
Đối tượng là hệ thống quản lý dự án nội bộ (Redmine). Tiến độ các dự án, hồ sơ xử lý sự cố, diễn biến trao đổi với khách hàng — 10 năm dữ liệu tích tụ ở đây. Đúng là trạng tháikhông thể dừng nên không thể chạm vào.
Nhưng khi điều tra bên trong, đó tuyệt nhiên không phải trạng thái có thể để mặc.
| Hạng mục | Trước khi di chuyển | Sau khi di chuyển |
|---|---|---|
| OS | CentOS 6.10 (hết hỗ trợ năm 2020) | AlmaLinux 10.1 |
| Ứng dụng | Redmine 3.2.1 (năm 2016) | Redmine 6.1.3 |
| Môi trường thực thi | Ruby 2.2.4 | Ruby 3.3.10 |
| Cơ sở dữ liệu | MySQL 5.7 | MariaDB 10.11 |
| Máy chủ Web | Apache 2.2 + Passenger | nginx 1.26 + puma |
Đã 6 năm kể từ khi OS hết hỗ trợ.Trong khoảng thời gian đó, không một bản vá lỗ hổng được công bố nào được áp dụng. Vậy mà nó vẫn tiếp tục chạy trong trạng thái có thể truy cập từ bên ngoài. Cách diễn đạt chính xác không phải "đang chạy nên an toàn", mà là"chỉ là đang chạy thôi, chứ không được bảo vệ".
Mà là nó không hỏng, chỉ có phần phòng thủ đã ngừng lại.
Thành bại của việc di chuyển đã được định đoạt bởi đo lường thực tế trước khi bắt tay.
Trước khi bước vào di chuyển, chúng tôi nắm bắt hiện trạng bằng con số. Chính điểm này rốt cuộc đã ảnh hưởng lớn đến khối lượng công việc.
- Cơ sở dữ liệu 38MB / tệp đính kèm 4,0GB
- 20–30 yêu cầu mỗi ngày =vẫn đang được sử dụng thực tế
- Plugin mở rộng: không có. Thiết kế riêng: không có
Dòng cuối cùng mang tính quyết định. Điều gây tranh cãi nhất trong loại di chuyển này làliệu các tính năng mở rộng cài thêm sau này có chạy được trên phiên bản mới hay không. Nếu không chạy được thì rơi vào ba lựa chọn "tìm cái thay thế", "từ bỏ tính năng", "tự sửa lấy", và ở đó mất đứt vài tuần. Lần này, chướng ngại đó ngay từ đầu đã không tồn tại.
Dựa trên đo lường thực tế này, trước khi bắt tay chúng tôi đã quyết định 3 phương châm.
1. Ngừng nâng cấp phiên bản từng bậc một
Ban đầu chúng tôi ước lượng với tiền đề nâng cấp từng bước 3.2 → 4.2 → 5.1 → 6.x. Nhưng khi kiểm chứng thì thấy rằngcó thể cập nhật nhảy vọt qua cả 10 năm trong một lần. Toàn bộ khối lượng công việc dự kiến đã trở nên không cần thiết.
2. Không thay đổi loại cơ sở dữ liệu
Cũng có phương án chuyển sang một sản phẩm cơ sở dữ liệu khác để đồng bộ vận hành với các hệ thống khác. Nhưng vì định dạng dữ liệu ở nguồn di chuyển khác nhau, nên cần chèn thêm bước xử lý chuyển đổi.Không mang rủi ro chuyển đổi vào loại "dữ liệu mà nếu mất cũng khó nhận ra" gồm 3.623 ticket và 6.071 bản ghi lịch sử.Chúng tôi ưu tiên việc không mất dù chỉ một mục dữ liệu hơn là thống nhất vận hành.
3. Không nâng cấp trực tiếp máy chủ hiện có
Chúng tôi chuẩn bị riêng một máy chủ mới, và việc chuyển đổi chỉ là viết lại một dòng cấu hình ở lối vào.thất bại thì chỉ cần lùi lại một dòng là về như cũ— để duy trì trạng thái đó cho đến cuối cùng.
Thứ ngốn thời gian không phải là Redmine.
Từ đây là phần thực thi. Khi liệt kê các vấn đề vấp phải trong lúc di chuyển, một xu hướng hiện ra rõ rệt.
Trong 8 vấn đề,chỉ có 3 vấn đề bắt nguồn từ chính bản thân Redmine. Hơn nữa, một trong số đó lại là sự tính toán sai theo hướng tốt: "đơn giản hơn tưởng". Thực chất chỉ có 2 vấn đề khiến chúng tôi vất vả.
Phần còn lại là khác biệt thế hệ OS, cơ chế bảo mật, đường truyền, mã hóa, liên kết với hệ thống bên ngoài —tất cả đều nằm ở bên ngoài ứng dụng.
Mà là "sự khác biệt của môi trường xung quanh" tích tụ suốt 10 năm.
Không buông bỏ "lùi lại được bằng một dòng" cho đến phút cuối.
Việc chuyển đổi chỉ là hướng đích chuyển tiếp của máy chủ lối vào sang máy chủ mới. Khi lùi lại cũng chỉ một dòng. Vàchúng tôi không dừng môi trường cũ mà để nó vẫn chạy.
Vào ngày chuyển đổi, "môi trường cũ đang chạy" và "môi trường mới đang chạy" cùng tồn tại, giữ trạng thái có thể qua lại giữa cả hai chỉ bằng một dòng. Sau khi để vài ngày và xác nhận không có vấn đề, chúng tôi mới dừng phía cũ.
Không dừng ở việc di chuyển, mà lấp đầy những thiếu hụt suốt 10 năm.
Ở môi trường mới, chúng tôi đồng thời chuẩn bị những thứ mà môi trường cũ không có.
- Sao lưu hằng ngày (7 thế hệ) — môi trường cũ vốn không có cả cơ chế sao lưu
- Ghi lại nguồn truy cập — trước khi di chuyển, mọi truy cập trông đều như một, không thể lần ra ai đến từ đâu
- Giới hạn số lần thử đăng nhập — vì không có tính năng chuẩn nên gia cố ở phía máy chủ Web
- Tự động cập nhật liên kết mã nguồn — việc liên kết vốn thực chất đã đóng băng nay được cập nhật mỗi 15 phút
Dữ liệu được kế thừa như sau. Chúng tôi đã xác nhận số lượng ở môi trường cũ và môi trường mới hoàn toàn khớp nhau.
Việc liên kết từ các hệ thống bên ngoài cũng chạy nguyên vẹn mà không cần thay đổi cấu hình.Dưới góc nhìn của người dùng thì chỉ có màn hình đăng nhập là mới— một cái kết lý tưởng cho một cuộc di chuyển.
Nếu "công ty tôi cũng có một máy chủ như vậy".
Lý do cuộc di chuyển lần này kết thúc trong thời gian ngắn có thể gói gọn trong 3 điểm.
- Không cài tính năng mở rộng nào— nên có thể nhảy vọt qua 10 năm trong một lần
- Đo lường thực tế trước khi bắt tay— cơ sở phán đoán đã đủ đầy bằng con số
- Giữ trạng thái có thể lùi lại— nhờ vậy không phải đánh cược vào ngày chuyển đổi
Nói ngược lại,cả 3 điều này đều có thể kiểm chứng trước khi bắt tay."Một hệ thống không thể dừng đang chạy trên máy chủ đã hết hỗ trợ" — nếu bạn thấy quen thuộc, hãy trao đổi với chúng tôi, bắt đầu từ việc nắm bắt hiện trạng bằng con số. Có di chuyển được hay không, thường cứ khảo sát là biết.
Chúng tôi hỗ trợ di chuyển và đổi mới các hệ thống nghiệp vụ vẫn đang chạy trên OS đã hết hỗ trợ hoặc framework cũ.
Việc khảo sát hiện trạng (phiên bản, dung lượng dữ liệu, có hay không tính năng mở rộng, phạm vi công khai) là miễn phí. Cùng với việc đổi mới hệ thống cũ (AI Re: Platform / viết tắt: AIR Platform),Hãy liên hệ với chúng tôi ngay hôm nay.
Biểu mẫu liên hệ(vui lòng ghi kèm "Mong muốn trao đổi về di chuyển hệ thống cũ") / info@flagship-ai.jp
Loạt bài "Legacy to AI — Ghi chép thực tế"
- Tổng hợp: 22 hệ thống và 246 nghìn dòng code trên một chiếc PC — ghi chép đo lường thực tế về 3,5 tháng phát triển với AI
- Ghi chép thực tế ①: Đổi mới toàn diện một hệ thống Java 20 năm tuổi trong khoảng 1 tuần
- Ghi chép thực tế ②: Tạo lối vào mới cho hệ thống lõi mà không thay đổi 0 dòng mã hiện có
- Ghi chép thực tế ③: Hoàn tất việc khảo sát kiến trúc vốn mất cả tháng bằng prototype 2 ngày + đo lường thực tế
- Ghi chép thực tế ④: Chiếc PC đào coin cũ trở thành "ChatGPT riêng cho nội bộ" trong 2 ngày
- Ghi chép thực tế ⑤: Giải cứu một hệ thống 10 năm tuổi khỏi máy chủ đã hết hỗ trợ trong 2 ngày (bài viết này)
* Các con số trong bài viết này là giá trị đo lường thực tế tại thời điểm tháng 8 năm 2026. Thời gian và nội dung công việc cần cho việc di chuyển sẽ khác nhau tùy theo cấu hình hệ thống và việc có hay không tính năng mở rộng.