Ngày 31 tháng 1 năm 2017, GitLab gặp một trong những sự cố vận hành nổi tiếng nhất trong lịch sử các dịch vụ SaaS. Trong lúc xử lý sự cố spam, một kỹ sư vận hành đã vô tình chạy nhầm lệnh xóa trên production database, làm mất hàng trăm gigabyte dữ liệu. GitLab.com bị gián đoạn hơn 18 giờ, và công ty phải khôi phục từ bản snapshot cũ hơn 6 giờ.
Chuyện gì đã xảy ra?
GitLab khi đó đang gặp tình trạng spam accounts và sự cố trong replication của database. Một kỹ sư trực tiếp chạy lệnh trên production để dọn dữ liệu, nhưng thay vì xóa theo mục tiêu, lệnh đã xóa cả bảng chính. Do backup tự động không hoạt động như mong đợi, họ buộc phải khôi phục từ snapshot thủ công gần nhất.
Timeline sự cố
- 31/01/2017 – 18:00 UTC: GitLab phát hiện database production bị quá tải vì spam và replication lỗi.
- 31/01 – 23:27 UTC: Một kỹ sư vận hành chạy lệnh thủ công để dọn dẹp dữ liệu.
- 31/01 – 23:30 UTC: Lệnh sai khiến 300 GB dữ liệu production bị xóa nhầm.
- 01/02 – 00:00 UTC: GitLab.com gián đoạn, toàn bộ dịch vụ phụ thuộc database không thể hoạt động.
- 01/02 – 06:00 UTC: Sau nhiều nỗ lực khôi phục không thành công, GitLab xác nhận phải rollback về snapshot cũ hơn 6 giờ.
- 01/02 – 18:00 UTC: Dịch vụ GitLab.com dần trở lại, downtime tổng cộng hơn 18 giờ.
Ảnh hưởng
- GitLab.com downtime 18 giờ, ảnh hưởng tới hàng triệu developer và dự án sử dụng dịch vụ.
- Khoảng 6 giờ dữ liệu (issue, merge request, comment) bị mất vĩnh viễn.
- Uy tín của GitLab bị ảnh hưởng nặng, nhất là khi cạnh tranh trực tiếp với GitHub thời điểm đó.
Cách tổ chức khắc phục sự cố
- Khôi phục từ backup thủ công: Vì backup tự động không hoạt động như mong đợi, GitLab phải dựa vào snapshot thủ công cũ hơn 6 giờ.
- Minh bạch toàn bộ: GitLab chọn cách công khai toàn bộ quá trình ứng cứu, từ log kỹ sư đến livestream trên YouTube cho cộng đồng theo dõi.
- Rà soát quy trình vận hành: Sau sự cố, GitLab bổ sung nhiều lớp kiểm soát trước khi cho phép lệnh xóa chạy trên production.
- Cải thiện backup: Thiết kế lại cơ chế backup và test định kỳ để đảm bảo dữ liệu có thể khôi phục ở bất kỳ thời điểm nào.
- Học hỏi từ thất bại: GitLab biến postmortem này thành tài liệu tham khảo cho cả cộng đồng về rủi ro vận hành thủ công.
Phản ứng từ cộng đồng
- Cộng đồng developer vừa hoảng hốt vừa… thán phục: hiếm có công ty nào dám livestream toàn bộ quá trình khắc phục sự cố production.
- Nhiều chuyên gia bảo mật coi đây là case study kinh điển về tầm quan trọng của backup và quy trình “test your backup”.
- Sự cố được giảng dạy trong nhiều khóa học SRE/DevOps như ví dụ điển hình về hậu quả của thao tác thủ công không có guardrail.
DevOps VietNam facts: Sự cố GitLab 2017 nhắc nhở rằng, backup không chỉ để tồn tại trên giấy tờ mà phải luôn được test. Và quan trọng hơn trong vận hành hệ thống, một lệnh thủ công sai có thể làm cả dịch vụ toàn cầu sập trong một đêm.
