Thiết kế Web

SLA uptime 99.99% website: số đẹp marketing chỉ có giá trị khi định nghĩa đo và ngoại lệ rõ ràng

SLA uptime 99.99% website — cửa sổ đo, provider, bồi thường credit — trao đổi với Webchốt qua 0905 151 701 hoặc hi@webchot.com ký phụ lục.

Tác giả: Nguyễn Văn Trường·Cập nhật: 23/04/2026·9 phút đọc

SLA Uptime 99.99% Website: Đo Lường & Ngoại Lệ

SLA uptime 99.99% website: số đẹp marketing chỉ có giá trị khi định nghĩa đo và ngoại lệ rõ ràng

Cập nhật: 05/05/2026 · Tác giả: Trường — Founder Webchốt

SLA uptime 99.99% website là cam kết không nằm trong slogan phấn khích mà nằm trong phụ lục kỹ thuật: probe ở đâu, tần suất, có tính lỗi dependency bên thứ ba không, maintenance báo trước bao lâu. Khách DN thường muốn “bốn chín” nhưng không đo lỗi ở tầng CDN vs origin — dẫn tới tranh cãi khi Lighthouse báo đỏ nhưng SLA hosting xanh. Webchốt khuyến nghị đặt SLO nội bộ (ví dụ 99.95% origin) và error budget cho deploy. Trao đổi gói: dịch vụ, bảng giá, liên hệ — 0905 151 701, hi@webchot.com.

Dashboard uptime SLA website 99.99%, Webchốt

Đồ thị availability — đừng chỉ nhìn uptime hosting mà quên DNS | Nguồn: webchot.com

Thiết lập monitoring đa điểm không thiên vị

Probe từ trong VN và quốc tế; kiểm cả HEAD request và full page transaction login. SLA uptime 99.99% website chỉ đáng tin nếu synthetic test phản ánh user journey. Log retention đủ để post-mortem — tối thiểu 30 ngày. Alert noisy làm team ignore; cần dedupe và on-call rotation ghi trong runbook.

Canary deploy giảm rủi ro breaking change ăn hết error budget.

Phân rã trách nhiệm khi hạ tầng phân mảnh

Rõ ranh giới: app, DB managed, payment, email transactional, WAF.

Điểm 1: Status page từng provider liên kết.
Điểm 2: Escalation tree PM và khách.
Điểm 3: Communications template RTO/RPO.
Điểm 4: Backup test định kỳ — uptime không có nghĩa mất data nhẹ.

Bảng: SLA hosting vs cam kết end-to-end

End-to-end chỉ hợp lệ khi một đầu mối chịu trách nhiệm tích hợp.

Phạm vi	Hosting SLA	End-to-end	Khuyên dùng
Trách nhiệm	Theo region cloud	Theo vendor tích hợp	DN vừa chọn end-to-end nếu thiếu SRE
Giá	Thấp hơn	Cao hơn	Đánh đổi op cost
Đo lường	Hẹp	Rộng	Định nghĩa endpoint login
Credit	Theo bill cloud	Theo hợp đồng	Đọc limit cap

Credit không bù thiệt hại gián tiếp trừ khi luật áp dụng và điều khoản riêng.

Quy trình incident 60 phút đầu

Bước 1: Triage severity và thông báo status page nội bộ.
Bước 2: Rollback hoặc scale out theo runbook.
Bước 3: Thu thập timeline log.
Bước 4: Fix forward nếu rollback không khả thi.
Bước 5: Post-mortem blameless + action items.

Complain khách chỉ sau khi có ETA — tránh “đang xem” vô hạn.

Chọn gói triển khai và bảo trì

Xem bảng giá managed service. Liên hệ để gắn SLA vào phụ lục. Dùng template triển khai để giảm mảnh vỡ config.

Sai lầm phổ biến

Cam kết 99.99% nhưng chỉ monitor ping; quên certificate expiry; không HA DB.

Sai lầm 1: Gộp staging incident vào prod SLA.
Sai lầm 2: Không maintenance window — deploy đêm không báo.
Sai lầm 3: Không load test trước sale — tự làm vỡ SLA.
Sai lầm 4: Single region — đứt cáp biển là đúng dự đoán.

Đo lường thực địa: RUM, synthetics và trách nhiệm từng tầng

