TL;DR
DEX (Digital Experience Monitoring) đo trải nghiệm người dùng trên Cloudflare One, trả lời câu hỏi “Gateway up, Access up, sao Alice nói Salesforce chậm?”. Dashboard control plane không thấy khoảng cách này; DEX thấy.
3 trụ:
- Kiểm thử tổng hợp: WARP client chạy probe HTTP/DNS/traceroute theo lịch từ bên trong tunnel.
- Tín hiệu thụ động của fleet: trạng thái kết nối WARP, phiên bản, tác động tới tài nguyên máy.
- Phân rã độ trễ từng chặng: DNS/TCP/TLS/TTFB/Download, chẩn đoán nút thắt cổ chai đúng tầng.
Bài này không phải tour tính năng. Đây là sổ tay vận hành cho DEX:
- Vì sao “phòng ngừa up” khác với “trải nghiệm up” (ví dụ thực).
- Kiến trúc sâu hơn: client đệm kết quả khi CF DEX API down, thử lại, config lỗi thời, telemetry và quyền riêng tư.
- Framework SLO thực dụng: Access 99.5% cứng, DEX 98% trung bình, Fleet 95% mềm, quan điểm kèm lý do.
- 5 chế độ hỏng DEX không thấy: phạm vi công cụ có giới hạn.
- Khi nào DEX là thừa.
Part 15, mở block Observability & Ops.
Dành cho ai
- Kỹ sư nền tảng vận hành Zero Trust fleet > 100 người dùng, đang phản ứng bị động với ticket thay vì dự đoán.
- SRE cần xác định SLO cho đường truy cập bảo mật trong tổ chức Zero Trust.
- Quản lý helpdesk muốn có dữ liệu chứng minh “ticket giảm 40%” sau khi dùng DEX.
Đọc trước:
- Part 9 WARP: client là agent của DEX.
- Part 14 Logs: kết quả DEX truyền cùng pipeline.
Không nói về
- APM trong mã ứng dụng (New Relic, Datadog APM): khác phạm vi, DEX đo đường truy cập, không đo nội bộ mã.
- Browser Real User Monitoring (CF Browser Insights): khác sản phẩm.
- Cloudflare Radar (xu hướng internet toàn cầu): dữ liệu công khai, khác trường hợp sử dụng.
Prevention UP, Experience DOWN: thực tế
Tình huống thực tôi gặp:
- Dashboard: Access 99.99% thời gian hoạt động tháng. Gateway 99.95%. Enrollment WARP 98%. Mọi thứ xanh.
- Ticket helpdesk tuần: 18 ticket “Salesforce chậm”, 5 ticket “không kết nối được WARP”, 3 ticket “app timeout”.
- Lãnh đạo hỏi: “nền tảng bảo mật có up không?”, “có”. “Sao người dùng khổ?”, im lặng.
Khoảng cách: dashboard đo control plane (bộ đánh giá policy, API, trạng thái tunnel). Người dùng đo data plane (thời gian tới byte đầu, thời gian render, tỉ lệ rớt cuộc gọi).
Nguyên nhân thực tế của “Salesforce chậm”
Tôi đào xuống 18 ticket đó, dữ liệu DEX:
- 8 ticket (44%): WARP định tuyến qua PoP xa. Người dùng ở HCM, lẽ ra vào PoP Singapore, nhưng 8 trường hợp rơi sang Tokyo. Độ trễ +60ms. Vấn đề phía Cloudflare: báo ticket lên CF, họ điều tra (cấu hình lại BGP peering tuần sau).
- 4 ticket (22%): bản thân API Salesforce chậm (phía nhà cung cấp). CF thêm 15ms, origin thêm 800ms. Không phải vấn đề CF.
- 3 ticket (17%): ISP nhà của người dùng chậm (cellular, chập chờn). Không phải vấn đề CF.
- 2 ticket (11%): chính sách DLP mới triển khai làm Gateway HTTP kiểm tra tăng 40ms. Vấn đề cấu hình CF: tôi lùi rule, xem lại.
- 1 ticket (5.5%): TLS handshake chậm vì chứng chỉ origin bị hỏng OCSP stapling. Vấn đề phía origin: báo cho Salesforce.
Không có DEX, cả 18 ticket trông như “CF chậm”. Với DEX: 2/18 thật sự cần CF hành động. 16/18 là nhiễu + nhà cung cấp + ISP người dùng.
Giá trị: không phải “phát hiện ma thuật” mà là “triage hiệu quả”
DEX không giải quyết vấn đề ISP, không sửa origin. Nó cho phép bạn không phải đoán. Tiết kiệm thời gian mới là giá trị.
MTTR của helpdesk giảm từ 4h còn 45 phút trong tổ chức 400 người sau 2 tháng dùng DEX. Không phải phép màu, mà là dữ liệu.
Kiến trúc: độ sâu mà tour tính năng không cho thấy
Góc tổng quan ai cũng biết: client test → CF lưu → dashboard. Nhưng chế độ hỏng mới là nơi cần đào sâu.
Client kéo config
- Client thăm dò CF API mỗi 30 phút để lấy cập nhật config.
- Cache nội bộ → vẫn OK khi CF API down 30-60 phút.
- Cạm bẫy: nếu admin đổi config kiểm thử lúc API down, triển khai bị chậm 30-60 phút. Không nguyên tử.
Chạy kiểm thử
- Lịch mỗi 5 phút (mặc định, hiệu chỉnh được 1-15 phút).
- Kiểm thử chạy trong tunnel WARP mặc định (đường đo = đường người dùng).
- Tài nguyên: 0.5-1% CPU lúc cao điểm, <100KB dữ liệu mỗi kiểm thử.
Đẩy kết quả
- Client POST kết quả tới DEX API sau kiểm thử.
- Thử lại: 3 lần với backoff số mũ (1s, 4s, 16s).
- Nếu API down > 1 phút: client đệm kết quả ở nội bộ, đĩa tối đa 24h (5MB tối đa).
- Nối lại: khi API trở lại, tải lên theo lô với timestamp giữ nguyên, gửi không theo thứ tự được xử lý phía server.
Telemetry và quyền riêng tư
Dữ liệu thụ động của fleet thu thập: trạng thái kết nối, phiên bản, vị trí địa lý (cấp thành phố), loại kết nối (wifi/cellular). Không thu thập: URL cụ thể mà người dùng duyệt, nội dung, thời gian xem màn hình thực theo app.
Dữ liệu kiểm thử tổng hợp: URL đang probe (đây là config, không phải hoạt động của người dùng), số đo độ trễ. Không thu thập tương tác thực của người dùng với Salesforce.
Nếu works council / công đoàn hỏi, phạm vi hẹp hơn APM. Điểm đáng nói.
Kịch bản config lỗi thời
Admin vô hiệu một config kiểm thử (gỡ target). Client đã kéo config cũ trước khi đổi sẽ vẫn chạy kiểm thử, trôi tối đa 30 phút. Dashboard hiện kết quả cũ trong 30 phút cuối. Cờ này quan trọng khi điều tra: “kiểm thử X vẫn báo green sau khi tôi gỡ?”, đúng, vì TTL của config.
Mở rộng quy mô
Doanh nghiệp 10.000+ thiết bị = rất nhiều probe. CF rate-limit theo tài khoản. Thực tế: không bật 20 kiểm thử × 10K thiết bị × mỗi 5 phút = 2.4M kết quả kiểm thử mỗi ngày. CF sẽ chặn nếu vượt quota.
Chiến lược:
- 3-5 kiểm thử quan trọng cho tất cả thiết bị.
- Kiểm thử theo vùng (chỉ APAC) giảm tải.
- Giảm tần suất cho kiểm thử ít quan trọng (15 phút thay vì 5).
Phân rã độ trễ từng chặng: công cụ cốt lõi
Giá trị lớn nhất DEX mang lại. Người dùng nói “Salesforce chậm” = vô nghĩa nếu không có phân rã:
- DNS chậm → vấn đề resolver (sức khỏe resolver CF, tăng đột biến đánh giá chính sách).
- Kết nối TCP chậm → đường mạng (BGP peering, nghẽn, lựa chọn PoP).
- TLS handshake chậm → vấn đề chứng chỉ origin (fail OCSP stapling, session resumption hỏng).
- TTFB chậm → ứng dụng origin chậm (database, queue, thời gian xử lý thực của server).
- Download chậm → vấn đề throughput (chặng cuối, luồng đồng thời, chi phí phụ WARP).
Cây quyết định chẩn đoán
User complaint: "Salesforce chậm"
↓
Query DEX: http_test.salesforce.com TTFB p95 last 30 min
↓
Baseline vs measured?
Normal (< 800ms) → user-specific issue, not platform
2× baseline → drill breakdown
DNS > 100ms → CF DNS Gateway issue, ticket CF support
TCP > 200ms → traceroute test
Hops in expected path → peering issue CF side
Extra hop / different ASN → BGP routing issue
TLS > 100ms → check origin cert OCSP
TTFB > 1s → origin issue, talk to Salesforce
Download slow + small payload → last mile issueChi phí đào thực tế: 10-15 phút nếu quen với phân rã. Không có DEX = ticket bị đá qua lại giữa nhóm hỗ trợ IT/Mạng/Nhà cung cấp trong cả ngày.
Kiểm thử cặp: tunnel so với trực tiếp
Kiểm thử cặp rất quan trọng cho các SaaS quan trọng. Cùng target, một kiểm thử chạy qua tunnel WARP, một kiểm thử chạy trực tiếp (bỏ qua tunnel).
- name: "Salesforce via tunnel"
target: "https://company.my.salesforce.com/"
route: tunnel
frequency_min: 5
- name: "Salesforce direct"
target: "https://company.my.salesforce.com/"
route: direct
frequency_min: 5So sánh trên dashboard:
- Tunnel chậm hơn đều 5-15ms → chi phí phụ CF bình thường.
- Tunnel chậm hơn 50ms+ → lựa chọn PoP của CF chưa tối ưu, điều tra.
- Trực tiếp chậm hơn → vấn đề ISP của người dùng, không phải CF.
Quan điểm: mọi SaaS quan trọng đều đáng có kiểm thử cặp. Chi phí tối thiểu (2 kiểm thử mỗi SaaS), rõ ràng rất lớn.
Fleet insights: tín hiệu passive
Fleet = telemetry thụ động mà WARP client phát ra. Nhẹ hơn kiểm thử tổng hợp, không cần cấu hình target.
Các tín hiệu cốt lõi tôi theo dõi hằng ngày
1. Tỉ lệ kết nối
- Mục tiêu: > 95% thiết bị đã kết nối trong giờ làm.
- Cảnh báo: rớt > 3 điểm phần trăm trong 1h = sự cố.
- Nguyên nhân hay gặp: MDM đẩy cấu hình hỏng, cập nhật chứng chỉ CF, tăng đột biến captive portal.
2. Phân bố phiên bản
- Mục tiêu: > 80% ở phiên bản mới nhất, > 95% trong n-2.
- Cảnh báo: thiết bị mắc kẹt > n-3 phiên bản với CVE đã biết → MDM ép nâng cấp.
- Thực tế: tổ chức doanh nghiệp thường có 3 đuôi phiên bản (chính sách tổ chức chậm chấp nhận so với người dùng tiên phong).
3. Phân tích lý do ngắt kết nối
- Phân rã lý do top hằng ngày:
- Captive portal (sân bay, khách sạn): dự kiến, ~40%.
- Người dùng tắt thủ công (ranh giới công việc và đời sống): chấp nhận, truyền thông.
- Mạng không tới được (xung đột VPN, rule firewall): điều tra.
- Xác thực hết hạn: TTL token cấu hình sai hoặc vấn đề IdP.
- Cảnh báo: phân bố lý do đổi > 15% → có thứ gì đó thay đổi trong môi trường.
4. Tác động tài nguyên
- CPU WARP trung vị < 1% trên toàn fleet.
- Ngoại lệ > 10% CPU: thường xung đột với client VPN, EDR, hoặc proxy công ty. Điều tra theo từng trường hợp.
Fleet như chỉ báo sớm
Tỉ lệ kết nối của fleet rớt thường đi trước ticket 30-60 phút. Nếu tôi thấy rớt bắt đầu 9:15 sáng, ticket đến khoảng 10:00. Chủ động: pager lúc 9:15, điều tra, có thể bắt được vấn đề trước khi 80% người dùng bị ảnh hưởng.
Framework SLO: thực dụng, không theo sách SRE
Mọi bài DEX đều nhắc SLO. Phần lớn lặp lại Google SRE book (p95 < 2s, mục tiêu 99.9%, ngân sách lỗi). Câu hỏi thật: SLO nào cho thành phần nào, và vì sao.
Phân tầng riêng cho Zero Trust
| Dịch vụ | SLI | SLO | Lý do |
|---|---|---|---|
| Đăng nhập Access | Tỉ lệ thành công | 99.9% | Ràng buộc cứng, đăng nhập fail = không làm việc được, người dùng thấy ngay. Ít cảnh báo nhầm vì ít xảy ra. |
| Đăng nhập Access | p95 độ trễ | < 2s | Ngưỡng nhận biết. > 2s người dùng nghĩ “hỏng”. |
| Gateway DNS | p95 phân giải | < 50ms | Mềm, DNS chậm khó chịu nhưng không chặn. Có nhiều cơ chế dự phòng. |
| Gateway HTTP proxy | p95 độ trễ cộng thêm | < 30ms | Trung bình, ảnh hưởng mọi request. |
| WARP fleet | Tỉ lệ kết nối | > 95% | Mềm, có ngắt kết nối là bình thường (mobile, captive portal). |
| SaaS quan trọng (Salesforce, M365) | p95 TTFB | < 800ms | Trung bình. Ngưỡng người dùng cảm nhận được. |
| Bản thân DEX | Tỉ lệ hoàn thành kiểm thử | > 95% | Nội bộ, DEX hỏng thì mù. |
Vì sao không 99.99% cho tất cả
Vì mệt mỏi cảnh báo giết giám sát. Mục tiêu 99.99% → 4.3 phút/tháng được phép down. Mỗi blip 5 phút pager ai đó. SOC bắt đầu tắt tiếng. 99.99% thật đòi hỏi kỹ thuật đắt đỏ (DR đa vùng, read replica, kiểm thử hỗn loạn), đáng cho đăng nhập Access, không đáng cho DNS resolver.
Thực hành ngân sách lỗi
Ngân sách theo tháng mỗi SLO. Tỉ lệ đốt > 50% ngân sách tháng trong < 7 ngày → đóng băng triển khai không quan trọng. Phải áp dụng thật, không chỉ lý thuyết.
Tôi từng thấy nhóm bỏ qua ngân sách lỗi, “tháng trước mình vẫn 99.5%”, triển khai thay đổi rủi ro, vi phạm 99%, ticket đổ về + lãnh đạo hỏi. Framework chỉ chạy được nếu được áp dụng.
Bắt đầu thoáng, siết dần
Triển khai Zero Trust mới: bắt đầu với SLO lỏng (99% đăng nhập Access, < 100ms DNS, 90% fleet). Đo đường cơ sở thực tế 3 tháng. Siết dựa trên dữ liệu, không phải kỳ vọng.
Rủi ro triển khai: doanh nghiệp đặt 99.99% ngày đầu, vi phạm tuần 2, “công cụ hỏng”, lùi lại. Để dữ liệu đặt mục tiêu.
5 chế độ hỏng DEX KHÔNG thấy
Công cụ có giới hạn. Danh sách thành thật:
1. Vấn đề ngoài tunnel WARP
Kiểm thử DEX chạy trong tunnel WARP. Nếu người dùng không có WARP (khách BYOD, nhân sự thuê ngoài chưa enroll, chế độ DNS-location) → DEX mù.
Đường vòng: ép enroll WARP cho mọi người dùng quan trọng. Chấp nhận người dùng DNS-location có khả năng quan sát thấp hơn.
2. Render phía client chậm
DEX đo thời gian HTTP response, không đo browser rendering. Trang Salesforce với JavaScript nặng, time to interactive 5s trong khi TTFB 200ms, DEX vẫn báo green.
Khoảng trống công cụ: cần Browser Real User Monitoring. CF Browser Insights là sản phẩm riêng.
3. Vấn đề trong trang
Người dùng click nút trong Salesforce, API call phía sau chậm. DEX không thấy API theo session của từng người dùng. Chỉ thấy tải trang ban đầu.
Khoảng trống công cụ: APM phía nhà cung cấp (Salesforce Trust portal, M365 Service Health) hoặc beacon phía client.
4. Trường hợp hiếm đường mạng cụ thể
Người dùng ở WiFi công ty, NAT cấu hình sai làm WARP MTU không khớp, gói bị drop. Kiểm thử DEX từ cùng vị trí có thể không tái tạo vì kiểm thử chạy theo thời điểm ngẫu nhiên.
Khoảng trống công cụ: chẩn đoán mỗi người dùng, khó tổng hợp.
5. Kịch bản “target kiểm thử lừa bản thân”
Kiểm thử DEX một endpoint → luôn 200 OK. Luồng thực của người dùng: đăng nhập → dashboard → báo cáo cụ thể. Những đường sâu đó không được kiểm thử. Hiệu năng khác.
Đường vòng: target kiểm thử mô phỏng hành trình thực của người dùng. Chi phí: nhiều config kiểm thử hơn phải duy trì.
Mẫu alert thực tế
Cảnh báo có hiệu quả
- Tỉ lệ fail của kiểm thử đường quan trọng > 10% trong 15 phút.
- Tỉ lệ kết nối fleet rớt > 3 điểm phần trăm so với đường cơ sở 1h.
- p95 TTFB của SaaS tier-1 vượt ngưỡng 30 phút liên tục.
Cảnh báo KHÔNG nên tạo
- Bất kỳ kiểm thử lẻ fail nào: cảnh báo nhầm, thoáng qua.
- Kiểm thử cấp thấp (site tiếp thị): không đáng nhiễu.
- Fleet rớt < 3%: dải nhiễu.
Cửa sổ bảo trì
Bảo trì CF (patch, cân bằng lại PoP) → giảm chất lượng tạm thời. Không đặt cửa sổ → pager nhầm. API trang trạng thái của CF có thể đưa vào tự động tắt cảnh báo.
Tích hợp Logpush + SIEM
Đã bao phủ đầy đủ ở Part 14. Dataset DEX riêng.
Các trường chính: timestamp, test_name, status_code, total_time_ms, phân rã dns/tcp/tls/ttfb/download, user_email, device_id, warp_location.
Tương quan trong SIEM:
- Người dùng báo “Salesforce chậm” + timestamp → query DEX cho người dùng đó, cửa sổ đó, chỉ ra chính xác chặng nào chậm.
- Sự cố theo vùng: nhóm theo warp_location, hiện suy giảm mỗi PoP.
- Xu hướng so với đường cơ sở: so sánh trung bình trượt 7d với cửa sổ 15m hiện tại.
Khi nào DEX là thừa
Không phải tổ chức nào cũng cần DEX:
- Fleet < 50 người dùng. Giao tiếp trực tiếp + rà soát thủ công là đủ. Chi phí phụ vận hành DEX > giá trị.
- Tổ chức không ép WARP. DEX gắn với WARP. Che một phần fleet = giá trị quan sát một phần.
- Stack VPN truyền thống chưa đổi, chưa chuyển sang Zero Trust. DEX là công cụ sau khi chuyển đổi.
- Ràng buộc ngân sách + triển khai giai đoạn đầu. Ưu tiên kiểm soát cốt lõi (Access, Gateway) hơn khả năng quan sát. Thêm DEX vào năm 2.
- Tổ chức phụ thuộc nhiều vào dashboard sẵn có của SaaS. Salesforce Trust portal, M365 Service Health bao phủ 60% trường hợp sử dụng. DEX thêm 40% tăng thêm, có thể không đáng.
Bài học tôi sẽ giữ
- DEX không “giải quyết”, nó bật triage hiệu quả. 18 ticket → 2 cái cần xử lý. Đó là giá trị.
- Kiểm thử cặp (tunnel + trực tiếp) quan trọng cho top 5 SaaS. Tách vấn đề do CF với vấn đề do nhà cung cấp.
- SLO thực dụng, bắt đầu thoáng, siết dần theo dữ liệu. Không 99.99% từ ngày đầu.
- Fleet thụ động là chỉ báo sớm, tỉ lệ kết nối rớt đi trước ticket 30-60 phút. Pager cho cảnh báo của fleet, không phải từng kiểm thử lẻ.
- Mệt mỏi cảnh báo là thật, 3 cảnh báo tốt hơn 15 cảnh báo nhiễu. Văn hoá tắt tiếng giết công cụ.
- Target kiểm thử mô phỏng hành trình người dùng, không phải homepage chung chung. Chi phí = nhiều config hơn, đáng.
- DEX có giới hạn, các chế độ hỏng (render phía client, trong trang, BYOD không WARP) cần công cụ bổ sung.
- MDM ép nâng cấp phiên bản WARP, nếu không đuôi phân bố phiên bản tăng, rủi ro bảo mật + DEX mù (phiên bản cũ có thể thiếu telemetry).
Kết luận
DEX là bằng chứng về trải nghiệm. Dashboard control plane nói “dịch vụ up”; DEX trả lời “dịch vụ chạy được cho ai, ở đâu, nhanh đến đâu”. Triển khai Zero Trust không có DEX = vận hành mù.
Công thức cho production:
- Kiểm thử tổng hợp cho đường quan trọng (5-10 kiểm thử).
- Fleet thụ động theo dõi hằng ngày (tỉ lệ kết nối, phiên bản, lý do ngắt kết nối).
- Kiểm thử cặp cho các SaaS top: so sánh tunnel + trực tiếp.
- SLO thực dụng theo tầng (Access cứng, Gateway trung bình, Fleet mềm).
- Kỷ luật cảnh báo: 3-5 cảnh báo tốt, không có cảnh báo nhiễu.
- Chấp nhận phạm vi có giới hạn: bổ sung bằng RUM / APM / dashboard nhà cung cấp.
Nếu phải nhớ một câu:
DEX không trả lời “có vấn đề không”, nó trả lời “vấn đề ở lớp nào, người phụ trách là ai”. Hiệu quả triage là giá trị, không phải phát hiện phép màu.
Trong Part 16 tiếp tục Observability & Ops: Device posture và continuous verification, từ “xác thực một lần lúc đăng nhập” sang “xác thực mỗi request”, tín hiệu EDR (Crowdstrike / SentinelOne / Defender), và playbook khi thiết bị fail posture giữa session.
Tài liệu tham khảo
- Cloudflare DEX overview
- Fleet status
- Synthetic test setup
- DEX Logpush dataset
- Google SRE SLO framework
Trong series này:
- ← Part 14: Logs pipeline end-to-end
- Tiếp theo → Part 16: Device posture
- Xem toàn bộ: Series Cloudflare One Handbook
