Поделиться
Михаил Михалев, Amazon: Инженер должен оценивать последствия решений на уровне всей системы
Современные цифровые логистические системы редко ограничиваются рамками одной страны. Они работают сразу в нескольких юрисдикциях, а также сталкиваются с разной инфраструктурой, регуляторикой и операционной практикой. В таких условиях особенно ценными становятся специалисты, чья экспертиза не привязана к одному рынку, а подтверждена способностью переносить и адаптировать сложные инженерные решения в разных странах. Инженер-программист в области вычислительной логистики Михаил Михалев работает в Amazon, где занимается разработкой алгоритмических решений для оптимизации транспортных сетей. В течение карьеры он последовательно работал с Россией, Германией, Канадой и США, каждый раз вовлекаясь в развитие и поддержку крупных логистических систем в новых условиях. Эти переезды были связаны с востребованностью его инженерной экспертизы в сложных проектах, где требовалось выстраивать устойчивые цифровые платформы на международном уровне. В этом интервью Михаил подробно рассказывает о том, как инженерные решения формируют реальную эффективность цифровых логистических систем, и делится опытом работы с такими платформами в разных странах.
CNews: В логистике часто говорят об алгоритмах. При этом по вашим проектам видно, что решающую роль играют именно инженерные решения, а не отдельные формулы. Расскажите, в чем принципиальная разница между ролями алгоритмиста и программного инженера?
Михаил Михалев: Разница проходит по линии ответственности. Алгоритмист работает с моделью, задавая формулировку задачи, рамки допустимых ограничений и критерии оптимальности. В свою очередь, программный инженер отвечает за поведение всей системы в реальности. А реальность почти никогда не соответствует предположениям модели.
В логистике это особенно заметно. Мы можем бесконечно усложнять модель, учитывая типы грузовиков, дорожные условия, расход топлива, режимы труда водителей и многое другое. Но в какой-то момент мы выходим за пределы того, что система вообще способна корректно использовать. Инженер сталкивается с тем, что данные приходят с задержкой, инфраструктура ведет себя не так, как ожидалось, а внешние события могут в одночасье сделать все исторические прогнозы нерелевантными. Я всегда говорю, что алгоритм оптимизирует гипотетическую реальность, а инженер отвечает за то, что происходит, когда эта гипотеза ломается.
Инженер следит за поведением системы и последствиями автоматических решений. Это означает, что он должен понимать, в каких ситуациях система должна принимать решение, а в каких — нет. Если автоматическое решение делает систему более хрупкой, инженер обязан это остановить. Это и есть ответственность за устойчивость всей операционной среды.
CNews: Вам довелось выстраивать работу устойчивых цифровых систем по всему миру. Вы часто говорите, что ваша основная зона ответственности в этом — интеграция и объединение алгоритмов. Почему именно это оказывается важно для эффекта?
Михаил Михалев: Потому что в больших логистических системах почти никогда нет одного алгоритма. Прогноз спроса обычно строится на недельном или месячном горизонте. Маршрутизация же, напротив, работает в коротком горизонте, поскольку состояние дорог, например, через месяц предсказать невозможно. Каждая из этих систем может работать отлично сама по себе. Проблемы начинаются, когда мы пытаемся объединить их в одну цепочку, поскольку у них разные временные допущения, частота обновлений и трактовка входных данных. В итоге каждая оптимизирует свою версию реальности.
Я думаю, что именно на стыках может потеряться эффект. Если инженер не выровнял семантику времени и контрактов между системами, то даже очень хорошие алгоритмы начинают мешать друг другу.
CNews: Получается, что бывают ситуации, когда алгоритм выглядит «хорошим», но реализация ломает качество. Можете привести пример, где ваше инженерное решение оказалось важнее самой модели?
Михаил Михалев: Это очень распространенная ситуация, особенно при переносе решений между странами. У меня была ситуация, в которой модель, разработанную в рамках одной страны, не получилось перенести без изменений в другую. Так, алгоритмы, которые отлично работают в США, перестают работать в Европе или Японии.
В США логистическая инфраструктура устроена так, что склады обычно находятся вне городов и имеют огромные парковочные зоны. Это исторически сложившаяся реальность, так как география позволяла строить именно так. В Великобритании, Японии или в центральной Европе склады часто находятся в черте города, потому что инфраструктура формировалась сотни лет назад, и сейчас переносить целые локации для хранения было бы очень трудно. Из-за этого там физически нет возможности принять одновременно большое количество грузовиков. Алгоритм этого не знает. Он оптимизирует расписание, и все выглядит идеально: машины приезжают вовремя, а маршруты выбраны оптимально. Однако в реальности грузовики просто не могут припарковаться. Возникает задержка, расписание начинает «плыть», и в какой-то момент операционные команды перестают доверять системе.
Здесь потребовались серьезные инженерные решения, ведь пришлось внедрять инфраструктурные ограничения. Формально это действительно ухудшает оптимум, но сильно повышает применимость результата. И это дает больший эффект, чем дальнейшее усложнение модели.
CNews: Вы работаете с целыми цепочками решений, где прогнозы, планирование и маршрутизация должны работать согласованно. Расскажите, как ваши инженерные решения в целом влияют на то, можно ли использовать результат оптимизации в операционной работе?
Михаил Михалев: Я бы ответил просто: они влияют напрямую. В логистике результат имеет ценность только тогда, когда его можно выполнить. Можно построить модель, где водитель работает 24 часа в сутки, техника не ломается, а пересчет маршрутов происходит мгновенно. На практике такой план просто невыполним.
Инженер отвечает за то, чтобы система учитывала человеческие, технические и регуляторные ограничения. Нам не сильно важна красота алгоритма, ведь мы работаем на доверие. Если операционные команды не верят системе, она перестает влиять на бизнес.
Важно понимать, что лучший алгоритм по локальной метрике может давать худший системный результат. Например, он может создавать нереалистичные пики нагрузки или переносить весь объем перевозок на отдельные дни. На бумаге это выглядит хорошо, но в реальности такие планы невозможно выполнить. Поэтому мы смотрим на систему в целом и учитываем характер распределения нагрузки, устойчивость планирования и реакции на сбои.
CNews: Понятно, то есть часто в больших системах «лучше» может означать «хрупче». Интересно, а в вашей практике были случаи, когда вы сознательно упрощали решение ради устойчивости?
Михаил Михалев: Да, такое часто бывает. Самый распространенный соблазн — пересчитывать оптимум при каждом изменении: будь то сломанный грузовик, обновленный прогноз или появление новой информации. На практике это приводит к хаосу, ведь маршруты постоянно меняются, водители теряют ориентиры, а операционные команды перестают понимать, по какому плану работать.
Часто в таких случаях я работаю с инерцией. Проще говоря, я фиксирую план на определенный цикл, например, день или неделю. Мелкие изменения игнорируются. Формально план становится менее точным, но это лучше, поскольку он стабильный, предсказуемый и реально используемый.
CNews: Вы создаете системы, функционирующие в огромных масштабах. Расскажите, что сложнее в крупных логистических системах, с которыми вы работаете: собрать алгоритмы или сделать их результаты интерпретируемыми и проверяемыми?
Михаил Михалев: С интерпретируемостью в логистических системах всегда больше сложностей, чем с самими алгоритмами. Алгоритм можно реализовать и встроить в систему. Гораздо труднее сделать так, чтобы результат его работы можно было спокойно разобрать и объяснить задним числом.
Операционные команды ежедневно работают с планом и должны понимать логику решений. Когда маршрут меняется или приоритеты выглядят иначе, чем вчера, им важно видеть не формулу, а ход рассуждений системы. Без этого любое решение начинает восприниматься как случайное, даже если расчет был корректным.
Для этого система должна сохранять контекст принятия решений. Я имею в виду понятную картину того, в каких условиях был сделан расчет и что было его основой. Если контекст не зафиксирован, повторный запуск легко приводит к другому результату, и система уже не способна связать его с предыдущим. В таком виде система может выдавать хорошие решения, но без возможности их объяснить доверие постепенно исчезает, а вместе с ним и реальное применение в работе.
CNews: В логистике постоянно появляются новые условия: погода, технологии или регуляторные изменения. Как вы внедряете новое, не переписывая систему целиком?
Михаил Михалев: Один из основных принципов в крупных логистических системах заключается в том, что ограничения должны задаваться через данные. Если появление нового условия требует переписывания ядра системы, это означает, что архитектура изначально была спроектирована неправильно. В масштабируемых системах изменения должны подключаться просто как новые параметры.
Хороший пример — появление и массовое внедрение электромобилей в логистике. В традиционных моделях грузоперевозок многие факторы можно было игнорировать без существенного ущерба для качества планирования, например, дозаправки. Электромобили меняют эту логику полностью. У них появляется жесткая зависимость от уровня заряда, длительные циклы подзарядки, сильное влияние температуры и погодных условий на запас хода. Эти параметры нельзя просто добавить как частный случай в существующий код, не разрушив архитектуру. Правильное инженерное решение здесь заключается в описании новых ограничений как данных: параметров транспорта, профилей энергопотребления, допустимых окон зарядки или же климатических коэффициентов. Система должна уметь работать с этими данными так же, как с любыми другими ограничениями, не зная заранее, с каким типом транспорта она имеет дело.
Тот же принцип работает и для регуляторных требований, особенно в международной логистике. Наиболее показательный пример — Франция. В рамках всего Европейского союза перевозки часто рассматриваются так же, как в границах одной страны: единые правила, схожие требования к режиму труда водителей, стандартизированная инфраструктура. Франция — заметное исключение из этого правила. У них в законодательстве действуют дополнительные требования к режиму отдыха водителей. В ряде случаев водитель обязан проводить отдых в отеле с соблюдением конкретных условий. Эти требования распространяются даже на тех, чей маршрут начинается, заканчивается или проходит через территорию Франции. Таким образом, даже транзитное пересечение страны накладывает дополнительные ограничения на планирование маршрута и смен.
С инженерной точки зрения это особенно сложный случай. Наивное решение было бы добавить в код специальные условия: «если Франция, то делать иначе». Такой подход быстро приводит к фрагментации системы. Сегодня есть Франция, а завтра будет аналогичное исключение уже в другой стране. В результате ядро системы превращается в набор плохо управляемых ветвлений, которые сложно тестировать, масштабировать и поддерживать. Правильным в таких случаях будет вынести регуляторные требования в слой данных и конфигураций, применимых к конкретному участку маршрута. Франция в этом случае — не особый «режим работы», а территория с набором дополнительных ограничений, которые автоматически учитываются при планировании.
Такой подход позволяет системе одинаково обрабатывать разные юрисдикции, не зная заранее их особенностей. Если правила меняются или появляются новые страны с похожими требованиями, достаточно обновить конфигурацию, не трогая архитектурное ядро. Это принципиально важно для систем, работающих в международном масштабе, где регуляторная среда постоянно эволюционирует.
CNews: И последнее. У вас большой опыт работы в логистике разных стран, и, как никто другой, вы знаете все тонкости профессии. Расскажите, какие качества программного инженера вы считаете ключевыми для работы в таких системах?
Михаил Михалев: В первую очередь, это системность. Любое изменение влияет на всю цепочку: от планирования до операционной работы. Инженер должен оценивать последствия решений на уровне всей системы, включая вторичные эффекты, которые проявляются со временем. Второе важное качество — аккуратность в работе с данными. В логистике данные напрямую отражают физическую реальность: доступность транспорта, состояние инфраструктуры и даже ограничения по времени и ресурсам. Ошибки, задержки или некорректная интерпретация данных быстро делают любые алгоритмы бесполезными. И последнее очень нужное качество — умение ограничивать сложность. В логистических системах всегда есть возможность добавить какой-нибудь еще один фактор, но избыточная детализация делает систему хрупкой и плохо управляемой. Инженер должен понимать, что не все действительно стоит включать в модель.
Короткая ссылка
