Kiểm thử synthetic monitoring đa điểm: quorum, alert và false positive

Synthetic monitoring chạy truy vấn hoặc giao dịch chủ động theo lịch để trả lời: người dùng từ vị trí X có hoàn tất hành trình Y trong ngân sách Z không? Nó khác passive telemetry ở chỗ chủ động tạo traffic; vì vậy kết quả có thể bị ảnh hưởng bởi chính probe, credential test, resolver, egress NAT và lịch chạy.

Objective nên tách availability, performance và correctness. HTTP 200 không chứng minh nội dung đúng; latency tốt không chứng minh login/checkout thành công. Mỗi check cần expected result có thể kiểm chứng, cùng scope user, region và network path.

Đặt probe theo failure domain: chi nhánh, ISP/Internet, cloud region, inside VPC và vị trí gần backend. Mỗi lớp trả lời câu hỏi khác nhau. Probe nội bộ tốt nhưng probe Internet lỗi gợi ý edge/DNS/WAF; mọi probe lỗi có thể là service hoặc dependency chung.

Mô tả service path DNS → TCP/QUIC → TLS → edge/WAF → load balancer → application → dependency. Thu resolver, resolved IP, route/ASN nếu phù hợp, certificate chain, response code, content assertion và transaction step. Đồng bộ thời gian, kiểm soát timezone và lưu cấu hình probe theo phiên bản.

Khóa interval, timeout, retry, DNS cache, connection reuse, HTTP version, payload, credential, test data và user-agent. Retry có thể che outage ngắn hoặc làm MTTD dài; không trộn first-attempt success với final success sau retry.

Lịch chạy phải tránh tất cả probe phát cùng giây gây self-induced spike. Dùng jitter có kiểm soát nhưng vẫn giữ correlation window đủ để tính quorum. Theo dõi health của probe: CPU, clock offset, packet loss tới nhiều đích tham chiếu và egress IP.

KPI gồm success rate theo lần đầu/cuối, latency từng phase, content assertion, error taxonomy, MTTD, alert delivery delay, false-positive rate và coverage. Với giao dịch nhiều bước, ghi step latency và step failure; tổng thời gian một con số không chỉ ra lỗi ở DNS, TLS hay backend.

Chuỗi bằng chứng nên nối probe run ID → DNS/TLS/HTTP result → alert ID → incident/ticket. Lưu raw response có chọn lọc, tránh secret/PII. Khi có packet capture, giới hạn phạm vi và thời gian; capture không phải mặc định cho mọi probe.

• Failure domain: Một probe · Dấu hiệu đa điểm: chỉ một vị trí lỗi, đích tham chiếu cũng lỗi · Bằng chứng ưu tiên: probe health, route, egress · Hành động đầu tiên: kiểm tra probe/path
• Failure domain: DNS/edge theo vùng · Dấu hiệu đa điểm: nhiều probe cùng resolver/region lỗi · Bằng chứng ưu tiên: DNS answer, edge IP, TLS · Hành động đầu tiên: so sánh vùng khác
• Failure domain: Ứng dụng · Dấu hiệu đa điểm: mọi vùng tới cùng endpoint lỗi assertion · Bằng chứng ưu tiên: trace, app log, dependency · Hành động đầu tiên: mở incident ứng dụng
• Failure domain: Credential test · Dấu hiệu đa điểm: login lỗi nhưng public check tốt · Bằng chứng ưu tiên: auth response, secret version · Hành động đầu tiên: kiểm tra tài khoản test
• Failure domain: Alert pipeline · Dấu hiệu đa điểm: check lỗi nhưng không có notification · Bằng chứng ưu tiên: rule evaluation, queue, webhook · Hành động đầu tiên: kiểm tra pipeline cảnh báo

Quorum “2 trong 3 probe lỗi” giảm báo động do một probe nhưng có thể che sự cố chỉ ảnh hưởng một quốc gia hoặc ISP. Do đó nên có hai lớp: alert theo vùng cho local impact và alert toàn cục theo quorum. Severity dựa trên user journey, phạm vi và thời gian, không chỉ số probe.

Thiết kế hysteresis: điều kiện mở và đóng incident không nhất thiết giống nhau. Ví dụ mở sau hai lần lỗi liên tiếp từ hai failure domain, nhưng đóng sau ba lần thành công ổn định. Ghi rõ retry nằm trong một run hay giữa các run để tránh đếm sai mẫu độc lập.

• Xác minh từng probe bằng đích tham chiếu và clock offset.
• Chạy baseline đủ chu kỳ ngày/tuần để thấy latency tự nhiên.
• Chặn DNS cho một probe, xác minh alert vùng không thành alert toàn cục.
• Làm certificate test hết hạn trong lab, kiểm tra taxonomy TLS.
• Trả HTTP 200 nhưng nội dung sai, xác minh content assertion.
• Tăng latency dependency theo bậc, đo threshold và MTTD.
• Chặn alert webhook, xác minh dead-letter/retry và cảnh báo out-of-band.
• Khôi phục từng lớp, đo time-to-clear và kiểm tra flapping.

• Xác nhận số probe, vùng và failure domain bị ảnh hưởng.
• Kiểm tra probe health và đích tham chiếu.
• So sánh DNS answer, edge IP, TLS và HTTP phase.
• Tách first attempt khỏi retry result.
• Đối chiếu change/deployment gần thời điểm lỗi.
• Kiểm tra passive telemetry và phản ánh người dùng.
• Thu artifact tối thiểu, che secret/PII.
• Ghi lý do đóng incident và cập nhật threshold nếu có bằng chứng.

Synthetic chỉ đo hành trình được lập trình, không đại diện mọi thiết bị, ISP, tenant hoặc dữ liệu người dùng. Probe chạy định kỳ có thể bỏ lỡ outage ngắn giữa hai lần đo. Quorum giảm nhiễu nhưng luôn đánh đổi sensitivity; không có ngưỡng chung cho mọi dịch vụ.

Kết quả lab của fault injection không chứng minh production sẽ phản ứng giống hệt nếu DNS, CDN, WAF hoặc dependency khác cấu hình. Báo cáo phải ghi vị trí probe, service path, interval, retry, threshold, test data và thời điểm xác minh.

• Synthetic monitoring: Giao dịch chủ động, lặp lại để đo availability/performance.
• Probe: Agent thực thi check từ một vị trí mạng cụ thể.
• Failure domain: Thành phần hoặc phạm vi có thể hỏng độc lập.
• Quorum: Số/tỷ lệ điểm đo cần đồng thuận trước khi ra quyết định.
• MTTD: Thời gian từ khi lỗi bắt đầu đến khi được phát hiện.
• False positive: Cảnh báo lỗi khi dịch vụ mục tiêu thực tế vẫn đạt mục tiêu đã định.