Phần 01
Bản đồ trong một hình
Dữ liệu chảy một chiều, từ trái sang phải. Không bên tiêu thụ nào nối thẳng vào FAST, và không bên tiêu thụ nào đọc lớp thô. Mỗi bên đọc qua một vai; vai quyết định nó thấy tới đâu.
Đỏ = vùng có dữ liệu cá nhân hoặc ranh giới nguồn. Vàng = vùng số liệu được phép đi xa hơn. Nét đứt = chưa dựng.
Vì sao chia lớp chứ không đọc thẳng FAST: mỗi lớp có một chủ và một lý do để đổi. FAST đổi định dạng → chỉ sửa lớp làm sạch. Kế toán đổi định nghĩa doanh thu → chỉ sửa một cột ở lớp phục vụ, và Power BI, bản tin, chatbot cùng đổi trong một đêm. Thêm một bên đọc mới → chỉ thêm một vai, không xin thêm quyền vào hệ bán hàng của 94 cửa hàng.
Phần 02
Số đo từng lớp
Một bảng để đối chiếu nhanh. Số kích thước gồm cả chỉ mục và phần nén ngoài dòng; số đối tượng đếm từ danh mục hệ thống trên PC.
| Lớp | Ở đâu | Gồm | Kích thước | Ai ghi | Ai đọc | Làm mới |
|---|---|---|---|---|---|---|
| 0 · Nguồn | FAST ERP, pos.sixdo.vn:8080 | 13 endpoint GET được phép | — | Cửa hàng, kế toán, sàn | Lớp nạp | Liên tục |
| 1 · Nạp | ingest/ trên PC | Một chương trình Python + một kịch bản PowerShell | — | — | — | 01:00 mỗi đêm |
| 2 · Thô | schema raw | 16 bảng · 18 chỉ mục | 3,67 GiB | datahub (lớp nạp) | datahub | Upsert mỗi đêm |
| 3 · Làm sạch | schema staging | 14 view | 0 | datahub (dbt) | datahub | Đọc lúc mart dựng |
| 4 · Phục vụ | schema mart | 17 bảng + 5 view · 0 chỉ mục | 1,19 GiB | datahub (dbt) | Theo vai: 16 cho bi_reader, 6 cho bi_pii | Dựng lại toàn bộ mỗi đêm |
| 5 · Chất lượng | schema dq | 11 bảng · 0 chỉ mục | 383 MiB | datahub (dbt) | 8 cho bi_reader, 3 chỉ datahub | Dựng lại toàn bộ mỗi đêm |
| 6 · Quyền | Danh mục vai của cụm | 6 vai dự án + 14 vai dựng sẵn | — | Script infra/0*.sql + post-hook dbt | — | Cấp lại mỗi đêm theo từng model |
| 7 · Tiêu thụ | PC và laptop | Power BI, bản tin, chatbot, DBeaver | — | — | — | Theo nhịp của từng bên |
Cả kho 5.632.146.455 byte (≈ 5,24 GiB). Lớp thô chiếm khoảng 70% — vì nó giữ nguyên văn từng chứng từ FAST dạng JSON, kể cả mảng dòng hàng và dòng thanh toán.
Phần 03
Lớp 0 · Nguồn — FAST, chỉ đọc, một chiều
Hub chỉ được gọi các đường GET dưới /api/Values/ đang nạp, cộng endpoint người duyệt đích danh (luật R10, lớp danh sách cho phép thêm 29/09). Mọi đường ghi của FAST bị cấm đích danh. Không bao giờ tắt kiểm chứng chỉ để lách.
| Nhóm | Endpoint → bảng thô | Mỗi đêm đọc gì |
|---|---|---|
| Chứng từ | GetListVoucherInfo → orders · GetListVoucherPaymentInfo → order_payments | 90 ngày chứng từ gần nhất, từng ngày một lời gọi (từ đêm 02/10; trước đó 14 ngày, trước nữa 2 ngày) |
| Danh mục lớn | GetItemList → items · GetCustomersList → customers | Hàng: toàn bộ danh mục từ 01/01/2015. Khách: chỉ khách tạo trong 90 ngày gần nhất |
| Danh mục nhỏ | Cửa hàng, kho, nhân viên bán, hình thức thanh toán, quốc tịch, tỉnh, quận, phường, thuộc tính hàng (9 loại) | Toàn bộ |
Vì sao đọc lại tới 90 ngày
FAST còn sửa tiền, xoá rồi tạo lại chứng từ cũ nhiều tuần sau ngày bán. Đo 26/09 (đọc lại 90 ngày, chỉ so, không ghi): tiền còn đổi tới chứng từ 45–56 ngày tuổi. Đối soát tháng 8 với FAST ngày 01/10: 16 chứng từ kênh TikTok bị FAST xoá rồi tạo lại với mã mới, hub chỉ còn bản cũ đã gắn cờ rút. Người chốt 01/10: đọc lại 90 ngày mỗi đêm. Cái giá đo được: lượt đêm trên PC ngày 06/10 mất 51 phút.
Thứ API không trả — nên kho cũng không có
Thuế suất VAT, "Nhóm vật tư 1" và cột "Kênh" của báo cáo FAST (kho tự dựng lại bằng quy tắc, xem Phụ lục 5) · giá vốn, tồn kho, chỉ tiêu, vùng / ASM · mã và tên chương trình khuyến mãi, coupon, điểm đã tiêu. Xin FAST cung cấp thêm là mốc P2.12 / P2.17.
Chứng chỉ bảo mật của pos.sixdo.vn hết hạn 10/10/2026 23:59:59 GMT = 11/10 06:59:59 giờ VN. Chưa gia hạn thì lượt hỏng đầu tiên là 01:00 ngày 12/10: lớp nạp dừng, mọi lớp phía sau vẫn phục vụ số đã có, và mọi bên tiêu thụ đều in ngày dữ liệu để không ai đọc số cũ như số mới.
Phần 04
Lớp 1 · Nạp — chạy lại không nhân đôi
ingest/sync.py là bước đầu của kịch bản đêm infra/sync_nightly.ps1. Nó là thứ duy nhất chạm FAST, và là một trong hai thứ ghi vào kho (thứ kia là dbt).
| Cơ chế | Làm gì | Số đo trên PC |
|---|---|---|
| Khoá đồng bộ 91626 | Giữ khoá suốt bước nạp; lượt thứ hai cùng lúc thì thoát. Đã thu hồi quyền lấy khoá khỏi mọi vai khác (26/09) | — |
| Upsert theo khoá tự nhiên | Mỗi bản ghi một dòng; nạp lại cùng ngày ra cùng kết quả | Cổng S01: 2.017.924 / 2.017.924 mã đơn duy nhất |
Sổ cửa sổ load_state | Mỗi (endpoint, ngày) một dòng xong / lỗi; lỡ đêm thì tự nạp bù | Cổng C08: 0 / 5.050 cửa sổ lỗi |
| Phát hiện rút | Đọc lại một ngày mà đơn cũ không còn trong lượt mới → gắn cờ withdrawn; FAST trả lại → gỡ cờ. Chốt an toàn: >10% và >20 đơn biến mất thì coi là FAST trả thiếu, không gắn cờ | Báo cáo S07: 709 chứng từ đang gắn cờ, 734.207.994 đ đã loại khỏi doanh thu |
Sổ lượt sync_run | Một dòng mỗi lượt: chế độ, số ngày đọc lại, số đơn, số rút | Cổng S04: 28 lượt thành công, 2 lỗi trong sổ của PC |
| Ngắt mạch | FAST lỗi liên tiếp ở một cửa sổ → dừng lượt, không chạy dbt — để không dựng lớp phục vụ trên lớp thô nửa vời | Xảy ra thật 26/09 (HTTP 500 ×3) |
Chi tiết lượt đêm, thời gian từng bước và cách tự đo lại: Phụ lục 4.
Phần 05
Lớp 2 · Thô — nguyên văn FAST, không sửa
Schema raw. Mỗi endpoint một bảng cùng cấu trúc: khoá tự nhiên, một cột JSON nguyên bản (kể cả mảng dòng hàng, dòng thanh toán), mã lượt nạp, giờ nạp. Cộng ba bảng sổ của lớp nạp. Đây là lớp duy nhất dbt không tạo — dbt khai nó là nguồn.
| Bảng | Dòng | MiB | Có gì đáng nhớ |
|---|---|---|---|
orders | 2.017.924 | 2.292 | Đầu đơn + mảng dòng hàng. Có địa chỉ giao hàng (dữ liệu cá nhân). Bảng lớn nhất kho: 43% |
order_payments | ≈ 2,02 triệu | 1.119 | Mảng dòng thanh toán của từng chứng từ |
customers | ≈ 387 nghìn | 241 | Tên, SĐT, email, ngày sinh khách. Chỉ khách tạo trong 90 ngày được đọc lại |
items · item_properties | ≈ 110 nghìn · 868 | 98 | Danh mục hàng, đọc lại toàn bộ mỗi đêm · 9 loại thuộc tính |
salespeople | 2.970 | 2 | Có họ tên nhân viên |
| 7 danh mục nhỏ | — | 5 | Cửa hàng 94 · kho 329 · phường 10.467 · quận 704 · tỉnh 63 · hình thức thanh toán 13 · quốc tịch 13 |
load_state | 5.050 | 0,7 | Sổ cửa sổ đã nạp — nhờ nó lượt nạp đứt giữa chừng chạy lại chỉ nạp phần thiếu |
doc_status | 709 | 0,3 | Cờ chứng từ bị FAST rút / tái phát hành. Không xoá nguồn; lớp phục vụ đọc cờ thành is_excluded |
sync_run | 30 | 0,1 | Một dòng mỗi lượt (28 thành công, 2 lỗi); nguồn của nhịp tim 26 giờ |
Số không có "≈" là số đếm chính xác bởi cổng dq lúc dbt chạy đêm 08/10 (C01 + C04, C08, S02, S04); số có "≈" là ước lượng thống kê. Danh mục nhỏ: số dòng theo ước lượng thống kê, trùng số danh mục ở Phụ lục 4.
Upsert: một bản, không lịch sử
FAST sửa một chứng từ thì bản mới đè bản cũ. Hệ quả tốt: chạy lại không nhân đôi. Hệ quả xấu: không đo được FAST đã sửa gì, lúc nào. Muốn biết, hiện chỉ có cách đọc lại FAST rồi so (như lượt so 90 ngày ngày 26/09).
Phần 06
Lớp 3 · Làm sạch — 14 view, không chứa gì
Schema staging, model dbt dạng view: mỗi bảng thô một view (đơn hàng hai view: đầu đơn và dòng đơn). View chỉ là câu truy vấn đặt tên, nên lớp này chiếm 0 byte; việc nặng xảy ra khi lớp phục vụ đọc qua nó.
| Việc của lớp này | Ví dụ cụ thể |
|---|---|
| Tách mảng JSON thành dòng | stg_order_line tách dòng hàng; stg_payment_line tách dòng thanh toán |
| Cắt khoảng trắng mã | Mã hàng ở dòng đơn dài đúng 32 ký tự có khoảng trắng đệm — không trim thì không nối được danh mục |
| Phân loại chứng từ | Theo hậu tố mã chứng từ: HDA = bán, HDF = trả (số lượng âm) |
| Ép kiểu, đặt tên cột | Ngày, số tiền, mã — tên tiếng Anh do lớp này đặt; FAST trả mã viết tắt tiếng Việt không dấu |
Không vai đọc nào ngoài datahub vào được schema này. Lý do: ba view còn mang dữ liệu cá nhân nguyên văn — stg_customer (tên, SĐT, email), stg_order (địa chỉ giao), stg_salesperson (họ tên nhân viên).
Phần 07
Lớp 4 · Phục vụ — nơi con số được định nghĩa
Schema mart, 22 đối tượng. Mặc định là bảng: mỗi đêm dbt tạo bảng mới rồi thay bảng cũ — dựng lại toàn bộ 6 năm dữ liệu, không có model gia tăng nào. Năm model là view để không nhân bản 5 triệu dòng. Không có chỉ mục nào.
| Nhóm | Model | Hạt · điểm đáng nhớ | Vùng |
|---|---|---|---|
| Fact · bảng | fact_order | 1 dòng / đơn · 2.017.924 đơn · cờ rút, tái phát hành, is_excluded · có địa chỉ giao | cá nhân |
fact_order_line | 1 dòng / dòng hàng · 5.186.333 dòng · 513 MiB, bảng lớn nhất lớp này | cá nhân* | |
fact_payment | 1 dòng / dòng thanh toán · 2.037.433 dòng | số liệu | |
| Dim · bảng | dim_customer, dim_salesperson | Khách ≈ 393 nghìn hồ sơ, gồm dòng "khách chưa định danh" cho mã có trong đơn mà không có trong danh mục · nhân viên có họ tên | cá nhân |
dim_product, dim_store, dim_channel, dim_payment, dim_geo, dim_nationality, dim_date | Hàng ≈ 110 nghìn · 94 cửa hàng · lịch 2020–2027 = 2.922 ngày, do dbt sinh (để cổng dq kiểm được) | số liệu | |
dim_thue_gtgt | Thuế suất GTGT chỉ cho kỳ đã xác nhận (P2.13). Kỳ chưa có thì doanh thu chưa VAT để trống | số liệu | |
| View | fact_sales | Hợp đồng giao diện với Power BI, bản tin và chatbot: nối dòng hàng với đầu đơn, phân loại dòng, gộp is_excluded, mang các cột định nghĩa bên dưới | số liệu |
fact_order_bi, dim_customer_bi · dim_customer_pii, dim_salesperson_bi | Hai bản của cùng dữ liệu, chia theo quyền: bản không cá nhân cho vùng số liệu, bản có cá nhân cho vùng cá nhân. Tên nhân viên dời sang vùng cá nhân ngày 26/09 (A2) | cả hai | |
| Bản tin · bảng | bt_kpi_ngay, bt_kenh_nhom, bt_khach_mua_dau, bt_khach_ngay | Số cộng sẵn theo ngày × kênh × cửa hàng (≈ 153,5 nghìn dòng) và theo khách (khoá băm). Bản tin và chatbot đọc ở đây trước | số liệu |
* fact_order_line không có dữ liệu cá nhân; nó được xếp vào vùng cá nhân theo yêu cầu 22/09 để tra dòng hàng bằng DBeaver. Vùng cá nhân nên hiểu là "chỉ bi_full thấy". Số dòng không có "≈" đếm bởi cổng dq C01–C03.
Các cột định nghĩa — một nơi, mọi bên cùng dùng
Cột (trên fact_sales) | Nghĩa | Ai chốt |
|---|---|---|
doanh_thu | Tiền dòng, bỏ phí ship. Mọi số doanh thu của Power BI, bản tin, chatbot chỉ cộng cột này | GATE B, 27/09 |
sl_ban | Số lượng của dòng hàng hoá / voucher (SL thuần FAST): tính hàng tặng 0 đ và phần set bộ 0 đ; bỏ phí ship và bao bì | GATE B, 27/09 |
is_excluded | Dòng của đơn bị rút hoặc tái phát hành — luôn lọc bỏ | P1.6 |
kenh_hien_thi, nhom_kenh, kenh_ban | Kênh theo cửa hàng + nguồn bill; "POS" = cửa hàng thật. Mã kênh gốc vẫn giữ nghĩa nguồn bill | P2.13 + D-13, 26–27/09 |
nhom_vat_tu | Dựng lại "Nhóm vật tư 1" của FAST: phí ship / voucher / công cụ dụng cụ / hàng hoá | P2.13 |
amount_chua_vat | Tiền chia (1 + thuế suất); trống khi kỳ chưa có thuế suất xác nhận — báo cáo B07: 67.624 dòng từ 09/08 đang trống | P2.13, chờ kế toán (N2) |
amount | Tiền dòng nguyên văn FAST, gồm phí ship. Giữ để đối soát dòng, không dùng làm doanh thu | — |
Bẫy đã trả giá 22/09: chạy tay dbt run --select <một bảng mart> mà không kèm dấu + thì dbt xoá bảng cũ kèm mọi view phụ thuộc — fact_sales biến mất — rồi không dựng lại, và vẫn báo thành công. Lượt đêm chạy dbt run đầy đủ nên không dính, nhưng mỗi đêm vẫn có một khoảng ngắn view không tồn tại. Với lớp này, luôn chạy đầy đủ hoặc kèm +.
Phần 08
Lớp 5 · Chất lượng — 20 cổng, 3 đỏ đã biết
Schema dq, 11 bảng do dbt dựng lại mỗi đêm. Mỗi dòng của ba bảng tóm tắt là một phép kiểm có số đo, ngưỡng và kết luận. Dòng cổng (is_gate) là bất biến phải luôn đúng; dòng báo cáo là số để người đọc, không chặn gì.
| Bảng tóm tắt | Cổng | Đỏ lúc đo (08/10) | Dòng báo cáo đáng nhớ |
|---|---|---|---|
dq_summaryđối chiếu dòng hàng ↔ thanh toán | 12 | C04 6/7 bảng khớp số dòng thô ↔ phục vụ — đỏ giả, do dòng "khách chưa định danh" thêm ở lớp phục vụ, chờ người chốt cách đếm · C05b 12/73 tháng lệch > 0,5% · C06b 11/97 cửa hàng lệch > 0,5% | R09: 767 đơn / 6,49 tỷ tiêu thẻ trả trước · tách nhóm thẻ trả trước thì C05c 0/73 tháng, C06c 0/97 cửa hàng · R06: 1.176 / 2.017.924 chứng từ lệch tiền (0,0583%) |
dq_sync_summaryđồng bộ đêm | 5 | 0 | S07: 709 chứng từ đang gắn cờ, 734.207.994 đ loại khỏi doanh thu · S08: 2 đơn còn sống trùng số chứng từ |
dq_bantin_doichieubảng bản tin ↔ hợp đồng | 3 | 0 | B01: 0/400 ngày lệch giữa bảng bản tin và fact_sales · B07: 67.624 dòng chưa có thuế suất |
Đỏ có chủ đích — và cái giá của nó
C05b và C06b đỏ vì một sự thật nghiệp vụ: đơn khách tiêu thẻ trả trước ghi doanh thu dòng gần 0 đ, còn tiền khách nạp thẻ không có trong hub (kế toán xác nhận Q22, phương án a). Luật R12: không nới ngưỡng, không đổi mẫu số — mang cái đỏ lên báo cáo. Vì thế kịch bản đêm chạy dbt run tách khỏi dbt test: test đỏ không chặn dựng dữ liệu. Cái giá: một cổng đỏ mới không làm gì kêu thêm, vì test đã đỏ sẵn. Đã xảy ra 26/09: C08 đỏ từ 09:07 mà không lớp nào báo.
Ngoài ba bảng tóm tắt: bảng đối chiếu từng đơn dq_order_recon (≈ 2,02 triệu dòng, 382 MiB — gần trọn lớp này), bảng ngoại lệ, bảng kiểm khoá ngoại; và năm bảng tóm tắt chuyên đề cho trang Vận hành của Power BI (ngoại lệ, thẻ trả trước, cổng M5.7 theo tháng / cửa hàng, cờ chứng từ). Ba bảng chi tiết mang mã khách từng đơn nên chỉ datahub đọc. Đo 06/10 trên PC: 96 test dbt — 94 đạt, 1 cảnh báo, 1 lỗi (chính là cổng M5.7).
Phần 09
Lớp 6 · Quyền — vai nào tới lớp nào
Quyền không nằm trong một file: lớp phục vụ và lớp chất lượng được tạo lại mỗi đêm, nên mỗi model tự cấp lại quyền của nó ngay sau khi dựng (post-hook dbt). Lớp thô và lớp làm sạch không cấp cho ai. Đo trên PC 08/10: 20 vai — 6 của dự án, 14 vai PostgreSQL tự tạo, không ai dùng.
| Vai | Thô + làm sạch 30 |
Vùng số liệu mart 16 + dq 8 |
Vùng cá nhân mart 6 |
Đối chiếu chi tiết dq 3 |
Ghi | Ai dùng |
|---|---|---|---|---|---|---|
datahub | ✓ | ✓ | ✓ | ✓ | ✓ | Lớp nạp, dbt, kiểm sức khoẻ — trên PC |
bi_full | — | ✓ | ✓ | — | — | Power BI, DBeaver — hiện chỉ trên laptop |
bi_reader | — | ✓ | — | — | — | Bản tin Teams — trên PC |
claude_ro | — | ✓ | — | — | — | Chatbot tại chỗ (PC; DB dev laptop) |
claude_ro_laptop | — | ✓ | — | — | — | Chatbot laptop qua NetBird; mọi câu ghi vào nhật ký PC |
bi_pii (nhóm) | — | — | ✓ | — | — | Không ai đăng nhập; chỉ bi_full là thành viên |
✓ đọc được · — Postgres từ chối (42501). Đo bằng danh mục quyền của từng bảng cộng quyền vào schema (thiếu quyền schema thì quyền bảng vô nghĩa — bẫy 17/09). Phép đo bằng đăng nhập thật cho hai vai chatbot: biên bản P2.10, N1.
Bản sao lưu không mang vai. pg_dump chỉ chép một database; vai là đối tượng cấp cụm. Khôi phục trên máy khác mà quên tạo vai trước thì mọi lệnh cấp quyền lỗi, đêm đầu dbt hỏng ở mọi model cấp cho bi_reader. Quy trình đúng — tạo vai bằng infra/tao_vai.ps1 trước khi khôi phục — đã diễn tập đạt ngày 30/09. Từng vai một, mật khẩu nằm đâu, lộ thì mất gì: Phụ lục 3.
Phần 10
Lớp 7 · Bên tiêu thụ — ai đọc, đọc gì, mới tới đâu
Mọi bên đều đọc cùng một lớp phục vụ, nên cùng một con số doanh thu. Chỗ khác nhau là vai, máy, và dữ liệu mới tới đâu.
| Bên tiêu thụ | Chạy ở | Vai | Đọc gì | Nhịp | Dữ liệu tới |
|---|---|---|---|---|---|
| Bản tin Teams | PC | bi_reader | Bảng bản tin, fact_sales, fact_payment, cổng dq bản tin | 07:00, bù 09:30 | Ngày hôm trước |
| Chatbot | PC · laptop qua NetBird | claude_ro · claude_ro_laptop | Vùng số liệu, bảng bản tin trước | Khi hỏi | 07/10 (đo 08/10) |
| Power BI Desktop | Chỉ laptop | bi_full | 19 bảng nạp sẵn (12 mart + 7 dq), mỗi bảng select * thuần | Bấm làm mới bằng tay | 02/10 — đọc DB dev của laptop |
| DBeaver | Laptop | bi_full | Tra cứu tay | Tay | DB dev |
| Kiểm sức khoẻ | PC | datahub | Chỉ sổ lượt nạp raw.sync_run — không đọc lớp phục vụ | 09:00, 15:00, 21:00 | — |
| Metabase (P2.11) | PC | vai riêng, chỉ bảng tổng hợp | 16 mục tổng hợp | — | Đề xuất, chưa duyệt |
| CDP (P3) | — | vai đẩy riêng | Schema cdp do dbt dựng | — | Plan nháp, cần GATE E |
Power BI chưa có đường tới kho PROD. Đường NetBird mở cho laptop chỉ đăng nhập được bằng vai chatbot (vùng số liệu); vai bi_full trên PC có mật khẩu khác laptop, nên Power BI vẫn đọc DB dev, số dừng ở 02/10 (rà soát 06/10, không có thay đổi nào ghi nhận tới 08/10). Kịch bản hỏng: mở báo cáo trình BOD, đọc lướt qua thẻ "Dữ liệu đến" — số tuần đầu tháng 10 vắng mặt. Mở đường này nghĩa là đưa vùng dữ liệu cá nhân qua NetBird: quyết định của người, không làm trong trang này.
Bản sao cache.abf của Power BI chế độ nạp sẵn là một bản sao dữ liệu cá nhân — đối xử như .env và bản dump (luật R9). Bản tin: Phụ lục 1. Chatbot: Phụ lục 2.
Phần 11
Máy, lịch, đường code — thứ bao quanh các lớp
Từ đêm 05→06/10 kho chạy trên PC đặt cố định ở văn phòng. Laptop là máy phát triển, không chạy task nào.
| Máy | Vai trò | Có | Không có |
|---|---|---|---|
| PC văn phòng | PROD | Docker datahub-pg chỉ nghe loopback · 5 task · file bí mật .env · NetBird + chuyển tiếp cổng cho laptop · bản code kéo từ GitHub bằng khoá chỉ đọc | Power BI · sao lưu DB tự động |
| Laptop | DEV, 0 task | Sửa code, đẩy lên GitHub · DB dev (bản sao, số tới 02/10; Docker tắt lúc đo) · Power BI Desktop · thư mục hỏi chatbot | Mật khẩu kho PC, trừ vai chatbot laptop |
| GitHub | Mã nguồn | Kho riêng tư, chỉ mã | Dữ liệu, bí mật |
| USB | Chuyển tay | Chỉ còn cho bí mật và bản dump | — |
Năm task trên PC
| Task | Giờ | Chạy dưới | Việc |
|---|---|---|---|
SIXDO-DataHub-NightlySync | 01:00 | Phiên đăng nhập | Nạp 90 ngày → dbt run → dbt test → kiểm P1.6 → báo sức khoẻ |
…-NightlySync-Health | 09:00 · 15:00 · 21:00 | Phiên đăng nhập | Nhịp tim 26 giờ |
…-TeamsDigest | 07:00 · 09:30 | Phiên đăng nhập | 3 thẻ vào 3 kênh; thẻ lỗi chỉ vào kênh Vận hành |
…-CanhGac | Lặp 30 phút | Không cần đăng nhập | Báo kênh Vận hành khi PC lên mà chưa ai đăng nhập / Docker chưa lên |
…-GiuCongNetBird | 3 phút sau khởi động, lặp 15 phút | Tài khoản hệ thống | Giữ chuyển tiếp cổng NetBird cho chatbot laptop |
dbt run 47/47 · dbt test 94 đạt, 1 cảnh báo, 1 lỗi có chủ đích · kiểm P1.6 17/17 · 07:00 bản tin gửi đủ 3 thẻ, thẻ nào cũng thành công ngay lần gửi đầu.infra\deploy_pc.ps1: chỉ kéo tiến thẳng, từ chối nếu bản trên PC có sửa tay, có file lạ, hoặc đang giờ cấm. Đạt thật trên PC ngày 08/10.Phần 12
Khoảng trống theo từng lớp
Mỗi dòng có mã trong bi/reports/findings-backlog.md. Trang này chỉ ghi lại, không sửa (luật R5).
| Lớp | Mức | Khoảng trống | Kịch bản hỏng cụ thể |
|---|---|---|---|
| 0 · Nguồn | Cao | Chứng chỉ TLS hết hạn 11/10 06:59 giờ VN | Chưa gia hạn → 01:00 ngày 12/10 lớp nạp dừng; mọi bên phục vụ số cũ và in ngày dữ liệu. Không tắt kiểm chứng chỉ để lách |
| 1 · Nạp | Cao | Lượt chết ngay ở bước nối kho thì sổ lượt không có dòng nào (SYNC-RUN-MU) | Docker tắt lúc 00:40 → lượt 01:00 chết không ghi gì → kiểm sức khoẻ đọc sổ thấy lượt hôm trước "ok", chưa quá 26 giờ, báo khoẻ. Chỉ file cảnh báo trên đĩa và mã thoát của task bắt được |
| 2 · Thô | TB | Upsert đè, không giữ lịch sử sửa | FAST sửa tiền một chứng từ tháng trước → hub có số mới, không ai biết số cũ là bao nhiêu và đổi lúc nào |
| 2 · Thô | TB | Khách chỉ được đọc lại nếu tạo trong 90 ngày (KHACH-CU-KHONG-DOC-LAI) | Khách cũ đổi hạng thẻ hay địa chỉ trên FAST → hub giữ bản đọc lần cuối (đo 26/09: 373.507 khách đọc lần cuối ngày 15/09) |
| 4 · Phục vụ | TB | View fact_sales nặng dần, 0 chỉ mục (FACT-SALES-CHAM-SAU-P213) | Một thay đổi dbt kế tiếp làm view nặng thêm → câu nặng của chatbot vượt 60 giây hoặc 1 GB file tạm |
| 4 · Phục vụ | Cao | Chạy dbt chọn lọc xoá view phụ thuộc (DBT-CASCADE-VIEW) | Phần 07 — chỉ xảy ra khi chạy tay |
| 5 · Chất lượng | TB | Đỏ có chủ đích che đỏ mới (DQ-DO-MOI-BI-CHE) | Một cổng khác đỏ thêm → mã thoát dbt test không đổi, kiểm sức khoẻ không đọc danh sách cổng → không ai biết |
| 6 · Quyền | TB | Bản dump không mang vai (CHUYEN-MAY-VAI-POSTGRES) | Có quy trình đã diễn tập; quên bước tạo vai trước thì hỏng như Phần 09 |
| 7 · Tiêu thụ | TB | Power BI chỉ đọc DB dev | Phần 10 |
| Máy | Cao | PC không có sao lưu DB tự động | Ổ PC hỏng → bản nằm ngoài PC gần nhất là dump 02/10 trên laptop (rà soát 06/10). Sau 12/10, nếu TLS chưa gia hạn, không nạp lại được từ FAST |
| Máy | TB | Docker theo phiên đăng nhập | PC khởi động lại lúc vắng người → kho không lên, lượt đêm mất; chỉ thẻ canh gác báo |
Phần 13
Đọc tiếp, theo lớp
Trang này là bản đồ. Mỗi phụ lục khác đi sâu vào một lớp hay một bên tiêu thụ.
Trang này đo được gì, và không đo được gì
Số kích thước và số đối tượng đo trực tiếp trên PC; số dòng phần lớn là ước lượng thống kê, trừ các số đếm bởi cổng dq. Phép đo dùng vai chỉ đọc của chatbot nên chỉ thấy danh mục, không thấy lớp thô từ bên trong. Câu về Power BI, sao lưu và task lấy từ biên bản ngày 06–08/10, không đo lại hôm nay. Phép đo là 3 lần kết nối, 12 câu đọc cùng các lệnh mở / đóng giao dịch, 15:32–15:33 ngày 08/10 — chúng nằm trong nhật ký container PC (vai này ghi mọi câu) nhưng không trong nhật ký máy chủ MCP, nên người đọc nhật ký ở bước 6.3 sẽ thấy chúng lệch nhau đúng chừng đó.