TGViewer
Good dev knows Good dev knows @gooddevknows · 2K subscribers
Post #21 1.17K
Хороший разработчик знает истории и учится на чужом опыте

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

Тогда, в середине 2000х, я работал на маленькую 🇳🇱голландскую компанию. У этой компании был внутренний, на то время инновационный, продукт для трекинга задач. Он действительно был красивее чем альтернативы, которые были доступны в то время. Отдельно менеджменту нравилось, что это наш собственный велосипед и мы могли его обновлять.

Однажды и мне поручили внести какое-то изменение в этот продукт. Процесс разработки был тоже простой — правь php файлы по ftp и смотри что получилось. В базу ходи через phpMyAdmin. Окружений было два - integration и production. Разница была в названии баз данных, которые они использовали.

И вот в какой-то чудный момент я, с помощью phpMyAdmin дропнул таблицу в базе данных. Я делал это уже десятки раз. Моя рука обладала мышечной памятью. Без секунды сомнения мой палец подтвердил удаление в появившемся попапе. Дело было сделано. Еще через минуту я понял, что я удалил таблицу в production базе данных. Это была основная таблица, та, где хранились таски.

Я обновил страницу в phpMyAdmin — таблицы не появилось 🙀. Через 5 минут судорожных кликов по табам в браузере я решил сказать об этом кому-то еще. Дальше пошел damage control.

В результате компания потеряла таски за последние 3 месяца. Потому что оказалось, что бекапы были предусмотрены, но они не работали. Нашелся только старенький, что лучше, чем ничего.

Меня никто ни разу не упрекнул в том, что я это сделал. Я знаю, что был разговор с человеком, который был ответственным за бэкапы. В отношении меня было понятно, что это была механическая ошибка. За бэкапами стали смотреть лучше. А в будущем мы перешли на Redmine.

Давайте выпишем недостатки инженеринга, которые нужно избегать:

1. Должна быть возможность развернуть проект локально. С локальной инфраструктурой.
2. Периодически нужно проверять что бэкапы работают. Сейчас лучше отдать это на аутсорс и использовать, например, AWS RDS.
3. Нужно чтобы команда знала как реагировать на такие ситуации. Лучше всего проводить 🎯 Game day.

◼️Еще раз — удалять базу данных на продакшене не страшно, такое точно будет происходить и в будущем. Но важно, чтобы команда была к этому готова. Design for failure.

Какие еще ошибки вы увидели? Пишите в комментариях.
More from @gooddevknows
  1. Aug 27, 2026🛰 Я придбав Starlink! Ще поза-вчора вранці я не збирався купляти ніякий Starlink. Але, пр…
  2. Jul 1, 2026photo post
  3. Jul 1, 2026✨ Crash Course: Storytelling для інженерів ✨ 📅 9 — 13 липня 2026 1️⃣ Чому історії працюют…
  4. Jul 1, 2026Post #278
  5. Apr 1, 2026We have one ticket left for: https://fwdays.com/event/tech-lead-course-5 . Code LIFE_BY_PP…
  6. Mar 9, 2026Hi friends, For those who have missed it, I now regularly post in my 🇺🇦 channel: https:/…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →