Инженер ја избриша продукциската база на податоци на GitLab. 300 гигабајти.
31 јануари 2017 година, 23:27 UTC: Инженер на GitLab, борејќи се со скршена реплика на крајот од долгата ноќ, го отстранува директориумот за податоци на PostgreSQL на db1 наместо на db2.
31 јануари 2017 година, 23:27 UTC: Инженер на GitLab, борејќи се со скршена реплика на крајот од долгата ноќ, го отстранува директориумот за податоци на PostgreSQL на db1 наместо на db2. db1 е примарниот. Околу 300 GB од базата на податоци на GitLab.com исчезнуваат за секунда или две, а од петте механизми за резервна копија и репликација, ниту еден не работи. Пост-анализа: временската рамка од скокот на спам до погрешното име на хост, зошто pg_basebackup изгледаше заглавено, зошто pg_dump тивко откажуваше (бинарни датотеки 9.2 на база на податоци 9.6, е-поштата за грешките одбиени од DMARC), 18-часовното враќање од 6-часовна снимка од staging пренесувана во живо на YouTube и кој навистина е виновен. Пресуда за одговорот: SHIP IT.
Прочитајте го пишаното издание (англиски) ↗
Што покрива ова видео
- 31 јануари 2017 година: rm -Rvf на директориумот за податоци на примарниот; ~300 GB избришани, останати 4,5 GB
- 5 од 5 резервни копии откажуваат: празен S3 bucket (несовпаѓање на верзиите на pg_dump), без Azure снимки на базата на податоци, избришана реплика, дневна LVM копија без вебхукови
- 1 февруари, 18:00 UTC: GitLab.com се врати од 6-часовна рачна снимка; документ во живо, пренос во живо, пост-анализа без вина со листа на поправки
Преведен транскрипт
Преведено од оригиналната англиска нарација. Достапното аудио и наслови се контролирани од YouTube.
0:00 Инженер во GitLab извршува rm -rf на погрешен сервер за база на податоци, и триста гигабајти од GitLab.com исчезнуваат за секунда или две, отприлика колку што е потребно да се прочита име на хост. 31 јануари 2017 година, 23:27 часот UTC. GitLab твитува дека случајно избришал продукциски податоци, ги отвора своите белешки за инциденти на интернет и го пренесува обновувањето на YouTube, вториот најгледан пренос во живо на платформата. Следниот ден, писмено: од пет техники за резервна копија,
0:25 ниту една не работи сигурно. Како се случува, зошто е можно и кој навистина е виновен. Ова е The Daily Diff, пост-анализа. 17:20 часот: инженер прави снимка од продукцијата за да тестира балансер на оптоварување во staging. 19:00 часот: спам ја бомбардира базата на податоци, плус работа која насилно брише вработен во GitLab, трол пријавен за злоупотреба. 23:00 часот: репликата заостанува толку многу што примарниот веќе го отфрлил
0:48 логот што ѝ е потребен; единственото решение е да се избрише репликата и повторно да се копира примарниот повторно. pg_basebackup виси без излез. Всушност чека, тивко, на примарниот; никој не знае дека, и прирачникот не го вели тоа. Инженерот, кој требаше да се одјави во единаесет, одлучува дека празниот директориум за податоци е проблемот и го отстранува. На db1. Примарниот. Забележува секунда или две подоцна; од приближно триста гигабајти,
1:11 остануваат 4,5. Резервните копии. Еден: pg_dump во S3, дневно. Кофата е празна. Cron job-от работи на сервер за апликации без база на податоци, па пакетот избира бинарни датотеки на PostgreSQL 9.2 за база на податоци 9.6, откажува и испраќа е-пошта за откажувањето, која се одбива поради недостасувачки DMARC. Два: Azure диск снимки, овозможени за серверите за датотеки, не за базите на податоци.
1:32 Три: репликата, намерно избришана пред еден час. Четири: дневната снимка, стара 24 часа, секој вебхук отстранет од страна на синхронизацијата на staging. Пет: рачната снимка од 17:20, за неповрзан тест. Таа победува. Враќањето значи копирање на дискот од staging назад во продукција преку евтиниот Azure складиште со шеесет мегабити во секунда: осумнаесет часа. GitLab.com се враќа на 1 февруари во шест часот попладне UTC, шест часа постари податоци.
1:58 git blame: две имиња на хостови со еден знак разлика и пет системи за резервна копија од кои никој никогаш не направил враќање. Не инженерот. Пост-анализата, потпишана од извршниот директор, го задржува анонимен, ја обојува продукциската наредба во црвено и ѝ дава сопственик на трајноста на податоците, бидејќи досега немаше. Опсег на оштетување: осумнаесет часа застој, шест часа изгубени податоци, приближно пет илјади проекти, пет илјади коментари,
2:18 седумстотини нови корисници и пет илјади луѓе кои гледаат лента за напредок. Hacker News му дава на документот во живо 1.162 поени и цитира една линија назад кон нив: од пет резервни копии, ниту една. Пресуда, пост-анализа: SHIP IT, на одговорот. Тие го водат инцидентот јавно, го обвинуваат процесот и ја објавуваат листата за поправки со броеви на проблеми. Акција за понеделник: вратете резервна копија. Ако никогаш не сте ја вратиле, ја немате.
2:42 Испратете ми го инцидентот за кој сè уште не ви е дозволено да зборувате, во коментарите или на the daily diff dot dev. И тоа е денешната разлика. Јас сум Нико од Axrisi. Спојувајте одговорно.
Извори
- 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
