«Все, что можно автоматизировать, мы будем автоматизировать»

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

Приведу пример. Пандемия 2020 г. буквально за несколько недель кардинально изменила бизнес — произошел сильный перекос в сторону онлайна. Для «Леруа Мерлен» закрытие физических магазинов, генерирующих более 90% товарооборота, — просто катастрофа. Если бы мы не были готовы переключиться технически и психологически (использовать облака, преимущества микросервисной архитектуры и API-зации), мы бы не смогли в считанные дни перестроиться под новые требования клиентов. 

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

Это сильно влияет не только на скорость разработки и снижение Time-to-Market, но и на стабильность всех ИТ-решений компании. Чем больше мы автоматизируем, тем меньше зависим от человеческого фактора.

Еще один тренд последних лет в нашей компании — платформенные решения. С одной стороны, их появление обусловлено переходом на микросервисную архитектуру, с другой — требованиями к скорости изменений, о которой я упоминал выше.

Практически все они — результат внутренней разработки и следствие процесса API-зации, перехода на микросервисную архитектуру и последующую грануляризацию приложений. Так возникли интеграционная платформа, API-менеджмент, Service Mesh, то есть вся интеграция в компании, все связи приложений внутри и снаружи. 

Для управления интеграцией используется инструментарий API-менеджмента (единое управление распределенными интерфейсами). В «Леруа Мерлен» есть единый хаб, позволяющий интегрировать различные медиаторы (шаблоны для обеспечения взаимодействия объектов, избавляющие их от необходимости явно ссылаться друг на друга): шлюзы, сервисную сеть (Service Mesh, уровень поддержки межсетевого взаимодействия сервисов), брокеры сообщений и единый интерфейс по управлению интеграцией.

В отличие от классических подходов, инструменты API-менеджмента в «Леруа Мерлен» используются не только как внешний фасад, но и как платформа поддержки коммуникаций между командами.

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

Для оркестрации, разработки API, процессов и микросервисов мы используем подход Low-code. Так появился наш флагманский продукт Platformeco — платформа для разработки и управления микросервисами, имплементации интеграций и логики. Ее появление стало неизбежным, когда мы столкнулись, с одной стороны, с отсутствием готовых решений, способных справляться с нашим объемом бизнес-задач, а с другой — с кадровым голодом и высокими расходами на персонал.

Platformeco доступна продуктовым командам в режиме PaaS и позволяет разрабатывать микросервисы, формировать интеграционные потоки и API в графическом интерфейсе, а затем разворачивать их в облаке, получая функциональность CI/CD, автомасштабирования, транспорта между средами. Благодаря Low-code аналитики и frontend-разработчики практически без привлечения backend-разработчиков формируют функционал бизнес-логики и оркестрируют сервисы. Это позволяет обходиться минимальным количеством специалистов без потери качества, обеспечивает эффективную коммуникацию и быструю интеграцию в процесс новых сотрудников, которые ранее не работали с продуктом. Квалифицированные разработчики бизнес-функционала, в свою очередь, фокусируются на архитектуре, сложных кейсах, разработке плагинов и коннекторов для системы.

Platformeco ведет мониторинг, алертинг и трейсинг инцидентов в режиме real time, благодаря чему их обнаружение и исправление занимают в десятки раз меньше времени.

Одним из самых первых кейсов использования Platformeco стала разработка мобильной платформы для сотрудников — набора приложений для решения операционных задач в магазинах (от инвентаризации до печати ценников прямо с телефона). Для платформы было разработано более 120 единиц потоков бизнес-логики и API. Сегодня она обеспечивает выполнение более 5 млн операций ежедневно, с ней работают более 30 тысяч пользователей из ста с лишним магазинов. Благодаря Platformeco время запуска нового функционала и внесения изменений сократилось более чем в 15 раз и более чем в 20 раз уменьшилось время на локализацию инцидентов за счет встроенного сквозного мониторинга. В конечном счете Time-to-Market сократился в 3 раза. 

