Эх, воспоминание разблокировано.

Работал я тогда инженером в одном региональном банке. Часть софта была от внешних вендоров, и они же поставляли обновления. Выглядело это так: на неделе тебе присылают само обновление и мануал с его установкой. А так-как банк - контора важная, шатать его системы можно только тогда когда они никому нафиг не нужны. Самое удобное время это 2-4 часа ночи в воскресенье. Если что идет не так всегда есть инженер вендора которому можно позвонить.

Само действо, время пол-третьего утра декабрьского воскресенья, причем почти предновогоднее, я сонный сижу в офисе(помним что это банк, и удаленкой тогда не пахло).

Запускаю локальный бэкап, потом его проверку, линуксовая консоль плюется радостными строчками "усе окэй". И поехали....

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

Настал час, "звонок другу". Сонный инженер на другом конце необъятной начинает давать советы и слать скрипты (помним про то что система не собственной разработки, шибко шашкой не помашешь).

И в одном из скриптов так же как в посте есть rm -rf тут был путь/*. Скрипт пошел...и мой сонный мозг понимает что удаляющиеся файлы находятся совсем не там где хотелось бы.

Пару мгновений на протупиться...прерывание скрипта. Сервак зачищен от корня процентов на 60... пользовательских директорий со всеми временными бэкапами как не бывало.

Поднятые админы банка накатывают бэкап из ленты и получаем голый чистый сервак. Профили пользаков не восстанавливаются. Ленточный бэкап в помойку.

Дальше были звонки из серии "Наташа мы там все уронили" начальству. Я молодой и зеленый стоя в курилке думал "Нууу на время поиска работы денег должно хватить". Потом восстановление с нуля всего утраченного в ручном режиме. Как итог в ПОНЕДЕЛЬНИК в 14 00 я вышел из офиса, начальник отправил отсыпаться.

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

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

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...