Cách tạo trang trạng thái (status page): thành phần, sự cố và kiểm tra uptime

Trang trạng thái cho người dùng biết, ở một chỗ duy nhất, dịch vụ của bạn có đang hoạt động bình thường hay không. Để tạo một trang như vậy, bạn cần danh sách các thành phần (trang web, API, thanh toán, gửi email), trạng thái hiện tại của từng thành phần, các sự cố kèm cập nhật có mốc thời gian, lịch sử sự cố đã qua và, nếu muốn, chức năng đăng ký để người dùng được báo tin mà không cần tự kiểm tra. Bản thân trang thì đơn giản. Quyết định quan trọng nhất là nơi đặt nó: trang trạng thái phải vẫn chạy khi app của bạn bị lỗi, nên không được dùng chung hosting, cơ sở dữ liệu hay quy trình triển khai với thứ mà nó báo cáo.

Trang trạng thái dùng để làm gì

Khi có sự cố, người dùng muốn biết ba điều: có phải chỉ mình tôi bị không, bên bạn đã biết chưa, và khi nào thì sửa xong. Trang trạng thái trả lời cả ba mà không phải nhận hàng loạt yêu cầu hỗ trợ. Nó cũng xây dựng niềm tin theo thời gian, vì lịch sử sự cố công khai với những bản tường thuật thẳng thắn cho thấy cách bạn xử lý vấn đề.

Đây không phải là nhật ký thay đổi. Tính năng mới thuộc về trang changelog; sự cố và bảo trì thì đưa lên đây.

Trang cần có gì

Dữ liệu

Trạng thái thành phần thường là một danh sách cố định ngắn: Hoạt động bình thường, Hiệu năng suy giảm, Gián đoạn một phần, Gián đoạn nghiêm trọng, Đang bảo trì.

Các trang

• Trang trạng thái công khai: một banner tổng quan (“Mọi hệ thống hoạt động bình thường” hoặc trạng thái xấu nhất hiện tại), từng thành phần kèm trạng thái, sự cố đang diễn ra kèm các cập nhật, lịch bảo trì sắp tới và dải lịch sử 90 ngày nếu bạn có dữ liệu kiểm tra.
• Trang sự cố: toàn bộ dòng thời gian cập nhật của một sự cố, có URL riêng để bộ phận hỗ trợ có thể gửi link.
• Lịch sử: các sự cố đã qua, nhóm theo tháng.
• Đăng ký: đăng ký bằng email có bước xác nhận và tùy chọn theo từng thành phần.
• Quản trị: tạo sự cố, đăng cập nhật, thay đổi trạng thái thành phần, lên lịch bảo trì.

Phân quyền

Công chúng xem được mọi nội dung đã đăng. Chỉ đội của bạn được đăng nội dung. Nếu có thể, hãy tách đăng nhập trang quản trị khỏi hệ thống đăng nhập của app chính, để khi nhà cung cấp xác thực gặp sự cố thì bạn vẫn vào được trang trạng thái của chính mình.

Quyết định then chốt: giữ cho trang độc lập

Đây là chỗ phần lớn các trang trạng thái tự làm bị hỏng. Nếu trang trạng thái của bạn:

• chạy trên cùng máy chủ hoặc cùng tài khoản hosting với app,
• đọc từ cùng cơ sở dữ liệu,
• nằm sau cùng cấu hình tên miền hoặc CDN,
• hoặc được triển khai bằng cùng quy trình,

thì nhiều sự cố sẽ làm nó sập theo, đúng lúc người dùng cần nó nhất. Các bước thực tế:

• Hosting riêng. Một dự án hoặc nhà cung cấp khác với app chính.
• Subdomain riêng, như status.example.com, trỏ DNS riêng. Xem cách hoạt động của tên miền và DNS.
• Dữ liệu riêng. Sự cố được lưu trong bộ nhớ của chính trang trạng thái, không nằm trong cơ sở dữ liệu của app.
• Phương án dự phòng tĩnh. Một số đội làm trang công khai dạng tĩnh và dựng lại mỗi khi có cập nhật, nên gần như không có gì để hỏng.

Cập nhật thủ công hay kiểm tra tự động

Thủ công (nên bắt đầu từ đây)

Đội của bạn đăng sự cố và đổi trạng thái thành phần bằng tay từ trang quản trị. Đây là cách nhiều trang trạng thái vận hành trong thực tế, vì một đánh giá của con người (“thanh toán bằng một số loại thẻ đang chậm”) hữu ích hơn một chấm đỏ tự động.

Để biết sự cố nhanh, hãy dùng một dịch vụ giám sát uptime bên ngoài, kiểm tra app của bạn khoảng mỗi phút và cảnh báo qua email, SMS hoặc chat. Nhiều dịch vụ giám sát có gói miễn phí.

Tự động

Tự động nghĩa là có thứ gì đó kiểm tra từng thành phần theo lịch và cập nhật trạng thái. Điều này cần mã chạy định kỳ, từ bên ngoài hạ tầng app chính. Hai mẫu phổ biến:

• Một dịch vụ giám sát bên ngoài gọi trang trạng thái qua webhook khi một kiểm tra thất bại hoặc hồi phục, và trang trạng thái cập nhật thành phần đó.
• Một tác vụ định kỳ trên chính hosting của trang trạng thái, ping từng thành phần và ghi lại kết quả. Hãy kiểm tra hosting của bạn hỗ trợ tác vụ định kỳ như thế nào trước khi phụ thuộc vào nó; hướng dẫn chạy tác vụ nền giải thích các lựa chọn.

Thay đổi tự động có thể bị nhấp nháy (lên, xuống, lên) khi mạng chậm. Hãy yêu cầu hai hoặc ba lần kiểm tra thất bại liên tiếp trước khi đổi trạng thái, và để một người xác nhận trước khi công bố sự cố nghiêm trọng.

Viết cập nhật sự cố

• Đăng sớm. “Chúng tôi đang điều tra báo cáo về lỗi đăng nhập” đăng trong vài phút tốt hơn một thông điệp hoàn hảo sau một giờ.
• Nói rõ người dùng thấy gì, không phải điều gì hỏng về mặt nội bộ.
• Hứa thời điểm cập nhật tiếp theo, và giữ lời.
• Kết thúc bằng bản tóm tắt ngắn khi đã xử lý xong: chuyện gì đã xảy ra, kéo dài bao lâu, bạn sẽ thay đổi gì.

Prompt đầu tiên hiệu quả

Hãy tạo một trang trạng thái độc lập cho app Parcelio của chúng tôi, lưu trên hosting riêng tại status.parcelio.com. Các thành phần: Website, Tracking API, Notifications, Payments, mỗi thành phần có một trong các trạng thái Hoạt động bình thường, Hiệu năng suy giảm, Gián đoạn một phần, Gián đoạn nghiêm trọng hoặc Đang bảo trì. Trang công khai hiển thị banner tổng quan theo trạng thái xấu nhất hiện tại, từng thành phần kèm trạng thái, các sự cố đang diễn ra với cập nhật có mốc thời gian, mới nhất lên đầu, lịch bảo trì sắp tới và danh sách sự cố đã qua theo tháng. Mỗi sự cố có trang riêng. Thêm trang quản trị có mật khẩu để tạo sự cố (tiêu đề, mức ảnh hưởng, thành phần bị ảnh hưởng), đăng cập nhật (nội dung và trạng thái: Đang điều tra, Đã xác định, Đang theo dõi, Đã xử lý), đổi trạng thái thành phần và lên lịch bảo trì. Thêm endpoint POST /api/check-result nhận tên thành phần và up/down từ một dịch vụ giám sát bên ngoài, được bảo vệ bằng secret token, và chỉ đánh dấu một thành phần là Hiệu năng suy giảm sau ba lần down liên tiếp. Lưu mọi thứ trong cơ sở dữ liệu riêng của app này. Thiết kế đơn giản, điềm tĩnh, tải nhanh trên điện thoại.

