Обновление защитного агента CrowdStrike разом вывело из строя массу серверов и рабочих станций на Windows по всему миру. Машины уходили в синий экран и зацикливались на перезагрузке, то есть переставали загружаться вообще. Для бизнеса это означало одно: сервисы лежат, сотрудники не работают, а счётчик потерь идёт каждую минуту.
Ниже разберём, почему один внешний файл смог обрушить инфраструктуру, как вернуть такие серверы в строй вручную и, главное, что сделать заранее, чтобы следующий подобный инцидент не превращался в простой на весь день.
Что именно сломалось и почему это так больно
Корень проблемы был в одном повреждённом файле обновления, который агент CrowdStrike подгружал на уровне ядра операционной системы. Когда сбойный компонент работает так глубоко, ошибка в нём роняет не отдельную программу, а всю систему целиком, ещё до того как машина успевает полностью загрузиться.
Отсюда и масштаб последствий. Сервер не просто работает медленно, он не поднимается. Удалённо подключиться нельзя, потому что сеть и службы управления стартуют позже, чем происходит сбой. Привычные инструменты администрирования бесполезны, пока машина не загрузилась. На практике это значит, что к каждому серверу и к каждому рабочему месту приходится подходить отдельно, и время восстановления растёт пропорционально размеру парка.
Для бизнеса важна простая мысль: когда сбой случается на уровне ядра и приходит сразу на все машины через автоматическое обновление, у вас нет одной кнопки, чтобы всё починить. Есть ручная работа, умноженная на количество узлов.
Быстрое решение: загрузка в безопасном режиме
Несмотря на масштаб, само исправление оказалось несложным. Сбой вызывал конкретный файл агента, и достаточно было его удалить, чтобы система снова загружалась нормально. Проблема в том, что обычным образом до этого файла не добраться: операционная система падает раньше, чем вы получаете доступ к диску.
Здесь и нужен безопасный режим. Это особый вариант загрузки, в котором система стартует с минимальным набором драйверов и служб и не подгружает проблемный компонент. В таком режиме машина становится управляемой, и можно вручную убрать сбойный файл.
Общая логика восстановления выглядела так:
- загрузить сервер в безопасном режиме, чтобы обойти автоматическую подгрузку проблемного компонента;
- добраться до служебной папки агента и удалить повреждённый файл обновления;
- перезагрузить машину в обычном режиме и убедиться, что система поднимается штатно.
Решение рабочее, но у него есть жёсткое условие, и о нём честно стоит сказать: вам всё равно нужен доступ к загрузке в безопасном режиме на каждой машине. На физическом сервере в собственной стойке это означает руки на месте или удалённую консоль управления. На зашифрованном диске потребуется ключ восстановления. На сотнях машин это означает часы ручной работы, даже когда сама процедура занимает минуты. Именно поэтому быстрый фикс закрывает аварию, но не закрывает вопрос устойчивости.
Почему ручной фикс это лечение симптома, а не причины
Удаление одного файла вернуло серверы в строй, но не убрало главную уязвимость: внешнее обновление дошло до всей боевой инфраструктуры сразу, без проверки и без возможности быстро остановить раскат. Любой следующий сбойный апдейт, от того же поставщика или от другого, повторит сценарий.
Поэтому правильный вывод из инцидента лежит не в технике удаления файла, а в дисциплине доставки изменений. Несколько практик снимают большую часть таких рисков:
- Контроль над обновлениями. Апдейты, особенно те, что работают на уровне ядра, не должны приходить напрямую от поставщика на каждый боевой сервер в момент выхода. Между вендором и вашей инфраструктурой нужен этап, где вы решаете, что и когда устанавливать.
- Проверка перед раскатом. Новое обновление сначала разворачивается на тестовом контуре и на небольшой группе машин. Если оно вызовет сбой, проблема проявится на нескольких узлах, а не на всём парке одновременно.
- Поэтапное распространение. После успешной проверки изменение идёт волнами. Это даёт окно, чтобы заметить проблему и остановить раскат до того, как пострадает весь бизнес.
- Готовая процедура восстановления. Доступ к безопасному режиму, ключи шифрования дисков и понятная инструкция должны быть подготовлены заранее, а не искаться в момент аварии. Разница между этими двумя ситуациями измеряется часами простоя.
Каждый из этих пунктов переводится в деньги напрямую. Контролируемый раскат означает, что сбойное обновление задевает малую долю инфраструктуры, а не всю. Подготовленная процедура восстановления означает, что вы поднимаете сервисы за часы, а не за сутки. Для компании, чья выручка зависит от работающих систем, это разница между неприятным инцидентом и публичным простоем, о котором потом узнают клиенты.
Итог
Сбой CrowdStrike показал две вещи сразу. Первая: даже глобальную аварию иногда лечит удаление одного файла в безопасном режиме, и знать эту процедуру полезно. Вторая, более важная: если внешнее обновление способно разом обрушить весь ваш парк серверов, проблема не в конкретном вендоре, а в том, как устроена доставка изменений и насколько вы готовы к восстановлению.
Быстрый фикс закрывает текущую аварию. Устойчивость закрывает класс таких аварий целиком, и закладывается она заранее, дисциплиной обновлений и отрепетированным планом восстановления.
Если хотите понять, где ваша инфраструктура уязвима к подобному сценарию, до того как это проверит очередное обновление, мы предлагаем бесплатный технический аудит инфраструктуры. Разберём, как у вас устроена доставка обновлений и план восстановления, и дадим конкретные рекомендации. Оставьте заявку на странице https://myod.it/contact-us/
