К счастью, для моего проекта это был единственный форс-мажор за всю карьеру (тьфу-тьфу-тьфу). Но, как говорится, даже если ты самый опытный профессионал в мире, всегда найдётся что-то, что сделает тебя тупым новичком. И это меня спасло.На дворе был конец 2022 года. Я работал в одной небольшой компании, разрабатывал SaaS-платформу с использованием Node.js и PostgreSQL, и мы как раз собирались выйти на новый уровень.Мы с командой планировали релиз продукта для массового использования, и настал тот самый день. Мы провели все тесты, всё было гладко и предсказуемо. Но в середине дня, когда тысячи студентов сидели за компьютерами, ожидая занятий, наш продакшен лёг.Причина: ошибка в процессе деплоя. Звучит, конечно, просто, но на самом деле это была проблема с тонкостями PostgreSQL. У нас был сложный запрос, который включал в себя soft delete и partial index.Что такое soft delete? Это механизм, который позволяет удалять записи из базы данных без фактического удаления. Частичный индекс (partial index) позволяет ускорить выполнение запроса, когда в таблице есть только некоторые столбцы, которые часто используются в запросах.В нашем запросе мы использовали soft delete для удаления данных, а также partial index для ускорения выполнения запроса. Но из-за тонкостей PostgreSQL, когда мы пытались выполнить этот запрос, возникли проблемы.Это привело к падению сервера и блокировке всех запросов.И вот тут-то я понял, что наделал. Я начал анализировать ситуацию, просматривая логи, и увидел, что запрос был выполнен, но результат не был возвращён. Это означало, что что-то пошло не так.Я начал изучать код, чтобы понять, где может быть проблема. И в итоге обнаружил, что мы использовали устаревший способ проверки на существование данных перед удалением.Конечно, это не было проблемой в наших тестовых средах, но в продакшене, где данные постоянно обновлялись, эта проверка не работала должным образом. Это и вызвало ошибку.Мне пришлось быстро исправить код, и это заняло около 30 минут. В конце концов, я восстановил данные и перезапустил сервер.После этого я провёл ещё несколько тестов, чтобы убедиться, что всё работает как надо. И вот тогда я заметил кое-что интересное.Когда я запросил данные из таблицы, они были доступны намного быстрее, чем раньше. Это было связано с тем, что я удалил устаревшую проверку на существование данных. После этого я решил оптимизировать запрос, чтобы он использовал индексы более эффективно.Вот так я уронил свой продакшен, но это стало уроком для меня. Я узнал о тонкостях PostgreSQL и научился лучше понимать, как работают запросы.Теперь я знаю, что база данных – это не только хранилище данных, но и мощный инструмент для анализа и оптимизации. И я научился использовать его с умом.Этот опыт научил меня быть более осторожным при работе с данными и анализировать все возможные последствия своих действий. Теперь я понимаю, что ошибки могут произойти в любой момент, и нужно быть готовым к ним.Надеюсь, моя история поможет кому-то избежать подобных ситуаций.