Các bước xây dựng

1. Trang công khai và trang quản trị với sự cố nhập tay. Chỉ riêng việc này đã là một trang trạng thái hoạt động.
2. Lưu trên hosting riêng và trỏ subdomain về đó.
3. Trang sự cố và lịch sử.
4. Cửa sổ bảo trì.
5. Đăng ký nhận thông báo. Đăng ký email xác nhận hai bước và thông báo khi có sự cố hoặc cập nhật mới. Email cần một nhà cung cấp; xem cách gửi email từ app.
6. Webhook giám sát nếu bạn muốn thay đổi trạng thái tự động.
7. Diễn tập. Tạo một sự cố giả, đăng cập nhật, đánh dấu đã xử lý, kiểm tra email gửi đi, rồi xóa.

Lỗi thường gặp

• Lưu chung với app. Đây là lỗi phổ biến nhất và nghiêm trọng nhất.
• Trang luôn ghi “Mọi hệ thống hoạt động bình thường”. Nếu không bao giờ hiện vấn đề, người dùng sẽ thôi tin tưởng.
• Không có mốc thời gian hoặc múi giờ. Luôn hiển thị giờ kèm múi giờ.
• Dựa vào đăng nhập của app chính cho trang quản trị.
• Im lặng giữa các cập nhật. “Chưa có thay đổi, chúng tôi vẫn đang xử lý” cũng là một cập nhật hợp lệ.
• Trạng thái tự động bị nhấp nháy. Hãy yêu cầu nhiều lần thất bại lặp lại trước khi đổi trạng thái.

Khi nào dịch vụ trang trạng thái có sẵn là lựa chọn tốt hơn

Các dịch vụ trang trạng thái có sẵn được xây dựng để giải quyết bài toán độc lập: chúng chạy trên hạ tầng riêng, xử lý thông báo cho người đăng ký qua email và SMS, và thường có sẵn chức năng giám sát cùng tích hợp với các công cụ xử lý sự cố. Nếu uptime là một phần giá trị bạn bán cho khách hàng, hoặc bạn có nghĩa vụ hợp đồng phải báo cáo sự cố, một dịch vụ chuyên dụng thường đáng chi phí. Nhiều dịch vụ có gói miễn phí hoặc giá thấp cho đội nhỏ, nên hãy kiểm tra trước khi tự xây.

Hãy tự xây khi bạn muốn kiểm soát đầy đủ thiết kế và cách diễn đạt, khi nhu cầu đơn giản (vài thành phần, cập nhật thủ công), hoặc khi trang trạng thái là một phần của sản phẩm bạn làm cho người khác.

Xây dựng với Mythex

Trên Mythex, bạn có thể tạo trang trạng thái như một dự án riêng, tách khỏi app chính, nhờ đó có hosting riêng và cơ sở dữ liệu riêng. Mô tả yêu cầu trong chat, kiểm tra trong bản xem trước trực tiếp, rồi xuất bản và kết nối một subdomain như status.tenmiencuaban.com (tên miền tùy chỉnh dùng trên gói Pro). Lưu ý rằng các app Mythex đã xuất bản và cơ sở dữ liệu của chúng sẽ ngủ khi không dùng và thức dậy ở lần truy cập tiếp theo, nên lần tải đầu tiên sau một thời gian yên ắng có thể chậm hơn; một trang đơn giản và nhẹ sẽ giúp ích.

Mythex chưa ghi chép tài liệu về tác vụ định kỳ, nên với kiểm tra tự động hãy dùng một dịch vụ giám sát uptime bên ngoài gọi một endpoint webhook trong trang trạng thái của bạn (xem công thức webhook). Email thông báo cho người đăng ký đi qua nhà cung cấp email của bạn, với khóa được lưu làm secret của dự án (công thức gửi email).

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