Inženýr smazal produkční databázi GitLabu. 300 gigabajtů.

Co toto video pokrývá

• 31. ledna 2017: rm -Rvf v datovém adresáři primárního serveru; odstraněno ~300 GB, zbývá 4.5 GB
• 5 z 5 záloh selhalo: prázdný S3 bucket (nesoulad verzí pg_dump), žádné snímky Azure na DB, smazaná replika, denní LVM kopie bez webhooků
• 1. února, 18:00 UTC: GitLab.com je zpět z 6hodinového manuálního snímku; živý dokument, živý přenos, bezchybný postmortem se seznamem oprav

Přeložený přepis

Přeloženo z původního anglického vyprávění. Dostupné audio a titulky jsou řízeny YouTube.

0:00 Inženýr v GitLabu spustí rm -rf na nesprávném databázovém serveru, a tři sta gigabajtů GitLab dot com zmizí během vteřiny nebo dvou, přibližně tak dlouho, jako trvá přečtení názvu hostitele. 31. ledna 2017, 23:27 UTC. GitLab tweetuje, že omylem smazal produkční data, zpřístupní své poznámky k incidentu internetu a streamuje obnovu na YouTube, druhý největší živý přenos na platformě. Následující den, písemně: z pěti zálohovacích technik,

0:25 žádná nefunguje spolehlivě. Jak se to stane, proč je to možné a kdo za to skutečně nese vinu. Toto je The Daily Diff, postmortem. 17:20: inženýr pořídí snímek produkce k testování vyvažovače zátěže ve stagingu. 19:00: spam zatíží databázi, plus úloha tvrdě smaže zaměstnance GitLabu, kterého nahlásil troll za zneužívání. 23:00: replika se tak daleko opozdí, že primární server již zahodil

0:48 potřebný log; jediná oprava je smazat repliku a znovu zkopírovat primární server. pg_basebackup se zasekne bez výstupu. Ve skutečnosti tiše čeká na primární server; nikdo to neví, a příručka to neuvádí. Inženýr, který se měl odhlásit v jedenáct, se rozhodne, že prázdný datový adresář je problém a odstraní ho. Na db1. Primární server. Všimne si o vteřinu nebo dvě později; zhruba ze tří set gigabajtů,

1:11 zbývá 4.5. Zálohy. Jedna: pg_dump na S3, denně. Bucket je prázdný. Cron job běží na aplikačním serveru bez databáze, takže balíček vybere binární soubory PostgreSQL 9.2 pro databázi 9.6, selže a odešle e-mail o selhání, který se odrazí kvůli chybějícímu DMARC. Dva: snímky disků Azure, povolené pro souborové servery, nikoli databáze.

1:32 Tři: replika, úmyslně smazaná před hodinou. Čtyři: denní snímek, starý 24 hodin, všechny webhooky odstraněné synchronizací stagingu. Pět: manuální snímek z 17:20, pro nesouvisející test. Ten vyhraje. Obnovení znamená zkopírovat disk stagingu zpět do produkce přes levné úložiště Azure rychlostí šedesát megabitů za sekundu: osmnáct hodin. GitLab dot com je zpět 1. února v 18:00 UTC, o šest hodin starší data.

1:58 git blame: dva názvy hostitelů vzdálené o jeden znak a pět zálohovacích systémů, ze kterých nikdo nikdy neobnovoval. Ne inženýr. Postmortem, podepsaný generálním ředitelem, ho udržuje v anonymitě, obarví produkční výzvu červeně a přidělí vlastníka pro trvanlivost dat, protože dosud žádného neměla. Dosah výbuchu: osmnáct hodin mimo provoz, šest hodin dat pryč, přibližně pět tisíc projektů, pět tisíc komentářů,

2:18 sedm set nových uživatelů a pět tisíc lidí sledujících ukazatel průběhu. Hacker News dává živému dokumentu 1 162 bodů a cituje jeden řádek zpět na ně: z pěti záloh, žádná. Verdikt, postmortem: ship it, k reakci. Veřejně řeší incident, obviňují proces a zveřejňují seznam oprav s čísly problémů. Pondělní akce: obnovit zálohu. Pokud jste ji nikdy neobnovili, žádnou nemáte.

2:42 Pošlete mi incident, o kterém stále nesmíte mluvit, v komentářích, nebo na daily diff dot dev. A to je dnešní diff. Jsem Niko z Axrisi. Spojte se zodpovědně.

Zdroje

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