Инженер, прошедший путь от строительства дата-центров до финтех-разработки, — о том, почему в эпоху Edge Computing знание «железа» становится обязательным для создания надежных интерфейсов.
В 2026 году периферийные вычисления (Edge Computing) стали повседневной инженерной практикой. Продукты все чаще работают там, где возникают данные — на смартфонах, в транспорте, в промышленных системах. Это означает, что код должен быть автономным, устойчивым к сбоям сети и ограниченным ресурсам устройства. Однако для индустрии, привыкшей последние 15 лет опираться на облачные модели вычисления, этот разворот оказался болезненным — разработчиков учили абстрагироваться от «железа», а теперь понимание инфраструктуры снова становится критически важным.
Почему период «безлимитного облака» заканчивается, как Edge Computing меняет требования к инженерам и какие компетенции становятся решающими в мире, где интерфейс больше не может быть оторван от инфраструктуры — об этом мы поговорили с Мариусом Малышевым, который уже проходил подобную переквалификацию в своей карьере. В конце
— Мариус, вы проектировали инфраструктуру для дата-центров девелопера, а сейчас в международной продуктовой компании Garage-IT пишете код для финтех-сервисов, которые работают в Азии и Африке — часто на старых устройствах и с нестабильным интернетом. Получается, вы видите Edge Computing и со стороны «железа», и со стороны разработки. Исходя из этого опыта — что для вас лично означает этот переход и в чем, на ваш взгляд, индустрия его пока не до конца осознает?
— Думаю, главное, что ускользает от внимания — это перенос ответственности. Когда я работал в «Прагме», мы строили системы так, чтобы они были отказоустойчивы физически: резервирование каналов, источники бесперебойного питания, контроль температуры. Код мог быть любым — инфраструктура его вытягивала.
Сейчас, в Garage-IT, ситуация зеркальная. Инфраструктура — это смартфон пользователя с непредсказуемым зарядом батареи и связью, которая может исчезнуть в любую секунду. И всю эту отказоустойчивость, которую раньше обеспечивали инженеры на уровне железа, теперь должен обеспечивать код. Индустрия все еще часто мыслит категориями «облако все стерпит», но в реальности, особенно на развивающихся рынках, облако — это просто еще один узел, причем не самый надежный. И просчитывать сценарии отказов — не задача системного администратора, а прямая обязанность разработчика.
— Сейчас вы пишете код для финтех-сервисов, где ошибка означает потерю денег клиентами. Ваше «двойное» зрение — что оно позволяет увидеть в повседневной разработке такого, чего не замечают коллеги? И как ответственность за «живые» деньги влияет на ваши решения — вплоть до каждой строчки кода?
— Обычно разработчик сосредоточен на том, чтобы новая функция работала и укладывалась в сроки. Это правильно, так устроен любой процесс. Но когда за плечами десять лет в «Прагме», где сбой означал вызов бригады инженеров ночью, привыкаешь просчитывать отказы до того, как они случились.
В Garage-IT это выглядит так. Мы проектируем экран оплаты — стандартная задача. Но я не могу не думать о том, что произойдет, если сеть исчезнет между нажатием кнопки и ответом банка. Или если у пользователя сядет батарея в этот промежуток. Для европейского банка задвоение транзакции — это штрафы и проблемы с регулятором. Для пользователя в Африке ошибочно списанные 10 долларов могут значить, что он не купит продукты на неделю.
Когда постоянно работаешь с такими сценариями, код перестает быть просто кодом. Ты начинаешь писать его так, чтобы он выдерживал любые обстоятельства — не только идеальный сигнал и полный заряд. Проверяешь не просто работает ли функция, а выживет ли она в реальном мире, где связь обрывается, батарея садится, а пользователь не читает инструкций. Это не избыточная осторожность, это просто другой масштаб ответственности — его дает только опыт, в котором не бывает абстрактных сбоев.
— Мариус, ваш переход из инфраструктуры в разработку — для индустрии до сих пор нетипичная траектория. Если посмотреть шире: что вы благодаря этому опыту увидели в индустрии с обеих сторон, чего обычно не замечают те, кто остается внутри одного направления?
— Главное — насколько по-разному устроено мышление. В инфраструктуре ты привыкаешь просчитывать отказы: любой инженер автоматически проверяет «а что будет, если упадет сеть/сервер/питание?». В разработке фокус на том, чтобы функция работала в идеальных условиях. Вопрос «а что будет, если...» возникает уже после падений в продакшне.
Самый острый разрыв сейчас — между разработкой и безопасностью. В финтехе это видно особенно отчетливо. В некоторых странах биометрию нельзя передавать за пределы устройства — верификация должна работать локально, на слабых процессорах. Безопасник говорит: «не передавать». Разработчик отвечает: «нет ресурсов». Торг может длиться месяцы.
Мой опыт здесь работает как переводчик: я видел, как валится инфраструктура, когда безопасность не учли, и знаю, как писать код, который закрывает эти риски на этапе проектирования.
Со временем я понял, что это не моя проблема, а системный разрыв. И когда я начал преподавать, то уже целенаправленно встраивал эти знания в программу.
— За пять лет ваши курсы программирования прошли больше тысячи человек. Какую главную проблему в подготовке разработчиков вы увидели и что сознательно добавляли в программу, чтобы ее решить?
— Платформа SwiftBook, где я выступал не просто преподавателем, а автором и продюсером, ставила перед собой амбициозную задачу — закрыть кадровый голод в iOS-разработке начала
— А где этому учиться состоявшемуся разработчику? У вас был опыт в Termius, где вы пришли как разработчик, но понимали пользователей-сисадминов. Этот опыт можно как-то масштабировать?
— Коротких путей действительно нет. Курсы сисадминов в чистом виде не дадут нужного эффекта, потому что знания о «железе» должны быть встроены в контекст разработки, а не существовать отдельно.
Самый рабочий способ — искать проекты, где твоя основная специализация пересекается со смежными областями. Мой опыт в Termius это хорошо иллюстрирует. Эта компания делает инструменты для системных администраторов по всему миру, и они искали iOS-разработчика, который сам много лет был их пользователем. Мой бэкграунд идеально подошел под задачу, и меня пригласили на контракт. Компания делает инструменты для системных администраторов, меня взяли туда как iOS-разработчика. Но поскольку я сам много лет был пользователем их продуктов, я постоянно сталкивался с задачами, где нужно было понимать обе стороны.
Курсы дают базу, но реальное понимание приходит только когда ты попадаешь в среду, которая не прощает незнания.
— Вы работаете с финтехом для Европы, Азии и Африки — рынков с разным регулированием и качеством инфраструктуры. Где именно ваш прошлый инфраструктурный опыт оказался незаменим? И приходилось ли менять архитектуру из-за ограничений оборудования или требований регуляторов?
— Это самая жесткая среда из всех, где я работал. Европа — стабильность, высокие нагрузки, жесткий контроль. Азия и Африка — нестабильная связь, старые устройства, требования безопасности на уровне Центробанков. Без понимания инфраструктуры код здесь просто не дойдет до пользователя.
Менять архитектуру приходится постоянно. Здесь инфраструктурный опыт срабатывает как система раннего обнаружения: ты автоматически просчитываешь сценарии, о которых другой не подумает — что будет, если сеть встанет, сядет батарея или процессор не потянет. Для коллег это паранойя, для нас — рутина.
— В распределенных командах вы фактически выступаете «переводчиком» между инфраструктурой, дизайном, бизнесом и разработкой. Эта роль стала следствием вашего бэкграунда или вы осознанно взяли ее на себя?
— Это не было осознанным решением. Просто когда ты видишь картину целиком, тебе физически больно смотреть, как люди говорят на разных языках и не слышат друг друга. Дизайнеры мыслят сценариями, бэкенд — контрактами и нагрузками, бизнес — метриками и регуляторикой. Кто-то должен соединять это так, чтобы все говорили на одном языке. Со временем это становится второй натурой — ты уже не можешь иначе.
— Вы упомянули локальные нейросети на слабых устройствах. В компании вы инициировали создание AI-сообщества. С какими запросами приходят коллеги? И что меняется в инженерной культуре, когда команда начинает понимать ограничения локальных моделей?
— Запросы сводятся к одному: люди хотят использовать AI, но не понимают, как встроить его без риска. Разница между облачным и локальным AI фундаментальна. С облаком ты просто вызываешь API. С локальными моделями — они живут на устройстве пользователя, и ты обязан думать о памяти, процессоре, батарее.
Когда команда это осознает, исчезает магическое мышление «AI все решит». Модель становится кодом, который надо оптимизировать и тестировать. Инфраструктурный опыт здесь дисциплинирует: ты привыкаешь думать о том, что может пойти не так. Для коллег это открытие — нейросеть может сбоить не хуже кривого сетевого запроса. Сейчас я веду это AI-сообщество в Garage-IT, помогая командам внедрять современные инструменты безболезненно и эффективно.
Плюс обсуждаем, как ускорять прототипирование без потери качества. Но это работает только когда понимаешь границы технологии.
— Если смотреть стратегически — как начинающему специалисту выстраивать карьерную траекторию, чтобы лет через
— Если смотреть на то, что уже происходит, то разработка только по ТЗ уже рискованное ограничение. Рутинные задачи — верстка экранов, CRUD, простые интеграции — уже сейчас автоматизируются. Обязательным станет понимание того, как код работает в реальной среде. И вырастет спрос на экспертизу в предметной области: универсал, не понимающий бизнеса, проиграет специалисту, разбирающемуся в тонкостях финтеха или логистики.
— Исходя из этого, какой совет вы бы дали разработчику, который хочет оставаться востребованным?
— Не бойтесь уходить в проекты, где вы ничего не понимаете. Где ваша специализация пересекается с незнакомой предметной областью, с незнакомыми техническими ограничениями, с незнакомыми регуляторными требованиями. Именно там нарабатывается способность видеть систему целиком.
Каждый такой шаг давал новый способ смотреть на задачи. Их было несколько — переход из администрирования в разработку, проекты для ЕВРАЗа в КРИТ, попадание из коммерческой разработки в финтех.
Самые ценные уроки получаешь не на курсах, а когда разбираешь падения продакшна в Termius или отлавливаешь редкие баги в пиковые нагрузки в Kupibilet. Это больно и некомфортно, но это единственный способ вырасти.
