Как бизнесу выживать в эпоху «черных лебедей»: принципы антихрупкой архитектуры ИТ

Андрей Янкин: Конечно, хочется построить неуязвимую ИТ-архитектуру раз и навсегда, но мир настолько изменчив, особенно в части ИТ и информационной безопасности, что это маловероятно. Настоящая киберустойчивость бизнеса — это не единожды и на десятилетия построенная надежная как швейцарские часы ИТ-инфраструктура. Это способность очень быстро меняться и становиться сильнее во время и после атаки или сбоя. Мне нравится термин «антихрупкая ИТ-архитектура», описывающий решение этой проблемы. Антихрупкость ИТ позволяет принимать разнообразные удары (кибератаки, неожиданный уход вендоров, крупные аварии) с приемлемым для бизнеса ущербом. А главное — делать вывод из неприятностей, которые происходят с тобой и с соседом, и оперативно меняться. Причем не за годы, как раньше, а за считаные дни.

Юрий Семенюков: Думаю, что лучше всего ответить на этот вопрос, рассматривая эволюцию ИТ за последние 20 лет. ИТ-инфраструктура, которую компании строили в 2000-е и 2010-е годы, всегда проектировалась «вокруг» надежности и отказоустойчивости: применялись проверенные enterprise-решения, дорогие аппаратные и программные системы ведущих вендоров. Но такая архитектура применительно к теории антихрупкости лишь казалась устойчивой в тех условиях, потому что упор делался на два основных фактора: максимальная централизация и максимальная надежность одного компонента. Сервер, система хранения данных, СУБД — каждый из этих компонентов был очень сложным и дорогим и проектировался так, чтобы допускать минимальное время простоя. Дата-центр был единственным и основным и обрабатывал всю нагрузку. Переключение на резерв считалось событием масштаба катастрофы — например, вследствие пожара, землетрясения, глобального блэкаута.

Современная ИТ-архитектура меняется в силу двух основных факторов. Изменился характер прикладной нагрузки, а также факторы рисков и угроз. Для обработки современных пользовательских нагрузок прикладное ПО перешло от парадигмы «монолитов» к парадигме «микросервисов». От этого меняется и ИТ-ландшафт. Вместо надежности одного дорогого компонента ставка сделана на быструю масштабируемость и взаимозаменяемость элементов. Дорогие серверы за миллионы долларов превратились в десятки и сотни стандартных и недорогих x86-«пицца-боксов». СУБД от концепции единой центральной базы перешли к концепции «множество различных баз под разные задачи и типы данных». СХД от концепции единого массива перешли к распределенному хранению и программно-определяемым хранилищам. ЦОДы тоже поменялись. Больше нет главного и резервного. Несколько равноправных площадок делят нагрузку между собой равномерно. Это децентрализация, которая и формирует антихрупкость.

Сами риски также изменились. Пандемия и массовая удаленка, уход вендоров, санкции, шифровальщики — это угрозы, которые никто не закладывал в модели рисков десятилетней давности. Классическая централизованная архитектура ИТ оказалась к ним не готова. И именно поэтому эта инфраструктура казалось устойчивой, но на деле оказалась хрупкой. Антихрупкая архитектура ИТ в виде распределенной динамической децентрализованной системы противостоит подобным сбоям. Это и есть проявление данной концепции. Под давлением система становится только сильнее.

Сергей Андронов: Чтобы инфраструктура не просто выдерживала удары, а становилась сильнее, нужны гибкие механизмы изменений и развитый change management. Любая стрессовая ситуация должна рассматриваться не как форс-мажор, а как штатная процедура. Под это выстраивается и организационная структура компании.

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

Если говорить о технических аспектах, то в антихрупкой ИТ-инфраструктуре ключевую роль играет взаимосвязанность компонентов. На всех уровнях должны действовать единые правила и принципы построения, закрепленные в стандартах и поддерживаемые гибкими процессами управления архитектурой. Важно уйти от статичности. Долгое время инфраструктура компаний оставалась неизменной: ее строили один раз, прописывали риски и ждали, когда они реализуются. Радовались, если система отрабатывала их корректно — например, включался резервный канал при падении сети или восстанавливалась резервная копия вместо СХД.

Андрей Янкин: Система должна получать оперативную информацию об угрозах, иметь «план Б» на случай катастрофы и быстро меняться. В части ИБ это смещение акцента с построения непреодолимого периметра к средствам киберразведки, развитию мониторинга, замедлению распространения атаки в сети, развитию средств восстановления. Сейчас способность к изменениям в первую очередь определяют люди, а не техника. Правда, сделать в одиночестве это почти невозможно, а потому развиваются различные сообщества и коллаборации между вендорами, интеграторами и пользователями систем. Также для этих целей все активнее применяется и ML.

