Как максимально вежливо обновлять действующий, загруженный веб-сайт?

https://stackoverflow.com/questions/67368

09-06-2019
|

Вопрос

Когда вы внедряете изменения на действующий веб-сайт, как вы проверяете, что жить система работает корректно?Какие инструменты вы используете?Кто это делает?Блокируете ли вы доступ к сайту на период тестирования?Какое время простоя является приемлемым?

Решение

Я обычно провожу все тестирование в другой среде (не в реальной!).Это позволяет мне размещать обновления на действующем сайте, зная, что код должен работать нормально, и я просто провожу проверку работоспособности реальных данных - чтобы убедиться, что я где-то не забыл файл или что-то странное пошло не так.

Итак, правильное тестирование в тестовой или промежуточной среде, а затем просто тривиальная проверка работоспособности.Нет необходимости в простоях.

Другие советы

Уже много хороших советов.

Как уже упоминали люди, если у вас нет единой точки, можно просто поэтапно вносить изменения, обновляя сервер приложений за раз.Но это случается редко, поэтому давайте проигнорируем это и сосредоточимся на сложных моментах.

Обычно там есть база данных, общая для всего остального.Это означает простой всей системы. Как свести это к минимуму?

Автоматизация.Напишите сценарий всей процедуры развертывания.Это (особенно) включает в себя любые изменения схемы базы данных.Сюда (особенно) входит любая необходимая миграция данных между версиями схемы.

Контроль качества.Убедитесь, что есть тесты.Автоматизированные приемочные тесты (то, что пользователь видит и ожидает с точки зрения бизнес-логики/опыта).Рассмотрите возможность создания тестовых учетных записей в производственной системе, которые вы можете использовать для тестирования действий только для чтения.Если вы не взаимодействуете с другими внешними системами, рассмотрите возможность записи.Возможно, вам придется отфильтровать активность тестового аккаунта в определенных частях системы, особенно если они связаны с деньгами и бухгалтерским учетом.Счетчики зерен по уважительным причинам расстраиваются, когда зерна не совпадают.

Репетировать.Развертывание в промежуточной среде, максимально идентичной производственной.Сделайте это с объемами производственных данных и производственными данными.Вам нужно почувствовать, сколько времени занимает изменение таблицы.И вам нужно проверить, что таблица изменений работает как структурно, так и со всеми внешними ключами в реальных данных.

Если у вас большие объемы данных, изменение схемы потребует времени.Возможно, больше времени, чем вы можете себе позволить.Одним из решений является использование поэтапная миграция данных, так что изменение схемы заполняется «недавними» или «текущими» (скажем, одного или трехмесячного возраста) данными во время простоя, а данные за оставшиеся пять лет могут поступать после того, как вы снова подключитесь к сети.Для конечного пользователя все выглядит нормально, но к некоторым функциям нельзя получить доступ еще пару часов/дней/что угодно.

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

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

Создайте милое, обезоруживающее изображение и/или резервную страницу.На некоторых сайтах реализованы простые игры на JavaScript, чтобы занять вас в ожидании обновления.

Например, провальный кит.

-Адам

На последнем месте, где я работал, QA проводил тестирование в QA Environment.Любые серьезные проблемы будут исправлены, протестированы и проверены перед развертыванием.

После того как сборка была сертифицирована QA, группа поддержки производства отправляет код в промежуточную среду, где клиент просматривает сайт и проверяет, что все соответствует желанию.

Фактическое развертывание производства происходит в нерабочее время (после 21:00).если это экстренный ночной толчок, или с 5 утра.- 8 утра.если это обычное запланированное развертывание).

Сайт размещен на нескольких серверах, нагрузка на которых балансируется с помощью балансировщика нагрузки F5:

Пару серверов сняты с производства,
код установлен и
Перед помещением серверов обратно в пул выполняется поверхностная проверка серверов.

Это повторяется до тех пор, пока все серверы не будут обновлены до последней версии кода и не позволят сайту работать все время.

Этот процесс идеален, но бывают случаи, когда необходимо обновить и базу данных.Если это так, то есть два варианта, в зависимости от того, сломает ли новая база данных сайт или нет.

Если новая база данных несовместима с существующим интерфейсом, у вас нет реального выбора, кроме как иметь некоторое время, когда сайт не работает.

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

Весь трафик направляется на вторую БД, а первый сервер БД загружается.
Первая БД обновляется и после завершения проверки снова запускается в производство.
Весь трафик направляется к первой БД, а вторая БД извлекается.
Вторая БД модернизируется и после завершения проверки снова запускается в производство.
Следующим шагом является выполнение частичного обновления, как описано выше.

Итак, подведем итог:

Когда вы внедряете изменения на действующий веб-сайт, как вы проверяете правильность работы действующей системы? В лучшем случае это делается постепенно.
Какие инструменты вы используете? Ручные проверки правильности установки кода, а также некоторые базовые автоматические тесты с использованием любого инструмента автоматизации.Мы использовали Selenium IDE.
Кто это делает? Администратор базы данных выполняет обновления БД, техническая поддержка/системные администраторы отправляют/извлекают серверы и устанавливают код, а служба контроля качества или производственная поддержка выполняет ручные тесты и/или запускает автоматические тесты.
Блокируете ли вы доступ к сайту на период тестирования? По возможности этого следует избегать любой ценой, особенно, как упоминал ранее Жиль, если это платный сайт.
Какое время простоя является приемлемым? Время простоя должно быть ограничено периодами, когда пользователи с наименьшей вероятностью будут использовать сайт, и должно длиться менее 3 часов.
Примечание: 3 часа — это очень щедро.После практики и репетиций, как упомянул Джплиндстром, команда сможет полностью контролировать весь процесс и может приходить и уходить иногда менее чем за час.

