Hỏi – Đáp: Nâng cấp hạ tầng hệ thống QLTN
Docker → Kubernetes trên cloud CMC

Docker là cách đóng gói từng phần mềm vào một "thùng" riêng để chạy. K8s là người quản đốc tự động trông coi cả kho thùng đó: thùng nào hỏng nó tự thay thùng mới, đông khách thì tự mở thêm quầy, vắng thì thu bớt lại để khỏi tốn.

Hiện tại mình có thùng (Docker) nhưng người canh là con người, thủ công — đêm hôm sập thì phải có người thức dậy sửa tay.

1. Tự phục hồi: hiện tại một service chết là nằm đó tới khi có người phát hiện. Hệ mới tự khởi động lại trong vài giây — ít cuộc gọi lúc 2 giờ sáng, ít downtime khách thấy.
2. Hết phụ thuộc một người: hệ mới vận hành theo chuẩn ngành, ai biết K8s đều làm được; cấu hình nằm trong Git có sổ sách. Docker hiện tại nằm trong đầu và tay người đang quản — người đó nghỉ là rủi ro lớn.
3. Bán được & mở rộng được: chuẩn K8s cho phép khách tự host trên server của họ (điểm bán hàng cho khách lớn / khắt khe bảo mật) và mở rộng theo số khách mà không phải đập đi xây lại.

Nhu cầu kinh doanh. Cái lõi không phải "dùng K8s", mà là ba thứ kinh doanh cần:

• Không được mất dữ liệu cư dân — dữ liệu cá nhân, mất / lộ là hậu quả nghiêm trọng về uy tín và trách nhiệm;
• Không được để khách sập mà khôi phục chậm — rủi ro mất khách + uy tín;
• Bán / mở rộng được.

K8s + cloud quản lý chỉ là công cụ rẻ và chuẩn nhất để đạt ba thứ đó. Nếu có cách khác rẻ hơn đạt được thì mình đã chọn.

Ở tầng hạ tầng thô thì K8s không rẻ hơn, thậm chí nhỉnh hơn một chút — vì có thêm phần quản trị. Nhưng tổng chi phí thật (gồm cả công người vận hành + tổn thất khi sự cố) thì rẻ hơn, vì:

• Không phải trả lương người trực tay canh sập / khởi động lại — hệ tự làm.
• Tự co giãn: đông mới bung thêm máy, vắng thì thu — không phải trả tiền cho công suất đỉnh suốt 24/7.
• Một sự cố mất dữ liệu / sập kéo dài đắt hơn nhiều lần khoản chênh hạ tầng mỗi tháng.

Chi phí gồm hai phần: phần nền cố định (trả như nhau ở mọi quy mô) và phần tăng dần theo số dự án / cư dân dùng app. Mọi con số dưới đây đã gồm VAT, tính theo đơn giá CMC Cloud.

1) Phần nền cố định: ~11,2 triệu/tháng

2) Phần tăng theo quy mô — gồm máy chạy ứng dụng (worker 8 vCPU / 16 GB), lưu trữ tăng thêm (CMC + Cloudflare R2) và email (5.000đ/tháng/tòa nhà). Tổng chi phí mỗi tháng theo từng mốc:

Lưu trữ file dùng kết hợp CMC + Cloudflare R2 (R2 không mất phí tải dữ liệu ra — khoản các nhà khác tính rất đắt); phần này đã nằm trong các con số trên. Các mốc quy mô trung gian (40, 60, 80, 90 dự án) có trong bảng tính chi tiết.

Phần lớn là chi phí thuê hạ tầng hàng tháng (như tiền thuê văn phòng) — co giãn theo số khách. Phần một lần là công dựng + di chuyển trong 4 tháng. Sau đó hàng tháng chỉ còn tiền thuê + vận hành nhẹ.

1. Đo thật rồi mới mua: em đã đo — data nghiệp vụ prod chỉ ~3,6 GB (file upload 62 MB), prod ước cần ~25 GiB RAM gồm cả nền K8s, dù máy cũ tới 188 GiB. → không mua thừa, chọn cấu hình vừa (giống thuê kho 25 m² thay vì 188 m²).
2. Dùng cloud quản lý (CMC lo phần lõi) → bỏ được lớp vận hành nặng nhất, đỡ công người.
3. R2 miễn phí egress → tiết kiệm phí tải file (khoản hay bị đắt ngầm).
4. Tự co giãn (autoscale) → trả theo dùng thật, không trả cho đỉnh suốt ngày.
5. Dev / sandbox vẫn ở máy cũ đã trả tiền rồi → không tốn thêm; chỉ phần prod (phục vụ khách) mới đưa lên cloud có lưới an toàn.

Mục tiêu gần như không gián đoạn (~0). Cách làm:

