Патчи и обновления серверов: как не сломать прод

Две фразы на совещаниях звучат почти одинаково часто: «Обновим, когда будет окно» и «Лучше не трогать — работает же». Обе кажутся разумными. Обе в итоге дорого стоят. Пока обновления откладывают, на серверах копятся известные уязвимости. Пока ставят всё сразу в пятницу вечером, в понедельник не встаёт 1С, сайт отдаёт 500, а директор спрашивает, кто это разрешил.

Страх обновить и страх не обновить — одна и та же проблема. Нет процесса, есть удача. В типичной компании среднего размера админ один, подрядчик «на звонках», тестового контура нет, окно работ месяцами никто не согласовывал. Patch management существует как идея в голове, а не как календарь с ролями, проверками и планом отката.

Инциденты здесь редко бывают «технически сложными». Чаще это управленческая дыра: некому сказать «ставим», некому сказать «не ставим до среды», некому ответить за результат. Пока ответственность размыта, любой CVE превращается в переписку, а любой патч — в риск персональной вины.

Сценарии, которые узнают почти все

Первый сценарий начинается с аудита. Приходит список уязвимостей, часть из них критичная и уже с публичными эксплойтами. Команда кивает: «Закроем в ближайшее окно». Окна нет три месяца. Потом случается неприятность — и выясняется, что патч давно лежал в репозитории. Не хватило не знания, а владельца перезагрузки и проверки служб после неё.

Второй сценарий — обратный. Обновления всё‑таки ставят. Без снимка виртуальной машины, без тестовый контур, без предупреждения бизнеса. После перезагрузки ломается зависимость, которую никто не считал важной. Без неё не работает обмен, почта или лицензирование. Откат занимает ночь. Компания запоминает не аббревиатуру CVE, а сорванные отгрузки и злые письма клиентов.

Третий сценарий — зоопарк ответственности. Windows‑контур у одного подрядчика, Linux — у другого. Один патчит по расписанию вендора, второй — «когда освободится». Единой картины рисков нет. В отчёте руководству всё «в целом спокойно», пока не потребуют закрыть конкретную дыру за семьдесят два часа.

Четвёртый сценарий — устаревшая платформа. Сервер «ещё отвечает», CentOS или старый Windows Server формально живы. По факту security‑контур уже неуправляем: нормальных обновлений нет либо они настолько рискованны, что их боятся сильнее атаки. Здесь разговор уже не про вторничный патч, а про миграцию или жёсткую изоляцию.

Почему ломается процесс, а не только пакеты

Чаще виноват не «ленивый администратор», а отсутствие правил. Нет классификации: что ставить за сутки, что за две недели, что можно отнести в квартальное окно. Нет метрики в днях по открытым критичным уязвимостям. Нет даже минимального стенда для проверки 1С, сайта и почты до боя.

Отдельно мешает культура «не беспокоить бизнес». Патчи начинают ассоциировать исключительно с простоем. В итоге их откладывают именно потому, что когда‑то одно обновление уже всё сломало — без плана отката и без нормальной коммуникации. Страх закрепляется как корпоративная привычка.

Где команды наступают на одни и те же грабли

• Update-All-на боевом контуре. На ноутбуке это удобно. На сервере с десятком служб-—-лотерея.
• Нет снимка и свежего бэкапа перед окном. Откат превращается в археологию.
• Работы-«молча». Бизнес узнаёт о патче по недоступности сервиса.
• Смешение-security-и-feature. Hotfix-уязвимости и-major‑апгрейд ОС требуют разной глубины теста.
• Нет короткого отчёта после работ. Через месяц невозможно сказать, что закрыли и что отложили осознанно.

Как выглядит взрослый-runbook

Сначала обновления делят на категории. Критичные с активной эксплуатацией идут быстро, но с понятным-rollbackом. Обычные-security-—-в горизонте одной‑двух недель со-staging. Работы по стабильности и крупные апгрейды-—-только через полноценный тест и согласованное окно.

Для-smb-часто хватает простого контура:-snapshot-виртуальной машины или облачный снимок,-staging-с тем же стеком, быстрая проверка‑тест ключевых сценариев, работы в часы минимальной нагрузки, уведомление ответственным заранее. После-—-короткий отчёт: что поставили, что перезапускали, что-rollbackили, какие риски закрыты.

Важно заранее закрепить источники правды: бюллетени-Microsoft, уведомления дистрибутивов-Linux, письма вендоров прикладного ПО. Иначе всё снова скатывается к чтению рассылок-«когда вспомнят». Имеет смысл вести единый список уязвимостей и статусов-—-даже в простой таблице, лишь бы она была живой и у неё был хозяин.

Исключения тоже оформляют. Иногда патч действительно нельзя ставить сразу: сертифицированная связка вендора, ожидание апдейта-1С, конфликт с железом. Тогда нужна дата пересмотра и компенсирующие меры, а не вечное-«потом». Роли лучше развести явно: кто утверждает исключение, кто проверяет-staging, кто нажимает кнопку на проде. Отпуск одного человека не должен автоматически открывать окно для инцидента.

Если внутренней экспертизы мало, разумный путь-—-администрирование с-runbookом обновлений: не разовые-«поставь патчи», а календарь, ответственность и критерии готовности.

Что получает бизнес

Хороший patch management не про «всегда самая новая версия». Он про управляемый риск. Дыры закрывают в срок. Прод не ломают сюрпризом. Если простой и случается, он заранее согласован и ограничен по времени.

Для директора это перевод с языка CVE на язык решений. Можно увидеть, сколько критичных уязвимостей открыто, какой средний срок закрытия, когда следующее окно и какова цена стратегии «не трогать». Споров становится меньше не потому, что все согласны обновлять всегда, а потому что правила заранее отвечают на вопросы «почему сейчас» и «почему не сейчас».

На горизонте квартала регламент честно подсвечивает тупики: сервисы на платформах без нормального security‑контура. Тогда начинается взрослый разговор о миграции или изоляции — раньше, чем тот же факт обнаружит атакующий или внешняя проверка.

Команда перестаёт жить аварийными ночами. Обновления становятся скучной регулярной практикой. Именно скучные практики защищают выручку лучше героизма. Серверы либо обновляют по плану, либо однажды обновляет инцидент. Второй вариант почти всегда дороже — деньгами, репутацией и нервами клиентов.