Hosting lấy AI làm gốc
- Deploy bằng câu lệnh thường
- Chẩn đoán vận hành
- Truy nguyên sự cố
- Quét an toàn
- Tối ưu chi phí
Roadmap từ PO · đối chiếu mã nguồn, vận hành, cổng chuyển đổi
Vibe Host V1 và V2 là một đường tiến hoá, không phải một cuộc thay thế
Bản đồ tương quan giữa giá trị V1 đã tạo, giới hạn khi mục tiêu chuyển sang multi-node, những mảnh V2 đã có trong mã nguồn và bằng chứng, và các năng lực còn phải triển khai hoặc nghiệm thu.
Ảnh chụp 07/08/2026 · “Đã có mã nguồn” không đồng nghĩa “đã sẵn sàng phục vụ khách thật / sẵn sàng cao”.
Năm chỉ số mức sẵn sàng — khác mẫu số, khác cổng
Không chỉ số nào thay thế được chỉ số nào. Đọc từ trái sang phải là đọc từ “đã làm xong việc” sang “dám chuyển sang phục vụ khách thật”.
Khối lượng đã làm87%
178/204 việc đã đóng — đo khối lượng, không đo mức sẵn sàng
Mức phủ tính năng so với V186%
Phủ luồng chức năng so với V1
Chạy thử nhóm không dữ liệu riêng56%
Mới đủ cho pilot giới hạn
Chuyển hẳn sang V245%
Chấm lại 08/08 (42% → 45%) — chỉ một ô đổi, xem bảng dưới
Kiểm trước khi chuyển43%
Kiểm kê · đường quay lại · chạy thử — giữ 43%, ba việc này chưa động
| Thành phần của “Chuyển hẳn sang V2” | Trọng số | Điểm 07/08 | Điểm 08/08 | Vì sao đổi hoặc vì sao giữ |
|---|---|---|---|---|
| Sao lưu · khôi phục · quay lại bản cũ | 15% | 20 | 40 | Ô DUY NHẤT ĐỔI. Hai trong năm tiêu chí nay có số đo: sao lưu đặt ngoài máy chạy dịch vụ, và khôi phục đã diễn tập đo được. Ba tiêu chí còn chưa có số: ba loại cơ sở dữ liệu còn lại, diễn tập trên hệ phục vụ khách thật, và hai con số thời gian khôi phục / mức dữ liệu chấp nhận mất. |
| Mức phủ tính năng cốt lõi | 15% | 86 | 86 | Giữ. Việc làm được trong đợt này là yêu cầu mới của PO, không phải phủ thêm tính năng V1. |
| Kiểm trước khi chuyển | 20% | 43 | 43 | Giữ. Khôi phục chỉ là một trong bốn phần; kiểm kê, chạy thử khô và đường quay lại chưa động tới. |
| Hạ tầng · vận hành | 15% | 55 | 55 | Giữ. |
| Bằng chứng phát hành | 15% | 50 | 50 | Giữ. |
| Ổ đĩa mang đi được + hàng rào ghi | 15% | 10 | 10 | Giữ — đây mới là cổng thật của việc chuyển ứng dụng có dữ liệu sang máy khác, và nó chưa nhúc nhích. |
| Chạy thử · chạy dài · ký Go/No-Go | 5% | 0 | 0 | Giữ. |
| Tổng | 100% | 41,75 ≈ 42% | 44,75 ≈ 45% | Chỉ số nhích 3 điểm vì đúng một ô có bằng chứng mới. |
Đọc con số 40 cho đúng. Nó là 2/5 tiêu chí đã có số đo, không phải một cảm nhận. Ai thấy tỉ trọng năm tiêu chí nên khác thì sửa ở đây rồi tính lại — công thức và đầu vào đều để lộ ra chính vì vậy. Nguyên tắc giữ nguyên từ bản gốc: không nâng điểm chỉ vì đổi quy trình, chỉ nâng khi có số đo mới.
Đầu mục cần xử lý — đọc từ AI Factory ngày 08/08/2026
Không phải suy từ chỉ số, mà là 26 việc đang mở lấy thẳng từ bảng kế hoạch. Ngày đích của dự án là 14/08 — còn 6 ngày.
0%Cột mốc “Đóng vướng mắc CTO trước chạy thử” — 8 việc, chưa việc nào bắt đầu, hạn 14/08
9Việc đã quá hạn, trễ từ 1 đến 4 ngày
1Việc quá hạn 4 ngày mà chưa giao cho ai — #3406, quên mật khẩu & đăng nhập Google
0Việc đang ở trạng thái “đang làm”. 26 việc đều nằm ở “chưa bắt đầu”
| Chỉ số | Thành phần đang kéo nó xuống | Việc phải làm để nó nhích |
|---|---|---|
| Khối lượng đã làm 87% | 26 việc còn mở, 9 quá hạn | Giao ngay #3406 (quá hạn 4 ngày, chưa có người). Bảy việc quá hạn còn lại đều đã có người — cần một lượt chốt lại hạn thay vì để trôi tiếp. |
| Mức phủ tính năng 86% | Điểm đóng băng ở một bản mã cũ | Con số này cố ý không đổi cho tới khi có bản phát hành mới được chấm lại — #3442 (gắn thẻ bản phát hành cuối + ghi dấu vân tay ảnh). Trước đó mọi việc làm thêm không làm nó nhích, và đó là chủ ý. |
| Chạy thử nhóm không có dữ liệu riêng 56% | Phần yếu nhất: hợp đồng nhóm khách · sổ tay sự cố · đường quay lại — mới 15% | Đây chính là cột mốc đang 0%: truy nguyên 9/19 cụm kém (#3434), cổng kiểm tự động xanh trên mã sạch (#3435), nghiệm định tuyến live (#3436), hợp đồng nhóm khách (#3437), sổ tay sự cố (#3441), mở phục vụ công khai (#3439). |
| Kiểm trước khi chuyển 43% | Cột mốc kiểm trước khi chuyển mới 50% | Bốn việc: chốt kiểm kê W0 (#3238, quá hạn 3 ngày), nhập thử khách/gói (#3240), dựng bộ mẫu chuyển việc thật (#3241), diễn tập quay lại và thảm hoạ (#3242). |
| Chuyển hẳn sang V2 45% | Hai ô gần như bằng không: ổ đĩa mang đi được + hàng rào ghi (10) và chạy thử · chạy dài · ký Go/No-Go (0) | Cả hai cố ý nằm ngoài phạm vi trước lượt chạy thử — theo chính mô tả cột mốc. Nghĩa là chỉ số này sẽ không nhích đáng kể trước 14/08, và đó là điều nên nói trước thay vì để lộ ra ở buổi Go/No-Go. |
Một điều lệch nhau cần người quyết. Cột mốc “Đóng vướng mắc CTO trước chạy thử” tự khai 29,25 giờ công AI cho 8 việc, hạn 14/08. Nhưng nó đang ở 0%, và cột mốc “Sẵn sàng cho khách” thì đã quá hạn từ 06/08 mà vẫn dừng ở 94%. Hai lượt Go/No-Go (#3237 ngày 06/08 và #3443 ngày 14/08) đều chưa chạy. Ba việc này xếp chồng lên nhau trong 6 ngày — hoặc dời ngày đích, hoặc cắt phạm vi, chứ không có cách thứ ba.
“Cổng kiểm tự động xanh trên mã sạch” là điều kiện số 1 của CTO — và nó chưa từng đúng, theo nghĩa đen. Bộ bảy cổng chất lượng đã có (kiểu, quy tắc mã, dựng, hai bộ kiểm, biên dịch và kiểm Go). Nhưng cho tới 08/08 không có gì gọi nó: cấu hình chạy tự động chỉ có đúng một việc là đẩy bản mới lên máy chủ. Nên câu “cổng đang đỏ” cũng sai — chính xác là chưa có lượt chạy nào để mà xanh hay đỏ. Đo thật ngày 08/08 khi chạy tay bộ kiểm nghiệp vụ: 120 đạt · 7 hỏng · 8 đỏ-có-lý-do · 5 không kết luận được. Bảy cái hỏng là việc phải xử, không phải nền để tuyên bố xanh.
Ba câu hỏi đang chặn, và chúng không chờ ai viết mã. (1) “Phục vụ công khai” là theo từng website hay theo từng máy chủ? Hôm nay chỉ mở được theo máy, bằng tay — không có cách để một khách công khai còn khách bên cạnh vẫn nội bộ. (2) Ngưỡng nào thì gọi người trực khi triển khai hỏng? Hệ cố ý không báo từng lượt, vì hỏng lẻ là chuyện thường ngày; cần một ngưỡng, không phải một công tắc. (3) Người trực hỗ trợ có vai riêng không? Hiện họ được cấp quyền quản trị đầy đủ để làm một việc chỉ cần đọc. Mỗi câu đã có 2–3 phương án kèm hệ quả và phương án mặc định nếu quá hạn 11/08 — xem docs/plan/QUYET-DINH-CAN-CHOT-08-08-2026.md.
Điểm chặn chưa ai nêu thành mục riêng: ba việc Go/No-Go đang thiếu dữ liệu V1. Nhập thử khách và gói · dựng bộ mẫu chuyển việc · diễn tập quay lại — cả ba là điều kiện của cột mốc kiểm-trước-khi-chuyển, và cả ba cần một đường đọc dữ liệu V1 mà hôm nay chưa có. Mã cho ba việc này đã tồn tại nhưng bị loại khỏi bộ kiểm tự động vì thiếu đúng nguồn dữ liệu đó. Nếu tới 11/08 chưa được cấp quyền đọc, thì phải chọn: dời hạn, hoặc thu hẹp lượt chạy thử xuống chỉ dịch vụ không có dữ liệu riêng. Để nó tự trôi tới 14/08 rồi mới phát hiện là cách tệ nhất.
1Mindmap điều hành
V1 không bị mô tả là “sai”; V2 là nền tiếp nối cho mục tiêu mới. Cầu nối là đồng tồn tại, kiểm kê, chạy thử và đường quay lại bản cũ — và một lượt chuyển đổi đã chạy thật ngày 03/08. Hai điều kiện quyết định còn lại là tính năng và hạ tầng.
Trục chính
Vibe Host · tiến hoá có kiểm soát
Giữ dòng chảy phục vụ khách → nền nhiều máy chủ → AI operations → quyền sở hữu mã nguồn.
Bằng chứng đang phục vụ khách thật
Đang phục vụ việc thật của khách; có dựng/triển khai, tên miền/chứng chỉ bảo mật, hạn mức, cơ sở dữ liệu và sao lưu.
Kiểm soát theo khách
CPU/trần RAM, hạn mức theo gói, kiểm soát theo dây chuyền và theo người dùng, xác thực, chặn gọi dồn và nhật ký kiểm toán.
Một máy hỏng là hỏng tất cả
Bộ chạy việc, Docker, khâu dựng, phần chạy của khách, định tuyến và ổ đĩa tại chỗ dính chặt vào nhau.
Hàng đợi & khoá nằm trong tiến trình
Redis pop → memory channel; project lock không phân tán.
Artifact & state cục bộ
Image/cache/volume/DB khó mang sang máy chủ khác một cách xác định.
Vai trò giai đoạn chuyển tiếp
Vận hành thường ngày, lỗi nghiêm trọng, bảo mật, mất dữ liệu và hỗ trợ kiểm kê, chuyển đổi và quay lại bản cũ.
Dừng thêm tính năng mới cho V1
Giảm đầu tư kép và lỗi hồi quy; không tắt V1 ngay.
Kiểm kê & ánh xạ
User/Project/Deployment/container/image/volume/domain/DB.
Storage di chuyển được
Ổ đĩa ứng dụng mang đi được giữa các máy chủ + hàng rào chỉ-một-nơi-được-ghi. Sao lưu là việc vận hành song song, không phải cổng chuyển đổi.
Shadow deploy
Build V2 chưa nhận traffic; kiểm technical + business + data.
Chuyển đổi theo từng đợt
Loại không có dữ liệu riêng đi trước, đổi định tuyến gọn một nhịp, chạy thử kéo dài ≥ 72 giờ.
Luôn sẵn đường quay lại bản cũ
Giữ V1 và dữ liệu trong khoảng thời gian còn quay lại được; stop-the-line khi mismatch.
Mặt điều khiển theo nghiệp vụ
dự án, bản triển khai, việc, lượt thử, mã máy chủ, nhật ký kiểm toán và nguồn gốc bản dựng.
Bộ thực thi Wings
Build → run → health → đưa lên chính thức hoặc quay lại bản cũ; máy chủ báo nhịp sống, giữ quyền và chạy lại vẫn ra một kết quả.
AI Fix & Env
Analyze, gợi ý biến môi trường, vòng sửa có trần, ảnh chụp, hoàn tác và xuất bản vá.
Target multi-node
Edge LB → Traefik đúng máy chủ; kho ảnh chuẩn có dấu vân tay; ổ đĩa dùng chung có hàng rào ghi; dư một máy.
AI Solution Builder
Dữ liệu thật → AI normalize → preview → mã nguồn riêng → deploy → Git.
Chưa được phép khẳng định
Chưa sẵn sàng phục vụ khách thật, chưa sẵn sàng cao, chưa chuyển hẳn — trước khi có phép chạy thử trên hệ thật và phép thử gây lỗi có chủ ý và diễn tập chuyển đổi.
Bấm vào một nhánh để soi riêng nhánh đó; bấm lại để bỏ lọc.
V1 đã chứng minh
V2 có trong mã nguồn/evidence
Roadmap / target — chưa build
Còn cổng nghiệm thu
Giới hạn / rủi ro
16 coreHost V1
39 GBRAM V1
409/873 GBDisk đã dùng — không phải IOPS
151User record — 138 khách + 13 nội bộ
138Mẫu số khách hàng đúng để dùng
250Project record — 206 active + 44 suspended
251Container đang chạy — không phải sức chứa tối đa
Hiệu chỉnh 05/08/2026 (đo trực tiếp trên V1 đang phục vụ khách, quyền chỉ-đọc): bộ số cũ 210 user / 326 project / 375 GB lệch 23–28%. Dùng 138 làm mẫu số khách hàng, không dùng 151 và tuyệt đối không dùng 210.
Đã chuyển đổi thật — máy chủ hoadon, 03/08/2026
Đây không phải diễn tập và không phải fixture. Khách thật, tên miền thật, đo bằng md5. Nguồn: vays-wt-docs/docs/plan/dong-bo-v1-v2/13-NHAT-KY-MIGRATE-HOADON.md.
20/20Khách đã sang V2 — 18 khách + 1 admin + 1 superadmin
10/10Website chạy dưới wings V2, giữ nguyên tên miền cũ
0 giâyGián đoạn của khách — V2 xanh rồi mới hạ V1
8/8Dự án gõ được có md5 nội dung V1 ↔ V2 khớp tuyệt đối
0 / 0 / 0Cert xin lại · bản ghi DNS đổi · byte qua mạng
10/10Site trả 2xx/3xx qua HTTPS công khai sau khi hạ V1
Điều kiện phải nói kèm, nếu không là suy rộng sai: đợt này rẻ bất thường vì máy chủ V2 đặt trên chính máy V1 — không chở ~100 GB ảnh, không đổi DNS, không xin lại cert. Nó chứng minh nghiệp vụ chuyển đổi, đối soát nội dung, blue-green và đường lui chạy được trên khách thật. Nó không chứng minh đường sang máy khác — đó vẫn là khoảng trống, và là kịch bản của phần lớn 250 dự án.
Sự cố V1 — 07/08/2026: ba lần tê liệt trong một ngày
Đo trực tiếp trên hệ phục vụ khách thật V1 103.138.88.40 bằng quyền chỉ-đọc, ngay trong lúc sự cố đang diễn ra. Nguồn: dmesg -T, docker inspect, log Traefik trong container. Đây là bằng chứng đo được cho nhánh “Một máy hỏng là hỏng tất cả” ở mindmap — trước nay là nhận định thiết kế, giờ có sự cố kèm số.
6Lần Traefik khởi động lại trong 2,5 giờ — 14:23 → 16:55
2Lần Traefik bị global OOM killer bắn — 7,0 GB và 10,4 GB RSS
338.99Load average 15 phút, trên máy 16 core
19.210Lần restart của một container khách duy nhất — trần 64 MB
934.8%CPU cadvisor chiếm thường trực — 9,3/16 core, không giới hạn
0 BSwap, trên máy 39 GB RAM
~2 giờKhông SSH vào được máy — 16:50 → 18:54
| Thời điểm | Bằng chứng đo được | Hệ quả |
|---|---|---|
| 14:23 · 14:49 15:18 · 15:37 | Traefik khởi động lại 4 lần liên tiếp | Cụm treo thứ nhất. Ring buffer dmesg chỉ còn giữ từ 15:49 nên không còn chứng cứ kernel cho cụm này — ghi nhận theo log Traefik, không suy đoán nguyên nhân. |
| 14:49 và 15:18 | Cannot start the provider *file.Provider: error creating file watcher: too many open files | Mất toàn bộ middleware @file và TLS store. Ba site trả 404; cert rơi về TRAEFIK DEFAULT CERT thay cho wildcard đã mua. File dynamic.yml vẫn nguyên vẹn — sửa file hay remount đều vô ích. |
| 15:37 | Traefik khởi động lại, lần này giành được suất theo dõi tệp | 404 tự khỏi, không ai can thiệp. Đây là lý do lỗi khó truy: nó phụ thuộc một cuộc đua tài nguyên lúc khởi động, chỉ hỏng ở 2/6 lần. |
| 16:27:29 | Out of memory: Killed process 270265 (traefik) — anon-rss 7,0 GB, constraint=CONSTRAINT_NONE, global_oom | Cụm treo thứ hai. Kernel hết RAM toàn cục và chọn tiến trình lớn nhất máy, chính là cửa vào. |
| 16:31 → 16:46 | Traefik mới phình từ 0 lên 10,7 GB trong 15 phút — khoảng 700 MB/phút | Trong cùng lúc: RAM 34/39 GB, kcompactd 43,5% CPU, 3005 tiến trình, 0 tiến trình kẹt đọc-ghi. Nghẽn thuần CPU + RAM, không phải đĩa. |
| 16:50:48 | Out of memory: Killed process 953562 (traefik) — anon-rss 10,4 GB | Cụm treo thứ ba. Cùng cơ chế, lần này nặng hơn. |
| 16:50 → 18:54 | SSH chết ở banner exchange; TCP 443 và 22026 vẫn accept nhưng không có phản hồi HTTP | Kernel còn sống, userspace không giành nổi tài nguyên để trả lời. Mất luôn đường vào để cứu máy. |
| 18:54 | Máy tự hồi, load về 5.71; Traefik mới chạy 2 giờ ở 1,25 GB | Không ai khắc phục. Vòng lặp OOM của ứng dụng của khách vẫn đang chạy — 66 lần OOM riêng trong giờ 18h. |
| Lỗ hổng cấu trúc | Mức | Số đo | Vì sao một lỗi nhỏ thành sự cố toàn máy |
|---|---|---|---|
| Cửa vào không có trần bộ nhớ | Chặn | traefik · Memory=0 · RSS đỉnh 10,4 GB | Traefik dùng chung cho toàn bộ 254 container lại là tiến trình duy nhất không có trần. Nó phình → nó thành nạn nhân global OOM → chết → mọi route chết theo → restart → phình lại. Vòng lặp khép kín, không có điểm dừng tự nhiên. |
| Ứng dụng của khách đặt trần sai | Chặn | ts-testnhacviec-app-1 · 19.210 restart · trần 64 MB cho Next.js | OOM đều đặn mỗi ~68 giây suốt cả ngày. Mỗi vòng đẻ một Docker event → Traefik dựng lại cấu hình cho 254 container. Một ứng dụng của khách cấu hình sai đủ sức tạo tải nền cho cả host. |
| Container loop thứ hai chưa ai thấy | Cao | ts-grimoire-backend-1 · 2.753 restart · trần 512 MB | Cùng cơ chế, nhỏ hơn một bậc. Không có bảng xếp hạng restart thì không ai phát hiện — nó chỉ lộ ra khi quét toàn bộ 265 container. |
| cadvisor chạy không trần | Cao | Không CPU/trần bộ nhớ · 934,8% CPU · 88.634 phút CPU tích luỹ · chạy liền 2 tháng | cAdvisor quét toàn bộ cgroup mỗi chu kỳ housekeeping, chi phí bung ra theo số container. Trên host 254 container nó ăn thường trực ~9/16 core, làm mọi sự cố khác nặng thêm một bậc. |
| Máy không có swap | Chặn | 0 B trên 39 GB RAM | Không có van xả. Máy treo cứng thay vì chậm dần, và mất luôn SSH — không vào cứu được, phải ngồi chờ nó tự hồi sau 2 giờ. |
| sysctl inotify để mặc định | Cao | fs.inotify.max_user_instances = 128, dùng chung cho mọi container chạy root | Traefik thua cuộc tranh suất lúc khởi động thì file provider chết im — mất middleware và TLS store, nhưng tiến trình vẫn “Up (healthy)”. Lỗi không cố định nên rất dễ chẩn đoán nhầm sang mất file cấu hình. |
| Giám sát mù đúng chỗ cần thấy | Chặn | docker inspect .State.OOMKilled = false dù kernel đã bắn | Global OOM không set cờ memcg của container. Mọi cảnh báo dựa vào cờ này sẽ báo “bình thường” đúng vào lúc cửa vào bị giết. Phải bắt bằng dmesg/kernel.log, không bắt bằng Docker API. |
Đọc cho đúng, đừng suy rộng sai: sự cố này không phải do V1 thiếu tính năng. Nó xảy ra vì V1 gộp cửa vào, phần chạy của khách và bộ giám sát vào một một vùng hỏng chung, lại không đặt trần tài nguyên — nên một ứng dụng của khách đặt nhầm 64 MB đã kéo sập cửa vào của toàn bộ 254 dự án trên host. Đó là số liệu xác nhận cho nhánh “Một máy hỏng là hỏng tất cả”. Nhưng đọc ngược lại cũng phải sòng phẳng: multi-máy chủ của V2 chỉ thu nhỏ bán kính, nó không tự chữa bảy lỗ hổng ở bảng trên — tất cả đều là vệ sinh vận hành cấp node: trần bộ nhớ cho cửa vào, trần restart cho ứng dụng của khách, swap, sysctl, và cảnh báo không dựa vào cờ OOMKilled. Nếu V2 bê nguyên cách dựng node hiện tại thì mỗi máy chủ V2 sẽ tái diễn đúng sự cố này, chỉ khác là ít khách hơn mỗi lần. Đề nghị đưa bảy mục này vào cổng nghiệm thu node V2, không xếp chúng vào việc vá V1.
Sao lưu & khôi phục V2 — đã diễn tập thật, 07/08/2026
Đo trên hệ thử + node cmc-1, DB thật aiv-nexus-mb-postgresql (pgvector/pgvector:pg16). Đây là bằng chứng đối trọng trực tiếp với con số V1 ở nhánh sao lưu: V1 có 1.162 bản ghi sao lưu (đo lại 10/08), 100% ghi “Hoàn tất”, chưa từng có bản “Thất bại”, trong đó 98 bản không hề sao lưu database. V2 nay có một bản khôi phục đo được bằng md5. Nguồn: docs/analysis/R2-BACKUP-THU-NGHIEM-07-08-2026.md.
6/6Chỉ số dấu vân tay khớp sau khôi phục — md5, số dòng, bảng, index, HNSW, extension
3/3Bảng có
oid đổi ⇒ bị drop và dựng lại thật, không phải chạy cho có217.945 BẢnh chụp an toàn nền tảng tự tạo trước khi ghi đè — chụp hỏng thì dừng hẳn
0 dòngMã tầng lưu trữ phải sửa để chạy trên Cloudflare R2
17,8 MB/sĐẩy tệp 80 MB lên R2, trung vị 3 lượt (khoảng 15,1 – 21,5)
0 đPhí egress của R2 ⇒ mất hẳn cái cớ tài chính để không diễn tập khôi phục
| Đo cái gì | Trước khôi phục | Sau khôi phục | Đọc thế nào |
|---|---|---|---|
oid bảng drill_r2 | 16863 | 17232 | Phải ĐỔI — pg_restore --clean drop rồi dựng lại từng đối tượng |
oid bảng tasks | 16758 | 17259 | |
oid bảng teams | 16750 | 17267 | |
| md5 toàn bộ dữ liệu mốc | 977462db8dcc… | 977462db8dcc… | Phải GIỮ NGUYÊN — dữ liệu quay về đúng từng byte |
| Số dòng | 5.000 | 5.000 | |
| Bảng · index · index HNSW | 12 · 22 · 3 | 12 · 22 · 3 | |
| Extension | plpgsql, vector | plpgsql, vector |
Luật cho mọi lượt diễn tập còn lại. Hai cái bẫy dưới đây làm một lượt diễn tập xanh mà không đo gì cả — lượt vừa rồi tránh được, các lượt sau phải tránh y như vậy. (1) Khôi phục lên một cơ sở dữ liệu rỗng thì luôn đạt, nên phải gieo dữ liệu biết trước rồi mới sao lưu. (2) Khôi phục lên một cơ sở dữ liệu đang có sẵn dữ liệu đúng cũng đạt kể cả khi nó không làm gì cả — nên phải khoá bằng hai điều kiện ngược chiều: dấu nhận dạng đối tượng phải đổi (chứng tỏ bị dựng lại thật) trong khi md5 dữ liệu phải giữ nguyên.
Còn phải diễn tập — bốn mục, chưa mục nào có số. (1) Ba loại cơ sở dữ liệu còn lại: MySQL, MongoDB, Redis. Đường khôi phục của chúng khác hẳn Postgres trong mã — MySQL không xoá gì cả mà ghi chồng lên, Redis thay tệp rồi khởi động lại — nên không được suy từ kết quả Postgres sang. (2) Trên hệ phục vụ khách thật, không phải hệ thử. (3) Bộ dữ liệu mẫu theo khách đại diện, không phải một cơ sở dữ liệu 217 KB. (4) Đo thời gian khôi phục và mức dữ liệu chấp nhận mất — hai con số này quyết định cam kết với khách, và hôm nay chưa có.
Sao lưu V1 — rủi ro hẹp hơn tưởng, nhưng chưa đóng hẳn. Kho sao lưu của V1 nằm ở CMC Telecom Cloud, thùng tinhgon-v1 — tức ngoài máy chủ V1. Vậy rủi ro mất riêng máy V1 đã loại trừ. Nhưng “ngoài máy” chưa bằng “khác vùng hỏng hoàn toàn”: chưa biết khoá kho có tách khỏi khoá quản trị máy V1 không, chưa có chế độ chống xoá trong hạn giữ, chưa có bản sao thứ hai. Và 1.162/1.162 bản “Hoàn tất” chỉ là trạng thái công việc chạy xong — riêng phần khôi phục nay đã có bằng chứng: diễn tập 10/08 khôi phục 3 dự án đại diện, đối soát khớp tuyệt đối. Rủi ro thật nằm ở chỗ khác — mức phủ: chỉ 12 trên 279 dự án có lịch sao lưu, và 178 dự án chưa từng có bản nào. Còn “giữ 3 bản gần nhất” là thiết lập của từng dự án chứ không phải quy tắc hệ thống — đo được các mức 2, 3, 4, 5, 7, 10 và 30.
Một điều dễ hiểu nhầm, và nó đổi cách viết cam kết. Khôi phục không đưa cơ sở dữ liệu về đúng ảnh chụp — nó chỉ ghi đè phần có trong bản sao lưu, nên bảng tạo sau lúc sao lưu vẫn sống sót. Đây là đọc từ mã, chưa đo. Kèm theo: khoá kho lưu trữ đang có phạm vi toàn tài khoản (nhìn thấy dữ liệu dự án khác) và chưa đặt hạn giữ cho kho sao lưu — hai mục phải xong trước khi mở cho khách thật.
!Hạ tầng đo thật · 10/08/2026 — bốn máy chủ
Bổ sung theo yêu cầu CTO: từng hạng mục hạ tầng phải có số chứng minh, phải nói rõ đã hứa vượt bao nhiêu, và phải liệt kê rủi ro cụ thể. Toàn bộ đo trực tiếp trên máy đang chạy bằng lệnh chỉ đọc — không tạo, không sửa, không khởi động lại thứ gì.
24.304Số lần một ứng dụng khách trên V1 sập rồi bật lại — vẫn đang lặp, không ai được báo
34sThời gian 11/11 trang khách tự phục vụ lại sau khi khởi động lại hẳn node — diễn tập thật 10/08, không ai đụng tay
239 GBImage trên V1 xoá được ngay không ảnh hưởng gì — bằng 58% toàn bộ dung lượng image
81%Đĩa máy chạy bảng điều khiển V2 đã dùng. Trong đó ~43 GB xoá được ngay
| Hạng mục | Bảng điều khiển V2 | Node cmc-1 | Node hoadon | V1 production |
|---|---|---|---|---|
| Nhân CPU · RAM · đĩa | 16 · 32 GB · 81% | 8 · 16 GB · 10% | 8 · 16 GB · 32% | 16 · 40 GB · 51% |
| Tải so với số nhân | 10% | 1% | 6% | 131% |
| Ứng dụng đang chạy | 51 | 47 | 33 | 275 |
| Đã hứa vượt — RAM | 1,7× | 2,4× | 1,6× | 6,1× |
| Đã hứa vượt — CPU | không đặt trần | không đặt trần | 2,1× | 11,3× |
| Ứng dụng không có trần bộ nhớ | 32/51 | 3/47 | 8/34 | 10/275 |
| Bộ nhớ tráo (chỗ giãn khi hết RAM) | 511 MB | 0 | 0 | 0 |
| Lần máy chủ cạn RAM (trong ~2 giờ quan sát được) | 0 | 0 | 0 | 0 |
| Ứng dụng đang lặp sập–bật | 0 | 0 | 0 | 1 — lần thứ 24.304 |
| Tự lên lại khi tiến trình Docker chết bất thường | 61% | 100% | 91% | 97% |
| Tự lên lại khi khởi động lại máy — diễn tập thật | chưa thử | 11/11 trang · 13/13 CSDL · 34 giây | chưa thử | chưa thử |
| Tường lửa hệ điều hành | tắt | tắt | tắt | tắt |
| Luật cách ly mạng ở tầng Docker | không | có | không | không |
| Cổng mở ra Internet | 10 cổng | 3 cổng | 9 cổng | 14+ cổng |
Hai nhận xét ngược với kỳ vọng thông thường. Thứ nhất, V1 phủ trần bộ nhớ rộng hơn các máy V2 được đối chiếu — chỉ 4% container V1 không có trần, so với 63% trên máy bảng điều khiển V2. Thứ hai, node cmc-1 là máy an ninh tốt nhất trong bốn máy: duy nhất có luật chặn ứng dụng khách gọi ngược vào máy chủ, và chỉ mở 3 cổng ra Internet. Nghĩa là node V2 nên học kỷ luật tài nguyên của V1, còn node mới nên chép nguyên bộ cách ly mạng của cmc-1.
Đo lại kỹ hơn đã lật một kết luận — ghi lại để không ai dùng con số cũ. Bản đầu đọc 957 dòng báo hết bộ nhớ thành “máy V1 hết RAM 957 lần”. Sai. Đo lại: 0 lần ở mức máy chủ, và toàn bộ đến từ đúng một ứng dụng khách tự chạm trần 64 MB của chính nó — ứng dụng đó đã sập/bật 24.304 lần và vẫn đang lặp. Nghĩa là trần bộ nhớ đang làm đúng việc: nó nhốt một ứng dụng hỏng lại thay vì để nó kéo sập máy. Việc phải làm vì thế cũng đổi: không phải bật bộ nhớ tráo, mà là đặt phanh cho vòng lặp sập–bật và báo cho người ta biết. Lưu ý phạm vi: nhật ký chỉ giữ ~2 giờ nên đây không phải bằng chứng cho cả 14 tuần máy chạy.
Kiểu sập thứ hai của V1 — không liên quan bộ nhớ, và V2 mới chặn được một nửa. Ca thật: một ứng dụng khách gọi API của chính nó ~1.200 lần/phút, mỗi lần lấy nguyên bảng từ cơ sở dữ liệu → ~42 GB truyền qua lại, CPU ~49%, kho kết nối cạn, phải tạm ngưng bằng tay. Không phải bị tấn công — chỉ là mã khách viết chưa tối ưu, nên nó sẽ tái diễn. Đọc mã V2: ba chỗ hơn V1 — có trần CPU thật ở tầng nhân (V1 không có), mỗi cơ sở dữ liệu là container riêng nên khách này cạn kết nối không kéo khách khác, và chốt chặn tự-bật-lại 20 lần. Năm chỗ chưa chặn — không giới hạn tốc độ gọi, không đếm truy vấn theo ứng dụng, không đo lưu lượng ứng dụng↔cơ sở dữ liệu, cảnh báo mức máy chỉ nhìn đĩa và bộ nhớ chứ không nhìn CPU, và vẫn phải tạm ngưng bằng tay.
Nguy hiểm hơn “chưa có tính năng”: giao diện đang nói một điều không đúng. Hai trần maxConnections và maxDataSizeGB có trong lược đồ dữ liệu, có kiểm tra dữ liệu nhập, có ô nhập trên giao diện, có lưu vào bảng — nhưng không có một dòng nào thi hành chúng trên cả đường Panel → Wings → cơ sở dữ liệu. Chúng chỉ được đọc để vẽ thanh phần trăm, và ba chỗ tạo cơ sở dữ liệu đều ghi cứng 100. Postgres của khách thật ra chạy với trần mặc định của ảnh gốc, không phải con số hiện trên màn hình. Khách và đội hỗ trợ đều tin là có trần. Kèm một lỗ nhỏ cùng họ: container xem trước lúc khách đang sửa mã chạy không kèm trần tài nguyên nào (container chạy thật thì có đủ).
Tìm thấy và đã vá: một lưới an toàn viết sẵn nhưng chưa từng chạy. Wings có sẵn vòng tự dựng lại dự án mỗi lần khởi động — duyệt mọi dự án, cái nào bảng điều khiển bảo "phải chạy" mà đang tắt thì bật lên, giới hạn 4 cái một lúc, thử lại 2 lần. Viết cẩn thận, gọi đúng chỗ. Nhưng bảng điều khiển gửi trạng thái mong muốn là chuỗi rỗng, còn wings chỉ hành động khi trường đó bằng running — nên nó bỏ qua 100% dự án, mọi lần, không log một dòng nào. Đã sửa ngày 10/08: bảng điều khiển gửi trạng thái thật (dự án đang chạy thì dựng lại; đình chỉ thì không, bất kể gì khác), và wings nay ghi một dòng tổng kết mỗi lượt kèm cảnh báo nếu còn dự án không được khai trạng thái — chính dòng này nếu có từ đầu đã tố cáo lỗi ngay ngày đầu.
Bộ kiểm không thử ngược thì không biết nó kiểm gì. Hợp đồng giữa hai bên là một chuỗi trong tệp dữ liệu, mà bảng điều khiển viết bằng một ngôn ngữ còn wings viết bằng ngôn ngữ khác — không công cụ biên dịch nào bắt được khi một bên đổi chuỗi. Đúng khe hở đã để lọt lỗi này. Nên sau khi viết bộ kiểm đã cố tình phá 7 kiểu để xem có đỏ không. Hai kiểu lúc đầu ra xanh — bộ kiểm của chính mình có lỗ: canh nhầm tên trường ghi nhật ký thay vì canh điều kiện thật, và chỉ canh một trong hai chỗ so chuỗi. Vá bộ kiểm rồi phá lại, cả bảy mới đỏ.
DIỄN TẬP THẬT 10/08 — khởi động lại hẳn node đang phục vụ khách, hai lượt. Lượt đầu: chỉ 5/11 trang tự phục vụ lại; 6 trang và toàn bộ 13 cơ sở dữ liệu nằm im, ~6 phút mới đủ và chỉ vì có người ngồi bật. Nguyên nhân ở callout dưới. Lượt sau, cùng node, sau khi đổi chính sách khởi động lại: 11/11 trang khớp đúng mã trạng thái sau 34 giây, 13/13 cơ sở dữ liệu cũng tự lên, không ai đụng tay.
Nguyên nhân, đọc từ mã thoát của từng container: tất cả đều thoát với mã 0. Khởi động lại máy là một lần tắt sạch sẽ — ứng dụng nhận tín hiệu dừng rồi thoát bình thường. Mà chính sách on-failure chỉ bật lại khi thoát LỖI. Còn khi tiến trình Docker chết bất thường thì container cũng chết bất thường ⇒ đúng điều kiện để on-failure bật lại. Hai kiểu mất nghe giống nhau nhưng khác nhau ở mã thoát, và mã thoát mới là thứ quyết định.
Một lưu ý về cách đo, vì nó dễ cho ra con số đẹp mà sai. Traefik trả mã 404 cho tên miền nó chưa có đường đi, trông giống hệt 404 do ứng dụng của khách trả. Phép đếm nào nhận cả hai là “đang phục vụ” sẽ báo 11/11 trong khi thực tế là 5/11. Cách đo đúng: so đúng mã trạng thái từng trang với mức đo trước khi khởi động lại. Một phép đo không phân biệt được “hạ tầng trả lời” với “ứng dụng trả lời” thì không đo được cái nó tưởng đang đo.
| Cần diễn tập / cần đo | Vì sao chưa có số | Đo xong thì trả lời được gì |
|---|---|---|
| Đã diễn tập | Xong, và KHÔNG ĐẠT: 5/11 trang tự lên, 6 trang + 13 CSDL phải bật tay, ~6 phút mới đủ. Còn thiếu: đo lại sau khi sửa | |
| Khôi phục một dự án V1 từ kho sao lưu | V1 có 1.162 bản sao lưu, chưa bản nào được chứng minh khôi phục được | Có dám chuyển khách trả phí không, và mất bao lâu mỗi dự án |
| Đo tải node mới trước khi nhận khách | Node chưa dựng | Node chịu được bao nhiêu ứng dụng ở mức nào |
| Tỷ lệ dự án có cơ sở dữ liệu mà không được sao lưu | Cần đối chiếu hai nguồn dữ liệu V1 | Con số 12,6% bản sao lưu có cơ sở dữ liệu là bình thường hay là lỗ hổng |
| Chi phí node mới mỗi tháng | Chưa chốt cấu hình | Chuyển khách có lãi hay lỗ |
★Cụm Singapore · 11/08/2026 — dựng, bắn, và đo
Đây là lần đầu kiến trúc nhiều máy của V2 được bắn thật chứ không mô phỏng: bốn máy riêng, một địa chỉ công khai duy nhất, ứng dụng deploy qua bảng điều khiển production, rồi giết máy đang phục vụ giữa lúc có lưu lượng. Nguồn số: ARCH-V2-DUONG-DI-CUA-MOT-YEU-CAU.md §15.
95/95Yêu cầu thành công khi giết máy đang phục vụ giữa chừng — không một lần lỗi
4/4Vòng diễn tập chuyển đổi cơ sở dữ liệu, tổng kiểm khớp cả bốn lần
5/7Ca nghiệm thu lưu trữ dùng chung đã đo đạt — gồm cả ba ca khó nhất
2m41sDựng lại một ứng dụng ở máy khác từ mã nguồn — số đo thật, không ước lượng
| Câu hỏi đặt ra | Kết quả | Ý nghĩa |
|---|---|---|
| Hai máy có cùng ghi vào một ổ dữ liệu được không? | Bị chặn · 4/4 | Hàng rào loại trừ hoạt động. Đây là ca làm hỏng dữ liệu vĩnh viễn nếu sai |
| Đứt mạng mà không tắt máy thì sao? | Vẫn chặn | Ca khó nhất: máy cũ tưởng mình còn sống. Nó không giành lại được quyền ghi |
| Máy cũ sống lại sau khi đã chuyển? | Không giành lại | Đạt sau khi thêm 120 giây đứng ra — xem “hai lỗi” bên dưới |
| Giết máy đang phục vụ giữa lúc có lưu lượng | 95/95 · 200 | Khách không thấy gì. Địa chỉ không đổi, không ai phải sửa DNS |
| Dữ liệu có nguyên vẹn sau khi chuyển máy? | Khớp 4/4 | Đối chiếu bằng tổng kiểm. Lệch một lần là đổ cả kết luận |
Hai lỗi chỉ bắt được nhờ bắn thật — đọc mã không ra. (1) Bộ canh lên dây đồng hồ giám sát trước khi giành được quyền ghi, nên máy dự phòng đang xếp hàng thì bị chính đồng hồ của mình khởi động lại — 5 lần trong 3 phút. (2) Máy vừa bị bắn giành lại quyền ghi ngay: giao thức lưu trữ dành một khoảng ân hạn cho máy khởi động lại đòi lại quyền cũ, và quyền đòi lại đó thắng máy đang xếp hàng chờ. Lỗi thứ hai nguy hiểm hơn vì nó không báo lỗi — nó làm cả hai máy đều tin mình đúng, đúng lúc một máy đang ghi. Cả hai đã sửa và diễn tập lại đạt.
◷Roadmap cập nhật · 11/08/2026
Cập nhật của roadmap tháng 08 sau khi cụm nhiều node đã được dựng và bắn thật. Bản đầy đủ kèm lịch từng ngày: Vibe_Host_V2_Roadmap_CAP-NHAT-2026-08-11.xlsx (6 trang: trạng thái R01–R42 · 12 hạng mục mới · gate chấm lại · lịch hai tuần · ba quyết định chờ CTO).
G4Cổng multi-node đạt sớm 10 ngày so với mốc 21/08 — có bằng chứng đo, không phải tự chấm
12Hạng mục mới lộ ra khi bắn thật — không có trong bản lập tháng 7
2Điểm hỏng đơn còn lại — đều chặn việc nhận khách thật lên cụm
3Quyết định chờ CTO, mỗi cái chặn một nhánh việc đứng yên
| ID | Hạng mục mới | Ưu tiên | Vì sao cần — căn cứ đo được | Chặn việc gì |
|---|---|---|---|---|
| H01 | Dựng máy biên thứ hai | P0 | Cụm thử có đúng một máy biên; nó chết là mất cả cụm | Chặn nhận khách thật |
| H02 | Bỏ điểm hỏng đơn ở lưu trữ dùng chung | P0 | Cụm thử có đúng một máy lưu trữ; nó chết là mọi node mất dữ liệu chung | Chặn nhận khách thật |
| H03 | Bảng định tuyến do bảng điều khiển tự sinh | P0 | Cách dò hiện tại là số ứng dụng × số node; 10.000 × 100 mỗi 5 giây không đứng được | Chặn quy mô lớn |
| H04 | Đường kiểm sẵn sàng riêng thay cho trang chủ | P0 | Ứng dụng chỉ có API, trả 404 hợp lệ ở trang chủ, hiện bị coi là không tồn tại | Chặn một số loại ứng dụng |
| H05 | Ngưỡng hỏng/khoẻ liên tiếp + ân hạn khởi động | P0 | Ứng dụng khởi động chậm bị loại quá sớm; một lần chậm mạng làm node dao động vào/ra | Rủi ro vận hành |
| H07 | Cắt chuyển dứt điểm khi chuyển node | P0 | Lúc hai node cùng có ứng dụng, lưu lượng chia cho cả hai ⇒ phiên bị văng, tác vụ nền chạy đôi | Chặn chuyển ứng dụng có trạng thái |
| H09 | Liệt kê được ổ dữ liệu riêng của ứng dụng | P0 | Cổng chặn chỉ đếm được cơ sở dữ liệu; tệp tải lên và SQLite không có bảng nào ghi lại | Chặn chuyển node an toàn |
| H10 H11 | Đo độ trễ ghi · diễn tập nạp lại từ sao lưu | P0 | Hai ca cuối trong bảy ca nghiệm thu lưu trữ dùng chung | Chặn chốt kiến trúc lưu trữ |
| H12 | Bật AI tự vá lỗi cho nhóm thí điểm | P1 | Phần mềm đã xong và đang tắt vì chi phí — không bật thì vĩnh viễn không có tỉ lệ sửa thành công thật | Chặn quyết định đóng gói AI |
| Cổng | Điều kiện | Trạng thái 11/08 | Bằng chứng · còn thiếu |
|---|---|---|---|
| G4 | Nhiều node điều phối nhất quán | Đạt — sớm 10 ngày | Cụm 4 máy · hàng rào 4/4 vòng · giết node đang phục vụ cho 95/95 lượt gọi thành công · chuyển ứng dụng giữa node bấm được trên giao diện. Còn thiếu: chưa đo dưới tải thật |
| G5 | AI và bảo mật | Có phần mềm, chưa có số | Sổ chi tiêu, trần và cổng theo gói đã có. Còn thiếu: AI tự sửa đang tắt nên chưa có tỉ lệ thành công trên khách thật |
| G7 | Khôi phục thảm hoạ và cơ sở dữ liệu | Xong một phần | Chuyển cơ sở dữ liệu giữa node, tổng kiểm khớp 4/4. Còn thiếu: chưa diễn tập khôi phục toàn bộ lớp điều khiển |
| G9 | MỚI — cụm không còn điểm hỏng đơn | Không đạt | Một máy biên, một máy lưu trữ. Đây là cổng chặn việc nhận khách thật lên cụm nhiều node |
| G10 | MỚI — chuyển node an toàn cho ứng dụng có dữ liệu | Không đạt | Cổng chặn hiện chỉ đếm được cơ sở dữ liệu, chưa thấy ổ dữ liệu riêng của ứng dụng |
Ba quyết định chờ CTO, mỗi cái làm một nhánh việc đứng yên. (1) Ngưỡng độ trễ ghi chấp nhận được của ổ dùng chung — phải chốt trước khi đo, vì chốt sau khi có số là chốt theo số. (2) Trần bán vượt RAM/CPU cho node nhận khách — V1 đang ở 6,1× RAM và 11,3× CPU mà chưa ai ký. (3) Trần token tháng cho AI tự vá lỗi và nhóm được bật — mỗi lượt tự sửa tiêu tiền thật, và đang tắt hoàn toàn nên vĩnh viễn không có số để quyết bán.
→Chuyển khách theo nhóm gói — bản chốt 10/08
Khách trả phí sang node V2 mới. Khách dùng thử ở lại V1 nhưng vẫn chuyển sang nền Wings ngay tại chỗ, giống cách node hoadon đang làm. Khách dùng thử mới là nhóm thí điểm trên node mới.
180Dự án khách trả phí đang chạy trên V1 — nhóm phải chuyển sang node V2 mới
45Dự án khách dùng thử đang chạy — ở lại V1, chỉ đổi nền sang Wings
178Dự án trên V1 chưa từng có một bản sao lưu nào — điểm chặn của làn khách trả phí
12/279Dự án có lịch sao lưu tự động. Cơ chế chạy tốt, mức phủ mới là vấn đề
| Làn | Đối tượng | Đi đâu | Đổi máy? | Đổi nền? |
|---|---|---|---|---|
| B — chạy trước | Khách dùng thử cũ · 45 dự án | Ở lại V1 | Không | Có → Wings, tại chỗ |
| C | Khách dùng thử mới | Node V2 mới, vai trò thí điểm | — | Sinh ra đã ở V2 |
| A — chạy sau | Khách trả phí · 180 dự án | Node V2 mới | Có | Có → Wings |
Vì sao đặt làn B trước — và nó chứng minh được tới đâu. Làn B đổi một thứ (nền thực thi, tại máy cũ); làn A đổi hai (nền thực thi và máy chủ). Chạy B trước để loại bớt nhóm lỗi tương thích của Wings trước khi cộng thêm biến đổi máy. Nhưng nói cho đúng: làn B không phải phép thử cô lập nguyên nhân — máy V1 đang mang sẵn nợ vận hành, và khối lượng của khách dùng thử có thể nhẹ hơn khách trả phí. Nên làn B chạy trơn không chứng minh làn A an toàn; làn A vẫn phải có nhóm thử nhỏ riêng trên node mới.
| Node V2 mới cần lớn cỡ nào | RAM | CPU | Đĩa | Nhận xét |
|---|---|---|---|---|
| Nếu cam kết đúng trần đã bán | 895 GB | 501 nhân | 2 TB | Không khả thi về chi phí |
| Theo mức khách thật sự dùng (đo trên V1) | ~19 GB | ~1,5 nhân | ~130 GB | Đúng thực tế nhưng không còn chỗ nào để thở |
| Đề xuất | 64 GB | 16 nhân | 1 TB | Thực dùng nằm dưới 30% RAM, còn chỗ cho đợt dựng ứng dụng đồng thời |
Ba việc phải xong trên node mới trước khi nhận dự án trả phí đầu tiên — đều là cấu hình, không phải viết phần mềm. (1) Đặt tự khởi động lại cho mọi ứng dụng khách, đưa 6% lên 100%. (2) Đặt phanh cho vòng lặp sập–bật kèm báo động — trên V1 có ứng dụng lặp 24.304 lần mà không ai biết. (3) Chép nguyên bộ luật cách ly mạng của node cmc-1. Và một điểm chặn nằm ở phía V1: 178 dự án chưa có bản sao lưu nào — phải xong trước, không làm song song.
Một phát hiện có lợi: V1 đã có sẵn thứ V2 đang thiếu. V1 có mô hình gói cước đầy đủ — 7 gói, mỗi gói ghi rõ giới hạn CPU, RAM, đĩa, số lần triển khai và số bản sao lưu được giữ. Đây đúng là phần V2 chưa có: lược đồ dữ liệu V2 không có khái niệm “dùng thử”, nên hai hạng mục bảng điều khiển #3331 và #3336 đang bị chặn vì không phân biệt được khách dùng thử với khách trả phí. Lấy mô hình của V1 làm bản thiết kế thì gỡ được cả hai — và đó cũng là điều kiện để V2 tự phân loại khách sau khi chuyển sang.
Một cảnh báo phải đọc trước khi dùng con số 180 để tính tiền. Gói “Vibe Host Starter” đang được đặt là gói mặc định, nên tài khoản mới có thể được gán gói này tự động mà chưa hề thanh toán. Vì vậy 180 là phân loại theo gói, không phải xác nhận đã thu tiền. Danh sách chuyển thật phải đối chiếu với hệ thống thanh toán trước khi chốt.
✍Điều kiện để ký cho phép chuyển — và đường quay lui
Câu quyết định của cả bản đồ này: “Bằng chứng nào cho phép ký, và nếu chuyển hỏng thì bao lâu khách về lại được như cũ?” Mọi con số CPU/RAM đều không trả lời được câu này — nên phải có bảy điều kiện đo được dưới đây.
Diễn tập khôi phục 10/08 — chạy trên dữ liệu khách thật, khôi phục sang môi trường cách ly. Kho tinhgon-v1 ở CMC Telecom: 1.166 tệp · 27,11 GB. Ba dự án đại diện đều khôi phục được: mã nguồn bung đủ 206 tệp; ổ đĩa thật sự nằm trong gói (46 MB, thư mục dữ liệu hợp lệ); và cơ sở dữ liệu khôi phục rồi chạy được. Đối soát với bản đang chạy trên V1: 12/12 bảng khớp, 166.678 = 166.678 bản ghi. Dữ liệu tải về đã xoá sau khi đo. Báo cáo diễn tập đầy đủ — cách làm từng bước, bảng đối soát, ba bẫy khi khôi phục — ở docs/analysis/DIEN-TAP-KHOI-PHUC-V1-10-08-2026.md.
Ba điều học được từ diễn tập, đều đổi cách viết quy trình. (1) Bản sao lưu cơ sở dữ liệu là bản chép nguyên thư mục dữ liệu, không phải bản kết xuất logic ⇒ chỉ khôi phục được sang đúng phiên bản chính, và nhật ký cho thấy nó phải chạy phục hồi sau sự cố vì bản chép lấy lúc cơ sở dữ liệu đang chạy — lần này tự sửa xong, nhưng đó là may chứ không phải bảo đảm. (2) Cụm khôi phục ra không có tài khoản mặc định, chỉ có tài khoản của khách — không đọc tệp mô tả trong gói thì sẽ tưởng là hỏng. (3) Số liệu thống kê bị đặt lại sau phục hồi nên nó báo 0 bản ghi cho mọi bảng dù dữ liệu còn nguyên — đối soát bằng thống kê sẽ kết luận mất sạch dữ liệu trong khi không mất gì. Phải đếm thật.
| # | Điều kiện | Cách chứng minh | Trạng thái |
|---|---|---|---|
| 1 | Khôi phục được một dự án V1 từ kho sao lưu | 3 dự án đại diện (tĩnh · có cơ sở dữ liệu · có ổ đĩa riêng), khôi phục sang môi trường riêng, đối chiếu nội dung | ✅ ĐẠT diễn tập 10/08 trên cả ba loại: mã nguồn bung đủ 206 tệp · cơ sở dữ liệu khôi phục và chạy được · ổ đĩa bung ra hợp lệ |
| 2 | Máy khởi động lại thì dịch vụ phục vụ được thật | Khởi động lại node thử rồi gọi thử từng trang, không chỉ xem container có chạy | ✅ ĐẠT diễn tập 10/08 trên node đang phục vụ khách: 11/11 trang khớp đúng mã sau 34 giây, tự động; 13/13 CSDL cũng tự lên |
| 3 | Quay lui đã diễn tập, không phải chỉ mô tả | Chuyển một dự án sang node mới rồi quay ngược về V1, bấm giờ | ✅ ĐẠT bấm giờ thật trên test-abc.hoadon.online: về bản V1 7 giây, về lại bản V2 7 giây. Bản V1 còn nguyên container và ảnh nên quay lui là bật lại, không phải dựng lại |
| 4 | Đối soát sau chuyển có tiêu chí số | Đếm bản ghi từng bảng + mã kiểm tra nội dung + gọi thử đường kiểm tra sức khoẻ | ✅ ĐẠT chạy trên dữ liệu khách thật: 12/12 bảng khớp, 166.678 = 166.678 bản ghi |
| 5 | Mọi dự án làn A có bản sao lưu đã kiểm | Hiện 178/279 dự án V1 chưa từng có bản nào | Chưa đạt |
| 6 | Node mới chịu được tải thật | Đo tải với khối lượng đại diện trước khi nhận dự án đầu tiên | Chưa làm |
| 7 | Ba việc cấu hình trên node mới đã xong và kiểm lại bằng đo | Không nhận khai báo, phải đo | Chưa — node mới chưa dựng |
Bốn điều kiện đã ĐẠT — 1, 2, 3 và 4 — tất cả bằng diễn tập thật trên dữ liệu và máy đang phục vụ khách, có bấm giờ và có đối soát số. Ba cái còn lại đều không có việc kỹ thuật nào chặn, chỉ chờ hai quyết định: (5) cho phép bật sao lưu cho 178 dự án chưa có bản nào — thao tác chạm dữ liệu khách thật; (6) và (7) duyệt dựng node V2 mới. Kèm hai con số phải chốt trước khi bắt đầu: mất tối đa bao nhiêu dữ liệu thì còn chấp nhận được, và bao lâu phải đưa khách trở lại phục vụ được. Chọn cách làm trước khi chốt hai con số này là làm ngược — chấp nhận mất 1 giờ dữ liệu thì phải đồng bộ liên tục; cho phép 24 giờ thì chép một lần là đủ.
Câu chặn thật sự của đường quay lui: khách ghi dữ liệu mới trên node mới rồi mới quay lui — dữ liệu đó đi đâu? Hiện chưa có lời đáp. Nếu chưa trả lời được thì cách an toàn duy nhất là khoá ghi trong suốt lượt chuyển và chấp nhận gián đoạn ngắn: chọn gián đoạn có kiểm soát thay vì rủi ro mất dữ liệu âm thầm.
2Tương quan: thiếu sót V1 → V2 đã làm → V2 sẽ làm
Mỗi chuỗi đọc theo năm bước cố định. Cổng nghiệm thu là một phần của giải pháp, không phải phụ lục.
01Continuity & quyết định sản phẩmGiữ dòng tiền và niềm tin trong lúc chuyển nềnCòn cổng
V1 hiện có
V1 đã chứng minh nhu cầu và đang phục vụ việc thật của khách.
Thiếu sót / tác động
Đầu tư tính năng mới song song tạo chi phí kép, làm hai bản trôi xa nhau và kéo dài việc chuyển đổi.
V2 đã làm
Kế thừa luồng V1, giữ import Vercel file-tree và mô hình Project/Deployment/Job.
V2 sẽ làm
Dừng thêm tính năng mới cho V1; V1 chỉ vận hành thường ngày, lỗi nghiêm trọng, bảo mật, mất dữ liệu, chuyển đổi và quay lại bản cũ.
Cổng nghiệm thu
Không tắt V1 theo ngày; đóng wave sau đối chiếu, chạy thử kéo dài và khoảng thời gian còn quay lại được.
02Multi-node placementChọn máy chủ theo chỗ trống còn lại thay vì gắn chết vào một máyCòn cổng
V1 hiện có
Worker/Docker/Traefik/storage gắn một host; không có node assignment.
Thiếu sót / tác động
Không khoanh vùng thiệt hại hoặc chọn máy chủ theo chỗ trống còn lại.
V2 đã làm
Node UUID, heartbeat, schedulable/drain, mã máy chủ và số đo sức chứa đã có trong mã.
V2 sẽ làm
2+ Wings/Traefik, luật đặt máy, đối chiếu và phương án dư một máy.
Cổng nghiệm thu
Drain/placement + thử mất một máy chủ; không dựng trùng container; đo thật thời gian khôi phục.
03Durable Job & concurrencyJob không được mất, không được chạy trùngCòn cổng
V1 hiện có
Redis pop → memory channel; khoá chỉ nằm trong một tiến trình chạy việc.
Thiếu sót / tác động
Restart có thể làm job mất/kẹt; nhiều Worker có nguy cơ side effect trùng.
V2 đã làm
Job attempt, lease/renew, retry, idempotency và stage ledger.
V2 sẽ làm
Reconciliation đủ mọi exit: success/fail/cancel/retry/replace/teardown.
Cổng nghiệm thu
Kill-worker/node: không mất job, không duplicate và lịch sử đối soát được.
04Bản dựng, triển khai & quay lại bản cũQuay lại bản cũ phải dựng lại được y hệt trên bất kỳ node nàoCòn cổng
V1 hiện có
Ảnh, bộ nhớ đệm và đường quay lại bản cũ đều phụ thuộc Docker tại chỗ; khâu dựng tranh tài nguyên với phần đang chạy của khách.
Thiếu sót / tác động
Node khác không chắc có artifact; quay lại bản cũ ở máy khác thì không dựng lại được y hệt.
V2 đã làm
Deployment version/imageTag/commit; Wings build → run → thăm dò và quay lại bản cũ theo ảnh.
V2 sẽ làm
kho ảnh chuẩn có dấu vân tay, tải trước, ghi rõ nguồn gốc bản dựng, cache policy và budget build riêng.
Cổng nghiệm thu
Build/push/pull node khác, dấu vân tay bản dựng khớp, quay lại bản cũ mà không phải dựng lại, đo tốc độ ở mức 95% lượt truy cập.
05Persistent data & storage di chuyển đượcCổng thật là ổ đĩa di chuyển được + hàng rào ghi, không phải sao lưuCòn cổng
V1 hiện có
Volume/DB gắn cứng vào một host. Không có khái niệm di chuyển ổ đĩa giữa các máy chủ.
Thiếu sót / tác động
Đây mới là cổng thật: ổ đĩa ứng dụng chưa mang đi được giữa các máy chủ, chưa có hàng rào chống hai bên cùng ghi. Chặn app có dữ liệu sang máy khác — không chặn app không dữ liệu, và không chặn kịch bản cùng máy.
V2 đã làm
Cơ sở dữ liệu có quản lý, khoá đã niêm, ánh xạ máy chủ. Lượt chuyển đổi hoadon đã chuyển uptime-kuma có dữ liệu sang nguyên vẹn (kuma.db md5 trùng) — nhưng bằng chép tay khi container dừng, cùng máy. Là tiền lệ, chưa phải cơ chế.
V2 sẽ làm
Ổ đĩa mang đi được cho dữ liệu lúc chạy, hàng rào chỉ-một-nơi-được-ghi, manifest + SHA-256.
Cổng nghiệm thu
Recreate/move node không mất dữ liệu, checksum khớp, không có giây nào hai nơi cùng ghi. Chỉ áp cho ứng dụng có dữ liệu riêng khi chuyển sang máy khác.
Sao lưu đã tách khỏi cổng chuyển đổi — quyết định 07/08 của Tech Lead. Sao lưu của V1 có vấn đề thật và đã đo (1.162 bản ghi (đo lại 10/08), 100% ghi “Hoàn tất”, chưa từng có bản “Thất bại”; 98 bản không sao lưu database dù dự án có database, có bản chỉ 396 byte) — nhưng đó là rủi ro vận hành phải vá song song, không phải điều kiện chặn go-live. Lý do: đường lui của lượt chuyển đổi không dựa vào sao lưu mà dựa vào giữ nguyên container V1 và ảnh có dấu vân tay. Điều kiện quyết định go-live là tính năng và hạ tầng.
Phía V2 có bằng chứng đo được, không còn là lời hứa. Kho lưu trữ của hệ thử nay đặt ở Cloudflare R2 — sao lưu nằm ngoài máy chạy dịch vụ, và R2 không tính phí tải về nên diễn tập khôi phục không còn tốn tiền mỗi lần. Diễn tập khôi phục đã chạy thật trên cơ sở dữ liệu có dữ liệu và đạt — chi tiết ở mục Sao lưu & khôi phục. Đây là điểm khác biệt cốt lõi so với V1: V1 có 1.162 bản sao lưu chưa bản nào được chứng minh khôi phục được; V2 có bản khôi phục đo bằng md5. Vẫn không đổi kết luận ở trên — sao lưu không phải cổng chuyển đổi; ổ đĩa mang đi được cùng hàng rào chỉ-một-nơi-được-ghi mới là cổng.
06Routing & availabilityRoute đúng máy chủ đang giữ Deployment, không chia lượt luân phiên một cách mù quángCòn cổng
V1 hiện có
Traefik và ứng dụng của khách chung một vùng hỏng và nhìn container local.
Thiếu sót / tác động
Multi-node phải route đúng máy chủ đang giữ Deployment, không chia lượt luân phiên một cách mù quáng.
V2 đã làm
Domain → active Deployment → nodeUuid; Traefik từng Wings; định tuyến và chứng chỉ bảo mật đã ghi nhận cơ chế chặn-khi-không-chắc.
V2 sẽ làm
Bộ cân tải ở biên có dự phòng, dùng địa chỉ IP nổi, hostname-SNI routing, cập nhật gọn một nhịp và quay lại bản cũ.
Cổng nghiệm thu
Tên miền lạ thì chặn thẳng; mất bộ cân tải mà địa chỉ IP không đổi; định tuyến lúc chuyển đổi có phép kiểm sức khoẻ từ bên ngoài.
07Sức chứa & app ngốn tài nguyên của nhauKiểm kê không phải là sức chứaCòn cổng
V1 hiện có
Có hạn mức theo khách nhưng chưa có cổng nhận việc chung theo chỗ trống còn lại; hạn mức ổ đĩa không phủ mọi khoản chiếm dụng.
Thiếu sót / tác động
Inventory và disk trống không chứng minh sức chứa; khâu dựng, cơ sở dữ liệu, bộ nhớ đệm và phần chạy của khách cùng giành tài nguyên.
V2 đã làm
Số đo máy chủ, các trường sức chứa, cờ nhận việc/rút tải và suất dựng.
V2 sẽ làm
Số liệu đo, mô hình tải, cổng nhận việc, phương án dư một máy, đo hàng đợi và tải.
Cổng nghiệm thu
CPU/RAM/đọc-ghi đĩa/mạng/hàng đợi, lượt triển khai và cơ cấu tải ở mức 95% lượt phải được đo.
Số đo trên hệ thử 07/08 — hai máy chủ ở hai trạng thái trái ngược. cmc-1 đã hứa 9,9 phần CPU trên một máy 8 phần: hệ vẫn nhận thêm việc (đúng chủ ý — không chặn khách vì một con số dự phòng), nhưng đây chính là chỗ cổng nhận việc chung phải nhìn vào. Cùng lúc v1-beta-hoadon để chế độ bảo trì, nên 11 website nằm trên máy đó không nhận được lượt triển khai mới cho tới khi gỡ. Đọc cùng nhau mới ra vấn đề thật của nhánh này: việc dồn về một máy trong khi máy còn lại đóng cửa — và hôm nay chưa có cơ chế nào tự cân lại.
08UX & developer workflowMa sát thao tác đang đổ thẳng vào chi phí supportCó source
V1 hiện có
Ma sát ở activation, env/redeploy, HTML, Git, SQL console và redeploy speed.
Thiếu sót / tác động
Thao tác thừa tăng support; SQL/Git multi-account đụng security/data model.
V2 đã làm
Email/mail, env editor + AI suggestion, DB module, disconnect integration, Git webhook/commit pin.
V2 sẽ làm
Save+deploy, HTML redeploy, SQL read-only có guard, multi-Git, build cache.
Cổng nghiệm thu
nghiệm thu bởi người không kỹ thuật, nhật ký kiểm toán, che dữ liệu nhạy cảm, trần truy vấn, deploy success và first value.
09AI operationsVòng tự sửa phải có phanh: approval, sandbox, revertCó source
V1 hiện có
V1 có hard-coded patch và AI seam nhưng chưa vòng tự sửa an toàn end-to-end.
Thiếu sót / tác động
Lỗi lạ đổ về support; AI thiếu khâu duyệt, khâu hoàn tác và dấu vết nguồn gốc có thể làm hỏng mã nguồn.
V2 đã làm
AI phân tích/biến môi trường/sửa lỗi, hạn mức, vòng lặp có trần, ảnh chụp/hoàn tác và xuất bản vá.
V2 sẽ làm
Triển khai bằng câu lệnh thường, chẩn đoán vận hành, truy nguyên sự cố, hỏi đáp trên nhật ký, an toàn, chi phí, tài liệu và sơ đồ.
Cổng nghiệm thu
Human approval, sandbox, redaction, no-convergence stop, revert và Git PR.
10Template → AI Solution BuilderDeploy demo không tạo outcome cho SMEMới có blueprint
V1 hiện có
Catalog thiên demo/utility; chưa business schema, ingestion, generator và mã nguồn riêng.
Thiếu sót / tác động
Deploy demo không tạo outcome SME; dữ liệu thật thiếu dấu vết nguồn gốc và bản xem trước.
V2 đã làm
Đã có research, 5 case study, GitHub rà soát mã nguồn và hợp đồng lúc chạy; chưa hiện thực.
V2 sẽ làm
AI ingest → normalize → preview → generate source → deploy → Git source of truth.
Cổng nghiệm thu
Approval, sanitize, asset rights, no secret/PII, clean build và first-value test.
11Security, identity & observabilityTrạng thái “xanh giả” là rủi ro lớn nhất còn lạiStop-the-line
V1 hiện có
V1 có auth/rate-limit/nhật ký kiểm toán nhưng khả năng nhìn thấy và phạm vi thiệt hại vẫn dính chặt vào một máy.
Thiếu sót / tác động
Trạng thái xanh giả xảy ra nếu thư điện tử, sao lưu hoặc bộ quét không chạy thật.
V2 đã làm
Tách Customer/Admin, đóng billing bypass, niêm khoá và biến môi trường, dấu vết bản phát hành, nhật ký kiểm toán và lượng dùng AI.
V2 sẽ làm
Đóng quality blockers; dashboard/log/trace; alert sớm; mTLS/KMS/Vault.
Cổng nghiệm thu
P0 = 0; cổng chất lượng + phép chạy thử trên hệ thật + quét bảo mật và dọn nhật ký kiểm toán có evidence.
12Khách lớn & nhiều vùng địa lýKhông kéo một cụm ổ đĩa dùng chung vắt qua đường truyền diện rộngCó điều kiện
V1 hiện có
V1 không được thiết kế để kéo phần chạy và ổ đĩa tại chỗ vắt qua nhiều vùng địa lý.
Thiếu sót / tác động
Đường truyền diện rộng làm tăng độ trễ, làm dữ liệu khó khớp nhau và có thể khiến hai nửa cùng tưởng mình là chính; không kéo một cụm ổ đĩa dùng chung vắt qua đó.
V2 đã làm
V2 có node identity, local executor và route authority ở mức kiến trúc/source.
V2 sẽ làm
Ceph từng region, nhân bản kho ảnh, cân tải toàn cầu; đăng nhập một lần, tuân thủ và mạng riêng làm sau.
Cổng nghiệm thu
ADR, danh mục thiết bị & lịch trực, mạng riêng, mức dữ liệu chấp nhận mất và thời gian khôi phục, chuyển dự phòng và phép kiểm dữ liệu nằm đúng vùng.
3Roadmap PO · 11 cải tiến trước mắt
Trạng thái dưới đây là đối chiếu trực tiếp với mã nguồn ngày 08/08/2026, không phải trạng thái việc trên bảng kế hoạch. “Đã xong” nghĩa là đã chạy được đầu-cuối trên hệ thật; “Có source” nghĩa là mã có nhưng còn cổng chặn hoặc còn thiếu một nửa; “Một phần” nghĩa là có thứ gần giống nhưng chưa đúng điều PO xin — và chỗ lệch được nói rõ ở từng dòng.
| Mã | Yêu cầu PO | Đối chiếu | Nhận định |
|---|---|---|---|
| F01 | Gửi ngay email thông tin đăng nhập sau đăng ký | Một phần | Hạ tầng thư đã đủ (soạn + hàng đợi + bộ gửi). Đăng ký xong có gửi thư chào mừng và thư xác minh, trễ dưới ~15 giây vì đi qua hàng đợi. Nhưng thư không chứa thông tin đăng nhập — đó mới là điều PO xin. Và đường cấp tài khoản tự động từ cổng khác không gửi thư nào cả. |
| F02 | Lưu và deploy ở màn env | Sẽ làm | Màn biến môi trường chỉ có nút Lưu, kèm dòng nhắc “thay đổi có hiệu lực sau khi triển khai lại”. Không có nút gộp, cũng không có lời gọi triển khai nào trong đó. |
| F03 | Menu “Database của tôi” | Một phần | Danh sách cơ sở dữ liệu của người dùng đã có, nhưng nằm trong Bảng điều khiển. Thanh bên chỉ có mục “Tạo database” trỏ tới trang tạo mới; chưa có trang danh sách riêng để đặt vào menu. |
| F04 | Upload HTML khi redeploy | Đã xong | Chạy thật trên hệ: dự án nguồn HTML hoặc tệp tải lên nay dán hoặc tải bản mới ngay trong hộp thoại triển khai lại. Nguồn mới ghi vào cơ sở dữ liệu trước khi dựng, và trang thật đã đổi nội dung ở lượt nghiệm. Nguồn Git không có ô nhập vì nó vốn tự kéo mã mới theo nhánh đã đặt. |
| F05 | Gỡ kết nối kho mã | Đã xong | Đủ ba tầng cho GitHub: nút trong giao diện (có hỏi lại), lời gọi xoá kết nối, và ghi nhật ký kiểm toán. Vercel thì chưa có nút gỡ — cùng một việc nhưng mới làm một nửa số nhà cung cấp. |
| F06 | SQL console | Sẽ làm có cổng | Chưa có gì trong sản phẩm — trang chi tiết cơ sở dữ liệu mới dừng ở chuỗi kết nối, vòng đời và nhật ký. Khi làm phải kèm cổng: mặc định chỉ đọc, phân quyền, ghi nhật ký, hạn giờ và trần số dòng. |
| F07 | Build cache / redeploy nhanh | Một phần | Đã có đường nhanh: mã nguồn không đổi thì dùng lại ảnh đã dựng và bỏ hẳn bước dựng. Nhưng đó là dùng lại cả ảnh, không phải bộ nhớ đệm theo lớp — lệnh dựng phía máy chủ không khai báo nguồn đệm nào, nên mã đổi một dòng là dựng lại từ đầu. |
| F08 | Nhiều tài khoản Git | Phải đổi lược đồ | Chặn ngay ở tầng dữ liệu: ràng buộc duy nhất theo cặp người dùng + nhà cung cấp, tức mỗi người chỉ giữ được một tài khoản mỗi bên. Muốn nhiều tài khoản phải đổi lược đồ, chuyển dữ liệu cũ, và thêm bước chọn tài khoản khi deploy. |
| F09 | AI tự vá lỗi build | Xong · chờ bật có kiểm soát | Vòng tự sửa đã dựng đủ: đọc lỗi, phân loại lỗi nào sửa được, sửa mã trong máy chủ của dự án, dựng lại, kiểm sức khoẻ, có trần số lượt, có đường hoàn tác và có trang thống kê kết quả. Nó tắt vì một quyết định chi phí, không phải vì thiếu tính năng: mỗi lượt tự sửa tiêu token trả tiền thật, nên có hai lớp gác — một công tắc toàn hệ trong phần quản trị, và một cổng theo gói dịch vụ để gói miễn phí không được phục vụ bằng tầng trả tiền. Thứ còn thiếu là số: tỉ lệ sửa thành công trên khách thật, mà muốn có số thì phải bật cho một nhóm nhỏ rồi đọc trang thống kê. Đề xuất: bật cho nhóm thí điểm, đặt trần token tháng, đọc số sau 2 tuần. |
| F12 | Phân ngành + chọn repo case study | Mới có tài liệu | Chưa có gì trong mã: không có trường ngành nghề, không có bộ phân loại. Danh mục hiện tại vẫn là danh sách theo loại công cụ, và ba nhóm kinh doanh mới thêm chưa nằm trong bộ lọc nên khách không lọc ra được. Việc chọn kho mã case study mới nằm ở một tài liệu viết tay. |
| F13 | Case study template · 2 mẫu/tuần | Một phần | 5 mẫu giải pháp đã vào cơ sở dữ liệu nhưng cả 5 đang TẮT — chúng chưa có nguồn triển khai thật, và hệ cố ý không cho mẫu chưa có nguồn lộ ra danh mục khách. 25 mẫu ứng dụng thì đang bật và dùng được. Nhịp 2 mẫu/tuần chưa tồn tại dưới bất kỳ dạng nào. |
Không có mục nào ở trạng thái này.
4Roadmap PO dài hạn · bản gốc 11 tuần
Giữ nguyên ý định và mốc của file đính kèm, nhưng không coi là cam kết nếu cổng nghiệm thu hoặc sức chứa chưa đạt.
-
GĐ1 · Bản chạy được
22/07 – 16/08/2026Deploy nhanh cho người viết mã. Phần lớn đã chạy được trên hệ thử. Đây cũng là giai đoạn đang ở trong tính tới 08/08.
Tự động triển khaiDựng & chứng chỉ bảo mậtTên miềnPostgreSQL/MySQLTệp & dòng lệnhSao lưu & giám sát -
GĐ2 · Vận hành
17/08 – 06/09/2026Tăng giá trị dùng lâu dài. Kho lưu trữ đã có bằng chứng đo được. Sáu mục còn lại chưa bắt đầu.
Tự co giãnKho lưu trữXem trước theo nhánhLàm việc nhómDòng lệnhQuay lại bản cũTìm trong nhật ký -
GĐ3 · Khác biệt AI
07/09 – 27/09/2026Vũ khí cạnh tranh của sản phẩm. Vòng AI tự sửa lỗi đã dựng nhưng đang tắt — bật được bằng công tắc quản trị, chưa có số liệu trên khách thật.
Deploy bằng câu lệnh thườngChẩn đoán vận hànhTruy nguyên sự cốQuét an toànTối ưu chi phíSơ đồ kiến trúc -
GĐ4 · Doanh nghiệp
28/09 – 30/09/2026Cho khách lớn và mở rộng vùng. Ba ngày cho bảy mục ở mức doanh nghiệp — đây là chỗ mốc gốc không đứng vững nếu đọc như cam kết.
Kubernetes (điều phối cụm)Nhiều vùng địa lýĐăng nhập một lầnNhật ký kiểm toánKhôi phục thảm hoạTuân thủMạng riêng
Cần PO xác nhận: file tự khai báo 28 tính năng dài hạn nhưng phần card hiển thị chỉ có 25 mục trong 5 nhóm. Chính file cũng cảnh báo GĐ1 gốc cần 3–4 tháng, nên dồn cả bốn giai đoạn vào 11 tuần cần rebaseline.
Một chạm & Git
- Cài ứng dụng phổ biến
- Tự triển khai khi đẩy mã
- Xem trước theo nhánh
Dịch vụ hạ tầng
- Cơ sở dữ liệu có quản lý
- Kho lưu trữ
- Mạng phân phối & chứng chỉ bảo mật
- Domain
Quan sát & chi phí
- Dashboard
- Cảnh báo sớm
- Tự co giãn
- Dự báo chi phí
- Nhiều vùng địa lý
Developer experience
- Dòng lệnh
- Lịch sử triển khai
- Khôi phục thảm hoạ
- Nhật ký đọc bằng lời thường
- Ra lệnh bằng trò chuyện
- Auto docs
- Infra diagram
5Roadmap PO được rebase theo cổng
Trình tự đề xuất để giữ tầm nhìn PO nhưng không hạ tiêu chuẩn chuyển đổi hay tiêu chuẩn phục vụ khách thật.
07 – 14/08
An toàn & kiểm trước khi chuyển
- Bằng chứng cho lỗi nghiêm trọng nhất
- Kiểm kê/phân vai
- Chạy thử — chạy lại vẫn ra một kết quả
- Khôi phục sạch
- Đường quay lại bản cũ
- Vướng mắc chất lượng
17 – 21/08
Nền multi-node
- 2+ Wings/Traefik
- Bộ cân tải ở biên
- Kho ảnh có dấu vân tay
- Ổ đĩa dùng chung có hàng rào ghi
- Dư một máy
- Quyền quyết định định tuyến
24 – 31/08
Pilot có kiểm soát
- 2 ứng dụng không có dữ liệu riêng đi trước
- 5–10 nếu cổng xanh
- Chạy thử kéo dài ≥ 72 giờ
- Diễn tập máy chủ / cơ sở dữ liệu / thảm hoạ
- Go / No-Go 31/08
09/2026
Product ops + AI
- UX P0
- Template generator
- AI chẩn đoán & đọc nhật ký
- Xem trước / quay lại bản cũ
- Đo giá trị đầu tiên khách nhận được
Q4+ có điều kiện
Khách lớn & nhiều vùng
- Đăng nhập một lần & tuân thủ
- Mạng riêng
- Kho lưu theo vùng
- Cân tải toàn cầu
- Đo thật mức mất dữ liệu & thời gian khôi phục
- Mô hình chi phí & lịch trực
6Cách đọc trạng thái và nguồn sự thật
Các nhãn dùng để ngăn lộ trình biến mục tiêu thành lời khẳng định về hiện trạng.
Bằng chứng hiện có
V2 đã có mảnh máy chủ / hàng việc / Wings / AI tự sửa; Wings đã có bộ kiểm dựng → chạy → thăm dò HTTP 200. Multi-node đang gánh việc thật: 2 máy chủ, phân tải 4/10 app, cả hai schedulable, TLS hợp lệ cả hai miền, cơ sở dữ liệu và phần đang chạy khớp hoàn toàn. Và đã có một lượt chuyển đổi thật trên khách — xem mục trên.
Cập nhật 07/08 chiều — cổng release đã xanh: npm run lint exit 0 · npx tsc --noEmit exit 0 · go test ./... xanh dưới cả umask 0022 lẫn 0077. Lượt sửa Wings còn lòi ra một lỗi lúc chạy thật: copyTree không giữ quyền tệp (nguồn 0640 → đích 0600), đã vá cả hàm lẫn test.
Còn lại đúng hai việc kỹ thuật: (1) phép chạy thử trên hệ thật phụ thuộc môi trường phải chạy với cơ sở dữ liệu, kho lưu trữ và Wings thật; (2) app có dữ liệu chuyển sang máy khác — cần ổ đĩa di chuyển được và hàng rào chống hai bên cùng ghi. Ngoài ra là thủ tục: tag SHA sạch và chữ ký Go/No-Go.
Không được đánh đồng
Việc đã đóng 87% ≠ mức phủ tính năng 86% ≠ chạy thử với nhóm không có dữ liệu riêng 56% ≠ chuyển hẳn sang V2 42% ≠ kiểm trước khi chuyển 43%. Mỗi chỉ số có mẫu số và cổng khác nhau.
Stop-the-line — chỉ áp cho ứng dụng CÓ dữ liệu riêng khi chuyển sang máy khác: không chuyển app có dữ liệu sang máy khác trước khi có ổ đĩa mang đi được, hàng rào chỉ-một-nơi-được-ghi và phép thử gây lỗi có chủ ý. Không áp cho app không dữ liệu, và không áp cho kịch bản cùng máy — kịch bản đó đã chạy thật ngày 03/08 với 20 khách, 0 giây gián đoạn. Sao lưu là việc vận hành song song, không nằm trong lằn dừng này.
Sức chứa256 container chỉ là kiểm kê; không chứng minh còn bao nhiêu chỗ trống hoặc số khách tối đa.
Sẵn sàng caoV2 có mới ở mức sơ khai cho nhiều máy chủ; Chỉ được gọi là sẵn sàng cao sau khi có bộ cân tải, kho ảnh, ổ đĩa dùng chung, dư một máy — và đã diễn tập.
MigrationKhông copy container; phải kiểm kê → sao lưu → chạy song song → kiểm thử → chuyển đổi → chạy thử kéo dài → quay lại bản cũ hoặc đóng.
Nguồn: roadmap PO đính kèm
roadmap-tinh-nang__2_.html; source V1 tại /workspace/factory/deploy-project-main_vibe_host_v1; source V2 tại /workspace/factory/vays-portable; báo cáo giới hạn V1, CTO defense pack, Bộ thực thi Wings và roadmap V2 trong workspace. Ảnh chụp mức sẵn sàng dùng số liệu rà soát gần nhất ngày 07/08/2026.