Юрий Семенюков: Поддержу коллег. На мой взгляд, три фактора являются ключевыми: гибкость, скорость изменений и минимизация человеческого участия. Антихрупкая инфраструктура не просто выдерживает стрессы и сбои. Она адаптируется и эволюционирует каждый раз. Это то, что отсутствовало в монолитных классических архитектурах.

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

Программно-определяемая инфраструктура обеспечивает автоматическую реакцию и, как следствие, скорость отработки инцидента. Упал сервер или выросла нагрузка — дополнительные мощности запускаются в облаке скриптами и автоматизацией, а не людьми. Применение программно-определяемых компонентов (SDN, SDS и т.д.) позволяет гибко менять конфигурацию и даже заменять технологический стек, если выбранный не подходит по каким-то причинам. Это можно делать без необходимости многомесячных процедур закупки аппаратных решений другого производителя.

Человек больше не тушит сбои вручную и не отрабатывает все запросы на изменения по заявкам со сроком ответа в две недели. Он реализует автоматизацию и закладывает правила, описывая «инфраструктуру как код» (Infrastructure-as-Code). Все остальное выполняют скрипты: от перераспределения нагрузки до самовосстановления.

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

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

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

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

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

Андрей Янкин: Антихрупкость — это в первую очередь про способность меняться. Поэтому инерция и проверенные временем способы действовать — главные враги антихрупкости.

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

Юрий Семенюков: На конференции мы будем демонстрировать концепцию глобальной антихрупкости. Наша цель — показать практические подходы и конкретные методы, которые подтверждают эти принципы. Сообщество экспертов из разных областей ИТ — инфраструктура, сети, безопасность, прикладная разработка — поделятся опытом, покажут примеры, конфигурации и способы построения инфраструктурных подсистемных компонентов, которые соответствуют принципам антихрупкости. Важен именно комплексный подход на всех уровнях ИТ — от железа до приклада. Современная инфраструктурная платформа неотделима от прикладного ПО, которое на ней работает, и зоны ответственности сегодня практически размылись.

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

Кроме того, мы покажем, как строить отказоустойчивые конфигурации между несколькими ЦОДами с использованием современных доступных технических решений, особенно в случаях, когда невозможно применять западные.

В программе также будут демонстрации по распределенным базам данных современного типа, по решениям под ИИ и LLM и многое другое. Все это будет представлено в виде практических воркшопов с готовыми рабочими конфигурациями, которые эксперты подробно разберут и объяснят.

Андрей Янкин: Сейчас совершенно невозможно выстроить ИБ без вовлечения ИТ для харденинга инфраструктуры, сегментации, патч-менеджмента и т.п. Также бессмысленно, например, строить РЦОД и по старинке считать, что главная угроза для доступности данных — это пожар или отключение электричества, забывая о шифровальщиках. На IT Elements есть шанс вместе обсудить проблемы устойчивости ИТ-инфраструктуры людям из разных, казалось бы, миров — разработчикам, безопасникам, инфраструктурщикам, сетевикам — и обогатить тем самым картину мира друг друга.

Сергей Андронов: Мы уже определили, что компоненты антихрупкой ИТ-инфраструктуры между собой очень сильно переплетены. Именно поэтому на IT Elements мы показываем все уровни инфраструктуры и обсуждаем архитектурные подходы, которые позволяют сделать ее соответствующей современным требованиям и по-настоящему антихрупкой.

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

В блоке сетевой инфраструктуры мы сделаем акцент на практических семинарах, как мы это сделали на «Сетевом лете», и поговорим об ИИ для сетей и сетях для ИИ, о технологиях организации сложных сетевых фабрик и о высоконагруженных инженерных комплексах.

Андрей Янкин: В ИБ есть замечательный термин — киберустойчивость. Это способность бизнеса продолжать нормальную работу под непрерывным и неизбежным потоком кибератак. Но невозможно добиться киберустойчивости, не меняясь или используя только наложенные средства защиты. Антихрупкая ИТ-архитектура предполагает коллаборацию ИТ, ИБ и бизнеса, а также постоянное изменение и подстройку. Именно это и является путем к киберустойчивости.

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

