НОВОСТИ СЕГОДНЯ
Еще десять лет назад мир IT жил по кредо: «Двигайся быстро и ломай вещи». Скорость вывода на рынок (time-to-market) считалась главным конкурентным преимуществом. Чем быстрее компания внедряла новые технологии, будь то облачные сервисы, контейнеры или автоматизацию, тем успешнее она выглядела. Но парадокс технологического прогресса заключается в том, что чем сложнее становится инфраструктура, тем она хрупче. Сегодня ошибка в одной строке кода или неправильная настройка роутера способны обрушить работу целого региона и оставить компании без выручки.
Где заканчивается зона комфорта и начинается катастрофа? Как защитить бизнес, когда сама система защиты превращается в мишень для хакеров, а искусственный интеллект принимает решения быстрее человека, но не всегда верно?
На эти вопросы отвечает Евгений Жиделев — IT Director топ-20 мирового ритейлера, отвечающий за технологическую инфраструктуру в 6 странах, под его руководством находится сложнейший комплекс офисов, дата-центров и распределённых команд инженеров в регионе. Почему скорость внедрения технологий больше не является синонимом качества и почему тестовые серверы могут стать дверью для киберпреступников? Он приводит пугающий пример того, как автономный ИИ почти уничтожил производство гигантской корпорации. Этот материал поможет понять, почему стабильность завтра важнее скорости сегодня.
В этом интервью — реальные истории сбоев, анализ ошибок AI и практические принципы, которые помогают сохранять стабильность там, где цена простоя измеряется миллионами.
— Евгений, вы работаете в глобальном ритейлере: несколько стран и более 500 сотрудников на производстве. Ваша IT-инфраструктура — это сложнейшая система. Что сейчас является вашим главным приоритетом: скорость внедрения новых технологий или что-то другое?
— Еще несколько лет назад я бы без колебаний сказал: скорость. Быстрее запустить облака, быстрее автоматизировать, быстрее развернуть новый сервис. Time-to-market действительно был королевской метрикой.
Но сегодня приоритет сместился. На первый план выходит цифровая устойчивость — способность инфраструктуры сохранять стабильность, управляемость и доступность даже в условиях инцидентов, кибератак и ошибок автоматизации. Потому что цена сбоя стала слишком высокой. Системы настолько взаимосвязаны, что ошибка в одном компоненте способна за минуты «положить» всё.
— Вы упомянули, что на вашей памяти был случай, когда тестовый маршрутизатор, подключенный в изолированный сегмент, положил сеть на несколько часов. Как такое возможно?
— Это классический пример того, что мы называем «непредсказуемыми последствиями». Новый маршрутизатор взяли на тест и подключили в сегмент, который считался изолированным. Но из-за ошибки в конфигурации и совпадения нескольких маловероятных факторов — например, некорректной настройки протоколов динамической маршрутизации и специфической топологии сети — этот «безобидный» тестовый прибор начал рассылать широковещательные запросы, которые были некорректно обработаны на основном оборудовании.
Несколько часов команда разбиралась, почему вдруг перестала работать связь между ключевыми узлами. А ведь этот маршрутизатор еще даже не внедрили в «продакшен» — просто тестировали. Урок, который я вынес: изолированных сегментов в сложной сети не бывает. Всегда есть вероятность, что через какой-то неосновной маршрут ошибка «протечет».
— Вы упомянули историю про сбой NTP-сервера у коллег из компании-разработчика. Казалось бы, мелочь — синхронизация времени. А привело к многодневной выверке данных. Расскажите подробнее.
— Это показательный случай, как самый простой компонент может стать причиной катастрофы. У коллег случился временный сбой в NTP-сервере — это служба, которая синхронизирует время на всех серверах сети. В результате время на одном из серверов синхронизировалось некорректно, и часть записей попала в базу данных с неправильными датами.
Сервис быстро самовосстановился, синхронизировавшись со внешним источником. Но проблему не заметили в моменте. А «кривые» данные успели распространиться по многим системам — через интеграции, репликацию, очереди сообщений. Когда бизнес обратил внимание на аномалии в заказах (например, заказы с далекой датой в прошлом), простого решения уже не было.
Выверка и исправление данных в полуручном режиме заняла несколько дней. Все эти дни соответствующие заказы «висели», не обрабатывались. Финансовые потери колоссальные. А началось всё с крошечного сбоя в служебном сервисе, на который обычно никто не смотрит.
— Сейчас принято думать, что хакеры атакуют основные сервисы — сайты, приложения, платежные шлюзы. Но вы говорите, что цель — маленькие служебные сервисы. Почему?
— Потому что основные сервисы защищены хорошо. У них многоуровневая система безопасности, регулярные аудиты, мониторинг 24/7. Их взломать сложно.
А маленькие служебные сервисы — тестовые среды, вспомогательные базы, внутренние API без аутентификации — часто остаются без должной защиты. «Там же нет ценной информации», — рассуждают администраторы. Но через такой сервис можно получить доступ к ключевым компонентам сети. Сервис, развернутый в тестовом режиме и по ошибке выставленный в интернет, — нередкий сценарий.
И главное: тысячи ботов ежесекундно сканируют интернет в поисках таких дыр. Шанс быть замеченным — 100%, вопрос только времени. Если в компании нет сегментации сети и строгих политик доступа, такая ошибка может стоить очень дорого.
— Технический долг — отдельная боль. Как вы с ним боретесь в условиях, когда бизнес требует быстрых результатов?
— Честно — это постоянная битва. Бизнесу нужен результат здесь и сейчас. Команда внедряет систему, достигает результата, и руководство говорит: «Отлично, теперь следующая задача». Документация доделывается по остаточному принципу. Через несколько месяцев никто уже не помнит, почему приняли то или иное архитектурное решение.
А потом приходит задача что-то изменить. И выясняется, что на доработку уходит в 3–5 раз больше времени, чем если бы документация была полной. Потому что сначала нужно понять, как вообще работает этот «черный ящик».
Мой подход: документация — это не опция, а часть Definition of Done. Без нее задача не считается выполненной. Да, это замедляет процесс. Но это сэкономит драгоценное время в будущем.
— Вы упомянули проблему зависимости от внешних сервисов. Многие компании уходят в облака, а вы говорите, что это создает новые риски.
— Облака — это замечательно. Гибкость, масштабируемость, снижение CAPEX. Но есть обратная сторона: вы становитесь зависимы от стороннего провайдера. Глобальный сбой в облачной инфраструктуре — не такая уж редкость. И он может затронуть тысячи компаний одновременно.
Помните историю с ограничением доступности сервисов у одного из крупных облачных провайдеров? Компании в авральном режиме, буквально за несколько дней, были вынуждены мигрировать терабайты данных на свои мощности. Получилось не у всех. Кто-то безвозвратно потерял доступ к своим же данным.
Поэтому мы придерживаемся гибридной стратегии: критически важные системы и чувствительные данные остаются в собственных дата-центрах. А для неключевых нагрузок используем облака. И всегда имеем план отката.
— А теперь про AI. История с Amazon Kiro облетела весь мир. AI-ассистент для DevOps получил права инженера и выбрал сценарий «delete and recreate environment». Восстановление заняло 13 часов. Вы следили за этой историей? Что она говорит о рисках AI в IT-инфраструктуре?
— Конечно, я следил. Это был шок для всего индустриального сообщества. Amazon — один из технологических лидеров, у них лучшие инженеры и процессы. И всё равно AI привел к многочасовому сбою.
Суть в том, что AI-автоматизация принимает и распространяет решения значительно быстрее человека. Ошибка в конфигурации или сценарии, сгенерированном AI-агентом, может за минуты затронуть инфраструктуру целиком. Человек в такой ситуации успел бы остановиться, подумать, запросить подтверждение. AI — нет, если ему не заложить соответствующие ограничения.
Вывод, который я сделал для себя: AI в инфраструктуре должен работать по принципу «сначала покажи, потом сделай». Любое деструктивное действие (удаление, пересоздание, массовое изменение) должно требовать явного подтверждения от человека. И права AI должны быть минимально необходимыми, а не сопоставимыми с правами инженера, как это случилось в AWS.
— Если подводить итог: что вы посоветуете коллегам-IT-директорам, которые сегодня находятся под давлением бизнеса — «внедряйте AI быстрее, переходите в облака, автоматизируйте всё»?
— Мой совет будет звучать не очень популярно.
Первое: не гонитесь за скоростью любой ценой. Инвестируйте в устойчивость. Проводите chaos engineering — намеренно создавайте сбои в тестовой среде и смотрите, как система восстанавливается.
Второе: документируйте всё. Без документации вы не управляете инфраструктурой — вы на нее надеетесь.
Третье: уделяйте внимание безопасности, сегментируйте сети, ограничивайте права и т. д. Ни тестовый сервис, ни AI-агент не должны иметь доступ к production-критичным компонентам без явного подтверждения.
Четвертое: имейте план восстановления после сбоя и регулярно его тестируйте. Не в теории, а на практике.
Цифровая устойчивость — это не противоположность скорости. Это фундамент, на котором скорость может быть безопасной. Сначала надежность, потом скорость. Иначе одна ошибка перечеркнет все ваши достижения.
— Евгений, спасибо. Финальный вопрос: если бы вам нужно было выбрать одну самую важную метрику для IT-директора сегодня, что бы это было?
— Не MTBF (среднее время между сбоями), а MTTR (среднее время восстановления). Сбои неизбежны. Важно не то, как долго вы можете их избегать, а то, насколько быстро вы возвращаетесь в норму. Компании, которые умеют быстро восстанавливаться, выигрывают. Те, кто тратит часы и дни на выверку данных, проигрывают. Научитесь восстанавливаться — и скорость внедрения перестанет быть вашим врагом.
Похожие новости: