Руководитель корпоративных практик ALP Group Александр Казеннов выдвинул свою версию, почему произошел глобальный сбой Windows
По заверениям наших критически значимых компаний, глобальный сбой не коснулся России благодаря успешному импортозамещению иностранного программного обеспечения. Однако нужно понимать, что у нас будут свои сбои — по той простой причине, что 100% совершенного софта на данный момент не существует.
Да и у Microsoft это не первый и не последний сбой. Например, 25 января 2023 года неудачное обновление глобальной вычислительной сети WAN на 7,5 часов парализовало работу целого ряда популярных облачных сервисов, включая Microsoft Teams, Outlook и Power BI.
Как обезопасить себя от подобных проблем? В первую очередь, обязательно создавать резервные серверы. Если на основном сервере произойдет сбой, то включится резервный. Кроме того, любые, даже самые минимальные обновления, стоит выкатывать сначала на основном сервере и только через определенное количество дней — на резервном.
Во-вторых, не спешить обновляться. Да, сейчас кейс был в основном про централизованный онлайн-сервис, но и для внутрикорпоративных критичных решений не стоит торопиться с обновлением до его тщательной проверки и обратной связи от рынка — всё ли в порядке. Как правило, на профильных форумах достаточно оперативно появляется информация о тех или иных сложностях обновлений и результатах установки. После выхода новых обновлений, патчей ПО, стоит выждать «театральную» паузу в паре с тестированием, посмотреть на результаты применения обновлений по рынку, и только после этого устанавливать новую версию софта к себе. Бывают ситуации, когда обновление критично — например, устраняет опасную уязвимость. Но даже в таких случаях стоит взвесить все за и против, и только потом обновляться. К слову, интересно было изучать комментарии отдельных зарубежных компаний, о том, что их проблемы не затронули, потому что критическая инфраструктура всё еще на Windows 3.11. Видимо, тот случай, когда «работает — не трогай». Правда, такие компании берут на себя повышенный риск подверженности хакерам — старый софт всегда более уязвим к проникновениям.
В-третьих, нужно продолжать работу над качеством продуктов и тестов. Сложность IT-систем только растет. Особенно когда речь идет о критической инфраструктуре, на QA-тестировании новых релизов нельзя экономить ни человеческие, ни временные ресурсы.
В-четвертых, имеет смысл заранее продумать план действий на случай внештатной ситуации, чтобы оперативно и качественно сработать и не быть застанными врасплох. Здесь нужно помнить, что проблемы могут произойти на любых узлах — не только, как в случае с Microsoft Azure, на этапе обновления программного обеспечения, но и по причине человеческого фактора, сбоя в оборудовании или ввиду природных катаклизмов. Произошедшее лишь напоминает о том, что софт тоже сбоит, и это нужно учитывать в плане реагирования. Подозреваю, что об этом все вспоминают в последнюю очередь.
В-пятых, разработчикам нужно в целом ответственнее подходить к решению рабочих задач. Судя по масштабу крушений, инцидент Microsoft Azure легко выявлялся на этапе внутренних тестов до выпуска в продуктивную среду.