Полный инструментарий Platformeco сегодня используют более чем 50 продуктовых команд «Леруа Мерлен», платформа обрабатывает более 10 млрд бизнес-транзакций в месяц. Нагрузка на Low-code-системы может превышать 8 тысяч транзакций в секунду. 

Продукт активно развивается и обрастает новым функционалом за счет открытых плагинов и коннекторов к различным базам данных. В начале этого года мы тестировали его в одном из подразделений «Адео», а в прошлом месяце Platformeco стала стандартом для всей группы компаний. Наше подразделение LM Tech предлагает сам продукт и соответствующие методики внешним заказчикам из других сфер: финансов, страхования, телекома и др. 

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

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

2020 г. во многих смыслах был феноменальным. Мы закончили реструктуризацию, в результате которой на смену классическим отделам и департаментам пришли домены, в которых объединены операционные и продуктовые команды, то есть бизнес и ИТ соответственно. Поэтому да, с уверенностью могу сказать, что ИТ сыграли в наших успехах ключевую роль.

Когда магазины были закрыты, потребности клиентов не только не исчезли, но и выросли. Часть людей, оказавшись запертыми в квартирах, принялись за косметические ремонты и обустройство рабочих мест. Те, у кого была возможность уехать за город, стали заниматься дачами и приусадебными участками. Многие начали оборудовать дома для круглогодичного проживания. Спрос вырос, а поехать в магазины нельзя. Тут нам на помощь пришли развитые облачные решения. Мы используем гибридное облако — приватное, интегрированное с публичным. Контейнеризация и микросервисная архитектура, подходы к разработке, интеграция с помощью API и других асинхронных методов — все это можно было достаточно быстро перевести в облако и вносить изменения именно в те части кода, которые необходимы. Опять же, благодаря платформенным решениям, мы сокращали Time-to-Market и даже на фоне в десятки раз возросшего трафика поддерживали стабильность сайта и оперативно вносили изменения. При этом ассортимент и обслуживание клиентов за время пандемии поменялись довольно ощутимо.

Нагрузка на ИТ выросла на порядок, требования к пропускной способности увеличились в десятки раз. Если бы мы сидели на «железе», то нам просто не хватило бы мощностей. Плюс менялись процессы обработки заказа и его выдачи. Приходилось работать с персоналом и обучать людей новым процессам и операциям. Сотрудники осваивали смежные профессии, и если за контентную часть обучения отвечала операционная команда, то за использование и доступность — как раз продуктовая.

У нас полно примеров подобного симбиоза. Это новая ИТ-парадигма «Леруа Мерлен» — обеспечение необходимой скорости внутренних изменений и гибкого реагирования на изменения внешние.

Мы используем приватное облако на OpenStack и публичное от Yandex. Мы остановились на этом варианте как на самом сбалансированном с точки зрения стоимости и возможностей. Приватное облако дешевле публичного. Но для чего мы используем облака? В том числе чтобы иметь возможность быстро скалировать наши приложения в моменты пиковых нагрузок. Пики — они на то и пики, чтобы случаться нечасто. Если мы хотим, чтобы в облаке всегда были ресурсы на все случаи жизни, то в приватном нужно иметь избыточный запас. Согласно принципу Парето, в этом случае у нас 80% времени будет задействовано 20% ресурсов, остальные будут просто «греть воздух». В таком случае об эффективном использовании мощностей и денег речи быть не может. Поэтому у нас есть приватное облако, с небольшим запасом закрывающее текущие потребности, и публичное, которое в любой момент может предоставить нам нужные ресурсы. Как только необходимость в них пропадет, мы можем перестать платить. При этом мы постоянно следим за потребностями команд и увеличиваем ресурсы приватного облака, когда его загрузка достигает определенной отметки. Таким образом оно развивается, мощности увеличиваются, но деньги тратятся эффективно.

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

