Глобальный сбой Microsoft сказался почти на всех, кроме России. Но это не повод расслабляться

Сбой систем Windows нарушил работу авиакомпаний, аэропортов, банков и СМИ по всему миру. Руководитель корпоративных практик ALP Group Александр Казеннов объясняет, что делать, чтобы не допустить подобных провалов в будущем.

В пятницу, 19 июля, на миллионах устройств с Windows 10 появился «синий экран смерти». По всему миру аэропорты не могли принимать самолеты, в США отменили более 1 400 рейсов, ограничил работу международный аэропорт Сиднея, пострадали железнодорожные службы Великобритании, прервалось вещание крупнейших телеканалов (ABC News, Sky News), наблюдались проблемы с проведением безналичных платежей через Visa, а в Израиле с техническими проблемами столкнулись больницы, банки, почта и системы оказания экстренной помощи.

Как позже выяснилось, хакеры в этот раз были ни при чём: глобальный сбой произошел в облачной платформе Microsoft Azure и был вызван ошибкой в обновлении от американского вендора решений по информационной безопасности CrowdStrike. Главный виновник сбоя — датчик Falcon, который должен блокировать кибератаки… но вместо этого вызвал «синий экран». Представители Microsoft сообщили, что «изменения конфигурации в части серверных рабочих нагрузок Azure вызвали перебои между хранилищем и вычислительными ресурсами, что привело к сбоям подключения и затронуло приложения Microsoft 365, зависящие от этих подключений».

Ошибка была обнаружена, и в тот же день был подготовлен патч. Но исправление требовало ручного обращения к системе, поэтому даже на частичное восстановление потребовалась половина пятницы. Илон Маск поспешил назвать сбой компьютерных систем Microsoft «крупнейшим провалом в истории IT», а журналисты окрестили его «цифровой пандемией».

Что интересно, России проблема массово не коснулась. Как многие помнят, Microsoft отключила российских корпоративных клиентов от облачных сервисов Azure в марте 2024 года. Кроме того, сбой затронул только устройства, на которых было установлено непопулярное в нашей стране антивирусное ПО CrowdStrike.

По заверениям наших критически значимых компаний, глобальный сбой не коснулся России благодаря успешному импортозамещению иностранного программного обеспечения. Однако нужно понимать, что у нас будут свои сбои — по той простой причине, что 100% совершенного софта на данный момент не существует.

Да и у Microsoft это не первый и не последний сбой. Например, 25 января 2023 года неудачное обновление глобальной вычислительной сети WAN на 7,5 часов парализовало работу целого ряда популярных облачных сервисов, включая Microsoft Teams, Outlook и Power BI.

Как обезопасить себя от подобных проблем? В первую очередь, обязательно создавать резервные серверы. Если на основном сервере произойдет сбой, то включится резервный. Кроме того, любые, даже самые минимальные обновления, стоит выкатывать сначала на основном сервере и только через определенное количество дней — на резервном.

Во-вторых, не спешить обновляться. Да, сейчас кейс был в основном про централизованный онлайн-сервис, но и для внутрикорпоративных критичных решений не стоит торопиться с обновлением до его тщательной проверки и обратной связи от рынка — всё ли в порядке. Как правило, на профильных форумах достаточно оперативно появляется информация о тех или иных сложностях обновлений и результатах установки. После выхода новых обновлений, патчей ПО, стоит выждать «театральную» паузу в паре с тестированием, посмотреть на результаты применения обновлений по рынку, и только после этого устанавливать новую версию софта к себе. Бывают ситуации, когда обновление критично — например, устраняет опасную уязвимость. Но даже в таких случаях стоит взвесить все за и против, и только потом обновляться. К слову, интересно было изучать комментарии отдельных компаний, о том, что их проблемы не затронули, потому что критическая инфраструктура всё еще на Windows 3.11. Видимо, тот случай, когда «работает — не трогай» с защитой от проникновений (надеюсь 🙂).

В-третьих, нужно продолжать работу над качеством продуктов и тестов. Сложность IT-систем только растет. Особенно когда речь идет о критической инфраструктуре, на QA-тестировании новых релизов нельзя экономить ни человеческие, ни временные ресурсы.

В-четвертых, имеет смысл заранее продумать план действий на случай нештатной ситуации, чтобы оперативно и качественно сработать и не быть застанными врасплох. Здесь нужно помнить, что проблемы могут произойти на любых узлах — не только, как в случае с Microsoft Azure, на этапе обновления программного обеспечения, но и по причине человеческого фактора, сбоя в оборудовании или ввиду природных катаклизмов. Произошедшее лишь напоминает о том, что софт тоже сбоит, и это нужно учитывать в плане реагирования. Подозреваю, что об этом все вспоминают в последнюю очередь.

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

А вы что думаете? Поделитесь своим мнением в комментариях ⬇