Андрей Янкин: Фундаментальные принципы ИБ хорошо помогают, когда мы не можем получить исчерпывающий список возможных угроз. Кроме принципов Zero Trust (нулевое доверие на каждом этапе работы в противоположность построению защищенного периметра) и Security by Design, я бы отметил принцип наименьших привилегий, фундаментальные основы криптографии и многофакторной аутентификации, принцип невозможности Security Through Obscurity (безопасность, опирающаяся на гипотезу, что злоумышленник не догадается об устройстве системы). Все это зачастую забывается и заново переоткрывается в своеобразной форме специалистами по ИБ. Нестабильность влияет на способы реализации контролей ИБ, но не на фундаментальные ее основы. По крайней мере, так это выглядит сейчас. Но мы должны быть готовы скинуть с пьедесталов и этих ИБ-кумиров, если будет необходимо для подстройки под новых «Черных лебедей».

Андрей Янкин: Действительно, путь к киберустойчивости у многих компаний идет через увольнение пары-тройки руководителей ИБ, которые не смогли обеспечить 100% непробиваемой защиты, как от них ожидали. Если не принять факты, что взломы будут гарантированно, а главное — устойчивость бизнеса в такой ситуации, то никакой антихрупкости добиться не выйдет. Парадигма «кризис как возможность» тоже достижима лишь в корпоративной культуре, где все сосредоточены на улучшениях, а не на поисках виноватого.

Андрей Янкин: Статистика нашего центра мониторинга и реагирования на инциденты ИБ Jet CSIRT показывает, что львиная доля взломов происходит с использованием давно известных техник и приемов. Зачастую во взломанных компаниях просто некому было делать выводы на основе известных кейсов атак, потому что полноценная функция ИБ, а также вовлеченность в защиту ИТ и бизнеса возникают уже после потерь миллиардов рублей вследствие взлома. Таких случаев куда больше, чем может показаться: общественность узнает примерно об одном из десяти разрушительных инцидентов ИБ.

Сергей Андронов: В антихрупкой ИT-инфраструктуре сеть не является каким-то выделенным компонентом, это один из кубиков, который плотно взаимосвязан, интегрирован с остальными. Поэтому change management должен быть не для сети отдельно, а для всей инфраструктуры, в том числе и для сетевого сегмента. Испытания и регулярные проверки также должны проходить для всей инфраструктуры целиком. Безусловно, при этом отказоустойчивость сети обеспечивается определенными протоколами. Система при этом должна быть децентрализованной, чтобы не класть все яйца в одну корзину.

Например, антихрупкая архитектура ЦОДа предполагает, что все уровни архитектуры распределены и дублируют себя целиком и полностью множество раз. Падение какого-либо компонента, безусловно, окажет влияние на компоненты внутри одной из единиц, но при этом сработает система резервирования и не будет критичных потерь: отказ одной вертикали просто увеличит, причем незначительно, нагрузку на остальные вертикали. И чем больше таких вертикалей будет, тем надежнее инфраструктура.

Более того, события, которые произойдут в одной архитектуре, будут отработаны в виде change management и окажут влияние на все аналогичные архитектуры. Поэтому ключевая задача — это работа с изменениями, в частности, работа с машинным обучением и искусственным интеллектом.

Приведу простой пример на базе сетевой инфраструктуры. В большой распределенной сети аварии неизбежны, но им всегда предшествует набор факторов, фиксируемых в логах. Эти данные можно использовать не только для анализа прошлого, но и для прогнозирования будущих рисков. На основе ML строится модель «здоровья сети», которая выявляет потенциальные узкие места. Дальше через change management вносятся изменения: где-то расширяются каналы, где-то меняется оборудование или увеличивается число портов. С помощью AI можно увязать конфигурации всех сетевых устройств и минимизировать ошибки человеческого фактора. Получается замкнутый цикл: аварии → данные → прогнозирование → изменения → новая база знаний. Количество ошибок экспоненциально снижается. Это и есть пример антихрупкой сети — одного из элементов антихрупкой ИТ-инфраструктуры.

Сергей Андронов: SD-WAN — лишь один из инструментов. Основная работа строится вокруг ML и AI, которые анализируют статистику, конфигурации и управляют изменениями. Но при постоянных и сложных процессах критически важен механизм восстановления: нужно заранее знать, как откатиться в рабочую конфигурацию. Для этого используются либо AI-механизмы, либо более простые системы вроде SD-WAN. При этом точка возврата не фиксирована: она регулярно пересобирается на основе накопленных данных, становясь все более устойчивой. Такой подход позволяет в случае сбоя быстро вернуться к стабильному состоянию.

Есть еще один принципиальный момент: развитие инфраструктуры должно быть согласовано с бизнесом. Оставлять изменения без контроля опасно — бизнес формирует требования и направление развития, а технологии лишь подстраиваются. Задача инженеров и администраторов — не просто быть «буфером», а переводить бизнес-требования в сетевые, подстраивая управление под реальные цели компании. Для этого необходима высокая квалификация специалистов и отлаженный процесс работы с изменениями на уровне администрирования. «Сети ради сети» не существует.

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