У Open Source есть свои преимущества. Например, отсутствие сильного вендорлока. Особенно это касается крупных вендоров, уйти от которых, конечно, можно, но сложно: требуются большие финансовые и временные затраты. Управляет Open Source не конкретная корпорация, а сообщество разработчиков. Можно стать его частью и участвовать в развитии решения, которое компания будет использовать.

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

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

Да, как я уже упоминал, мы делаем ставку на облака, контейнеризацию, автоматизацию и автоскейлинг. За счет этого получаем гибкость и отказоустойчивость. Что же до must have, это, скорее, касается соблюдения законов или определенных норм, без которых бизнес не сможет выжить. Есть компании, в которых контейнерный подход в силу разных причин неприменим. Но вместе с тем я уверен, что рано или поздно многие из них задумаются об уходе от монолитов, которые очень сильно ограничивают возможности технологического развития. 

В ритейле нет жесткого регулирования, кроме закона «О персональных данных», при этом горизонт атаки небольшой. Мы не так интересны, как финансовые организации, где всегда есть чем поживиться, либо промышленные предприятия или стратегические государственные объекты, где существует риск глобального disruption и любая атака влечет серьезные последствия. 

С безопасностью в ритейле в целом проще: у нас практически нет точек монетизации, а значит, и достаточной почвы для злоумышленников. Как правило, атакуют энтузиасты, которые хотят попробовать свои силы (таких большинство). В целом ритейл с точки зрения зрелости ИБ-систем стоит ниже перечисленных выше областей. 

Тем не менее мы занимаемся задачами, о которых многие еще даже не думают. Если мы говорим не о компаниях, которые изначально формировались в е-com, а именно о классическом ритейле с сетью физических магазинов, то наш уровень развития ИБ довольно высок. За последние 2–3 года у нас появилось много собственных продуктов, безопасность которых является одним из наших приоритетов. У клиента есть кредит доверия к крупной международной компании: скачивая приложение «Леруа Мерлен», он рассчитывает на то, что не поймает вредоносную программу, которая получит доступ к данным его банковских карт и отправит их злоумышленнику. 

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

У нас есть собственный портал управления уязвимостями — внутренняя разработка, с помощью которой мы анимируем уязвимости конкретного продукта в каждой продуктовой команде практически в режиме реального времени. Сейчас портал предоставляется как сервис другим бизнес-юнитам в группе компаний «Адео». 

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

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

Если речь о правильном подходе к написанию кода, суть как раз в стандартах, например security by design (безопасность по умолчанию). То есть безопасность приложений — это, скорее, вопрос зрелости процессов и людей, которые их реализуют.   

Отдельного внимания заслуживает работа с зависимостями. Они используются практически в любом продукте. Это библиотеки Open Source, которые применяются as is. Проблема в том, что они могут иметь уязвимости или еще хуже — бэкдоры.  Когда мы берем готовый код, то обязательно проводим проверку зависимостей. Так мы можем запретить подгружать библиотеки, которые имеют уязвимости, еще при сборке приложения.

Для статического анализа исходного кода мы используем готовое решение, которое дорабатываем под себя. Этот инструмент каждая продуктовая команда интегрирует в свой pipeline. Для анализа зависимостей мы также используем готовое решение, которое поставлялось вместе с нашим репозиторием зависимостей, то есть мы взяли «родной» инструмент мониторинга.

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

Аутсорсинг оправдан, когда нужно получить компетенции, которых у вас пока нет или, как в случае с управлением инцидентами, когда процесс может быть автоматизирован и мы можем сэкономить собственные ресурсы. У нас есть подрядчики, которых мы привлекали на задачи, по которым у нас не было собственных компетенций, в том числе на ИТ-инфраструктуру. При разработке мобильного приложения, к примеру, мы наняли аутсорсера, с которым заранее договорились, что параллельно будем развивать собственную команду. За 2 года произошел плавный переход, и сейчас разработкой мобильного приложения занимаются уже наши специалисты.

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