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