Архитектурные решения инженера-разработчика лежат в основе крупнейших коммерческих платформ, государственных сервисов и международных ИТ-проектов, помогая компаниям сокращать простои, экономить ресурсы и превратить ИТ-системы в стратегический актив.
Сайт для современного бизнеса — это не визитка, а инфраструктура, на которой держатся продажи, учёт, коммуникации и клиентские сервисы. С ростом компании веб-сайт становится стратегической системой. Вместе с этим растут риски: дубли кода, хаотичные интеграции, отсутствие общей логики приводят к сбоям и простоям с прямыми финансовыми потерями. Согласно опросам, 58% российских организаций в 2024 году сталкивались с незапланированными перебоями или потерей данных. Более того, по данным Monq Digital Lab, серьёзные ИТ-инциденты за тот же год испытали 93% компаний, средний ущерб при четырёхчасовой паузе — около 2 миллионов рублей.
О том, как архитектурные решения помогают бизнесу избегать сбоев, экономить ресурсы и превращать ИТ-системы в стратегический актив, мы поговорили с Дмитрием Кузьминым, членом международного объединения разработчиков Raptors.Dev и Международной Ассоциации Экспертов в области Технологий (AITEX). Во время работы с программным обеспечением для крупной сети магазинов и онлайн-ритейла 12 STOREEZ он выступал единственным фронтенд-архитектором новой программы для управления складом (WMS-системы) и с нуля создал пользовательские логику и интерфейс системы, обеспечив ее стабильную работу. Сегодня Дмитрий отвечает за пользовательский интерфейс и его архитектуру в крупных международных проектах. Его решения — от консолидации репозиториев до внедрения единых стандартов Angular — позволили ускорить CI/CD, сократить издержки и повысить качество кода, а менторство более двадцати full-stack разработчиков укрепило экспертизу команды.
Дмитрий, как разработчик и архитектор программного обеспечения, чьи решения легли в основу крупнейших коммерческих и государственных платформ, вы известны своей способностью предотвращать сбои и превращать ИТ в стратегический ресурс. Почему, на ваш взгляд, сбои в ИТ-системах до сих пор остаются такой распространённой проблемой для компаний?
Это вопрос не только технологий, а приоритетов. ИТ-решения часто воспринимают как вспомогательный инструмент, и на его устойчивость обращают внимание в последнюю очередь. В итоге компания годами работает на временных решениях, пока они не начинают сыпаться. Добавьте сюда кадровый дефицит: опытных инженеров мало, а молодые команды не всегда видят всю картину. В совокупности это и делает сбои массовым явлением.
Вы создавали архитектурные решения для стартапов, крупных ритейлеров и международных корпораций. Работа с такими разноплановыми задачами требует умения адаптировать подход под разные масштабы. Какие результаты ваши уникальные разработки принесли индустрии в целом?
Мой опыт показывает, что архитектура способна менять не только внутренние процессы компаний, но и задавать ориентиры для отрасли. В государственных проектах, таких как «ЭМК» и «Дневник МЭШ», мои решения помогли миллионам пользователей получить доступ к медицинским и образовательным сервисам, а сами системы стали примером масштабной цифровизации. В международных проектах архитектура превратилась в инструмент координации десятков команд, позволив ускорять релизы и поддерживать высокое качество кода. А в ритейле я создал весь пользовательский интерфейс и часть серверных модулей WMS-системы для 12 STOREEZ, которая обеспечила показатель OTIF (On-Time In-Full)
Веб-сайт — это один из главных активов ритейла. Будучи единственным фронтенд-архитектором, вы с нуля создали пользовательский интерфейс для WMS-системы, которая выдавала максимально возможную стабильность для отрасли. Какие решения позволили построить интерфейс и клиентскую логику так, чтобы склад работал без остановок?
Чтобы предотвратить простои, я сделал ставку на поэтапную миграцию: микрофронтенды и feature-toggles позволяли развёртывать новые модули параллельно со старыми и при необходимости мгновенно возвращаться к предыдущей версии. Дополнительно я внедрил механизм поштучной прослеживаемости товаров (item_id), который принёс компании ощутимую экономию. Благодаря осознанным архитектурным решениям удалось добиться показателя OTIF на уровне
Многие компании используют такие инструменты для решения текущих задач. Но лишь немногие из этих проектов в итоге становятся фундаментом для роста всего бизнеса. За счет чего вам удалось превратить технический проект в фактор роста бизнеса и реальный источник прибыли?
Мы сразу вышли за рамки чисто технической задачи. Важно было показать, что новая система экономит ресурсы, ускоряет работу сотрудников и снижает вероятность простоев. Эти результаты легко измеряются — по времени обработки заказов, по уровню ошибок, по затратам на поддержку. Как только мы увидели этот эффект, система стала восприниматься не как программистский проект, а как реальный актив, который влияет на прибыль и масштабирование.
Сегодня вы работаете над международными проектами. Этот уровень требует иной ответственности и масштаба. Какие новые сложности появляются у вас как у старшего разработчика и фронтенд архитектора при работе с десятками команд и сотнями сервисов по всему миру?
В e-commerce главный приоритет — это непрерывность процессов: сайт должен всегда принимать заказы, корзина и оплата работать стабильно, статус доставки отображаться корректно. Когда я перешёл к международным системам, к знакомым задачам добавились сложности масштаба. Здесь десятки команд в разных странах, сотни сервисов и высокая цена ошибки при интеграции. Поэтому задачи как программиста, так и архитектора уже не ограничиваются стабильностью. Важно выстроить общие стандарты, сделать решения предсказуемыми и управляемыми. Например, объединение репозиториев в монорепозиторий и переход на pnpm ускорили CI/CD, снизили издержки и увеличили продуктивность команды, а системные код-ревью, архитектурным ревью и менторство помогли поддерживать высокий уровень качества. Если в e-commerce архитектура отвечает за бесперебойность ключевых пользовательских сценариев, то в международных компаниях она становится инструментом координации и устойчивого развития всей разработки.
Ваш вклад в государственные проекты имеет национальное значение. Например, «Электронная медицинская карта» — сервис, которым ежегодно пользуются сотни миллионов раз. От его стабильности зависит качество и своевременность медицинской помощи. Многие ключевые функции, от диспансеризации до больничных, реализовали именно вы. Какую роль сыграли ваши решения в успехе этого проекта?
Моя задача заключалась в том, чтобы сделать доступ к медицинским услугам максимально надёжным и удобным. Я разработал пользовательские интерфейсы для диспансеризации, акушерского анамнеза и электронных больничных. Эти функции напрямую влияют на жизнь людей: они помогают пациентам вовремя проходить обследования, получать корректные документы и быстро взаимодействовать с системой здравоохранения. Важно было построить интерфейс так, чтобы он был удобным, доступным и предсказуемым для граждан.
Ваши решения обеспечили устойчивость другой социально значимой платформы — «Дневник МЭШ», крупнейшего образовательного сервиса страны с аудиторией более 2,8 млн школьников и родителей, лауреата Премии Рунета. Как при такой массовой аудитории вы построили стабильно работающий сервис, гибкий к новым функциям?
Я занимался поддержанием стабильности пользовательского интерфейса и устранением багов различной степени сложности, от незначительных до критических. Это позволило повысить надежность пользовательской части системы и обеспечить ее предсказуемое поведение. Работа велась в команде, где важно было не просто исправлять ошибки, а поддерживать согласованность модулей и плавность работы интерфейса для миллионов пользователей. Так платформа сохраняла стабильность и оставалась удобной для школ, учеников и родителей.
Фактически вы заложили основу для цифровизации ключевых социальных сфер страны. Масштаб этих проектов огромен: «ЭМК» обрабатывает более 400 млн обращений в год, а от его стабильности зависит жизнь людей. Как вам удавалось справляться с такой нагрузкой и обеспечивать надежность решений на столь высоком уровне?
Самым сложным было то, что в госсекторе нельзя остановить систему ни на час: люди ждут, что сервис всегда доступен. При возникновении срочных задач я разбивал проблему на части, выстраивал приоритеты и действовал системно. Такой подход позволял сохранять качество решений даже под давлением. Для меня это стало настоящей школой устойчивости: работа в условиях высокой нагрузки научила концентрироваться на главном и делать программное обеспечение и его архитектуру максимально надежными, ведь от этого зависели не только бизнес-процессы, но и реальные потребности граждан.
Вы активно работали в open source, улучшая популярные инструменты, которые используют тысячи разработчиков по всему миру, а также такие глобальные корпорации, как Google и Adobe. Был ли у вас опыт именно разработки пользовательских интерфейсов в рамках открытого кода, когда результатом становится не только внутренняя оптимизация, но и удобный продукт для конечного пользователя?
Да, такой опыт был. Например, я сделал open source-проект для управления устройствами Xiaomi — mi-home-toolkit. Он позволял включать LAN-режим у лампочек через простой пользовательский интерфейс, без сложных манипуляций с кодом. Фактически я упростил задачу, которая раньше требовала технических знаний, до пары кликов. Этот проект получил отклик в сообществе Home Assistant, потому что дал пользователям прямую ценность. Позже инструмент получил дополнительный функционал, позволяющий выполнять команды и на других устройствах умного дома, помимо лампочек. А работа над документацией и примерами для Angular, MDN и web.dev тоже во многом связана с интерфейсами: чем понятнее гайд, тем проще разработчику внедрить решение в свой продукт, а документация закладывает чистоту и безопасность кода.
Многие компании всё ещё считают архитектуру внутренним делом разработчиков. Как убедить бизнес, что это стратегический актив, влияющий на прибыль и конкурентоспособность?
Лучше всего работают в цифрах. Когда показываешь руководству не только красивую схему, а конкретные метрики — скорость релизов, снижение ошибок, экономию времени команды, — отношение сразу меняется. Ещё один способ — демонстрировать сценарии «что если»: сколько заказов будет потеряно при падении сайта или сколько часов уйдёт на исправление накопленных багов. Тогда архитектура перестаёт быть абстрактной темой и становится частью разговоров о рисках и деньгах. В моём опыте именно такой язык помогает бизнесу увидеть архитектуру как стратегию, а не как техническую деталь, ведь по сути, это поле, где решается будущее его конкурентоспособности.
Какие новые вызовы в архитектуре вы видите в ближайшие годы? Что станет главным испытанием для компаний, которые хотят сохранить устойчивость цифровых сервисов?
Думаю, главный вызов в архитектуре — не технологии, а управление сложностью. Это требует фокуса на операционных качествах системы, таких как производительность и безопасность, которые часто конфликтуют. Поэтому зрелая архитектура — это стратегия осознанных компромиссов, а не погоня за техническим идеалом. Сегодня жизнеспособность этой стратегии проверяется в двух плоскостях. Первая — экономическая эффективность: архитектура должна быть финансово жизнеспособной в облаке, что требует грамотного выбора сервисов. Вторая — когнитивная нагрузка на команды: система должна оставаться понятной, чтобы её могли безопасно развивать и поддерживать. В итоге выигрывают не те, кто слепо следует трендам, а те, чьи архитектурные компромиссы соответствуют ключевыми целями бизнеса.