• Hệ cũ vẫn là "bản chính" chạy phục vụ khách cho tới khi hệ mới chứng minh ổn — khách không phải chờ.
• Chuyển từng phần một (như thay từng viên gạch khi người vẫn ở nhà), không "đập đi xây lại".
• Chuyển dần lưu lượng 5% → 50% → 100%, thấy lỗi là quay về cũ tức thì.

• Trước khi di chuyển bất cứ gì, em dựng một bản từ sao lưu và kiểm tra dữ liệu đúng — không chỉ "có file backup" mà "rút ra dùng được thật".
• Sao lưu để ở kho độc lập, tách khỏi hệ chạy — hệ chính cháy thì bản lưu vẫn còn.
• Mốc kiểm chứng: 14/6 — "Sao lưu khôi phục thành công" là cửa ải bắt buộc trước khi làm tiếp.

Có, và dưới 5 phút. Mỗi bước đều có nút lùi: chuyển lưu lượng về hệ cũ, hoặc hoàn tác cấu hình (vì cấu hình nằm trong Git, lật lại trang trước là xong). Hệ cũ không bị xóa cho tới khi hệ mới chạy ổn định nhiều ngày.

Ba điểm kiểm chứng được, không phải lời hứa suông:

1. Giám sát + log đầy đủ ngay từ đầu → đo được tốc độ, lỗi, tài nguyên trước / sau để so.
2. Vận hành thử song song trước khi cắt thật.
3. Một tháng "hypercare" (27/7 – 23/8) chỉ để theo dõi sát và căn chỉnh; tiêu chí thoát: chạy ổn định, không sự cố nghiêm trọng.

Có 3 tầng phòng thủ:

1. Tự động: phần lớn sự cố nhỏ (một service chết) hệ tự khởi động lại, không cần người.
2. Cảnh báo: có giám sát bắn cảnh báo về Telegram ngay khi bất thường — biết trước khi khách kêu.
3. Con người + nhà cung cấp: việc của mình + phần hạ tầng lõi do CMC chịu trách nhiệm (xem D3).

Thời gian xử lý cam kết theo mức độ sự cố (bảng ở D2).

Định nghĩa rõ 3 mức kèm ví dụ — chốt trước để không tranh cãi lúc nóng:

Có hai tầng cam kết, đừng lẫn:

• CMC cam kết với mình: thời gian hoạt động của phần lõi do họ quản (control plane, cân bằng tải, lưu trữ), thay phần cứng hỏng, và thời gian họ phản hồi khi mình báo lỗi.
• Mình cam kết với khách: dựng trên nền CMC + ứng dụng + quy trình trực của mình.

Việc đang làm: lấy bằng văn bản từ CMC — uptime cam kết bao nhiêu? hỗ trợ 24/7 hay giờ hành chính? kênh báo sự cố? thời gian phản hồi P1/P2? phần nào họ lo, phần nào mình lo? → từ đó mới chốt được SLA mình hứa với khách.

Giảm phụ thuộc: ngay cả khi CMC trục trặc dài, vì hệ đóng theo chuẩn K8s + cấu hình trong Git + sao lưu ở kho trung lập, mình dựng lại ở chỗ khác được (xem nhóm E).

Được. Sao lưu cơ sở dữ liệu liên tục (khôi phục về đúng thời điểm) + sao lưu trạng thái hệ thống, để ở kho độc lập.

Quan trọng: đã diễn tập khôi phục thật nên không phải "hy vọng nó chạy". Thời gian khôi phục tính bằng phút – giờ tùy quy mô, sẽ đo chính xác trong buổi diễn tập 14/6.

• Rẻ hơn AWS / Google ~40% ở quy mô này, chủ yếu do không bị phí tải dữ liệu ra đắt đỏ.
• CMC lo phần lõi nặng nhất (quản trị cụm) → đỡ công, đỡ rủi ro vận hành cho mình.
• Nhà cung cấp trong nước: làm việc trực tiếp, hỗ trợ tiếng Việt theo giờ Việt Nam, độ trễ thấp cho người dùng trong nước.
• Tự dựng hoàn toàn thì tốn người vận hành phần lõi — không đáng ở giai đoạn này.

• Cố tình thiết kế để KHÔNG bị khóa: hệ chạy trên K8s chuẩn quốc tế (không dùng thứ độc quyền của CMC ở tầng ứng dụng), cấu hình lưu trong Git, sao lưu ở kho trung lập.
• Hệ quả: khách / mình có thể tự vận hành trên server riêng hoặc chuyển sang nhà cung cấp khác — như hàng đóng container chuẩn, bốc từ tàu hãng này sang hãng khác được.
• Không chỉ nói — sẽ diễn tập thật việc chuyển đổi này ở giai đoạn cuối (24/8 – 30/9).
• Phần phụ thuộc CMC chỉ ở mức nhẹ (cách cắm cân bằng tải, lưu trữ) — đổi lại được phần đỡ vận hành; và phần này có phương án thay thế đã ghi rõ.

