«Инженер — это не тот, кто пишет красиво, а тот, кто разбирается и несет ответственность»

Инженер с 10-летним опытом в разработке масштабируемых распределенных систем, архитектуры API и образовательных программ Георгий Клюковкин пришел в профессию, по его словам, через «боль и любопытство». Он, в частности, разработал функциональность, которая улучшает поддержку асинхронных тестов, решая ранее не покрытые случаи. Разработанные им улучшения были, в частности, внедрены в продакшн в таких компаниях, как Veles Finance, и, по словам директора по информационным технологиям компании, снизили издержки на сопровождение и ускорили выпуск новых функций. О выборе профессии, важнейших разработках и планах по дальнейшему развитию — рассказывает сам Георгий Клюковкин.

— Как вы пришли в сферу разработки высоконагруженных систем?

— Через боль и любопытство. Сначала были обычные CRUD-сервисы, потом начали появляться реальные продуктовые задачи с высокими требованиями: нагрузка, отказоустойчивость, масштаб. Хотелось понимать, как все это работает под капотом — с очередями, балансировкой, кешами, SLA. Постепенно это стало основной областью, в которой я рос и получал удовольствие от инженерных вызовов.

— Расскажите о поддержке асинхронных тестов?

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

Такая доработка особенно важна в CI/CD-процессах, где автогенерация кода должна быть контролируемой и стабильной, а также в больших командах, где изоляция интерфейсов — это не просто удобство, а инженерная необходимость.

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

— Что вы считаете самым важным в сфере техпросвещения сегодня?

— Глубина и честность. Сейчас куча контента — но мало кто объясняет, почему система устроена именно так, и что будет, если сделать не так. Я стараюсь писать так, чтобы человек понял принципы, а не просто выучил синтаксис. Важно не хайпить, а реально помогать инженерам понимать, как всё работает на уровне системы.

— По каким принципам вы отбираете темы для своих публикаций? На какие из них был наибольший отклик?

— Я пишу то, чего мне самому не хватало. Если я столкнулся с проблемой, потратил день на разбор, и нигде не было нормального объяснения — значит, пора писать. Самый сильный отклик был у статей про гонки, конкурентные вызовы в Go, и практику логирования. Люди пересылали это коллегам, ссылались в коде, ставили в онбординг-доки.

Если спустя пару дней мне присылают мою же статью с фразой “смотри, пригодится” — значит, сработало. Если вижу, что кто-то вставляет оттуда куски в документацию или обсуждает в pull request — значит, статья начала жить своей жизнью. Это лучший индикатор.

— Как меняется подход к обучению разработчиков, если выстроить его под настоящие задачи продакшена?

— Он становится живым. Убираются игрушечные задачки и даются реальные сценарии: архитектура, ответственность, последствия решений. Студенты начинают мыслить как инженеры: не “написал код и сдал”, а “как этот код будет жить в проде, как его поддерживать, логировать, откатывать”. Это совершенно другой уровень.

— Вы выступаете на технических мероприятиях. Что это для вас значит и что сегодня важно доносить до профессионального сообщества?

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

— Какой проект или вклад вы считаете наиболее важным для вашей профессиональной репутации и почему?

— Со стороны прикладной пользы для бизнеса — это разработка модели оценки медицинских рисков, основанной на ретроспективных данных, системе весов и кубических сплайнах. Она применялась в актуарной аналитике, страховании и медицинском прогнозировании и стала реальным инструментом, влияющим на решения в сфере финансов и здравоохранения. А со стороны сообщества — это, безусловно, вклад в open-source и техпросвещение.

— Что вы изучаете сейчас и куда планируете расти дальше?

— Я работаю над ML инфраструктурой — системами, которые масштабируют и запускают модели в продакшене. Но хочется идти глубже: в математику, в архитектуру нейросетей, в саму механику обучения. Хочу расти в сторону ML-инженерии и системной разработки в ИИ — совмещая мой опыт в распределенных системах с будущим, в котором ИИ становится неотъемлемой частью продакшена.

Василий Хитрых