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



