Учитывая, что внутренний сервер работает в производственном режиме, я бы хотел свести к минимуму влияние на пользователей при развертывании регулярных обновлений (на сам сервер, а не на пользовательские машины... но это была бы довольно похожая проблема).
Очевидный ответ на мой вопрос: «ночью, когда пользователи дома». Но «ночь» — это долгий период времени. Стоит ли начинать рано вечером, чтобы, возможно, обнаружить проблемы с обновлением на ранней стадии и быть готовым к откату? Или лучше начать рано утром и использовать первых пользователей в качестве «подопытных кроликов», чтобы быстрее выявить проблемы? Или посреди ночи, когда концентрация внимания того, кто следит за обновлением, довольно низкая, но гарантированно нет открытых файловых дескрипторов некоторых поздно работающих пользователей?
Есть ли какие-либо научные работы по этой теме?
решение1
Почему бы не посмотреть на историю одновременного использования вашей системы и не определить, в какое время дня использование самое низкое? Затем вставьте изменения прямо в середину этого периода низкого использования.
При определении того, сколько времени займет изменение, включите тестирование до/после внедрения и тестирование проверки производства. Кроме того, определите, сколько времени займет откат изменения, если какое-либо тестирование не удастся.
IMHO ваши «первые пользователи» не должны быть подопытными кроликами. Нехорошо, когда живые пользователи, по сути, проверяют ваши изменения на производстве. Это разрушает доверие конечных пользователей, а неожиданные результаты могут испортить производство, что означает, что вам придется не только откатить изменение, но и откатить любой «ущерб», который могло вызвать изменение.
Я не знаю ни одной исследовательской работы, но взгляните на любую структуру управления ИТ-услугами (ITSM), например, ITIL, вы найдете множество стандартов и передовой практики по управлению выпуском ПО. Все системы разные, поэтому степень принятия вами практик и формальность зависят от этого. Стандарты ITSM рассчитаны на большие системы.
решение2
Это полностью зависит от характера бизнеса. Некоторые офисы работают с 9 до 5 пять дней в неделю. Другие предприятия работают 24 часа в сутки, 365 дней в году. Другие факторы, такие как наличие персонала и ресурсов, играют важную роль. Ни одна исследовательская работа не может всесторонне охватить все возможные графики или возможности.
В конечном итоге, руководство компании или отдела совместно с ИТ-менеджерами должны определить, что лучше.
Ключ к успеху — это общение с пользователями, когда запланировано начало простоя, как долго он, как ожидается, продлится, требуется ли какая-либо подготовка от пользователей и чего они могут ожидать в результате успеха или неудачи. Большая часть этого — соответствовать установленным вами ожиданиям.
В конце концов, ничто не высечено на камне. Если процесс не работает, внесите коррективы. Ваша гибкость и адаптивность будут оценены по достоинству.
Выполняя процедуры обслуживания и обновления на испытательном оборудовании заранее, когда это возможно, вы будете лучше подготовлены, когда придет время внедрять их в производственные системы.
решение3
Я работаю в интернет-провайдере, и по моему опыту, большинство людей, которых я бы назвал серьезными системными администраторами, выбирают пятничные вечера в праздничные выходные, чтобы провести капитальный ремонт сети. Это дает им дополнительные 24 часа для тестирования и, при необходимости, отката изменений. Однако в большой степени это полностью зависит от характера и привычек ваших пользователей.
решение4
В моем случае мы устанавливаем обновления в 4 утра, чтобы не оказывать влияние на пользователей, даже тех, кто работает допоздна.
Если у вас есть хорошая система мониторинга, которая предупреждает вас о возникновении проблемы, вы сможете устранить ее рано утром, еще до выхода на работу.