Сбои цифровых систем происходят регулярно. Чаще всего речь идет о мимолетном, но раздражающем подвисании приложения. Но иногда системы дают массовый сбой, прерывая работу бизнеса и критически важных систем. При этом обезопасить компанию от IT-провала все же можно. Руководитель корпоративных практик ALP Group Александр Казеннов назвал топ-5 способов снизить риск массового сбоя.
19 июля 2024 года на миллионах устройств с Windows 10 появился «синий экран смерти». Это произошло из-за глобального сбоя на облачной платформе Microsoft Azure после ее обновления. По всему миру нарушилась работа аэропортов и железнодорожных служб, крупные телеканалы временно перестали вещать, а в некоторых странах технические проблемы помешали работе почт, банков и больниц.
Глобальный сбой произошел не по вине хакеров. Он был вызван ошибкой в обновлении от американского вендора решений по информационной безопасности CrowdStrike. Представители Microsoft сообщили, что «изменения конфигурации в части серверных рабочих нагрузок Azure вызвали перебои между хранилищем и вычислительными ресурсами, что привело к сбоям подключения и затронуло приложения Microsoft 365, зависящие от этих подключений». Ошибку обнаружили и сразу подготовили патч. Однако чтобы исправить ситуацию, нужно было обратиться к системе вручную, поэтому на восстановление понадобились почти сутки. Илон Маск назвал сбой компьютерных систем Microsoft «крупнейшим провалом в истории IT», а журналисты окрестили его «цифровой пандемией».
России глобальный сбой не коснулся. Критически значимые компании уверяют, что так произошло, благодаря успешному импортозамещению иностранного программного обеспечения. Однако важно понимать, что 100% совершенного софта пока что не существует, поэтому у нас тоже могут быть массовые сбои и к ним нужно быть готовым.
Создавайте резервные серверы
Создание резервного сервера может показаться трудозатратным, но это самый надежный способ обезопасить себя от сбоя. Такие серверы обеспечивают сохранение данных и являются обязательной частью успешного плана восстановления. Если на основном сервере произойдет сбой, то включится резервный, и у вас появится время исправить все ошибки, не останавливая при этом работу. В случае же отсутствия сервиса данные будут потеряны, работа притормозится, и на восстановление уйдет значительно больше времени. Резервные серверы также защищают от хакерских взломов и кибератак. Кроме того, любые, даже самые минимальные обновления, стоит протестировать сначала на основном сервере и только через определенное количество дней — на резервном. Таким образом вы защитите себя от возможных ошибок в вышедшем обновлении.
Не спешите обновляться
Недавний кейс Microsoft касался преимущественно централизованного онлайн-сервиса, но при принятии внутрикорпоративных решений также не стоит спешить с обновлением. Лучше дождаться его тщательной проверки и получить обратную связь от рынка. Как правило, если с установкой обновления и дальнейшей эксплуатацией возникли сложности, информация быстро появляется на специализированных форумах. После выхода новых патчей стоит повременить с тестированием, посмотреть, как обновление применяется на рынке, какие возникают сложности, и только после этого устанавливать новую версию софта к себе. Таким образом вы обезопасите себя от возможных негативных последствий обновления и будете готовы ко всем техническим трудностям. Бывают ситуации, когда обновление критично — например, устраняет опасную уязвимость. Но даже в таких случаях стоит взвесить все за и против, и только потом принимать решение.
Работайте над качеством продукта
Не стоит пренебрегать качеством разрабатываемых продуктов. Технологии постоянно развиваются, и сложность IT-систем только растет. Поэтому необходимо постоянно совершенствовать программное обеспечение и тщательно подходить к QA-тестированию новых релизов. Не стоит экономить на нем ни человеческие, ни временные ресурсы, особенно если речь идет о критической инфраструктуре. Важность QA-тестирования трудно переоценить. Оно позволяет удостовериться, что продукт должным образом выполняет все заявленные функции и не делает того, что не должен. Уделяя процессу QA-тестирования должное внимание, вы обеспечиваете высокое качество продукта, а также снижаете будущие затраты на исправление ошибок.
- Разработайте план на случай сбоя
К сожалению, какие бы вы ни прилагали усилия, полностью защитить себя от потенциального сбоя невозможно: пока что не существует такого полностью идеального софта. Поэтому имеет смысл заранее продумать план действий на случай критической ситуации, чтобы она не застала вас врасплох и вы сработали оперативно и качественно. Здесь важно помнить, что проблемы могут быть разноплановыми и встречаться на любых узлах — не только на этапе обновления программного обеспечения. Причиной поломки может стать человеческий фактор, сбой в оборудовании или природные катаклизмы. Произошедшее лишь напоминает о том, что софт тоже сбоит, и это нужно учитывать при подготовке плана реагирования.
Будьте внимательны на всех этапах работы, не игнорируйте регламенты
Анализируя масштаб крушений, становится понятно, что инцидент Microsoft Azure легко выявлялся с помощью внутренних тестов и ошибка могла быть ликвидирована до выпуска решения в продуктивную среду. Поэтому разработчикам нужно в целом более ответственно подходить к решению рабочих задач, не разделяя их на менее и более значимые. Это касается всех этапов работы. Такой подход эффективнее всего поможет избежать будущих сбоев.
Важно помнить, что вероятность сбоя остается всегда, и мы можем только снизить риски и подготовиться к самому плохому сценарию. «Мелочей» в работе IT-систем не существует, ведь даже пропущенная в одной строчке кода запятая может потенциально «поломать» систему. Необходимо, чтобы индустрия более ответственно подошла к вопросу повышения качества разработки и тестирования цифровых продуктов. Тогда риск повторения «крупнейшего провала в истории IT» будет минимальным.
