24 Октября 2025 12:42 24 Окт 2025 12:42 |

Поделиться

Денис Тюменцев: Инженер с ИИ заменит инженера без ИИ

CNews: Ваш путь в ИТ начался с поддержки офисной инфраструктуры в институте СО РАН. Как за 20 лет удалось вырасти до ведущего DevOps-инженера в крупной интеграционной компании?

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

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

Более основательно с методологией DevOps я познакомился в 2016–2017 годах уже в «Еврохиме» в роли DevOps-инженера в Ruby/Node.js-стеке. А дальше — Integro Technologies, впоследствии вошедшая в консорциум Ramax Group. Туда я пришёл DevOps-инженером, первое время совмещал с обязанностями системного инженера Linux, постепенно вырос до старшего и ведущего. Именно здесь я столкнулся с по-настоящему сложными проектами: высокая нагрузка, жёсткие соглашения об уровне сервиса (SLA), критичная инфраструктура. Это и сформировало меня как инженера — умение принимать архитектурные решения самостоятельно, нести за них полную ответственность и видеть инфраструктуру не как набор серверов, а как систему, от которой зависят миллионы пользователей.

CNews: У вас за плечами обучение в IBM Educational Center по Power Systems, сертификация RHCSA, курсы по Kubernetes. Какие из этих знаний оказались самыми востребованными в последние годы?

Денис Тюменцев: Если честно — по-разному. Обучение в IBM Educational Center было организовано компанией под возможные проекты с участием продуктов IBM. Это был интересный опыт, который расширил кругозор и понимание корпоративного стека технологий, но на практике эти знания не пригодились. Продукты IBM глубоко специализированы, они живут в своей экосистеме и за её пределами практически не встречаются.

Куда более востребованными оказались RHCSA и всё, что связано с Linux. Это фундамент, который работает везде и всегда. Любая современная инфраструктура так или иначе стоит на Linux, и глубокое понимание системы на этом уровне даёт преимущество в любом проекте. Что касается Kubernetes — сейчас я целенаправленно готовлюсь к сертификации CKA. Это осознанный выбор: Kubernetes стал индустриальным стандартом оркестрации, он универсален, востребован и продолжает развиваться. Я ориентируюсь именно на такие универсальные технологии с понятными перспективами, а не на узкие корпоративные продукты, замкнутые внутри одного вендора.

CNews: У вас 18 научных публикаций. Какая тема из области DevOps и ИИ сейчас наиболее актуальна для исследований и почему?

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

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

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

CNews: У вас есть экспертные комментарии в зарубежных СМИ, включая авторитетное издание InfoWorld. О чём была та статья и какой отклик она получила?

Денис Тюменцев: В июле 2025 года журналист из Лос-Анджелеса Джош Фрулингер, лауреат премий Джесси Х. Нила и AZBEE, обратился ко мне за профессиональным мнением для своей статьи «DevOps, SRE, and platform engineering: What's the difference?» Он дважды процитировал меня наряду с представителями ServiceNow, CloudBees и Progress Software.

Статья разбирает три роли, которые часто путают: DevOps, SRE и платформенная инженерия (platform engineering). Все они пересекаются, но решают разные задачи и лучше всего работают вместе. Тема оказалась для меня особенно близкой. На практике часто бывает так: человек формально занимает позицию DevOps-инженера, но в зависимости от проекта его реальная зона ответственности смещается. Где-то больше в сторону SRE с фокусом на надёжность и метрики, где-то — в сторону инфраструктурных платформ с построением внутренней инфраструктуры как продукта. Именно это происходило со мной на разных проектах, поэтому я мог говорить о пересечениях и отличиях не в теории, а из реального опыта.

А в ноябре 2025 года меня процитировали в The CTO Club — материале «The First 90 Days: Step-by-Step DevOps Engineer Playbook» в разделе «Voices from the Field».

CNews: Ваш индекс Хирша — 5, 71 цитирование, есть статья в Scopus и Web of Science. Насколько научная деятельность важна для практикующего DevOps-инженера?

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

Показательный пример — статья «Evaluating the Impact of Cloud Service Models on Microservice Performance Metrics», опубликованная в 2025 году в серии Springer Lecture Notes in Networks and Systems в соавторстве с коллегами из МГУ и других российских вузов. Это моя наиболее значимая публикация по уровню издания: она индексируется в Scopus и Web of Science. Тема вышла прямо из практики: на реальных проектах постоянно сталкиваешься с тем, что одна и та же микросервисная архитектура ведёт себя по-разному в зависимости от модели развёртывания. Мы исследовали эти компромиссы между гибкостью, контролем и масштабируемостью в разных облачных моделях (в SaaS, IaaS и PaaS) и показали, что выбор напрямую влияет на задержки, пропускную способность и устойчивость системы.

Второй важный мотив — возможность поделиться видением того, куда движется индустрия. DevOps и platform engineering трансформируются быстро, и у практиков есть уникальная перспектива, которой академическому сообществу порой не хватает. Индекс Хирша и цитирования для инженера-практика — не самоцель, но приятное подтверждение того, что твои наблюдения резонируют с коллегами.

