Một kỹ sư đã xóa cơ sở dữ liệu sản xuất của GitLab. 300 gigabyte.
Ngày 31 tháng 1 năm 2017, 23:27 UTC: một kỹ sư GitLab, đang cố gắng khắc phục sự cố bản sao bị hỏng vào cuối một đêm dài, đã xóa thư mục dữ liệu PostgreSQL trên db1 thay vì db2.
Ngày 31 tháng 1 năm 2017, 23:27 UTC: một kỹ sư GitLab, đang cố gắng khắc phục sự cố bản sao bị hỏng vào cuối một đêm dài, đã xóa thư mục dữ liệu PostgreSQL trên db1 thay vì db2. db1 là máy chủ chính. Khoảng 300 GB cơ sở dữ liệu của GitLab.com đã biến mất chỉ trong một hoặc hai giây, và trong số năm cơ chế sao lưu và nhân bản, không có cơ chế nào hoạt động. Báo cáo hậu sự cố: dòng thời gian từ việc tăng đột biến thư rác đến sai tên máy chủ, tại sao pg_basebackup có vẻ bị kẹt, tại sao pg_dump lại âm thầm thất bại (các tệp nhị phân 9.2 trên cơ sở dữ liệu 9.6, các email lỗi bị DMARC trả lại), việc khôi phục 18 giờ từ một ảnh chụp nhanh dàn dựng 6 giờ tuổi được phát trực tiếp trên YouTube, và ai thực sự phải chịu trách nhiệm. Đánh giá về phản ứng: SHIP IT.
Đọc phiên bản viết (tiếng Anh) ↗
Nội dung video này đề cập
- Ngày 31 tháng 1 năm 2017: rm -Rvf trên thư mục dữ liệu của máy chủ chính; ~300 GB đã bị xóa, còn lại 4.5 GB
- 5 trên 5 bản sao lưu thất bại: thùng S3 rỗng (không khớp phiên bản pg_dump), không có ảnh chụp nhanh Azure trên DB, bản sao bị xóa, bản sao LVM hàng ngày không có webhook
- Ngày 1 tháng 2, 18:00 UTC: GitLab.com đã hoạt động trở lại từ ảnh chụp nhanh thủ công 6 giờ tuổi; tài liệu trực tiếp, phát trực tiếp, báo cáo hậu sự cố không đổ lỗi kèm danh sách sửa lỗi
Bản ghi đã dịch
Được dịch từ lời tường thuật tiếng Anh gốc. Âm thanh và phụ đề có sẵn được điều khiển bởi YouTube.
0:00 Một kỹ sư tại GitLab chạy rm -rf trên máy chủ cơ sở dữ liệu sai, và ba trăm gigabyte dữ liệu của GitLab dot com biến mất trong một hoặc hai giây, khoảng thời gian cần để đọc một tên máy chủ. Ngày 31 tháng 1 năm 2017, 11:27 tối. UTC. GitLab tweet rằng họ đã vô tình xóa dữ liệu sản xuất, mở ghi chú sự cố của mình ra internet, và phát trực tiếp quá trình khôi phục trên YouTube, là luồng trực tiếp số hai trên nền tảng này. Ngày hôm sau, bằng văn bản: trong số năm kỹ thuật sao lưu,
0:25 không có kỹ thuật nào hoạt động đáng tin cậy. Nó xảy ra như thế nào, tại sao nó có thể xảy ra, và ai thực sự phải chịu trách nhiệm. Đây là The Daily Diff, báo cáo hậu sự cố. 5:20 chiều: một kỹ sư chụp ảnh nhanh sản xuất để kiểm tra bộ cân bằng tải trong môi trường staging. 7 giờ tối: thư rác tấn công cơ sở dữ liệu, cộng với một công việc xóa cứng một nhân viên GitLab mà một kẻ phá hoại đã báo cáo vì lạm dụng. 11 giờ tối: bản sao bị tụt lại quá xa đến nỗi máy chủ chính đã loại bỏ
0:48 nhật ký cần thiết; cách khắc phục duy nhất là xóa bản sao và sao chép máy chủ chính một lần nữa. pg_basebackup bị treo không có đầu ra. Nó thực sự đang chờ đợi, một cách âm thầm, máy chủ chính; không ai biết điều đó, và cuốn sổ tay không nói. Kỹ sư, người định đăng xuất lúc 11 giờ, quyết định thư mục dữ liệu trống là vấn đề và xóa nó. Trên db1. Máy chủ chính. Anh ấy nhận ra một hoặc hai giây sau; trong số khoảng ba trăm gigabyte,
1:11 còn lại 4.5. Các bản sao lưu. Một: pg_dump vào S3, hàng ngày. Thùng chứa trống. Công việc cron chạy trên một máy chủ ứng dụng không có cơ sở dữ liệu, vì vậy gói chọn các tệp nhị phân PostgreSQL 9.2 cho cơ sở dữ liệu 9.6, thất bại, và gửi email thông báo lỗi, bị trả lại vì thiếu DMARC. Hai: ảnh chụp nhanh đĩa Azure, được bật cho các máy chủ tệp, không phải cơ sở dữ liệu.
1:32 Ba: bản sao, đã bị xóa cố ý một giờ trước. Bốn: ảnh chụp nhanh hàng ngày, 24 giờ tuổi, mọi webhook bị loại bỏ bởi quá trình đồng bộ staging. Năm: ảnh chụp nhanh thủ công từ 5:20, cho một thử nghiệm không liên quan. Cái đó thắng. Việc khôi phục có nghĩa là sao chép đĩa staging trở lại sản xuất qua bộ lưu trữ giá rẻ của Azure ở tốc độ sáu mươi megabit mỗi giây: mười tám giờ. GitLab dot com hoạt động trở lại vào ngày 1 tháng 2 lúc 6 giờ chiều UTC, dữ liệu cũ hơn sáu giờ.
1:58 git blame: hai tên máy chủ chỉ cách nhau một ký tự, và năm hệ thống sao lưu không ai đã từng khôi phục từ đó. Không phải kỹ sư. Báo cáo hậu sự cố, được ký bởi CEO, giữ cho anh ấy ẩn danh, tô màu đỏ dấu nhắc sản xuất, và giao quyền sở hữu cho tính bền vững của dữ liệu, bởi vì cho đến nay nó chưa có. Phạm vi ảnh hưởng: mười tám giờ ngừng hoạt động, sáu giờ dữ liệu bị mất, khoảng năm nghìn dự án, năm nghìn bình luận,
2:18 bảy trăm người dùng mới, và năm nghìn người xem một thanh tiến trình. Hacker News cho tài liệu trực tiếp 1.162 điểm và trích dẫn một dòng ngược lại với họ: trong số năm bản sao lưu, không có bản nào. Phán quyết, hậu sự cố: SHIP IT, về phản ứng. Họ công khai sự cố, đổ lỗi cho quy trình, và công bố danh sách sửa lỗi với số vấn đề. Hành động vào thứ Hai: khôi phục một bản sao lưu. Nếu bạn chưa bao giờ khôi phục nó, bạn không có một bản nào.
2:42 Gửi cho tôi sự cố mà bạn vẫn không được phép nói về, trong phần bình luận, hoặc tại the daily diff dot dev. Và đó là sự khác biệt trong ngày hôm nay. Tôi là Niko từ Axrisi. Hợp nhất một cách có trách nhiệm.
Nguồn
- GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
- GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
- @gitlabstatus, "We accidentally deleted production data…"twitter.com
- @gitlabstatus, emergency maintenance noticetwitter.com
- Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
- Hacker News, the postmortem thread (377 points)news.ycombinator.com
