DevOps và vận hành cloud server cho doanh nghiệp

Phần mềm ALODEV AIO, website alodev.vn và các hệ thống của công ty chạy trên cụm máy chủ riêng ALODEV tự vận hành, không thuê dịch vụ quản trị bên ngoài. Mô tả dưới đây giữ ở mức nguyên tắc, không nêu địa chỉ hay cấu hình nhạy cảm.

• Cụm ảo hoá Proxmox gồm ba máy chủ vật lý (đo ngày 25/09/2026), mỗi hệ thống chạy trong một container riêng.
• Phân tầng lưu trữ: ổ NVMe chỉ giữ dữ liệu nóng (hệ điều hành, cơ sở dữ liệu đang chạy, mã và bản dựng); sao lưu, bản xuất và dữ liệu cũ nằm trên ổ HDD. Tổng dung lượng cấp phát không được vượt dung lượng thật của ổ.
• Website và API của các hệ thống chính ra Internet qua Cloudflare Tunnel: máy chủ ứng dụng không cần mở cổng vào trực tiếp, lưu lượng đi qua mạng phân phối nội dung có bộ nhớ đệm.
• Tiến trình ứng dụng chạy dưới PM2, dịch vụ hệ thống dưới systemd, tự khởi động lại khi dừng bất thường.
• Cơ sở dữ liệu PostgreSQL chạy trong Docker với ảnh được ghim theo mã băm cố định, không theo nhãn "mới nhất".
• Có quy trình khởi động lại cả cụm sau mất điện, viết ra từng bước và đã dùng thật.

Ghi ảnh mã băm cố định cho cơ sở dữ liệu là một bài học: một lần nhãn "mới nhất" của ảnh Docker trỏ sang bản khác, cơ sở dữ liệu khởi động lên với danh mục hệ thống không khớp. Từ đó mọi ảnh chạy production đều ghim theo mã băm, nâng cấp là một thay đổi có chủ đích và có kế hoạch lùi.

Theo sách Site Reliability Engineering của Google, khoảng 70% sự cố xảy ra do thay đổi trên hệ thống đang chạy. Kinh nghiệm của ALODEV khớp với con số đó. Từ cuối tháng 8/2026 tới đầu tháng 9/2026, một website của ALODEV mất toàn bộ JavaScript suốt sáu ngày vì kịch bản triển khai cũ xoá thư mục bản dựng ngay dưới tiến trình đang phục vụ. Trang vẫn trả mã 200 nên không máy theo dõi nào báo, nhưng biểu mẫu không gửi được.

Quy trình hiện tại cho mọi bản phát hành:

1. Dựng bản mới ở thư mục riêng, với mức ưu tiên CPU và ổ đĩa thấp để không làm chậm hệ thống đang phục vụ.
2. Chạy bản mới ở một cổng phụ và kiểm tự động nhiều hơn mã trạng thái: trang có nội dung, tệp CSS và JavaScript tải được, các đường dẫn chính đúng.
3. Chỉ khi đạt mới chuyển lưu lượng sang bản mới; bản cũ được giữ nguyên để lùi lại bằng một lệnh.
4. Xoá bộ nhớ đệm CDN theo danh sách đường dẫn, rồi kiểm lại trên tên miền thật.

Việc hạ mức ưu tiên khi dựng cũng đến từ một sự cố: một lần dựng chạy ở mức ưu tiên thường đẩy tải máy chủ lên 56, đường hầm mạng rớt và trang quản trị báo lỗi 502. Chạy ở mức ưu tiên thấp, tải ở mức 21 và dịch vụ không gián đoạn.

Mọi thay đổi ghi dữ liệu được thử trên cơ sở dữ liệu chạy thử (staging) trước. Luật của ALODEV với production là chỉ đọc: không thử nghiệm, không sửa tay dữ liệu thật. Ở cấp kho mã, một hook trước khi commit chặn những lỗi đã từng lọt và chặn hai phiên làm việc sửa cùng một tệp.

Một điều nên nói rõ: ở hệ thống của ALODEV, cơ sở dữ liệu staging và production hiện là hai cơ sở dữ liệu riêng nhưng chạy chung một máy chủ PostgreSQL. Cách này tiết kiệm tài nguyên nhưng có giá: sự cố đầy ổ đĩa ngày 11/09/2026 làm dừng cả hai cùng lúc. Với khách có yêu cầu cao hơn, ALODEV tách hẳn hai máy chủ cơ sở dữ liệu và ghi rõ trong đề xuất.