CNews: Вы участвовали в миграции наземного программного обеспечения Airbus A350 из Тулузы в Москву для «Аэрофлота». В чём заключалась сложность проекта и как удалось обеспечить бесшовный перенос?

Денис Тюменцев: Проект заключался в переносе инфраструктуры из контура заказчика (on premise) из Тулузы, где базируется Airbus, в облачную инфраструктуру в Москве на базе Yandex Cloud. Заказчиком выступал «Аэрофлот»: компания хотела, чтобы наземная часть программной инфраструктуры управления, относящаяся к бортам Airbus A350 находилась в зоне её контроля и обслуживалась её силами или подрядчиками, а также обладала гибкостью современных облачных решений.

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

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

CNews: Сейчас вы работаете с мобильным приложением московского транспорта, у которого больше двух миллионов пользователей. Что изменилось в инфраструктуре за последний год, чтобы аудитория выросла на 500 тысяч человек?

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

За последний год мы провели системную работу по нескольким направлениям. Первое — автоматизация CI/CD (автоматизированный процесс сборки, тестирования и выпуска изменений): мы ускорили сборку и развёртывание релизов более чем на 50%. Это значит, что новые функции и исправления доходят до пользователей в разы быстрее, а влияние человеческого фактора при развёртывании существенно снизилось.

Второе — мониторинг. Мы выстроили расширенную систему наблюдаемости, включая нестандартный мониторинг внешних API-сервисов, от которых зависит приложение. «Московский транспорт» — агрегатор десятков внешних источников данных: расписания, геолокация, трекинг транспорта, сервисы такси, каршеринга, самокатов, пробок. Автоматизация проверок этих сервисов позволила проактивно видеть проблемы на стороне поставщиков данных. В результате риск сбоев в критически важных компонентах снизился на 70–80%, а время реакции на инциденты сократилось в несколько раз.

Третье — инфраструктура как код. Мы упорядочили зависимости между компонентами, автоматизировали повторяющиеся задачи. Управляемость всей системы выросла, по субъективным оценкам, в 2–3 раза. Это снижает влияние человеческого фактора со стороны команды эксплуатации и позволяет быстрее реагировать на изменения нагрузки.

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

CNews: Вы сократили количество используемых ресурсов в облаке примерно на 30%. Как это повлияло на производительность и стоимость обслуживания?

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

Основное снижение издержек произошло после анализа исторических метрик нагрузки в Grafana — не в моменте, а в динамике, включая пиковые часы. Оказалось, что на многих серверах ресурсы были выделены с избыточным запасом, что довольно расточительно. Мы пересмотрели лимиты на основе реальных данных и оставили резерв в 20% сверх пиковой нагрузки — чтобы система уверенно чувствовала себя в час пик и при внезапных всплесках. В итоге затраты на облако снизились примерно на 30%, а стабильность не пострадала.

CNews: Релизы ускорились вдвое. Это был один ключевой шаг или совокупность изменений?

Денис Тюменцев: Совокупность, но каждое изменение было обоснованным. Ускорение произошло за счёт перехода на многоступенчатую сборку образов, настройки локального кэша и оптимизации последовательности слоёв в Dockerfile. Время сборки образов сократилось примерно вдвое. Конвейеры в GitLab CI переработали: убрали лишние зависимости между стадиями. Процесс релиза, который раньше выполнялся вручную, обернули в скрипты — это убрало человеческий фактор и сделало выкатку воспроизводимой и предсказуемой.

CNews: Мониторинг — часто то, о чём думают в последнюю очередь. Как он помог поймать проблему раньше, чем её заметили пользователи?

Денис Тюменцев: Экосистема мониторинга на базе стека Prometheus, Alertmanager и Grafana в том виде, в котором она досталась нам от предыдущей команды, была малопригодна для реального наблюдения, особенно в условиях жёсткого соглашения об уровне сервиса SLA, по государственному контракту. Мы переработали его практически с нуля: сделали более управляемым и добавили то, чего критически не хватало, — полноценный мониторинг всех внешних API.

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

Хороший пример — данные о загруженности вагонов метро. Они обновляются не в реальном времени, а с определёнными интервалами. Если поставщик начал отдавать некорректные или устаревшие данные или вовсе стал недоступен, на стороне приложения это проявится с задержкой. Наш мониторинг ловил такие проблемы на стороне поставщика раньше, чем они добирались до интерфейса приложения. Это давало нам окно — мы успевали связаться с поставщиком и решить проблему до того, как пользователи и заказчик вообще её замечали. Мы перешли из режима «тушим пожар» в режим проактивного управления инцидентами.

CNews: Если бы вы могли дать один совет начинающему DevOps-инженеру, который хочет повторить ваш карьерный путь, что бы вы посоветовали?

Денис Тюменцев: Не бояться нелинейного пути. Не бояться пробовать новое в начале. Не попробовав, не поймёшь, твоё ли это. Это, пожалуй, главное.

Я сам прошёл через несколько компаний, разные роли и периоды, когда не понимал, куда двигаться. Задним числом это выглядит как потеря времени, но на самом деле каждое отклонение давало что-то полезное: понимание того, чего точно не хочешь, понимание своей природы, понимание, где ты по-настоящему в своей тарелке.

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

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

Иван Петров

Поделиться

Подписаться на новости Короткая ссылка