Інжынер выдаліў вытворчую базу дадзеных GitLab. 300 гігабайт.

Што ахоплівае гэта відэа

• 31 студзеня 2017 г.: rm -Rvf у каталогу дадзеных асноўнага сервера; выдалена ~300 ГБ, засталося 4.5 ГБ
• 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 UTC. 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, штодзённа. Кантэйнер пусты. Задача cron запускаецца на серверы прыкладанняў без базы дадзеных, таму пакет выбірае бінарныя файлы PostgreSQL 9.2 для базы дадзеных 9.6, церпіць няўдачу і адпраўляе электронныя лісты аб няўдачы, якія адхіляюцца з-за адсутнасці DMARC. Дзве: здымкі дыскаў Azure, уключаныя для файлавых сервераў, не для баз дадзеных.

1:32 Тры: рэпліка, наўмысна выдаленая гадзіну таму. Чатыры: штодзённы здымак, 24 гадзіны таму, кожны вэбхук выдалены з дапамогай сінхранізацыі тэставай асяроддзя. Пяць: ручны здымак з 17:20, для незвязанага тэсту. Гэты выйграе. Аднаўленне азначае капіраванне тэставага дыска назад у вытворчасць праз таннае сховішча Azure з хуткасцю шэсцьдзесят мегабіт у секунду: васемнаццаць гадзін. GitLab.com зноў працуе 1 лютага ў шэсць вечара UTC, на шэсць гадзін старэйшых дадзеных.

1:58 git blame: два імёны хостаў з розніцай у адзін сімвал і пяць сістэм рэзервовага капіравання, з якіх ніхто ніколі не аднаўляў. Ніколі не аднаўляў. Не інжынер. Постмортем, падпісаны генеральным дырэктарам, захоўвае яго ананімнасць, афарбоўвае вытворчую падказку ў чырвоны колер і прызначае ўладальніка для захавання дадзеных, таму што да гэтага часу яго не было. Радыус паражэння: васемнаццаць гадзін прастою, шэсць гадзін страчаных дадзеных, прыкладна пяць тысяч праектаў, пяць тысяч каментароў,

2:18 семсот новых карыстальнікаў і пяць тысяч чалавек, якія назіраюць за панэллю прагрэсу. Hacker News дае жывому дакументу 1,162 балы і цытуе адзін радок назад ім: з пяці рэзервовых копій — ніводнай. Вердыкт, постмортем: SHIP IT, адносна рэакцыі. Яны публічна вядуць інцыдэнт, вінавацяць працэс і публікуюць спіс выпраўленняў з нумарамі выпускаў. Панядзелак: аднавіць рэзервовую копію. Калі вы ніколі яе не аднаўлялі, у вас яе няма.

2:42 Дашліце мне інцыдэнт, пра які вам да гэтага часу не дазволена гаварыць, у каментарах або на thedailydiff.dev. І гэта ўвесь diff на сёння. Я Ніка з Axrisi. Аб'ядноўвайце адказна.

Крыніцы

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