Я нашел много информации о правильном подходе к исправлению серверов Windows (например, Обновлять или не обновлять?), но я нахожусь в ситуации, когда большая часть этой информации на данный момент просто непрактична.
Я ищу наименее плохой вариант в сценарии с ограниченными ресурсами. В частности, предполагая, что это мои единственные варианты: следует ли мне просто слепо применять «важные» (в отличие от «необязательных») обновлений Windows на производственных серверах, или мне лучше не применять их вообще?
Вот небольшой контекст: я - администратор баз данных в небольшом магазине с примерно 15 серверами, на которых размещены экземпляры SQL Server; меня беспокоят только блоки SQL (т.е. меня не беспокоят блоки Exchange, контроллеры домена и т. д.). Мы работаем 24 часа в сутки, но у меня нет регулярных плановых окон обслуживания (т.е. мне нужно явно запланировать одно с нашей группой операций / поддержки, если мне нужно перезагрузиться и т. Д.).
Мне достаточно комфортно управлять сервером, чтобы знать свои пределы и ничего не нарушать, но мне не хватает глубоких знаний. Я говорил об этом с сетевыми / серверными специалистами, но они, по сути, сказали мне, что у нас нет процесса или политики для этого, и что я должен просто руководствоваться своим здравым смыслом. Итак, они знают, что это проблема, но она не будет решена в ближайшее время. У меня нет навыков или времени, чтобы самостоятельно реализовать хорошее решение, я просто пытаюсь минимизировать свой риск, насколько это возможно, с помощью ресурсов, которые у меня есть сегодня. С философской точки зрения я склонен применять патчи, но признаю, что, вероятно, я не совсем понимаю риски, связанные с этим.
Подведем итог в форме ответного вопроса: безопаснее ли патчить вслепую или не патчить вообще?
Я открыт для других вариантов, но они в значительной степени должны быть такими же простыми и гибкими, как ручное применение обновлений Windows более или менее специальным образом. (это отстой, я знаю, но это моя реальность на данный момент и на ближайшее будущее)
или вообще не патчить?
В наши дни это просто не вариант. Ваша система почти наверняка будет скомпрометирована в какой-то момент, если вы не примените необходимые исправления безопасности. Единственный реальный вопрос заключается в том, как долго вы можете ждать после выпуска патча, прежде чем его нужно будет установить.
патч вслепую
В идеале вы должны протестировать, но если вы не можете проверить, то, по крайней мере, уменьшите потенциальный ущерб, убедившись, что у вас есть чрезвычайно хорошо протестированная система резервного копирования и восстановления. Поэтому, когда обновление действительно что-то ломает, вы можете восстановить его. Тогда вы должны выдержать некоторое время простоя для применения обновлений.
В общем, я обычно применяю патчи обновления Windows напрямую. Хотя у меня есть отличные резервные копии, а также у меня есть точка восстановления, к которой я мог бы вернуться. Поскольку обычно существуют значительные исправления безопасности, я бы не стал ждать очень долго.
Что касается тестирования, то я не обнаружил, что я могу хорошо протестировать что-либо с массивом различных элементов, таких как Windows, без значительного количества времени. И снова с высоким профилем безопасности и отличным резервным копированием я не могу ждать. У меня вообще не было проблем. Вероятно, на всякий случай целесообразно сначала сделать ваши серверы разработки и доработать до производственных серверов.
Одно замечание, патчи могут открывать другие нарушения, чем те, с которыми вы сталкиваетесь.
Итак, у вас есть ответ .... это зависит от обстоятельств!
Судя по комментариям, у вас уже есть хороший процесс резервного копирования / восстановления, доступный с помощью возможности создания снимков вашего гипервизора. С осторожностью они незаменимы при применении непроверенных обновлений.
Ответ Zoredache действительно охватывает ваши базы до обновления. Он не покрывает непосредственные последствия. Что вам действительно нужно, так это готовый способ испытать ваши системы после завершения. Одно дело иметь обновление, которое не было протестировано перед установкой. Другое дело - оставлять его непроверенным, если у вас есть возможность что-то с этим сделать.
Мое предложение по SQL - написать макет приложения (при условии, что у вас есть интерфейс) или готовый способ запустить ваши общие хранимые процедуры и проверить результаты, как вы ожидаете. Мой опыт работы с обновлениями, связанными с SQL, всегда (до сих пор) был сосредоточен на том, чтобы не допустить запуска службы или одной из основных функций наших приложений, в которых возникла проблема. За последние 10 лет имитация несколько раз спасала мой бекон.