• Không nằm trong đầu một người: mọi cấu hình, mọi bước, mọi cách dựng đều viết thành mã + tài liệu trong Git. Người mới biết K8s đọc vào làm tiếp được.
• Có sổ tay vận hành (runbook) và báo cáo bàn giao ở cuối dự án (mốc 30/9).
• Dùng chuẩn ngành → tuyển / thuê người vận hành dễ, không kén "người độc nhất".
• Đây chính là một lý do lớn để rời Docker thủ công — Docker hiện tại mới là cái phụ thuộc tay người.

1. Giảm rủi ro sống còn: bỏ canh bạc "cả hệ thống khách trên một máy không lưới an toàn" + tránh hậu quả nghiêm trọng khi mất dữ liệu cư dân.
2. Giảm chi phí ẩn: ít sự cố, ít trực tay, ít downtime → đỡ tiền và đỡ mất uy tín.
3. Mở khóa doanh thu: nền tảng bán được bản tự-host cho khách lớn, mở rộng theo số khách mà không đập đi xây lại.
4. Tăng giá trị công ty: hệ thống chuẩn hóa, có tài liệu, không khóa nhà cung cấp → tài sản gọn gàng, dễ thẩm định khi gọi vốn / M&A.

Thuê CMC giống thuê tòa nhà có điện nước và ban quản lý giữ thang máy chạy. Họ dựng hạ tầng và giữ nó sống 24/7 — nhưng không chuyển nhà giúp mình, không bài trí, không có bảo vệ canh đêm, không mở chi nhánh mới. Mấy phần đó là việc của em:

1. Di chuyển hệ thống (migrate, đồng bộ dữ liệu, cutover an toàn) — CMC không làm.
2. Giám sát + cứu sự cố ứng dụng — CMC nói thẳng "chỉ dựng, không check sự cố"; SLA của họ dừng ở "hạ tầng sống", không phải "app của mình chạy".
3. Đặt đúng cỡ để cắt chi phí — báo giá CMC đang thừa rất nhiều: riêng dòng ổ đĩa họ báo 8.100 GB ≈ 16,4 triệu/tháng, trong khi em đo thật data nghiệp vụ prod < 5 GB (Mongo ~3,6 GB + file upload 62 MB). Đặt đúng cỡ cắt ~một nửa hóa đơn — đó là tiền em mang về mỗi tháng, đều đặn.
4. Không khóa nhà cung cấp + bàn giao tài liệu — CMC sẽ không tự xây cho mình đường thoát khỏi CMC.
5. Mở rộng kinh doanh: CMC chỉ hỗ trợ 3 khách mới/năm; muốn bán cho nhiều tòa nhà / khách thì phải có người trong nhà dựng môi trường mới nhanh, lặp lại được.

• Tiến độ: ứng dụng lên môi trường mới 28/6, với điều kiện hợp đồng CMC xong trước 14/6. Tổng dự án 4 tháng (1/6 – 30/9).
• An toàn dữ liệu: không đụng dữ liệu trước khi sao lưu đã diễn tập khôi phục thành công (mốc 14/6).
• Không gián đoạn: hệ cũ chạy tới khi hệ mới ổn; mọi bước lùi được < 5 phút.
• Minh bạch: có mốc kiểm chứng ở 14/6, 28/6, 26/7, 23/8, 30/9 — mỗi mốc báo cáo được, không phải "tin em đi".
• Bàn giao: cuối kỳ có tài liệu vận hành + báo cáo tổng kết + lộ trình tiếp theo.

Mốc 28/6 phụ thuộc một điều kiện ngoài tầm em — hợp đồng CMC. Em đã ghi rõ điều kiện đó. Nếu CMC trễ, rủi ro lớn nhất chỉ là dời mốc, không phải mất an toàn — vì hệ cũ vẫn chạy bình thường suốt thời gian đó. Em không hy sinh an toàn để chạy theo ngày.

Làm được — và đây là điểm bán hàng, không phải gánh nặng. Vì hệ đóng theo chuẩn K8s + cấu hình trong Git, mình giao trọn gói chạy trên hạ tầng của khách (khách lớn / cơ quan / khách khắt khe về bảo mật rất chuộng điều này). Cơ chế chuyển sang môi trường độc lập đã nằm trong kế hoạch và sẽ diễn tập thật ở giai đoạn cuối.

Đúng. Cùng một sản phẩm, hai cách bán:

• (a) Mình host trọn gói — thu phí thuê bao.
• (b) Bán bản tự-host cho khách muốn giữ dữ liệu trong nhà.

Cái (b) trước đây Docker-thủ-công khó làm; chuẩn K8s khiến nó đóng gói & bàn giao được. Đồng thời nó xóa một lý do từ chối mua của khách lo lock-in / bảo mật.