Есть ошибки, после которых ты просто исправляешь код и работаешь дальше. А есть такие, после которых внезапно появляются новые жизненные принципы, дополнительные серверы и лёгкая нервная реакция на слово «бэкап».
Одна такая история случилась у меня во время разработки delniki.ru. Проект тогда уже был живым — пользователи регистрировались, писали статьи, размещали объявления, загружали фотографии, и контента постепенно становилось довольно много. То есть это уже была совсем не пустая тестовая площадка, которую можно спокойно пересоздать за десять минут.
Про то, как Дельники выросли из «площадки со статьями» в соцсеть — отдельная статья. Здесь — про ошибку, после которой у проекта появилась совсем другая дисциплина с резервными копиями.
Автотесты добрались до прода
В какой-то момент я запускал автотесты, которые должны были спокойно проверить очередную итерацию разработки. Что-то в настройках оказалось совсем не таким спокойным, и тесты вместо тестовой базы благополучно добрались до продовой. В результате они снесли базу данных, а заодно куда-то вслед за ней отправились фотографии пользователей.
Мда, момент был довольно неприятный, потому что я прекрасно понимал масштаб произошедшего. VPS тогда использовалась недорогая, автоматических серверных бэкапов на ней не было, а мои локальные копии оказались довольно старыми. Git прекрасно спасает код, но пользовательские статьи и загруженные фотографии он, к сожалению, обратно из воздуха не достаёт.
Что удалось восстановить
В итоге я поднял последние локальные копии и начал восстанавливать всё, что вообще можно было восстановить. Часть статей вернулась, часть фотографий тоже удалось вернуть, но полностью собрать прежнее состояние уже не получилось. Потом ещё вручную доделывали и восстанавливали отдельные куски контента, которые потерялись между резервной копией и прекрасным днём запуска автотестов.
Самое смешное, что сами автотесты были нужны именно для того, чтобы уменьшать количество ошибок при разработке. Формально инструмент безопасности в тот день устроил мне одну из самых неприятных аварий за всё время работы над проектом. И проблема была не в том, что автотесты плохие, а в том, что я недостаточно хорошо изолировал окружение и слишком сильно доверился существующей схеме.
Правило после аварии: бэкапов много не бывает
После этого у меня появилось очень простое правило — бэкапов много не бывает вообще никогда. Сейчас я сохраняю файлы и базу перед каждой серьёзной итерацией, перед автотестами дополнительно делаю полный архив, использую Git и держу стандартные ежедневные резервные копии на другом сервере. Причём способы специально дублируются, потому что один бэкап однажды уже доказал мне, насколько легко он может оказаться недостаточно свежим.
Наверное, именно такие истории лучше всего меняют отношение к разработке. Сейчас перед потенциально опасным изменением я гораздо чаще думаю не только о том, заработает ли новая функция, но и о том, что произойдёт, если она решит сделать что-нибудь совершенно неожиданное. Цена следующей ошибки от этого становится намного меньше, даже если сами ошибки никуда полностью не исчезают.
Главный вывод
Так что мой главный вывод из той истории оказался довольно приземлённым. Опыт разработчика заключается не в способности никогда больше не косячить, потому что это всё равно невозможно. Гораздо важнее однажды очень хорошо запомнить последствия своего косяка и построить процесс так, чтобы следующий уже не мог снести тебе половину живого проекта.
Это хорошо стыкуется с тем, как я выстраиваю работу с клиентами: фиксация, предоплата, границы — не бюрократия, а страховка от неприятных сюрпризов. А про другой подход к риску — быстрый MVP, где сначала ядро, а не «идеальная первая версия».
Если у вас живой продукт и хотите разобрать, как не потерять данные при разработке — напишите.
