Trang trạng thái hệ thống (status page) cho website nhỏ: công khai hay không, đo gì

Trang trạng thái hệ thống (status page) là trang web cho khách biết các phần chính của dịch vụ đang chạy bình thường, chậm hay gián đoạn, kèm thông báo khi có sự cố và khi đã khắc phục. Với website nhỏ của một người, status page có ích nếu khách phụ thuộc vào bạn để đăng nhập, học, thanh toán hoặc đặt lịch. Bài này không hứa status page làm website ổn định hơn: trang chỉ báo tình trạng, còn giữ website chạy là việc của giám sát và cách triển khai. Bài gồm: các trang công khai lớn hiển thị gì, nên đo gì (khả dụng, độ trễ, lỗi), vì sao kiểm tra từ bên ngoài, ngưỡng cảnh báo, thông báo sự cố trung thực, điều không nên công khai, và trang trạng thái OPCAIOS đang dùng kèm các giới hạn chưa giải quyết.

Đo từ bên ngoài, cảnh báo cho mình, công khai cho khách ở mức vừa đủ. Sơ đồ: OPCAIOS.

Status page là gì và website nhỏ có cần không?

Status page là trang công khai trả lời một câu hỏi duy nhất của khách: "Lỗi là do tôi hay do dịch vụ?". Khi khách không đăng nhập được, một trang trạng thái ghi "đăng nhập đang gián đoạn, đang xử lý" giúp họ không phải gửi tin nhắn hỏi, không thử đi thử lại, và tin rằng bạn đã biết. Website nhỏ nên có status page khi thoả ít nhất một điều kiện sau:

1. Khách đã trả tiền và dùng dịch vụ thường xuyên: khoá học, hội viên, phần mềm.
2. Có luồng phụ thuộc thời gian: thanh toán, đặt lịch, mã đăng nhập gửi qua email.
3. Bạn làm một mình và không thể trả lời từng người khi có sự cố.

Nếu website chỉ có bài viết và trang giới thiệu, một dòng thông báo trên mạng xã hội khi có sự cố thường đủ, và công sức nên dồn vào phần giám sát cho chính bạn.

Các status page công khai lớn hiển thị những gì?

Các status page công khai lớn đều chia dịch vụ thành nhóm mà khách hiểu được, gắn nhãn trạng thái cho từng nhóm, và giữ lịch sử sự cố. Đọc ngày 25/10/2026: status.claude.com liệt kê các nhóm như claude.ai, Claude Console, Claude API, Claude Code; githubstatus.com liệt kê Git Operations, Webhooks, API Requests, Issues, Pull Requests, Actions, Pages, Codespaces và các nhóm khác. Điểm chung đọc được trên hai trang:

1. Năm nhãn trạng thái: Operational, Degraded Performance, Partial Outage, Major Outage, Maintenance.
2. Dải lịch sử 90 ngày cho từng nhóm, ngày không có sự cố ghi rõ là không có gián đoạn.
3. Lịch sử sự cố theo ngày, mỗi sự cố có các bước cập nhật; trên status.claude.com hôm đó có một sự cố đang ở bước "Monitoring".
4. Kênh đăng ký nhận tin: email, SMS, Slack, webhook, RSS hoặc Atom.

Hai trang không hiển thị máy chủ, vùng dữ liệu hay kiến trúc bên trong; khách chỉ thấy tên tính năng họ dùng.

Nên đo gì trên website nhỏ?

Website nhỏ nên đo ba thứ: khả dụng (trang có trả lời không), độ trễ (trả lời nhanh hay chậm) và lỗi (trả lời sai hoặc vỡ phía trình duyệt). Mỗi thứ cần một định nghĩa cụ thể trước khi đo.

Chỉ số	Đo thế nào	Ví dụ ngưỡng (giả định, tự chỉnh)
Khả dụng	Gọi trang chủ và trang đăng nhập định kỳ, coi mã thành công là "lên"	Hai lần lỗi liên tiếp là "gián đoạn"
Độ trễ	Thời gian từ lúc gọi tới lúc nhận trả lời	Chậm hơn vài giây là "chậm"
Lỗi máy chủ	Tỉ lệ yêu cầu trả lỗi	Tăng đột biến so với ngày thường
Lỗi trình duyệt	Lỗi JavaScript do trình duyệt khách báo về	Có loại lỗi mới xuất hiện
Luồng chính	Thanh toán, email, cơ sở dữ liệu có phản hồi không	Một luồng ngừng là "gián đoạn một phần"

Đừng đo quá nhiều: mỗi chỉ số phải có một người (thường là chính bạn) biết cần làm gì khi nó đỏ.

Vì sao phải kiểm tra từ bên ngoài?

Kiểm tra từ bên ngoài nghĩa là một hệ thống đặt ở nơi khác gọi vào website giống như khách thật, qua đúng tên miền và đường mạng công khai. Một bộ kiểm tra chạy trên chính máy chủ của website có điểm mù lớn: khi cả máy chủ ngừng, bộ kiểm tra cũng ngừng và không ai được báo. Kiểm tra nội bộ vẫn có giá trị để đo cơ sở dữ liệu, ổ đĩa hay sao lưu, nhưng câu hỏi "khách có vào được không" cần một điểm nhìn độc lập. Với website nhỏ, có thể dùng một dịch vụ giám sát bên ngoài có gói miễn phí, hoặc một máy khác của bạn chạy lệnh kiểm tra định kỳ; chúng tôi chưa so sánh và chưa kiểm chứng giá các dịch vụ này nên không nêu tên hay số liệu. Điều cần kiểm tra khi chọn: tần suất kiểm tra, số điểm kiểm tra, kênh cảnh báo, và việc dịch vụ có cần bạn mở thêm quyền truy cập vào máy chủ hay không.

Đặt ngưỡng cảnh báo thế nào để không bị báo động giả?

Ngưỡng cảnh báo tốt là ngưỡng khiến bạn hành động mỗi lần nhận tin, không phải ngưỡng khiến bạn tắt thông báo sau một tuần. Ba quy tắc thực dụng:

1. Kiểm tra lại trước khi báo: một lần lỗi có thể chỉ là mạng chập chờn; chờ vài chục giây và thử lại, lỗi lần hai mới báo.
2. Báo một lần khi hỏng, một lần khi hồi phục: tin hồi phục nên ghi thời gian gián đoạn, để sau này bạn có số liệu thật về sự cố.
3. Tách "chậm" khỏi "hỏng": chậm là cảnh báo vàng để xem sau, hỏng là cảnh báo đỏ cần xử lý ngay.

Gửi cảnh báo qua kênh bạn thật sự đọc, ví dụ một Telegram bot hoặc webhook vào luồng tự động của bạn, và đặt kênh dự phòng nếu kênh chính phụ thuộc vào chính website.

Viết thông báo sự cố trung thực ra sao?

Thông báo sự cố trung thực nói điều bạn biết, điều bạn chưa biết, và khi nào bạn sẽ cập nhật tiếp. Một mẫu bốn bước, tương tự cách các status page lớn chia cập nhật:

1. Đang điều tra: "Một số người không đăng nhập được từ 9 giờ 10. Chúng tôi đang kiểm tra, cập nhật sau 30 phút."
2. Đã xác định: nêu phần bị ảnh hưởng và việc khách nên làm tạm thời.
3. Đang theo dõi: đã khắc phục, đang xem có tái diễn không.
4. Đã khắc phục: thời gian gián đoạn, ảnh hưởng, và việc bạn làm để không lặp lại.

Không ghi "mọi thứ bình thường" khi chưa chắc, không đổ lỗi chung chung cho "nhà cung cấp", không xoá sự cố cũ khỏi lịch sử. Nếu có dữ liệu khách bị ảnh hưởng, nói rõ phạm vi và tham khảo nghĩa vụ pháp lý (không phải tư vấn pháp lý).

Điều gì không nên công khai trên status page?

Status page không nên công khai bất cứ chi tiết nào giúp người ngoài tấn công hệ thống: địa chỉ máy chủ, cổng, phiên bản phần mềm, tên dịch vụ nội bộ, cấu trúc mạng, thông báo lỗi gốc hay tên nhà cung cấp hạ tầng riêng. Khách chỉ cần tên tính năng họ dùng và trạng thái. Chi tiết kỹ thuật để ở trang quản trị có đăng nhập. Xem thêm 5 quy tắc bảo mật dữ liệu kinh doanh khi dùng AI.

Kinh nghiệm của OPCAIOS

OPCAIOS có một trang /status công khai và một trang "Sức khoẻ hệ thống" trong khu quản trị. Ở mức khái niệm:

1. Trang công khai chỉ có bốn nhóm: website, đăng nhập và khoá học, thanh toán chuyển khoản, email. Mỗi nhóm chỉ hiện "đang hoạt động", "đang gián đoạn" hoặc "chưa mở", không có chi tiết cấu hình. Trang tự kiểm tra lại tối đa mỗi phút một lần và ghi giờ kiểm tra.
2. Trang nội bộ đo nhiều hơn: thời gian phản hồi của website qua đường công khai, cơ sở dữ liệu, tình trạng sao lưu, ổ đĩa, bộ nhớ, lỗi JavaScript trình duyệt khách báo về trong 24 giờ, và tốc độ tải thật của người xem.
3. Cảnh báo mỗi 5 phút: website, trang khoá học và cơ sở dữ liệu được kiểm tra; lỗi được kiểm tra lại sau khoảng 20 giây rồi mới báo; một tin khi hỏng, một tin khi chạy lại kèm số phút gián đoạn; phản hồi chậm hơn 2,5 giây bị đánh dấu "chậm" trên trang nội bộ.
4. Triển khai không gián đoạn: khi build bản mới, một bản dự phòng của website tiếp tục phục vụ khách; build lỗi thì bản đang chạy giữ nguyên. Theo ghi chú dự án, trong một lần đo khi triển khai toàn bộ, hơn 1.200 yêu cầu gửi vào đều trả lời thành công.

Giới hạn chúng tôi biết: bộ kiểm tra chạy trên chính máy chủ của website, nên khi cả máy chủ ngừng sẽ không có cảnh báo; chúng tôi chưa dùng giám sát độc lập từ bên ngoài. Dòng "Website" trên trang công khai luôn xanh khi trang tải được, nên không phản ánh lúc website sập hẳn. Trang công khai chưa có lịch sử 90 ngày, lịch sử sự cố hay kênh nhận tin. Đây là việc nên làm tiếp, và là một phần của kế hoạch rút phích cắm khi công cụ AI tăng giá hoặc sập: biết sớm thứ gì hỏng mới chuyển sang phương án dự phòng kịp. Xem thêm 10 bài học khi để tác tử AI xây và vận hành website.

Câu hỏi thường gặp

Website nhỏ có nên công khai status page không?

Nên, nếu khách đã trả tiền và phụ thuộc vào website để đăng nhập, học, thanh toán hay đặt lịch. Status page giảm số tin nhắn hỏi khi có sự cố và cho thấy bạn đã biết. Nếu website chỉ có bài viết, công khai status page ít giá trị; nên ưu tiên giám sát và cảnh báo cho chính bạn trước. Dù công khai hay không, trang chỉ nên hiện tên tính năng và trạng thái, không hiện chi tiết hạ tầng.

Status page nên kiểm tra bao lâu một lần?

Với website nhỏ, kiểm tra vài phút một lần thường đủ để biết sự cố trước khi nhiều khách gặp phải. Kiểm tra dày hơn tạo thêm tải và thêm cảnh báo giả mà không giúp bạn sửa nhanh hơn khi bạn làm một mình. Quan trọng hơn tần suất là kiểm tra lại trước khi báo, để một lần mạng chập chờn không đánh thức bạn lúc nửa đêm, và kiểm tra từ một nơi nằm ngoài máy chủ của website.

Uptime 99,9% có ý nghĩa gì với website nhỏ?

Uptime là tỉ lệ thời gian website trả lời được trong một khoảng thời gian. Tính đơn giản, 99,9% trong 30 ngày tương ứng khoảng 43 phút gián đoạn. Với website nhỏ, đừng hứa con số uptime nếu chưa đo được bằng giám sát độc lập trong nhiều tháng. Hãy đo trước, công bố lịch sử thật sau, và nếu đặt cam kết với khách thì ghi rõ cách tính, cách bồi hoàn và các trường hợp loại trừ.

Có nên tự làm status page hay dùng dịch vụ có sẵn?

Tự làm hợp khi bạn muốn trang hiển thị đúng các nhóm tính năng của mình và đã có dữ liệu kiểm tra sẵn. Dịch vụ có sẵn hợp khi bạn cần lịch sử sự cố, kênh đăng ký nhận tin và điểm kiểm tra bên ngoài mà không muốn tự xây. Điểm cần lưu ý: status page tự làm chạy trên cùng máy chủ sẽ sập cùng website, nên phần kiểm tra và thông báo khẩn nên có một đường ngoài máy chủ đó.

Bắt đầu từ đâu nếu chưa có gì?

Liệt kê ba đến năm tính năng khách dùng nhiều nhất, đặt một kiểm tra định kỳ từ bên ngoài cho trang chủ và trang đăng nhập, gửi cảnh báo vào kênh bạn đọc hằng ngày, rồi soạn sẵn mẫu thông báo sự cố bốn bước. Khi đã có vài tuần dữ liệu, mới làm trang công khai. Nếu muốn học cách dùng AI và công cụ tự động để giám sát, cảnh báo và vận hành website một mình, xem khoá đào tạo ứng dụng AI của OPCAIOS.

Nguồn: status.claude.com và githubstatus.com (chỉ các thành phần, nhãn trạng thái, lịch sử 90 ngày và kênh nhận tin hiển thị trên trang), đọc ngày 25/10/2026. Chưa kiểm chứng tên, giá hay tính năng của các dịch vụ giám sát bên ngoài; ngưỡng trong bảng là ví dụ giả định. Kinh nghiệm là của OPCAIOS.