Время от времени я вхожу в производственные окна web / db / tools и вижу типичное сообщение:
30 пакетов могут быть обновлены. 16 обновлений - это обновления безопасности.
Мой вопрос в том, как вы все справляетесь с обновлениями на своих производственных версиях Ubuntu? Вы автоматизируете эти обновления? Вы устанавливаете для них время простоя? Проблема в том, что вы никогда не знаете, когда обновление что-то сломает, например, существующий файл конфигурации и т. Д.
Другая часть этой проблемы заключается в том, что не отставать от патчей - это «хорошо», но патчи выпускаются почти ежедневно. Сколько запланированных отключений нужно сделать, если каждый день доступно новое исправление безопасности?
Я думаю, была бы очень полезна ветка ответов о том, как вы управляете своими обновлениями.
Нет ничего особенного в исправлении Ubuntu vs. Windows, RHEL, CentOS, SuSE, debian и т. Д.
Основное состояние ума, в котором вы должны находиться при разработке процедуры исправления, - это предположить что-то воля перерыв.
Вот некоторые из основных рекомендаций, которые я обычно использую при разработке установки патча:
Это может включать использование WSUS или зеркал <your_os_here> на внутреннюю машину управления исправлениями. Предпочтительно тот, который может централизованно запрашивать и сообщать вам статус исправлений, установленных на ваших индивидуальных машинах.
Когда это возможно, по мере выхода исправлений пусть центральный сервер скопирует их на отдельные машины. Это действительно просто экономия времени, так что вам не нужно ждать, пока они загрузятся и установятся, вам просто нужно начать установку во время окна вашего патча.
В соответствии с моей основной теорией, что исправления ломают вещи, убедитесь, что у вас есть окно простоя для применения исправлений на достаточно долгое время для устранения критических проблем и, возможно, откатить исправление. Совершенно необязательно, чтобы люди сидели и тестировали патчи. Лично я сильно полагаюсь на свои системы мониторинга, чтобы я знал, что все работает на самом минимальном уровне, который нам может сойти с рук. Но также будьте готовы к тому, что люди приступят к работе. У вас всегда должен быть кто-то, готовый ответить на звонок - желательно, не тот парень, который до трех часов ночи латал коробки.
Как и все остальное в IT, сценарий, сценарий, затем еще сценарий. Скрипт загрузки пакета, запуска установки, зеркала. По сути, вы хотите превратить окна с заплатками в присмотр за детьми, которому просто нужен человек на случай, если что-то сломается.
Это дает вам возможность не исправлять некоторые серверы, если по какой-либо причине они не могут быть исправлены "в назначенную ночь". Если вы не можете сделать их в ночь 1, потребуйте, чтобы они были бесплатными в ночь 2. Также позволяет поддерживать количество серверов, на которых одновременно устанавливаются исправления, в нормальном состоянии.
Самое главное следите за патчами! Если вы этого не сделаете, вы обнаружите, что вам нужно делать очень большие 10+ часовые окна исправлений, чтобы вернуться к той точке, где вы оказались в затруднительном положении. Введено еще больше точек, в которых что-то может пойти не так, и намного сложнее определить, какой патч вызвал и выпустил.
Другая часть этой проблемы заключается в том, что не отставать от патчей - это «хорошо», но патчи выпускаются почти ежедневно. Сколько запланированных отключений нужно сделать, если каждый день доступно новое исправление безопасности?
Патчить сервер один раз в месяц или один раз в два месяца - ИМХО - очень достижимая и приемлемая цель. Более того, и вы будете постоянно обновлять серверы, тем более что вы начнете попадать в ситуации, когда у вас есть сотни исправлений, которые необходимо применить на каждом сервере.
Насколько много окон нужно в месяц? Это зависит от вашего окружения. Сколько у вас серверов? Какое время требуется для ваших серверов?
Меньшие среды, которые имеют размер 9x5, вероятно, могут обойтись одним окном патча в месяц. Для больших круглосуточных магазинов может понадобиться два. Для очень большого размера 24x7x365 может потребоваться скользящее окно каждую неделю, чтобы каждую неделю обновлять разные наборы серверов.
Найдите частоту, которая подходит вам и вашей среде.
Следует иметь в виду, что обновление на 100% - это невозможно цель достичь - не позволяйте отделу безопасности говорить вам иначе. Делайте все возможное, не отставайте слишком далеко.
Дела, которые необходимо сделать:
Чего следует избегать:
На всех наших машинах с Ubuntu установлены версии LTS.
Мы просто автоматически устанавливаем все обновления - конечно, это не «лучшая практика», но у нас относительно небольшой магазин, и у нас нет среды тестирования / разработки / производства для каждой отдельной службы. Обновления LTS обычно довольно хорошо протестированы и в любом случае минимально инвазивны.
Очевидно, что обновление до новой версии требует больше усилий.
Еще один момент, на который стоит обратить внимание: если вы привыкли к Windows, вы будете удивлены, что большинство обновлений Linux не требуют простоя или перезагрузки. Некоторые делают, например, обновления ядра. Но обновления, требующие перезагрузки или простоя, обычно помечаются как таковые и могут обрабатываться по отдельному расписанию.
Мы занимаемся обновлениями для систем ubuntu LTS следующим образом:
Следующим логическим шагом для нас является устранение информации о сеансах в памяти, чтобы мы могли просто повторно развертывать инфраструктуру каждый день или даже несколько раз в день, не затрагивая клиентов, и исключить этап (2).
Этот подход требует минимального обслуживания и полностью позволяет избежать окон на обслуживание.
Я бы порекомендовал обрабатывать откаты пакетов. Видеть Транзакции и откат с помощью Debian для предложения, как это сделать, поскольку иногда вам нужно быстрое исправление для обновления, которое что-то ломает.