Надеюсь это поможет!

Отчасти это зависит от того, обновляете ли вы базу данных.Раньше, если база данных обновлялась, мы отключали сайт на запланированный (и опубликованный) период обслуживания — обычно это происходило в нерабочее время, когда влияние было минимальным.Если обновление не затрагивает БД, то в среде с балансировкой нагрузки мы возьмем один блок из набора, развернем и протестируем.Если это было успешно, он включался в обработку, а другой блок (при условии, что его было два) извлекался и обновлялся/тестировался.

Примечание:Мы НЕ тестируем код, просто развертывание прошло гладко, поэтому время простоя в любом случае было минимальным.Как уже упоминалось, код уже должен был пройти тестирование в другой среде.

ИМХО длительные простои (часы) допустимы для бесплатного сайта.Если вы достаточно обучите своих пользователей, они поймут, что это необходимо.Возможно, дайте им что-нибудь поиграть, пока веб-сайт не заработает снова (например.флеш-игра, прямая трансляция с веб-камеры, показывающая работу команды разработчиков и т. д.).Для веб-сайта, за доступ к которому люди платят, многие люди будут тратить ваше время на жалобы, если вы будете регулярно кормить их простоями.Я бы избегал простоев, как чумы, и развертывал обновления очень медленно и осторожно, если бы у меня был сервис, взимающий плату с пользователей.

В моей текущей настройке у меня есть дополнительный веб-сайт, подключенный к той же базе данных и кешу, что и действующая копия, для проверки моих изменений.

У меня также есть несколько сценариев «наблюдения за страницами», выполняемых в заданиях cron, которые используют регулярные выражения для проверки правильности отображения ключевых страниц веб-сайта.

Ответ таков: «Это зависит».Прежде всего, от того, в какую среду вы попадаете.Это веб-сайт типа «привет, мир» на общем хосте или google.com с полмиллиона серверов?Обычно в день присутствует один пользователь или около пары миллионов?Вы публикуете HTML/CSS/JPG или у вас есть большая серверная часть с серверами SQL, серверами среднего уровня, распределенными кэшами и т. д.?

В общем, если вы можете позволить себе иметь отдельные среды для разработки, контроля качества, подготовки и производства — сделайте это.Если у вас есть ресурсы — создайте экосистему, чтобы вы могли собрать полный устанавливаемый пакет в 1 (один) клик.И убедитесь, что одинаковый Бинарную установку можно успешно установить в DEV/QA/STAGE/PROD одним щелчком мыши...На эту тему написано множество материалов, и вам нужно быть более конкретным в своем вопросе, чтобы получить разумный ответ.

Запустите свой основной сервер на порте, отличном от 80.Прикрепите легкий сервер (например.nginx) перед ним на порту 80.Когда вы обновляете свой сайт, запустите еще один экземпляр на новом порту.Тест.Когда вы убедитесь, что он развернут правильно, отредактируйте файл конфигурации прокси-сервера и перезапустите его.В случае nginx это приводит к нулевому времени простоя или неудачным запросам, а также может обеспечить повышение производительности по сравнению с более типичным вариантом хостинга только с Apache.

Конечно, это не заменяет правильный промежуточный сервер, это просто «вежливый» способ выполнения передачи обслуживания с ограниченными ресурсами.

Чтобы проверить все, как можно больше, на отдельном сайте Dev, прежде чем отправиться в жизнь, я использую селен (тестер веб -страницы), чтобы пройти через все судоходные части сайта, заполнить фиктивные значения в формы, проверьте, что эти значения появляются справа места в результате и т. Д.

Он достаточно мощный, чтобы проверить много JavaScript или динамичных вещей.

Затем снова пробег с Selenium после обновления живого сайта подтверждает, что обновление сработало и что нет недостающих ссылок или ошибок в базе данных.

Это спасло меня несколько раз, поймав тонкие ошибки, которые я бы пропустил, просто вручную пролистающегося.

Кроме того, если вы поместите живой сайт за каким -то «обратным прокси» или балансировщиком нагрузки (если он большой), это позволяет легко переключиться на предыдущую версию, если есть проблемы.

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

Если у вас есть какая-либо бета-версия, не развертывайте ее на основном сервере.Если у вас «живой, загруженный сайт», скорее всего, люди начнут на него нападать и что-нибудь сломать.

Это типичная настройка высокой доступности. Для поддержания высокой доступности вам потребуется минимум 3 сервера.2 живых и 1 тестовый сервер.Плюс любые другие дополнительные серверы, если вы хотите иметь выделенную БД или что-то в этом роде.

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

Когда вы закончите бета-тестирование и будете готовы к работе, не нужно отключать свой сайт, просто удалите некоторые хосты из производственного класса хостов, добавьте их в новый класс хостов, разверните там свой последний код и протестируйте должным образом.Как только вы убедитесь, что все работает нормально, постепенно переместите весь ваш хост на новый и укажите новый класс хоста как рабочий класс хоста.Или вы можете использовать то же самое, что использовали изначально. Вся идея этого действия состоит в том, чтобы убедиться, что вы тестируете свое развертывание на производственных системах, где ваш сайт будет работать после развертывания, поскольку проблемы с развертыванием пугают и их трудно отладить.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow