Архитектура, устойчивая к санкциям и отключениям сервисов

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

А давно ли архитектура внезапно стала геополитическим вопросом?

Раньше архитектурные решения в IT-компаниях принимались исходя из трёх факторов: скорость разработки, стоимость поддержки и масштабируемость. Сегодня к ним добавился четвёртый — управляемость зависимости от внешней инфраструктуры.

Когда критичный сервис может быть отключён не из-за SLA, а из-за внешних факторов, классическая логика «возьмём лучший SaaS на рынке» перестаёт работать. Это касается всего: от облачных провайдеров до систем аналитики и CI/CD-инструментов.

По данным отраслевых обзоров, после 2022 года российские компании начали массово пересматривать архитектуру своих продуктов, снижая зависимость от зарубежных сервисов и переходя к локальным или self-hosted решениям.

Но здесь возникает ключевой нюанс: простая замена одного сервиса на другой не делает архитектуру устойчивой, она просто меняет точку риска.

Иллюзия импортозамещения

Одна из самых частых ошибок, которую можно наблюдать на рынке РФ — попытка «пересобрать стек» без изменения архитектурного подхода.

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

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

Предприняли ли мы что-то в Гринкор?

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

Вместо того чтобы оптимизировать систему под идеальные условия, команда начала проектировать её под условия деградации. Например, если внешний API недоступен — система не должна падать, она должна переходить в ограниченный режим. Если облачный сервис недоступен — должна быть возможность локального выполнения критичных функций.

Это звучит как очевидный принцип отказоустойчивости, но на практике он редко реализуется полноценно, потому что увеличивает сложность системы. В Гринкор приняли эту сложность как неизбежную плату за устойчивость.

Архитектура как управление рисками, а не только масштабом

Классическая архитектура ориентирована на рост: больше пользователей, больше данных, больше нагрузки.

Но санкционная реальность смещает фокус: архитектура должна быть готова не только к росту, но и к потере части инфраструктуры. Это требует другого мышления. Например, появляется необходимость:

1. разделять критичные и некритичные компоненты системы;
2. минимизировать точки отказа;
3. избегать жёсткой привязки к одному провайдеру;
4. проектировать fallback-сценарии.

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13480 тендеров
проведено за восемь лет работы нашего сайта.

В компании Гринкор это реализовали через принцип «контролируемых зависимостей». Любой внешний сервис оборачивается в абстракцию, которая позволяет заменить его без переписывания всей системы.

Это не всегда дешёво и быстро, зато делает архитектуру управляемой, а последнее, как известно — ключевой фактор устойчивости.

Существует ли полностью независимая архитектура?

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

Ошибка многих компаний в том, что они стремятся «избавиться от рисков», вместо того чтобы научиться ими управлять. CTO Гринкор пошёл другим путём: не минимизировать количество зависимостей любой ценой, а классифицировать их по уровню критичности и строить вокруг них защитные сценарии, что позволяет не тормозить развитие продукта, но при этом сохранять устойчивость.

Будет ли тема популярна в ближайшие годы?

Ну, постарайтесь ответить, исходя из своего опыта...:) Если раньше устойчивость архитектуры была задачей крупных enterprise-компаний, то сейчас это становится базовым требованием даже для среднего бизнеса.

Почему? Да банально потому, что риск отключения сервисов перестал быть теоретическим, он стал частью реальности.

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

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

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

Он стал частью реальности.