Отказоустойчивые высоконагруженные системы: что заложить в архитектуру

Масштабный сбой облака Microsoft Azure, связанный с обновлением защитного ПО CrowdStrike, остановил работу банков, больниц и тысяч компаний по всему миру. Урок здесь не про конкретного вендора. Он про то, что устойчивость к отказам закладывается в архитектуру заранее, а не достраивается в тот момент, когда сервис уже лёг и счётчик убытков пошёл.

Ниже разберём, что конкретно стоит проверить в своей инфраструктуре, как список вопросов, на которые у вас либо есть ответ, либо его отсутствие уже является риском.

Сбой неизбежен, вопрос только в том, кто его заметит первым

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

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

Чтобы это работало, сервисы приложения должны быть stateless: не хранить пользовательскую сессию и состояние внутри себя. Тогда любой запрос можно отправить на любой из узлов, а нагрузку наращивать горизонтально, добавляя новые экземпляры, а не покупая один всё более дорогой сервер. Для бизнеса это означает предсказуемое масштабирование под пиковую нагрузку и отсутствие потолка, в который упирается весь сервис в день максимальных продаж.

База данных и данные: где простой превращается в потерю

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

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

• RTO: за какое время мы поднимем сервис после аварии. Это длительность простоя, которую вы готовы оплатить упущенной выручкой.
• RPO: за какой период мы потеряем данные. Это объём транзакций, заказов и записей, которые исчезнут безвозвратно.

Пока эти два числа не названы и не подтверждены тестом, у компании нет плана восстановления, у неё есть надежда.

Поведение под нагрузкой и при частичном отказе

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

• Очереди и backpressure: при всплеске нагрузки запросы выстраиваются в очередь и обрабатываются по мере сил, а не убивают систему все разом. Когда очередь переполнена, сервис честно притормаживает источник вместо того, чтобы захлебнуться.
• Таймауты и ретраи с джиттером: зависший внешний вызов не должен держать ресурсы бесконечно. Повторы делаются с нарастающей задержкой и случайным разбросом, иначе тысячи клиентов синхронно ударят по уже перегруженному сервису и добьют его.
• Размыкатель цепи (circuit breaker): если зависимость не отвечает, обращения к ней временно прекращаются и возвращается запасной ответ. Это не даёт одному упавшему сервису утянуть за собой остальные по цепочке.
• Управляемая деградация: при перегрузке система отключает второстепенное (рекомендации, аналитику, тяжёлые отчёты) и сохраняет работоспособность главного, например оформления заказа и оплаты. Клиент видит чуть урезанный сервис вместо страницы с ошибкой.

Дополняют картину балансировка трафика, регулярные проверки здоровья узлов (балансировщик должен сам перестать слать запросы на больной экземпляр, без участия дежурного) и автоматическое масштабирование, которое добавляет мощность под рост и убирает её на спаде, не переплачивая за простаивающее железо.

Дисциплина обновлений: урок инцидента Azure и CrowdStrike

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

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

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

Как убедиться, что всё это работает

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

• Наблюдаемость: метрики, логи и трассировка запросов. Без них вы узнаёте об аварии от клиентов, а не от системы, и теряете время на поиск причины вслепую.
• Цели по доступности и бюджет ошибок: заранее согласованный уровень доступности и допустимая доля сбоев. Это переводит надёжность из эмоций в измеримую цель и помогает решать, когда выпускать новые функции, а когда укреплять фундамент.
• Нагрузочное тестирование и контролируемые сбои: проверка поведения под пиковой нагрузкой и осознанное отключение компонентов, чтобы увидеть реакцию системы в безопасных условиях, а не в день реальной аварии.

Итог

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

Если хотите увидеть слабые места своей инфраструктуры до того, как их найдёт очередной сбой, мы предлагаем бесплатный технический аудит инфраструктуры. Разберём вашу архитектуру по этим пунктам и дадим конкретные рекомендации. Оставьте заявку на странице https://myod.it/contacts