Меня попросили выяснить, как я могу сократить время простоя обновлений нашего веб-сайта.
Мы поддерживаем сайт DNN с общедоступными страницами и страницами только для участников. Страницы, предназначенные только для участников, напрямую связаны с нашей базой данных основного приложения, а общедоступные страницы - нет.
Наш текущий процесс заключается в перенаправлении пользователей веб-сайта, как только начинается процесс обновления, который включает
Этот процесс может занять от 2 до 8 часов в зависимости от требуемого обновления, запускаемых скриптов, размера базы данных и количества или порталов.
Мои первоначальные мысли заключаются в том, чтобы ограничить пользователей только чтением страниц, и любые страницы обновления будут недоступны.
Не мог бы кто-нибудь предложить свои рекомендации относительно того, что я считаю распространенной проблемой, чтобы мы могли сократить время простоя, и если нам потребуются изменения инфраструктуры, я могу передать это в наш технический отдел.
Я бы посоветовал:
а) установить сайт RO
б) сделать резервную копию базы данных // должно быть быстро. если это не так, используйте Redgate или что-то еще, чтобы ускорить
c) обновление базы данных: // должно быть быстрым. Если это не так, вы слишком часто вносите слишком большие изменения.
г) весь код должен быть предварительно протестирован при постановке. Вы должны иметь возможность запустить сайт, а затем протестировать его, пока он работает (потому что вы очень уверены, что тесты пройдут)
У нас есть очень большое приложение .net поверх базы данных sql-сервера объемом 500 ГБ, и наши действия такие же, как и у вас, но у нас есть всего несколько минут простоя для обновления (которое мы делаем несколько раз в неделю).
Практикуете ли вы какие-либо методологии гибкого развертывания? Мое первое предложение - измерить, какая часть развертывания занимает больше времени, чем хотелось бы, и оптимизировать ее. Попробуйте отделить развертывание базы данных от расписания развертывания кода.
Поскольку вы создаете резервную копию своей базы данных каждую ночь (правильно?), Не должно быть слишком много данных для отката в случае необходимости. Не эксперт по базам данных, но я уверен, что вы можете просто обновить схему базы данных там, где ее нужно обновить с помощью сценариев, не занимая слишком много времени.
Вы можете легко развернуть библиотеки DLL и ресурсы на сайте с помощью сценария, не прерывая существующие сеансы.
Перед развертыванием в производственной среде вам следует провести большую часть тестирования на промежуточном сервере. Итак, после развертывания вам не нужно столько тестировать на производстве.
Я бы посоветовал вам изучить непрерывную интеграцию или непрерывное развертывание (http://continuousdelivery.com/).