한 엔지니어가 GitLab의 프로덕션 데이터베이스 300GB를 삭제했습니다.

이 동영상에서 다루는 내용

• 2017년 1월 31일: 기본 데이터 디렉토리에 rm -Rvf 실행; ~300GB 삭제, 4.5GB 남음
• 5개 중 5개 백업 실패: 빈 S3 버킷(pg_dump 버전 불일치), DB에 Azure 스냅샷 없음, 삭제된 복제본, 웹훅 없는 일일 LVM 복사본
• 2월 1일, 18:00 UTC: 6시간 전 수동 스냅샷에서 GitLab.com 복구; 라이브 문서, 라이브 스트림, 수정 목록이 포함된 비난 없는 사후 분석

번역된 스크립트

원래 영어 내레이션에서 번역되었습니다. 사용 가능한 오디오 및 캡션은 YouTube에서 제어합니다.

0:00 GitLab의 한 엔지니어가 잘못된 데이터베이스 서버에 rm -rf를 실행하고, GitLab.com의 300기가바이트가 1~2초 만에 사라집니다. 호스트 이름을 읽는 데 걸리는 시간 정도죠. 2017년 1월 31일, 오후 11시 27분 UTC. GitLab은 프로덕션 데이터를 실수로 삭제했다고 트윗하고, 인터넷에 사고 기록을 공개하고, YouTube에서 복구 과정을 스트리밍합니다. 플랫폼에서 두 번째로 인기 있는 라이브 스트림이었죠. 다음 날 서면으로: 5가지 백업 기술 중,

0:25 어느 하나도 안정적으로 작동하지 않았습니다. 어떻게 이런 일이 일어났고, 왜 가능했으며, 누가 실제로 비난받아야 하는지. 여기는 The Daily Diff, 사후 분석입니다. 오후 5시 20분: 한 엔지니어가 프로덕션을 스냅샷합니다. 스테이징에서 로드 밸런서를 테스트하기 위해서요. 오후 7시: 스팸이 데이터베이스를 강타하고, 트롤이 악용으로 신고한 GitLab 직원을 하드 삭제하는 작업까지 겹칩니다. 오후 11시: 복제본이 너무 뒤쳐져서 기본 서버가 이미 필요한

0:48 로그를 폐기했습니다. 유일한 해결책은 복제본을 지우고 기본 서버를 다시 복사하는 것입니다. pg_basebackup은 아무런 출력 없이 멈춥니다. 실제로는 기본 서버를 조용히 기다리고 있는 것이었습니다. 아무도 그걸 몰랐고, 실행 지침서에도 나와 있지 않았습니다. 오후 11시에 퇴근하려던 엔지니어는 빈 데이터 디렉토리가 문제라고 판단하고 삭제합니다. db1, 즉 기본 서버에서 말이죠. 1~2초 후에 그는 알아차립니다. 대략 300기가바이트 중,

1:11 4.5기가바이트만 남아 있었습니다. 백업은요? 하나: S3로의 pg_dump, 매일. 버킷은 비어 있습니다. 크론 작업은 데이터베이스가 없는 앱 서버에서 실행되므로, 패키지는 9.6 데이터베이스용 PostgreSQL 9.2 바이너리를 선택하고, 실패하며, 실패 이메일을 보냅니다. 이는 DMARC 누락으로 인해 반송됩니다. 둘: Azure 디스크 스냅샷, 파일 서버에는 활성화되어 있었지만, 데이터베이스에는 아니었습니다.

1:32 셋: 복제본, 한 시간 전 의도적으로 삭제되었습니다. 넷: 일일 스냅샷, 24시간 전 것이고, 스테이징 동기화로 인해 모든 웹훅이 제거되었습니다. 다섯: 오후 5시 20분 수동 스냅샷, 관련 없는 테스트용이었습니다. 이것이 성공합니다. 복구는 스테이징 디스크를 Azure의 저렴한 스토리지로 초당 60메가비트 속도로 프로덕션에 다시 복사하는 것을 의미했습니다. 18시간이 걸렸죠. GitLab.com은 2월 1일 오후 6시 UTC에 복구되었고, 데이터는 6시간 전의 것이었습니다.

1:58 git blame: 한 글자 차이 나는 두 호스트 이름, 그리고 아무도 복구해 본 적 없는 5가지 백업 시스템. 엔지니어의 잘못이 아닙니다. CEO가 서명한 사후 분석은 그의 신원을 익명으로 유지하고, 프로덕션 프롬프트를 빨간색으로 표시하며, 데이터 영속성 소유자를 지정합니다. 지금까지는 아무도 없었기 때문이죠. 영향 범위: 18시간 중단, 6시간 데이터 손실, 대략 5천 개의 프로젝트, 5천 개의 댓글,

2:18 7백 명의 새 사용자, 그리고 진행률 표시줄을 지켜보는 5천 명의 사람들. Hacker News는 라이브 문서에 1,162점을 주고 한 문장을 인용했습니다. 백업 5개 중, 작동하는 것은 없었다. 평결, 사후 분석: 대응에 대해선 SHIP IT. 그들은 사고를 공개적으로 처리하고, 프로세스를 비난하며, 문제 번호가 포함된 수정 목록을 게시합니다. 월요일 조치: 백업 복구. 백업을 복구해 본 적이 없다면, 백업이 없는 것입니다. 백업을 복구해 본 적이 없다면, 백업이 없는 것입니다.

2:42 아직 이야기할 수 없는 사고를 저에게 보내주세요. 댓글이나 daily diff.dev로요. 오늘의 차이점은 여기까지입니다. Axrisi의 Niko입니다. 책임감 있게 병합하세요.

출처

1. GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
2. GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
3. @gitlabstatus, "We accidentally deleted production data…"twitter.com
4. @gitlabstatus, emergency maintenance noticetwitter.com
5. Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
6. Hacker News, the postmortem thread (377 points)news.ycombinator.com