Если у вас был круглосуточный веб-сайт на Windows Server 2003 (IIS6). Вы бы оставили функцию автоматического обновления Windows включенной или отключили бы ее?
Если этот параметр включен, вы всегда автоматически получаете последние исправления безопасности и исправления ошибок, как только они становятся доступны, что является наиболее безопасным выбором. Однако иногда компьютер автоматически перезагружается для применения обновлений, что приводит к паре минут простоя посреди ночи. Кроме того, я видел редкие случаи, когда машина не перезагружалась правильно, что приводило к дальнейшему простою.
Если автоматические обновления отключены, когда применять патчи? Я предполагаю, что вам нужно использовать балансировщик нагрузки с несколькими веб-серверами и перемещать их с рабочего сайта, вручную применять исправления и вставлять их обратно. Это может быть неудобно с точки зрения логистики, когда балансировщиком нагрузки управляет хостинговая компания. У вас также будут производственные машины, на которых не всегда установлены последние исправления безопасности, и вам придется постоянно тратить время на решение, какие исправления применять и когда.
Короткий ответ, нет.
В лучшем случае у вас должен быть хотя бы другой ящик / vm / морская свинка, чтобы протестировать патч, чтобы убедиться, что он не разрушит ваш мир.
В худшем случае я позволю ему загрузить исправления, но не установить, чтобы я мог проверить, что устанавливается. Но в этом смысле я просто помешан на контроле.
Боюсь, я не согласен с консенсусом.
Тот, кто говорит, что «необходимо вмешательство человека», не думает достаточно прогрессивно.
Все автоматизируйте.
Возможно, это означает включение автоматического обновления (я делаю это в моей среде с незначительными последствиями).
Возможно, это означает что-то более строгое (когда вы автоматически обновляете промежуточную среду, автоматически проверяете правильность ее работы, а затем запускаете автоматическое обновление в производственной среде). Следует использовать отчеты или уведомления по электронной почте, чтобы администраторы могли видеть статус процесса.
Есть несколько способов выполнить эту автоматизацию, от сценариев PowerShell до служб обновления программного обеспечения (SUS) ... и особенно, поскольку вы задали этот вопрос о stackoverflow, а не serverfault, я бы рекомендовал вам разработать процедуры для автоматизации как можно большей части процесс обновления по возможности.
В противном случае вы рискуете не применить обновления или применить их ненадлежащим образом. Кроме того, если вы похожи на меня, вы бы предпочли просыпаться в 3 часа ночи один раз в синюю луну, когда обновления терпят неудачу (и вы загружаетесь вашими процедурами обновления), а не просыпаться в 3 часа ночи каждый месяц, чтобы установить обновления. в часы с минимальными последствиями.
Конечно, YMMV. Разработайте процесс, который лучше всего подходит вам, но постарайтесь не делать слишком много ненужной работы для себя.
Для производственного сервера Windows я бы не рекомендуем настроить Центр обновления Windows на автоматическую загрузку и установку обновлений. Лучше загружать обновления автоматически, а устанавливать их вручную.
Преимущества этого подхода:
В основном все дело в контроле, и с автоматическими загрузками и автоматической установкой вы не получите многого !!
Я разрешаю автоматические обновления, но делаю это через WSUS. Это позволяет вам выбрать класс обновлений, которые вы хотите применить автоматически, чтобы вас не отвлекали от мелочей, которые вам не нужны, но вы получаете исправления для эксплойтов нулевого дня как можно скорее.
Я не думаю, что вопрос «разрешать обновления» и «не позволять им» быть правым или неправильным, кстати, это просто вопрос выбора того, на какие риски и неудобства вы готовы пойти. Если вы разрешите автоматическое выполнение обновлений, есть риски, а в противном случае - риски. Уравновесите их и сделайте осознанный выбор.
Вы можете подумать о поэтапном развертывании - патчи, выпущенные во вторник, сразу устанавливаются в тестовой среде и планируются к установке в четверг на производственных серверах, скажем, что дает вам два дня для обнаружения проблем в тестовой среде, которые указывают на блокировку или задержка определенного патча.
Если высокая доступность является такой большой проблемой, вам в любом случае следует использовать кластеризацию или балансировку нагрузки, что в любом случае должно покрывать время простоя из-за установки исправлений. В конце концов, почему простои из-за исправлений каким-то волшебным образом хуже, чем аппаратные сбои, которые могут произойти на любом одном устройстве в любое время?
Мы никогда не включаем автоматические обновления на нашем сервере. Он размещен в центре обработки данных, поэтому мы просмотрели статистику в Google Analytics, чтобы увидеть, в какое время трафик был минимальным, а затем запланировали установку обновлений на месте. Таким образом, если потребуется перезагрузка или что-то пойдет не так, это не повлияет на такое количество людей, как если бы Windows загрузила обновление в середине дня.
Как все здесь уже ответили: НЕТ! Мы используем System Centers Essentials для отправки обновлений на рабочие веб-серверы только ПОСЛЕ их установки на тестовые серверы.
Мы также получаем ежемесячные электронные письма с обновлениями от MS, чтобы мы точно знали, что такое каждое обновление и для чего оно нужно. Это значительно упрощает устранение неполадок, если вы точно знаете, что и когда было обновлено.
Точно нет. Слишком много раз меня учили на собственном горьком опыте, чтобы не допустить этого вздора. К сожалению, это означает, что применять патчи и обновления немного ленивее. Но пока мне еще не удалось взломать сервер, потому что я не сразу применил какой-то конкретный патч, но я иметь было очень много головных болей, вызванных перезагрузкой сервера в неудобное время или перезагрузкой и отказом запустить некоторые важные службы после установки патча.
Кстати, мы только что получили новый кластер из пяти машин через нашего поставщика услуг, очень крупного и известного интернет-провайдера из этой части мира. Когда мы получили учетные записи администратора и смогли войти в систему и начать настройку нашего программного обеспечения, я был очень рад увидеть, что эту обычную первую задачу уже взяли на себя сетевые системные администраторы. :)
Применение обновлений == случайные перезагрузки вашей системы, а не под вашим контролем. Это дает ульи SA. Кроме того, в прошлом были случаи взлома исправлений, поэтому вы редко хотите, чтобы они применялись, если вы не пробовали их в прошлом.
Один из подходов, который я изучал, - это переход на виртуализированную среду хостинга. Это позволяет вам опробовать обновление на непроизводственном экземпляре или даже применить обновление к автономному экземпляру и заменить его на производственный, если вы уверены, что все готово.
Точно нет. Обновления следует применять к серверам в нерабочее время и при наличии планов действий в чрезвычайных ситуациях, то есть достаточно времени для отката обновления в случае сбоя.
Как системный администратор, вы хотите, чтобы под вашим контролем было как можно больше переменных. Достаточно сложно не прийти утром на мертвый сервер! ;-)
Обратите внимание, что можно установить определенное время для обновлений, и что большинство обновлений происходит по вторникам. Таким образом, вы можете запланировать время для проверки поступающих и загруженных обновлений и знать, когда возникнут какие-либо потенциальные проблемы.
Хороший вопрос, который стоит задать себе: если что-то не так, что мне скажет мой вице-президент / ИТ-директор и т. Д.? Автоматизация может облегчить вам жизнь, но если возникнет проблема, вы будете тем, кто сгребут угли, и это может значительно усложнить задачу.
Я чертовски автоматизирую компьютеры, вам нужно несколько сотен. Серверы, хотя я планирую это и авторизую, поэтому, если что-то пойдет не так, мой @ $$ будет покрыт. Помните, что мы работаем с данными других людей и с ресурсами компаний, они всегда должны знать о рисках.