Антихрупкость архитектуры — неважно, сетевой или не сетевой — без динамики изменений не существует. А динамику изменений обеспечивает в первую очередь наличие технических средств.

Сергей Андронов: Для сети в первую очередь важна гарантированная доставка информации: данные должны попасть из точки А в точку В и сделать это с требуемой скоростью. Эти два параметра остаются базовыми. Дополнительно оцениваются показатели отказоустойчивости и надежности работы отдельных компонентов. Для контроля пропускной способности и загруженности сети применяются метрики задержки, вариации задержки (jitter), пропускной способности и загрузки каналов связи. А надежность измеряется через процент потерянных пакетов, время доступности сервисов (uptime) и среднее время восстановления после сбоев.

Юрий Семенюков: Совсем без переделки не получится. Изменения и адаптация — это и есть переделка в какой-то степени. Поэтому важно строить так, чтобы изменения были частью daily operations, а не деструктивными событиями. Я бы назвал основные значимые подходы:
• отказ от ставки на одного вендора и стандартизация технологий для взаимозаменяемости;
• отказ от проприетарных аппаратных решений и переход на программно-определяемые;
• автоматизация.

Время показало, что важно не рассчитывать только на один стек или одного вендора. Ситуация 2022 года и решения западных вендоров это показали очень явно. Все эти системы до сих пор работают, от них отказываются неохотно, но это очевидно тупиковый путь. Подход к современной ИТ-архитектуре — переход от вендора к вендору должен быть максимально простой и безболезненный за счет стандартизации применяемых технологий. Еще один важный принцип — отказ от проприетарных «железных» функций. То, что раньше пытались реализовать на уровне аппаратуры, сегодня нужно переносить в софт. Потому что софт заменить проще и быстрее. Это дает ту самую свободу и адаптивность, которая делает инфраструктуру антихрупкой.

Юрий Семенюков: На мой взгляд, речь должна идти не столько о минимализме, сколько об эффективности и осознанном подходе. С одной стороны, для отказоустойчивости нужна избыточность компонентов и их распределенность. И ставка на один технологический проприетарный стек, как показала практика, приводит к негативным последствиям. Пример — уход VMware. Компании, которые параллельно с использованием VMware использовали решения на базе KVM, оказались в гораздо более выгодном положении. Они уже имели экспертизу и опыт. Такая диверсификация оказалась полезной.

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

Юрий Семенюков: Вместо Active-Passive-ЦОДов — равнозначные зоны доступности. Раньше основной подход был таким: есть один главный дата-центр и один резервный. Сейчас иначе: дата-центры становятся равнозначными, формируется концепт «зон доступности». Нет главного и резервного ЦОДов, которые не симметричны между собой, есть набор равноправных дата-центров — зон доступности, каждый из которых выполняет часть нагрузки.

Сквозной мониторинг и User Experience. Раньше мониторинг ограничивался инфраструктурным уровнем — серверы, ОС, системный софт. Если что-то ломалось на уровне прикладного процесса, это не входило в зону ответственности инфраструктуры.

Сейчас критически важно иметь видимость всего процесса целиком: от бизнес-операций до серверов. Например, если бухгалтер не может войти в ERP, мониторинг должен показать, где именно проблема — серверы, сеть, балансировка, база данных, аутентификация или что-то еще. Это называется сквозной мониторинг, который оценивает работу всего бизнес-сервиса целиком, позволяет выявлять проблемы на любом уровне и быстро их устранять.

Кроме того, современный мониторинг тесно увязан с обнаружением ИБ-угроз, атак и попыток проникновений. Для отработки комплекса задач по мониторингу компании все чаще приходят к идее единого центра мониторинга и управления, в котором сосредоточена информация по всему ИТ-ландшафту.

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

Резервное копирование и восстановление. Резервные копии в том виде, как они делались раньше, сейчас не работают. В связи с актуальными угрозами в части ИБ — вирусы-шифровальщики, проникновения в периметр и уничтожение данных — требования к бэкапам значительно изменились. Теперь необходимо иметь как минимум один бэкап на полностью удаленной площадке в изолированном контуре (Air Gap). Это описывается концепцией «3-2-1», соблюдение которой раньше не являлось чем-то обязательным, а теперь является ключевым фактором: восстановитесь вы или нет.

Регулярное восстановление уже подсветили выше. Только оно позволит убедиться, что вы ничего не забыли забэкапить, а также что в ваших резервных копиях уже нет вирусов.