Sao lưu mà chưa từng khôi phục thử thì chưa biết có dùng được không. ALODEV học điều này bằng một sự cố thật. Tệp sao lưu mỗi đêm tăng từ 4 GB lên 49 GB trong sáu ngày vì tác vụ sao lưu nén cả thư mục dữ liệu của một dịch vụ phụ đang lớn dần; luật giữ 14 bản tính theo số tệp nên không có gì chặn tổng dung lượng. Ngày 11/09/2026 ổ đĩa đầy, cơ sở dữ liệu dừng, và bản sao lưu đêm đó là tệp rỗng.

Sau sự cố, sao lưu được làm lại thành ba lớp:

1. Bản xuất cơ sở dữ liệu mỗi đêm ngay trong máy chủ ứng dụng.
2. Mỗi đêm trên máy chủ vật lý: xuất từng cơ sở dữ liệu rồi kiểm tệp xuất đọc được, chụp nén toàn bộ container, chép sang ổ HDD của một máy vật lý khác. Giữ 7 bản ngày và 4 bản tuần; bản xuất cơ sở dữ liệu giữ 30 ngày.
3. Lịch sao lưu định kỳ của Proxmox cho các container khác.

Tác vụ chụp nén tự dừng nếu ổ NVMe đã dùng từ 80% trở lên, để sao lưu không bao giờ tự làm đầy ổ lần nữa. Ngày 25/09/2026, ALODEV diễn tập khôi phục toàn bộ container từ bản sao lưu: 6 phút để khôi phục, cơ sở dữ liệu đọc được đủ 168 bảng. Kết quả diễn tập được ghi lại cùng thời gian, để lần sự cố thật biết trước sẽ mất bao lâu.

Một sự cố ngày 02/07/2026 định hình cách ALODEV theo dõi hệ thống: sau khi máy chủ khởi động lại, các container không tự lên dù đã đặt chế độ tự khởi động; máy chủ API khởi động lỗi liên tục suốt bảy ngày trong khi trang quản trị vẫn trả mã 200. Kiểm "trang có lên không" là không đủ.

• Kiểm sức khoẻ mỗi 5 phút: cơ sở dữ liệu, bộ nhớ đệm, kho tệp; tự khởi động lại thành phần hỏng khi có thể.
• Máy chủ API có đường kiểm sức khoẻ báo cả trạng thái kết nối cơ sở dữ liệu, không chỉ báo "còn sống".
• Cảnh báo gửi vào nhóm quản trị chỉ khi trạng thái đổi (từ tốt sang hỏng và ngược lại), để cảnh báo không thành tiếng ồn bị bỏ qua.
• Biểu mẫu khách để lại trên website hỏng thì báo ngay lần đầu, sau đó nhắc lại định kỳ cho tới khi sửa; thông tin khách vào hàng đợi và tự gửi lại, không mất.
• Công cụ gửi cảnh báo tự kiểm tra việc gửi thành công, không báo "đã gửi" khi thực tế gửi hỏng.

Độ trễ cũng được đo, không đoán. Máy chủ API của ALODEV AIO trả lời trong khoảng 0,8 mili giây ở trung vị; phần lớn độ trễ người dùng cảm thấy đến từ đường mạng qua đường hầm nhân với số lần gọi API trên mỗi màn hình. Biết điều đó thì việc tối ưu đúng chỗ là gộp lượt gọi, không phải mua máy chủ mạnh hơn.

Doanh nghiệp chưa có máy chủ có thể thuê máy chủ ứng dụng, cơ sở dữ liệu hoặc GPU của ALODEV kèm vận hành, xem cấu hình ở trang hạ tầng. Doanh nghiệp đã có hạ tầng ở nhà cung cấp khác thì ALODEV vận hành ngay trên đó, tài khoản quản trị vẫn thuộc doanh nghiệp.

ALODEV tự vận hành máy chủ riêng vì khối lượng hệ thống đủ lớn và có người vận hành. Với phần lớn doanh nghiệp vừa và nhỏ, thuê VPS hoặc cloud là bước đầu hợp lý hơn. Dù chọn cách nào, theo mô hình trách nhiệm chia sẻ mà các nhà cung cấp cloud lớn công bố, nhà cung cấp chỉ lo phần cứng và nền tảng; dữ liệu, ứng dụng, phân quyền, cấu hình mạng vẫn là việc của doanh nghiệp.