How we built Status Page

GitLab · 2020 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc

Bài giới thiệu một tính năng của sản phẩm GitLab (Ultimate), nhưng khách hàng đầu tiên là chính đội vận hành GitLab.com; ghi chú này giữ phần thiết kế.

Bối cảnh

• Sự cố của GitLab.com được xử lý trong issue của một project công khai; người trực tự đăng cập nhật lên status.gitlab.com mỗi 15 phút. Người xử lý mất thời gian đổi công cụ và chép lại thông tin.
• Dùng project công khai cho sự cố có hại: tải dồn vào instance đúng lúc khó khăn, chi phí cao, không xem được cập nhật khi chính GitLab sập, và thông tin nhạy cảm trong thảo luận lộ ra trong khi lỗ hổng chưa vá.

Thay đổi chính

• Yêu cầu rút từ đội nội bộ: cập nhật ở một nơi (issue sự cố), chọn được bình luận nào công khai, hiện đủ loại nội dung (ảnh, chart nhúng).
• Làm spike trước; các status page mã nguồn mở không đáp ứng đủ nên tự viết. Cân năm cách lấy dữ liệu (webhook do người dùng dựng, alert từ Alertmanager, status page tự giám sát service, đẩy markdown/gọi API tay, CI job theo lịch) và bỏ cả năm vì cần thao tác tay, tốn tài nguyên CI, hoặc quá phức tạp.
• Chọn: background job chuyển mô tả issue và các bình luận được đánh dấu công khai thành JSON, đẩy lên object storage. Frontend (VueJS, dùng thư viện UI của GitLab) là app tĩnh riêng, repo riêng, giấy phép MIT, đọc các file JSON đó.
• Chỉ hỗ trợ Amazon S3: GitLab.com chạy trên Google Cloud, nên trang trạng thái phải sống được khi Google Cloud (và GitLab.com) sập.

Vì sao

• Theo GitLab: không over-engineer, và người xem thấy cập nhật gần như ngay khi người trực viết vào issue.

Bài học cho SWE

• Kênh báo sự cố không được phụ thuộc vào hệ đang sự cố: khác nhà cung cấp cloud, nội dung tĩnh, không gọi về backend chính.
• Cho người xử lý viết một lần ở chỗ họ đang làm việc, còn việc phát hành ra ngoài là một bước sinh tự động có lọc.

Liên quan

• Xử lý sự cố và on-call
• Cloudflare 2025 (phụ thuộc cứng lúc sự cố) · GitLab 2017 · Dropbox 2021