Хаос в "Домодедово" глазами айтишника: разбор причин сбоя регистрации

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

Утром 17 февраля пассажиры начали массово сообщать о невозможности пройти регистрацию на рейсы в аэропорту Домодедово. Стойки регистрации не работали, сотрудники авиакомпаний не могли получить доступ к системам бронирования, а информация на табло вылета либо отсутствовала, либо не обновлялась. По данным СМИ, сбой затронул несколько десятков рейсов, тысячи пассажиров оказались в здании аэропорта без возможности вовремя улететь. Официальные представители заявили, что причиной стал технический сбой в оборудовании, однако конкретных деталей не раскрыли. Многие пассажиры провели в очередях по 4–6 часов, некоторые рейсы были перенесены на следующий день. Позже в пресс‑службе аэропорта сообщили, что системы удалось восстановить к середине дня, но последствия в виде задержек ощущались до вечера. Этот инцидент стал одним из самых громких в истории аэропорта за последние годы и заставил задуматься о надежности критической IT‑инфраструктуры.

Чтобы понять, где могла произойти поломка, нужно разобраться, из каких компонентов состоит типичная система регистрации пассажиров в крупном аэропорту. В основе лежит глобальная система бронирования (GDS, Global Distribution System), которая взаимодействует с системами авиакомпаний (инвентарные системы, системы управления доходами). В аэропорту используется специализированное программное обеспечение — DCS (Departure Control System), которое управляет процессом регистрации, посадки, взвешивания багажа. DCS получает данные о пассажирах и рейсах из центральных систем авиакомпаний и обеспечивает работу стоек регистрации, киосков саморегистрации и посадочных терминалов.

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

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

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

• Аппаратные сбои: Отказ дискового массива, на котором хранились критически важные базы данных, перегрев серверов из‑за отказа системы кондиционирования, выход из строя сетевого коммутатора, агрегирующего трафик от всех стоек регистрации. В случае с Домодедово официальные лица говорили именно о «сбое оборудования», что может указывать на физическую поломку. Если резервные компоненты не были включены автоматически (например, из‑за ошибки конфигурации или отсутствия «горячего» резерва), то восстановление могло занять часы — пока технические специалисты вручную не заменят блок или не переключат кабели.
• Сбои в базах данных: База данных, содержащая информацию о рейсах и пассажирах, могла быть повреждена или достигла лимитов производительности. Например, если произошел скачок нагрузки (начало утренней волны рейсов), и запросы от множества стоек одновременно привели к исчерпанию подключений или блокировкам. В результате таблицы могли быть заблокированы, и система перестала отвечать. Часто причиной становится неоптимальный запрос или отсутствие индексов, но в критической инфраструктуре это должно отлавливаться на этапе тестирования.
• Проблемы с сетевым взаимодействием: Возможно, произошел сбой в маршрутизаторе или брандмауэре, который отсек сегмент сети, где находятся стойки регистрации, от серверов приложений. Тогда рабочие станции не могли соединиться с базой данных, и регистрация становилась невозможной. Если сеть не имела резервных каналов или протокол динамической маршрутизации не сработал, восстановление связи требовало ручного вмешательства.
• Ошибки в программном обеспечении: Обновление DCS или операционной системы на серверах могло содержать критическую ошибку. Например, после установки патча произошло зависание службы, и автоматический перезапуск не помог. Или же ошибка в коде вызывала утечку памяти, и через несколько часов работы сервер исчерпывал ресурсы. Если такие ошибки не были выявлены в тестовой среде, они могут проявиться на продуктивной системе в самый неподходящий момент.
• Человеческий фактор: Не исключены ошибочные действия администратора, который случайно удалил важные файлы, изменил конфигурацию сети или запустил скрипт, заблокировавший доступ. Даже случайное отключение питания в стойке с оборудованием может привести к простою, если нет системы автоматического ввода резерва.
• Кибератаки: Хотя официально об этом не сообщалось, нельзя исключать DDoS‑атаку на внешние каналы связи, через которые аэропорт получает данные от авиакомпаний, или целевое воздействие на уязвимости в софте. В современном мире аэропорты часто становятся мишенью хакеров, и парализация регистрации — способ создать хаос.

Для наглядности можно представить таблицу вероятных причин и их типичных проявлений:

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

1. Каскадный отказ: Первичный сбой (например, в сетевом коммутаторе) мог вызвать цепную реакцию, которая вывела из строя и резервные компоненты. К примеру, при отключении основного канала электропитания ИБП не справились с нагрузкой, и резервные серверы тоже отключились. Или при сбое в системе хранения данных репликация передала поврежденные данные на резервный массив, сделав его также непригодным.
2. Отсутствие автоматического переключения: Возможно, резервные серверы были настроены в режиме «холодного» резерва, то есть для их активации требовалось ручное вмешательство администратора. Если администратор не смог быстро добраться до серверной или потребовалось время на диагностику, простой затянулся.
3. Проблемы с синхронизацией данных: Если резервная база данных отставала по времени от основной (например, синхронизация происходила раз в час), то при переключении пассажиры, зарегистрировавшиеся в последние минуты, могли потерять свои данные. В такой ситуации авиакомпании могли принять решение не переключаться, пока не восстановят основную систему, чтобы избежать потери информации.
4. Человеческая ошибка при тестировании: Резервные механизмы могли быть настроены, но давно не проверялись. Например, при реальном отказе оказалось, что резервный сервер не имеет нужных лицензий или на нем установлена устаревшая версия ПО, несовместимая с текущими данными. Или резервный канал связи имел недостаточную пропускную способность для всей нагрузки.

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

Инцидент в Домодедово — не единственный случай сбоя в аэропортах мира. Подобные события происходили в аэропортах Амстердама, Чикаго, Лондона. Каждый такой случай должен становиться уроком для всей отрасли. Вот ключевые выводы, которые можно сделать с точки зрения IT.

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

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

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