SLA uptime 99.99% website chỉ có ý nghĩa khi RUM cho thấy user journey quan trọng — không chỉ ping ICMP. Hãy tag phiên bản deploy vào metrics để biết spike lỗi sau release nào. Nếu dùng serverless cold start, SLA nên phân biệt “first byte” và “warm request” — marketing không hiểu cold start sẽ hiểu nhầm vendor làm ẩu.

Đối với database managed, failover có thể kéo theo replay lag; định nghĩa degraded trong SLA giúp tránh tranh cãi “nhưng site vẫn lên được”. Bảo trì theo kế hoạch cần thông báo đủ lead time theo hợp đồng và có status page update — khách B2B đặt báo cáo quan trọng vào khung giờ maintenance sẽ rất tức nếu không biết.

Khi dùng edge worker, phiên bản script có thể cache khác nhau theo POP — log trace-id giúp debug. SLA credit nên có trần tuyệt đối mỗi tháng để vendor không phá sản khi sự cố diện rộng. Khách cũng nên có playbooks failover DNS nếu dùng multi-provider — uptime chỉ ý nghĩa khi cả chuỗi được thiết kế chịu lỗi.

SLA uptime 99.99 website tính theo rolling 30 ngày hay calendar month phải ghi contract — hai cách cho thống kê khác nhau khi incident rơi cuối tháng. Exclusion bảo trì định kỳ nên tối đa bao nhiêu phút và thông báo trước mấy ngày; nếu vendor tự ý reboot hypervisor, đó là breach không phải planned. Credit SLA nên có floor payment tối thiểu để dịch vụ không bị “miễn phí tháng đó” vô hạn.

Kiểm chứng uptime bằng synthetic probe từ ba region; chỉ nhìn dashboard CDN không thấy lỗi origin. RTO/RPO database phải align với điều khoản — 99.99 mà restore 6 tiếng vẫn là thất bại kinh doanh. Status page nên độc lập subdomain hoặc vendor third-party — tránh sập cả status cùng app chính.

Khi chạy blue-green, định nghĩa error budget theo SRE Google — burn rate báo động sớm hơn ticket khách. Multi-AZ không đồng nghĩa multi-region; flood một AZ vẫn có thể làm latency tăng dù không downtime tuyệt đối. Khách enterprise đôi khi yêu cầu chứng nhận SOC2 của vendor cloud kèm SLA chain.

Incident chứng minh uptime: status page timeline gap không được quá 15 phút so với log nội bộ — auditor sẽ đối chiếu. Game day failover: tài liệu hoá bước DNS TTL giảm trước 24h cutover. Nếu dùng serverless, cold start spike không được tính là “healthy” nếu p99 vượt ngưỡng hợp đồng — định nghĩa SLO riêng.

Khách D2C nên theo dõi uptime payment redirect — 99.99 frontend mà Stripe checkout fail vẫn mất doanh thu. Thỏa thuận maintenance blackout Tết cần ký sớm; nhiều team offshore ăn lệch lịch. Cuối cùng, backup status page data exporter — khi vendor status down ironically, bạn vẫn có CSV incident.

Chữ ký bổ sung SLA có thể đính bảng “compensating control” khi vendor không đạt SLO nhưng vẫn giữ RPO — ví dụ read replica 5 phút lag. Gaming mobile webview bridge crash không được hạ bậc incident vì không “tính” uptime website — thống nhất định nghĩa user journey quan trọng trước ký. Khách EU có thể yêu cầu chỉ số availability theo GMT; làm rõ timezone trong dashboard hợp đồng.

Third-party script tag manager có thể inject vendor mới mà không qua change control — bật approval workflow trước khi publish container. Đối với marketplace uptime, phân biệt buyer app vs seller portal; một nửa hệ sinh thái down vẫn là breach kinh doanh. Bảo hiểm cyber có thể yêu cầu log retention tối thiểu 90 ngày — kiểm tra chi phí storage trước ký policy. Cuối quý, so sánh uptime report vendor với log RUM nội bộ; chênh lệch >0.05% cần postmortem chung.

Ma trận service criticality nên đính kèm phụ lục: realtime websocket, cron gửi báo cáo đêm, hay chỉ blog marketing có ngưỡng downtime khác nhau — tránh cãi nhau khi seller portal vẫn xanh nhưng buyer checkout 500. Định nghĩa force majeure mạng biển và bảo trì đường trục quốc gia; luật thương mại có khung riêng, hợp đồng phải không mâu thuẫn. Cuối năm, benchmark SLA với CrUX field data thật — marketing số liệu “ba chín” không thuyết phục CFO.