17 Ноября 2021 13:23 17 Ноя 2021 13:23 |

Поделиться

Владислав Хинку, H&M: Офлайн-сценарий многие недооценивают

CNews: Владислав, у вас большой опыт в построении ИТ-архитектуры. Вы занимались модернизацией POS-системы H&M — одного из крупнейших ритейлеров в мире. Такие проекты — зона высокой ответственности: на кону работа тысяч магазинов и миллиарды выручки. Какова была ваша роль в этом проекте? И какие из архитектурных решений, которые вы лично предлагали и отстаивали, стали ключевыми для успеха?

Владислав Хинку: Я был архитектором систем обеспечения безопасности на стороне вендора Xender. Эта компания производит POS-системы для H&M. Наш продукт используется практически во всех европейских странах, а также ещё в нескольких государствах за пределами Европы, например в Южной Африке.

Я занимал позицию архитектора безопасности именно в стратегии перехода в облако. Отвечал за архитектуру и гибридные условия при переходе с монолитного продукта на гибридный. Изначально предполагалось строить решение с приоритетом облачных технологий, но я убеждал H&M, что более правильный подход — гибридная архитектура. По сути, я занимался проектированием архитектуры и этапов перехода с монолитного программного решения на гибридные условия.

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

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

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

CNews: Успешные ИТ-архитекторы в ритейле часто сталкиваются с противоречием: бизнес хочет «всё и сразу» — новые функции, нулевые простои, мгновенную отдачу. Как вы выстраивали диалог с руководством H&M? Что помогало убеждать в необходимости поэтапной модернизации, а не быстрой замены?

Владислав Хинку: Многие архитекторы, особенно старой школы, — очень технические специалисты. Но я часто видел, что у них есть серьёзный разрыв в коммуникации с бизнесом. А когда разговариваешь с бизнесом, надо говорить на его языке.

Если мы просто показываем технические данные, то они ничего не говорят. Поэтому каждый раз нужно аргументировать и объяснять на понятном языке. Например, через цену ошибки: сколько будет стоить один час простоя системы. Так бизнес сразу понимает риски и причины технологических решений.

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

CNews: В чём, на ваш взгляд, главная авторская находка или принцип, который вы применили в этом проекте и который отличает ваш подход от стандартных или типовых решений? Можно назвать это «методом Хинку»?

Владислав Хинку:. Я акцентируюсь на необходимом, когда начинаю работать с новой задачей или крупной модернизацией. Обычный подход архитектора: посмотреть, какие новые технологии можно использовать, какой тренд сегодня, куда движется индустрия. Я же обычно не смотрю на тренды. Конечно, я их изучаю, понимаю, в чём их плюсы и минусы. Но в первую очередь я смотрю на то, что бизнес не может проигнорировать. Какие ограничения абсолютно не подлежат обсуждению.

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

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

CNews: Владислав, у вас редкое для ИТ-архитектора сочетание глубокой технической экспертизы в глобальном ритейле и юридического образования. Я знаю, что вы много внимания уделяете управлению рисками. Как этот ваш «двойной контур» работает на практике? Что вы считаете самым важным? И, если не секрет, вспомните случай, когда именно ваше решение предотвратило серьёзный сбой.

Владислав Хинку: Я думаю в терминах последствий и ответственности. Не просто «сделали программное обеспечение, отдали клиенту, а дальше он сам». Я всегда стараюсь смотреть на то, как удобно будет клиенту использовать систему после внедрения, какие сценарии могут произойти, как это будет работать.

Нельзя думать: «95% будет работать хорошо, а 5% — плохо». Важно планировать наперёд и создавать решения для резервного копирования, которые покрывают худшие сценарии. Если даже в худшем случае мы сможем предоставить клиенту рабочую среду, где он продолжит работу, значит, наш продукт хорош.

Именно ответственность и взгляд вперёд отличают мою методологию от простого конструирования архитектуры под текущий тренд или новые технологии.

Мои решения не раз позволяли предотвратить сбои. Например, при запуске в производство я всегда настаивал на постепенности, а не на модели «большого взрыва». И несколько раз это давало большой эффект. Однажды возникла ошибка в бизнес-логике, которая могла сделать программное обеспечение неработоспособным в целой стране. Например, в Германии около 800 магазинов — ошибка стоила бы огромных денег. Поэтому лучше отложить внедрение функции и поэтапно тестировать её в реальной среде, чем запускать сразу. Мы можем увидеть, как она работает технически и как удовлетворяет бизнес-процессы. Это помогает предотвратить большие потери, потому что мы тестируем в реальной среде и понимаем, когда функция подходит, а когда её нужно изменить.

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

CNews: На форуме CNews «Кейсы: опыт ИТ-лидеров» вы рассказывали о гибридной архитектуре для ритейла и о том, как обеспечить цифровую трансформацию без остановки бизнеса. Ваше выступление вызвало большой интерес у профессиональной аудитории. Что, с вашей точки зрения, многие недооценивают, когда строят гибридные архитектуры, и к чему это приводит?

Владислав Хинку: Возьмём, например, перенос данных в облако. Многие думают, что облако — источник истины, а пограничные зоны — это просто локальный кэш. Но это не совсем так, по крайней мере для POS-платформы. Облако не является единственным источником истины, потому что сами транзакции происходят в пограничной зоне, а не в облаке. Роль пограничной зоны должна быть уравнена с облачным решением: она не просто кэш. Там идёт двусторонний обмен информацией: облако отправляет в неё данные, и она отправляет в ответ большой объём информации.

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

Это не значит, что POS должен каждый раз обращаться к облаку за информацией. Вся бизнес-конфигурация системы должна дублироваться на пограничном уровне. Потому что есть огромные массивы бизнес-данных, которые программный комплекс использует постоянно, и он всегда должен иметь к ним доступ.

Главный разрыв, который многие не замечают при создании гибридной архитектуры, — это офлайн. Нужно точно определить, для каких данных допустима задержка, а для каких — нет. Понимание, что актуально, а что не очень, позволяет системе работать правильно даже без связи с облаком.

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

CNews: На конференции Business Process Management вы делились опытом модернизации устаревших систем в глобальном ритейле. Это среда, где нельзя просто «выключить старое и включить новое»: многие магазины работают круглосуточно, транзакции идут непрерывно. Какой архитектурный паттерн в таких условиях оказывается самым сложным в реализации и как вы справлялись с этим вызовом?

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

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

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

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

CNews: Владислав, если смотреть вперёд, то в каком направлении, на ваш взгляд, будет развиваться ИТ-архитектура в ближайшие 5–10 лет? Какие тренды действительно изменят правила игры, а какие, возможно, окажутся переоценёнными?

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

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

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

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

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

Дарья Мингалева

Поделиться

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