1047

Как один программист случайно уничтожил компанию одной строкой кода3

Серия Очумительные истории

Привет, Пикабу! Сегодня я расскажу вам историю, от которой у любого программиста волосы встанут дыбом. Это история о том, как одна маленькая ошибка привела к гигантским последствиям.

  1. Дело было в 2016 году. Главный герой - разработчик по имени Марвин (имя изменено), работавший в хостинг-провайдере Gitlab.

  2. Gitlab - это платформа для хранения исходного кода проектов, которой пользуются миллионы разработчиков по всему миру.

  3. У Gitlab случилась небольшая проблема с производительностью базы данных. Марвин решил её починить.

  4. Он собирался удалить временную базу данных на одном из серверов. Команда была простая: rm -rf /var/lib/postgresql/9.6/pg_xlog/*

  5. Но случилось страшное - Марвин случайно запустил эту команду НЕ на том сервере!

  6. Результат? 300 ГБ данных пользовательских проектов были моментально и безвозвратно удалены.

  7. Осознав ошибку, Марвин немедленно остановил процесс. Но было уже поздно - данные исчезли.

  8. Команда Gitlab бросилась восстанавливать данные из резервных копий. И тут выяснилось, что система резервного копирования... не работала последние 6 месяцев!

  9. 18 часов непрерывной работы, паники и стресса. Инженеры Gitlab пытались спасти то, что осталось.

  10. В итоге им удалось восстановить большую часть данных, но около 5000 проектов были потеряны навсегда.

  11. Gitlab проявила удивительную прозрачность в этой ситуации. Они вели прямую трансляцию процесса восстановления и открыто рассказали о случившемся.

  12. Несмотря на ошибку, Марвина не уволили. Компания признала, что проблема была в системе, а не в конкретном человеке.

Мораль истории:

  1. Всегда дважды (а лучше трижды) проверяйте, на каком сервере выполняете команды.

  2. Регулярно проверяйте работу системы резервного копирования.

  3. Ошибки случаются со всеми, даже с профессионалами.

  4. Прозрачность и честность могут спасти репутацию даже в самой сложной ситуации.

P.S. После этого случая Gitlab значительно улучшила свои системы безопасности и резервного копирования. А Марвин, говорят, до сих пор трижды проверяет каждую команду перед выполнением.

А у вас были случаи, когда маленькая ошибка приводила к большим последствиям? Расскажите в комментариях!

UPD уточнение: #comment_324862867

Рабочий бэкап сделанный за 6 часов

Они не теряли 5000 проектов навсегда, чё за выдуманная хрень, они потеряли изменения, комменты и тд сделанные в 5000 проектах в течение этих 6 часов

On January 31st 2017, we experienced a major service outage for one of our products, the online service GitLab.com. The outage was caused by an accidental removal of data from our primary database server.

This incident caused the GitLab.com service to be unavailable for many hours. We also lost some production data that we were eventually unable to recover. Specifically, we lost modifications to database data such as projects, comments, user accounts, issues and snippets, that took place between 17:20 and 00:00 UTC on January 31. Our best estimate is that it affected roughly 5,000 projects, 5,000 comments and 700 new user accounts.

https://habr.com/ru/companies/slurm/articles/321074/
https://about.gitlab.com/blog/2017/02/10/postmortem-of-datab...
https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-data...

Вы смотрите срез комментариев. Показать все
729
Автор поста оценил этот комментарий

Мммм, какие шесть месяцев, был рабочий бэкап сделанный за 6 часов

Они не теряли 5000 проектов навсегда, чё за выдуманная хрень, они потеряли изменения, комменты и тд сделанные в 5000 проектах в течение этих 6 часов


On January 31st 2017, we experienced a major service outage for one of our products, the online service GitLab.com. The outage was caused by an accidental removal of data from our primary database server.

This incident caused the GitLab.com service to be unavailable for many hours. We also lost some production data that we were eventually unable to recover. Specifically, we lost modifications to database data such as projects, comments, user accounts, issues and snippets, that took place between 17:20 and 00:00 UTC on January 31. Our best estimate is that it affected roughly 5,000 projects, 5,000 comments and 700 new user accounts.



https://habr.com/ru/companies/slurm/articles/321074/#recover...


https://about.gitlab.com/blog/2017/02/10/postmortem-of-datab...


https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-data...

раскрыть ветку (38)
143
Snow Meow
Автор поста оценил этот комментарий

Это надо в топ, тоже хотел написать что был откат на 6 часов.

раскрыть ветку (12)
67
Автор поста оценил этот комментарий
На сколько надо быть глупым человеком, что бы поверить, что такая компания делает бекапы раз в пол года?
раскрыть ветку (11)
75
Snow Meow
Автор поста оценил этот комментарий

У уважаемого ТС написано что он опытный фронтенд. Видимо шутки про них, нифига не шутки))

раскрыть ветку (2)
19
Автор поста оценил этот комментарий

Ещё и заголовок кликбейтный

1
Автор поста оценил этот комментарий

Фронты не делают бекапы. Им джейсоны с бекенда посылает Аллах.

30
Автор поста оценил этот комментарий

Достаточно просто не знать, что такое гитлаб.

раскрыть ветку (3)
8
Автор поста оценил этот комментарий

Вот, это очень правильный коммент. :))

2
Автор поста оценил этот комментарий

Это всё равно что проктолог не знал бы, что такое анус

раскрыть ветку (1)
6
Автор поста оценил этот комментарий
Проктолог хоть анус видел пару раз минимум, а каким боком гитлаб и дворник?
12
Автор поста оценил этот комментарий

поверить, что такая компания делает бекапы раз в пол года?

Справедливости ради, там ситуация была очень близка к описанной :-) У них было 4 системы бэкапа, из которых 1 упала и никто не заметил (выяснилось постфактум), 2 была как раз уничтожена неверной командой инженера, 3 была не включена так как считалась избыточной, и только последняя "запасная резервная" система бэкапа сработала. Но сделанные ей бэкапы хранились в очень медленном хранилище и поэтому восстановление заняло почти сутки

5
Автор поста оценил этот комментарий

Так надо не только делать бекапы но и уметь из них восстановиться

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Как восстановиться - еще можно разобраться. А вот разбираться как делать бэкапы когда полетела основная база - уже не имеет смысла.

0
Автор поста оценил этот комментарий
Насколько, полгода
41
Автор поста оценил этот комментарий

@moderator, поставьте плашку, "в тексте есть уточнение" в пост, суть же извращена полностью.

раскрыть ветку (4)
8
Автор поста оценил этот комментарий

Ученый изнасиловал журналиста!!

раскрыть ветку (1)
4
DELETED
Автор поста оценил этот комментарий
А марвина отьебали всем руководством
3
Автор поста оценил этот комментарий

Не Баян, а повтор.

Не наброс из-под анонима, а авторская история.

Не Хуета беспруфная, а уточнение.

Пыкабу, нахуй, — мой любимый сайт. Столько сил, улыбок и эмоций дарит. Ну пиздец как я рад!

раскрыть ветку (1)
3
Snow Meow
Автор поста оценил этот комментарий

А вот хуй даже уточнение запилят. Как мне ответил уважаемый модератор "вы можете создать пост-ответ". А ведь когда-то вешалась плашка "фейк".

33
Автор поста оценил этот комментарий

@moderator скажите, а зачем нужно оставлять пост с АБСОЛЮТНО ЛОЖНОЙ информацией? Люди прочитают и запомнят пост, многие даже не перейдут и не увидят коммент, который полностью опровергает пост. Когда уже вы будете укдалять подобное? Или вешать ОГРОМНУЮ плашку фейк?

раскрыть ветку (3)
2
Автор поста оценил этот комментарий

Чтобы на ресурсе было больше трафика.

Так как если ставить upd в начало/сносить пост, то не будет так много просмотров и срача в комментах)

0
TH1RT3EN
Автор поста оценил этот комментарий

Поправил UPD.

раскрыть ветку (1)
3
кискадер
Автор поста оценил этот комментарий

но осадочек остался...

66
Автор поста оценил этот комментарий

лень вникать в историю и проверять пруфы, вспомнилось:
- Верно ли, что Рабинович выиграл «Волгу» в лотерею? - Все верно. Только не Рабинович, а Иванов. И не «Волгу», а сто рублей. И не в лотерею, а в карты. И не выиграл, а проиграл. (с)

раскрыть ветку (1)
4
Автор поста оценил этот комментарий

Итого, Иванов проиграл сто рублей в карты, а Рабинович выиграл Волгу в лотерее

8
Автор поста оценил этот комментарий

Все верно и они использовали технологию Point In Time Recovery. Был у них асинхронный сервер PostgreSql с отложением применением изменений.

4
Автор поста оценил этот комментарий

Насколько помню, они потом сделали в консолях разные цвета шрифтов, чтобы визуально человек понимал где в конкретный момент он находится.

Я знаю случаи когда инженер провайдера перезагружал довольно критичные коммутаторы.. тоже ошибся в какой консоли он на данный момент.. да я и сам путал консоли, не так эпично конечно... но было немного неприятно. И меня тоже не уволили.. девиз у нас прост: не косячит тот, кто нихера не делает!

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Да, это простая, но очень действенная штука - разный цвет консолей и рабочих столов на серваках, если по рдп работать.

4
Автор поста оценил этот комментарий

И не выиграл, а проиграл.

И не в лотерею, а в преферанс.

4
Автор поста оценил этот комментарий

Вот и я не поверил изначально. Слишком бредово выглядит.

Крупная площадка. Ладно сотрудник в запарке мог накосячить. Но бэкапов не делалось 6 месяцев?


Я, работая в небольшой организации с относительно небольшими базами данных и редкой частотой записей, делал бэкапы по 3-5 раз в неделю. Еще и проверял работоспособность периодически.

4
Автор поста оценил этот комментарий

Ужас, пришлось перекомитить из локальных веток

4
Автор поста оценил этот комментарий

Если бы нв пикабу давали плюсы за поедание говна, ТС бы рассказывал, что команда GitHub предварительно съела все говно, которое образовалось в силиконовой долине за год.

раскрыть ветку (1)
11
Автор поста оценил этот комментарий

пиздец, облажалась gitlab, а говно приходится есть github

6
Автор поста оценил этот комментарий

При этом коммиты вполне можно вернуть, запушив их с локальной машины. Вероятность что их оттуда успели удалить очень низкая

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

вот и это надо в upd: добавить =)

4
Автор поста оценил этот комментарий

1. Надо каждое предложение начинать отдельным пунктом пронумерованного списка.

2
Автор поста оценил этот комментарий

Есть ещё нюанс. Если мы говорим про GIT, то изменения же и на локальных машинах у пользователей остались

1
Автор поста оценил этот комментарий
Тс минус, тебе плюс
1
кискадер
Автор поста оценил этот комментарий

убрал плюс от поста и дал тебе

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества