Как снизить риск сбоя IT-систем

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

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

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

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

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

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

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

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