Деплой — не только один из ключевых этапов цикла любого приложения, но и страшный кошмар многих разработчиков. Ошибки при деплое могут привести к серьёзным последствиям: от временных сбоев до полной недоступности системы. Чтобы перечислить все возможные сценарии того, что может пойти не так, понадобится цикл статей, поэтому мы ограничимся самыми частыми.
Неправильная настройка окружения
Разработка обычно происходит на локальном компьютере с определённым окружением — набором программного обеспечения и настроек, который используется для запуска разрабатываемой программы. Локальная конфигурация может не совпадать с той, что на сервере. Рассмотрим самые распространённые отличия серверного окружения от локального.
Несоответствие версий языка программирования. Представим, что разработчик пишет код на Python 3.8, а на сервере установлен Python 3.6. В версии 3.8 есть функции, которые не поддерживаются более старыми версиями. Если в программе используются такие функции, она будет работать на компьютере разработчика, а на сервере может не запуститься.
# этот код будет работать на Python 3.8+
# а на Python 3.6 выдаст ошибку AttributeError
result = math.isqrt(100)Отсутствие необходимых библиотек и их версий. Если на сервере не установлены определённые библиотеки или модули, которые использованы в программе, или установлены другие версии, при запуске программа не сможет их найти и выдаст ошибки.
# ошибка ImportError на сервере,
# если pandas не установлен
import pandas as pdДругие системные настройки. Самый простой пример — когда часовой пояс на сервере отличается от нужного. Допустим, веб-приложение работает с датами и временем, добавляя их в базу данных при создании записи. По умолчанию сервер использует часовой пояс UTC вместо UTC+3. Из-за этого все временные метки и даты обрабатываются неправильно.
Неправильная конфигурация базы данных
Неправильная настройка базы данных может привести к ошибкам производительности, сбоям в подключении или даже потере данных.
Неправильные данные для подключения. Обычно приложение должно знать адрес, по которому находится база данных, имя базы данных, учётные данные для подключения и номер порта. Если хотя бы один из этих параметров на деплое и локальной среде различается, приложение не сможет подключиться к базе.
Отсутствие миграций базы данных на сервере. Даже если все параметры соединения заданы правильно, структура базы данных может не соответствовать ожидаемой. Представим, что структуру локальной базы данных изменили — добавили новые таблицы или столбцы. Эти изменения зафиксированы в виде миграций, но при деплое не были выполнены на сервере. Приложение на проде идёт в нужную ей таблицу (которая появилась в локальной среде), не находит её и падает с ошибкой. Все грустят.
Недостаточные права пользователя базы данных. Администраторы баз данных часто ограничивают на сервере права пользователя, под которым работает приложение, ради безопасности. Например, пользователю могут быть даны только права на чтение и запись данных, но не на создание или изменение таблиц. В результате приложение не может выполнить всё, что ему нужно, так как для этого нужны более широкие права.
Неправильная работа с переменными окружения
С помощью переменных окружения задают параметры, которые могут меняться в разных средах: на локальном компьютере разработчика, тестовом сервере и в продакшен-среде. Эти параметры указывают в отдельном файле конфигураций, чтобы не переписывать основной код.
Отсутствие переменных для секретных ключей и токенов. В переменных окружения часто хранят конфиденциальные данные: API-ключи, пароли и токены доступа. Для безопасности их не включают в исходный код, чтобы они не попали в кодовую базу и не были случайно раскрыты. Вместо этого их передают на уровень конфигурации. Если такие переменные не заданы, приложение может не заработать.
Неправильные значения переменных окружения. На сервере переменные окружения могут быть не такими, как в локальной среде. Например, переменная DEBUG в Django должна быть отключена в продакшене, но если она задана неправильно, приложение может работать в режиме отладки, из-за чего может быть утечка информации.
Ошибки с кэшированием
Кэширование позволяет улучшить производительность, но его неправильная настройка может привести к различным ошибкам, которые повлияют на работу приложения.
Старый кэш после деплоя нового кода. При деплое новой версии может измениться структура данных, запросов или логика их обработки. Если старый кэш не был очищен, приложение может по-прежнему использовать устаревшие данные и работать с ошибками. Тут правило простое: новый деплой = сбрасываем кэш.
Конфликт конфигурации кэша. Например, сервер может использовать распределённый кэш (Redis или Memcached), а в локальной среде — файловый или просто отключённый кэш.
Неправильная политика инвалидации кэша. Когда данные устаревают, они должны быть удалены из кэша, иначе приложение может использовать устаревшие данные. Представим, что цены в интернет-магазине кэшируются, чтобы приложение реже запрашивало их из базы данных. Если цена на какой-то товар изменится, но кэш не будет сброшен, приложение продолжит показывать цену, которая больше не соответствует реальной. В итоге люди купят айфоны по сто рублей, компания потеряет много денег, а виноват будет админ или девопс, который не проверил сброс кэша.
Отсутствие тестирования на сервере
Тестирование на сервере перед деплоем помогает выявить ошибки — перечисленные выше и многие другие. А ещё локальная среда разработки обычно не отражает реальных условий эксплуатации — на сервере могут быть совершенно другие объёмы трафика и нагрузка. Тестирование поможет определить, выдержит ли приложение реальную нагрузку, и выявить слабые места в производительности.
Бывает так, что в локальной среде не настроены или недоступны внешние сервисы, например API, микросервисы или системы платежей. Тестирование покажет, работают ли эти сервисы корректно. Или на сервере могут быть другие правила доступа к ресурсам, файлам или сетям. Без тестирования обнаружить такое сложно.
В продакшен-среде приложения часто состоят из множества компонентов: базы данных, очередей сообщений, кэшей, внешних сервисов и так далее. Если их совместную работу не протестировать заранее перед деплоем — может случиться всякое.
Деплой в пятницу вечером
Если вы ещё ни разу не деплоили вечером в пятницу — так и продолжайте впредь.
А если у вас уже был опыт пятничного деплоя — ну нужно просто пережить такое и сделать выводы. Сил вам.
