2 года назад мы начали вести блог на Habr, стартанув с обзорного текста о том, что мы делаем, какие технологии используем и куда движемся. С 2017 года многое поменялось, и сегодня мы расскажем как делаем свое решение – глобальную платформу управления Connected Cars, которую используют как многие пользователи, так и компании самого разного уровня. Материал разбит по процессам, от постановки проблемы до деплоя.
Флагманский продукт Bright Box — Remoto — технологически сложная, насыщенная функциональностью платформа для Connected Car, в которую входит оборудование, софт для дилеров и автопроизводителей плюс мобильное приложение для пользователя. По первичной аналитике Bright Box среди автовладельцев выяснилось, что в первую очередь им требуется удаленное управление блокировкой дверей, климат-контроль и поиск автомобиля с оповещениями об ударах или эвакуации. Последнее – уже классика. Сейчас блок Remoto обеспечивает пользователя следующими услугами: дистанционное управление функциями автомобиля, возможность получения данных от аппаратных средств и CAN, GPRS, SMS, Bluetooth и контроль выходной мощности на электронный блок зажигания. Пользователь получает эту информацию в мобильное приложение.
И таким пользователем может быть не только владелец машины. Доступная к сбору информация может стать полезным подспорьем для многих участников авторынка. Например, каршеринг. Сегодня каршеринговые компании являются самыми активными игроками на автомобильном рынке. Москва стала городом номер один по общему количеству автомобилей, задействованных в каршеринге. К 2020 году каршеринг должен достичь отметки в 40 тысяч автомобилей в России. Каршеринг-компании становятся владельцами следующих данных: пробег, GPS-координаты, скорость, состояние дверей и уровень топлива. Ключом ко всему этому является смартфон, который является более дешевым и более безопасным вариантом.
Андрей Куприков, сооснователь и директор по развитию бизнеса YouDrive и один из клиентов Bright Box:
“Каршеринг без телематического решения трудно себе представить. Наша платформа обязана собирать всю возможную информацию об автомобиле, что и как с ним происходит. Иначе это отразится на бизнесе. Именно телематика дает информацию о стоимости ремонта и запчастях, стоимости простоя автомобиля, который находится в ремонте по вине любителя скорости. При наличии на борту телематического устройства можно выстраивать уникальную программу лояльности пользователя.”
С начала этого года Remoto стали поставщиком решений для двух крупных компаний по совместному использованию автомобилей, YouDrive и EasyRide, с 1000 автомобилей в своем автопарке. Использование решения в каршеринге не только удобно, но и эффективно с позиции безопасности и финансовой стороны — в виде снижения риска ДТП и в программе лояльности. С развитием каршеринга накапливаются данные о пользователях, и вот уже у каршеринга, как у банков, появляется некая система скоринга клиентов. О логике работы алгоритмов скоринга пользователей каршеринга мы писали дважды, разбирая сначала алгоритм скоринга, основанный на резких ускорениях и торможениях, а затем алгоритмы анализа стиля вождения, основанные на значениях скорости, оборотов двигателя и показателях акселерометра.
Но мы активно работаем не только на российском рынке, а это – дополнительный вызов. С расширением географии работы стало ясно, что правильная и эффективная перестройка инжиниринговой вертикали – ключевой момент развития.
Рассказывают Виталий Баум, Chief Product Officer
и Вячеслав Соколов, Chief Engineering Officer:
Наша система состоит из набора компонентов. В инжиниринге за них отвечают выделенные команды. Фактически деятельность Engineering включает в себя 3 бизнес-процесса и набор поддерживающих сервисов.
Внутри Engineering подразделения можно выделить следующие бизнес-процессы:
Стоит отметить, что задача по определению функциональных требований к той или иной фиче лежит на департаменте Product Management, в который помимо продуктологов входят также аналитики и дизайнеры. Далее требования поступают в Product development департамент, перед которым стоит сложная задача по декомпозии фичей по компонентам системы, включая встроенное ПО устройства. Эту задачу решает Архитектор департамента Product Development вместе с командой системных аналитиков.
Как выглядит планирование продукта? С недавнего времени product management стал частью инжиниринговой команды. И такая оргструктура нашла отражение в том, как мы начали работать. PM-команда определяет, какой продукт должен быть в целом, какие у него должны быть функции безотносительно компонентов системы. Получается бриф – поверхностное описание того, что надо сделать в задаче. После этого готовятся функциональные спецификации, которые мы называем FSD, или набор job stories — например, возможность в продукте отправить заявку «записаться на ТО». Каждая фича у нас описана набором подобных job stories.
PM-ы также занимаются техническим дизайном. Они выполняют технический анализ функциональной спецификации и создают технический дизайн – TDD (Technical Design Document), обсуждают этот технический дизайн с разработчиками, приземляют его под их понимание. После того, как написаны функциональные требования и технический дизайн, мы начинаем работать над интерфейсом – это user experience интерфейс.
Таким образом, продуктологи формируют определенный набор «единиц» полезности для клиента (“записатьcя на ТО” может быть такой единицей полезности) и передают специалисту, описывающему логику в этом наборе. Полезность в заявке на ТО означает, что клиент может заполнить форму с нужной информацией, совпадающую с тем, что ожидают дилеры при подаче заявки на ТО. Продуктолог также анализирует рынок, изучает, что должно быть в продукте и какую это дает ценность клиентам.
Наши продуктологи сегодня больше общаются с бизнесом внутри компании либо с клиентами напрямую. Формированием roadmap занимается roadmap комитет, в который входят ТОП менеджеры компании, чтобы учесть все направления развития компании. Комитет собирается раз в квартал.
Это делается для того, чтобы координировать общие договоренности и обеспечивать целостность продукта, чтобы фичи плавно ложились в текущее видение продукта.
Есть отдельный сервис – cyber security, который взаимодействует с людьми, работающими с устройствами и специалистами из отдела бэкенда с целью выявления уязвимостей, их закрытия и оценке рисков, к чему эти риски могут привести. Сегодня этому подразделению задачи ставит Chief Engineering Officer, который возглавляет также продуктовую команду, а та в свою очередь общается с клиентом и понимает, что сейчас нужно для того, чтобы соответствовать всем нормам cyber security. Всё это включается в план релизов, закрываются уязвимости, получаются сертификаты и в целом устраняется gap в плане безопасности.
После того, как функциональность отработана инжинирингом и оценена отделом безопасности, ее спецификация поступает к product development team, где рабочая группа декомпозирует функции по компонентам системы – что относится к backend, что к устройству, что должно уметь мобильное приложение. Product development team и HW engineering team договариваются по взаимодействию, всё сводится в совместный план и расходится по командам.
В конце разработки собранный результат проходит интеграционное тестирование и выкатка в релиз на облачную платформу. На облачной платформе, где мы хостимся (Azure), размещены окружения для клиентов. За окружения отвечает операционная команда, в которой работают инженеры, DevOps-ы и поддержка.
Комментарий от Владимира Глазкова, Senior DevOps Engineer:
Вся наша инфраструктура описана в виде кода. Все изменения мы делаем только через код. Данный подход позволяет снизить риск человеческого фактора при обновлениях. Также это позволяет быстро развернуть дополнительный экземпляр окружения для неких временных срочных нужд. В случае отказа вычислительных мощностей (VM/VMSS), можно быстро развернуть новый инстанс.
О CI/CD – на данный момент мы используем связку TeamCity/Octopus Deploy. В TeamCity идет процесс сборки .net проектов, запускаются Unit-тесты, после чего создается релиз в Octopus и деплоится в соответствующие таргеты (VM / VMSS / K8S). После удачного деплоя запускаются acceptance-тесты. Если какой-то из тестов упал, команда разработки получит уведомление.
Изначально под каждый бизнес-проект создавались отдельные наборы ресурсов, в том числе инструменты CI/CD. Достаточно быстро пришло осознание, что при росте количества проектов данный подход обречен на провал – администрировать такой зоопарк эффективно просто невозможно. Два года назад был запущен проект унификации, который завершился 4 месяца спустя. В его процессе были выделены core-компоненты системы, для них процесс сборки и деплоя един для всех окружений. Также была описана и внедрена возможность добавления сборки/деплоя дополнительных компонентов специфичных для конкретного бизнес-проекта. При создании новых окружений отныне не требуются отдельные экземпляры TeamCity & Octopus. Были написаны скрипты, которые через API создают и конфигурируют все необходимые для сборки и деплоя вещи.
Мы пришли к следующему использованию окружений: для разработки каждая команда использует два окружения:
Таких наборов окружений может быть много, обслуживать их достаточно просто в виду проведенной унификации.
Также имеется окружение для приемки релиза командой, отвечающей за боевое окружение. На нем проходит финальное тестирование перед деплоем в продакшн.
Мы имеем договоренность с разработчиками насчет устройства трансформаций конфигурационных файлов. В каждом проекте существует файл, который содержит набор параметров, имеющих разное значение на разных окружениях. Разработчики заполняют файл необходимыми параметрами (строками подключения к БД, ключами подключений и т.п.), значениями этих параметров являются переменные. Для каждой среды значения этих переменных индивидуальны. При таком подходе разработчикам ничего не мешает собирать локально и проверять у себя. Переменные хранятся в Octopus Deploy.
Для мониторинга мы используем Azure Monitor, Application Insights и Log Analytics. Доживает свое время Zabbix, вероятно, в будущем ему будет отведена почетная роль внешних проверок.
Когда я присоединился к компании, создание нового окружения занимало три недели. Инструкций почти не было, изменения делались вручную и нигде не фиксировались. Наш путь к IaaC начался с простой автоматизации, которая позволила сократить процесс до 1 недели. Сейчас создание нового окружения занимает 4 часа. Автоматизировано около 95% действий.
Наш бекенд написан на .net (4.6/4.7 и core), фронт – JS. Для хостинга используем Virtual Machine Scale Sets и K8S. Соответсвенно, масштабироваться под изменение нагрузки очень легко.
Рассказывает Иван Столет, Head of Platform Development Bright Box:
Вы всегда можете найти схему текущей архитектуры на сайте.
Все данные в системе хранятся распределенно. Существуют отдельные базы по хранению персональных данных с привязкой к региону и организованные в соответствии с местным законодательством. Есть базы данных, в которых аккамулируется контентная часть сервисов customer retention, хранение новостей, заявок, данных из различных систем интеграций дилеров и автопроизводителей. Отдельно собирается обработанная телеметрическая информация, а также настройки и другие данные, необходимые для обеспечения работоспособности сервисов Remoto и наших устройств. Холодные данные телеметрии мы собираем отдельно с использованием баз, предназначенных для хранения огромных объемов информации. В стороне построены отдельных хранилища данных, обеспечивающих возможность функционирования систем Remoto AI. С помощью так называемых crawler’ов собирается вся необходимая статистическая информация, на ее основе искуственный интеллект осуществляет выборку пользовательских групп и строит «предсказания».
Сбор данных с устройств осуществляется с использованием IoT решения от Microsoft. Устройства подключаются к платформе, платформа собирает всю телеметрию и складывает ее в промежуточное временное хранилище данных event hub. К event hub’ам уже подключаются наши worker’ы, обрабатывают телеметрию, записывают холодые данные и обработанные данные, такие как маршруты и дорожные события, выполняют команды. Отдельный сервис умеет запрашивать у устройства диагностические данные, анализировать состояние автомобиля и строить пользовательские отчеты.
Для пользовательских мобильных приложений реализовано API, с помощью которого пользователь получает доступ к обработанной телеметрии, а также возможность выполнения команд для устройства, установленного в автомобиле. Это же API используется для получения доступа к данным сервиса customer retention, пользователь в свое мобильное приложение получает новости, специальные предложения дилеров и автопроизводителей, имеет возможность воспользоваться сервисами, например, заполнить заявку на тест-драйв или кредит. Через мобильное приложение пользователь может выставить настройки для устройства, активировать телематические сервисы, такие как пуш об ударе, превышении скорости или выезда из зоны, а также настроить автоматический запуск двигателя по расписанию или температуре.
Диллеры в свою очередь с помощью предоставляемых порталов имеют возможность запустить диагностику на устройстве пользователя, заблокировать удаленный запуск двигателя, например, для проведения технических работ или сервисного обслуживания, сформировать специальное персональное предложение, а также обрабатывать заявки пользователей. Коммуникация с пользователем в таких случаях чаще всего осуществляется с использованием push-уведомлений.
Также у диллера есть возможность кастомизации мобильного приложения, дилер или автопроизводитель может выкрасить приложение в цвета своего брэнда, поменять ключевые иконки, определить набор доступных в приложении функций и некоторые другие косметические функции, для этого создан отдельный портал.
Для осуществления поддержки клиентов имеется технический портал, в котором можно провалидировать текущие настройки пользователей и их устройств, диагностировать работоспособность устройства, в случае необходимости данные можно скорректировать по запросу клиента, например, если пользователь при конфигурации выбрал другую модель автомобиля, специалист поддержки может это исправить. Также портал предоставляет возможность FOTA (firmware over the air) обновления прошивки устройства или группы устройств в случае выхода новой версии прошивки с новыми функциями или исправлениями дефектов.
Комментарий от Артема Нероба, CISO:
Cегодня команда безопасности компании находится в активном диалоге с бизнесом.
Мы стремимся соответствовать требованиям законодательства: закону о персональных данных и GDPR. Важно как никогда налаживание процесса цикла безопасной разработки, т.е. добавление в текущие процедуры разработки некоторых контрольных точек в виде проверки кода до выпуска приложения, дополнительного стороннего анализа кода, повышение осведомленности разработчиков в плане того, как писать безопасный код изначально. Мировые практики и стандарты крайне рекомендуют озаботиться безопасностью во время разработки, а не после нее. Потому что после релиза стоимость исправления уязвимости на 30% выше. У нас периодически происходят проверки безопасности продукта клиентами, т.е. penetration tests. С учетом усиления информационной безопасности эти тесты мы сейчас проходим достаточно успешно, и в продукте от релиза к релизу нет ни одной уязвимости с Critical или High рисками.
Сегодня у нас есть команда для проведения penetration tests, и мы ее рассматриваем как команду, которая будет помогать нам в процессе разработки делать некий обзор безопасности кода для учета в последующих релизах. Это будут не полноценные penetration тесты, а просто ревью, которое будет встроено в наш бизнес-процесс по разработке, что крайне правильно с точки зрения безопасного цикла разработки кода.
Кроме того, мы подтвердили сертификат ISO 27001, стандарт менеджмента информационной безопасности согласно аудиту со стороны BSI.
Здесь, в Bright Box, мы постоянно ищем пути для развития Connected Car платформы Remoto.
И наши технологии уже помогли производителям, региональным офисам, импортерам и крупным дилерским сетям не только увеличить доход, но и существенно улучшить удержание клиентов и, что самое важное, снизить эксплуатационные расходы. За последние два года, нашими клиентами стали такие компании, как Honda, Motor Car, MINI. В конце 2017 года сама компания стала частью страховой группы Zurich.
Сотрудники компании шутят, что Bright Box работает в «атмосфере травли и завистничества». Конечно, это не так. Но поводы для зависти у тех, кто не работает с нами в команде, точно есть:
Гибкий соцпакет: каждый сотрудник сам в праве выбирать на что потратить выделенный на это бюджет в размере своего оклада, но не превышающий средний оклад в компании.
Здесь мы предоставляем широкие возможности выбора по типу «кафетерия»:
Стоит отметить, что сотрудники компании могут использовать социальный пакет и для членов своей семьи, будь то медицина, фитнес или отпуск.
Гибкий график начала рабочего дня и удалённые дни работы?
Кажется, что многие компании предоставляют гибкий график работы, но это далеко не так.
Мы не ограничиваем наших инженеров и разработчиков выделенным количеством дней удаленной работы в год, а предоставляем каждую неделю по вторникам и четвергам возможность работать удаленно. Нам знакомо понятие work-life баланс и мы не будем препятствовать забрать ребёнка из детского сада или посетить 1-е сентября в школе, как и не будем мешать посещениям выставок и прочих мероприятий. Сотрудники могут завершить срочные задачи из дома.
Командировки по всему миру и работа в офисах компании в Дубае, Будапеште, Цюрихе, Нью-Йорке по желанию.
Проекты запускаются довольно часто и наши инженеры и разработчики ездят в командировки по всему земному шару. А если занимаемая должность не предполагает командировок, то можно попросить своего менеджера об удаленной работе в одном из офисов компании.
Многие мечтают холодное время года провести в тёплом климате – к вашим услугам возможность уехать в Дубаи и работать из дубайского офиса удаленно.
Хотите в Европе пожить? Не вопрос, согласовывайте удаленную работу из офиса Будапешта.
Релокация в Будапешт
Для желающих работать в Европе или по зову службы мы находим место в нашем офисе в Будапеште, помогаем с оформлением документов для сотрудников и семьи, переездом и поиском жилья. Это достаточно длительный процесс, который занимает в среднем 3 месяца. Так что наберитесь терпения.
Бонусы
Сотрудники компании делятся на три типа, исходя из их задач. У каждого из них своя бонусная система:
Создатели – те, кто создают продукт. У Создателей достойный уровень зарплаты по рынку ИТ, поэтому в их случае бонусы могут быть за «сверх» результат. А определяет это непосредственный руководитель, который тесно взаимодействует с каждым из сотрудников и может оценить проделанную работу.
Викинги – те, кто завоёвывают новые территории и приносят прибыль компании. Есть Викинги, которые занимаются внедрением продукта – они участвуют в бонусном пуле, который определяется для каждого проекта индивидуально, в зависимости от сложности. Есть Викинги, которые занимаются продажами – они получают бонусы в размере 1-2% от стоимости реализованного проекта.
Фермеры – те, кто обслуживают Создателей и Викингов. У них бонусы составляют максимум до 1-го оклада в квартал, а итоговая сумма расчитывается исходя из личных достижений и командных целей.
Так что если вы всегда хотели быть викингом, но со временем и страной не сложилось – может стоит попробовать им стать в рамках нашей компании.
Будущим родителям
По случаю рождения ребенка у сотрудника – компания предоставляет приятный бонус в виде подарка детской коляски или же в виде выплаты денежной суммы.
А если вы готовы выйти из декрета, раньше положенного, то смело можете рассчитывать на бонусную доплату к своей заработной плате, которая установлена политикой компании.
Bright Box находится в поиске талантов. Если вам показалось близким то, что вы прочитали, и вы любите машины и искусственный интеллект, приходите.
Подписаться на регулярные новости, статьи и аналитику из мира Connected Cars вы можете здесь. Также есть официальный блог Driving to the future на Medium.
Флагманский продукт Bright Box — Remoto — технологически сложная, насыщенная функциональностью платформа для Connected Car, в которую входит оборудование, софт для дилеров и автопроизводителей плюс мобильное приложение для пользователя. По первичной аналитике Bright Box среди автовладельцев выяснилось, что в первую очередь им требуется удаленное управление блокировкой дверей, климат-контроль и поиск автомобиля с оповещениями об ударах или эвакуации. Последнее – уже классика. Сейчас блок Remoto обеспечивает пользователя следующими услугами: дистанционное управление функциями автомобиля, возможность получения данных от аппаратных средств и CAN, GPRS, SMS, Bluetooth и контроль выходной мощности на электронный блок зажигания. Пользователь получает эту информацию в мобильное приложение.
И таким пользователем может быть не только владелец машины. Доступная к сбору информация может стать полезным подспорьем для многих участников авторынка. Например, каршеринг. Сегодня каршеринговые компании являются самыми активными игроками на автомобильном рынке. Москва стала городом номер один по общему количеству автомобилей, задействованных в каршеринге. К 2020 году каршеринг должен достичь отметки в 40 тысяч автомобилей в России. Каршеринг-компании становятся владельцами следующих данных: пробег, GPS-координаты, скорость, состояние дверей и уровень топлива. Ключом ко всему этому является смартфон, который является более дешевым и более безопасным вариантом.
Андрей Куприков, сооснователь и директор по развитию бизнеса YouDrive и один из клиентов Bright Box:
“Каршеринг без телематического решения трудно себе представить. Наша платформа обязана собирать всю возможную информацию об автомобиле, что и как с ним происходит. Иначе это отразится на бизнесе. Именно телематика дает информацию о стоимости ремонта и запчастях, стоимости простоя автомобиля, который находится в ремонте по вине любителя скорости. При наличии на борту телематического устройства можно выстраивать уникальную программу лояльности пользователя.”
С начала этого года Remoto стали поставщиком решений для двух крупных компаний по совместному использованию автомобилей, YouDrive и EasyRide, с 1000 автомобилей в своем автопарке. Использование решения в каршеринге не только удобно, но и эффективно с позиции безопасности и финансовой стороны — в виде снижения риска ДТП и в программе лояльности. С развитием каршеринга накапливаются данные о пользователях, и вот уже у каршеринга, как у банков, появляется некая система скоринга клиентов. О логике работы алгоритмов скоринга пользователей каршеринга мы писали дважды, разбирая сначала алгоритм скоринга, основанный на резких ускорениях и торможениях, а затем алгоритмы анализа стиля вождения, основанные на значениях скорости, оборотов двигателя и показателях акселерометра.
Но мы активно работаем не только на российском рынке, а это – дополнительный вызов. С расширением географии работы стало ясно, что правильная и эффективная перестройка инжиниринговой вертикали – ключевой момент развития.
Рассказывают Виталий Баум, Chief Product Officer
и Вячеслав Соколов, Chief Engineering Officer:
Наша система состоит из набора компонентов. В инжиниринге за них отвечают выделенные команды. Фактически деятельность Engineering включает в себя 3 бизнес-процесса и набор поддерживающих сервисов.
Внутри Engineering подразделения можно выделить следующие бизнес-процессы:
- Разработка телематического устройства со встраиваемым ПО для интеграции с авто. Занимается департамент HW engineering.
- Процесс производства устройств под конкретного клиента по заказу бизнес-подразделения. Отвечает департамент Manufacturing,
- Разработка Remoto Cloud Services, отвечающих за взаимодействие клиента, пользователя и телематического устройства. Представляет собой множество бэкенд сервисов с набором порталов для различных пользователей, клиентские мобильные приложения, Data lake. Постановкой занимается Product management департамент. Разработкой всей софтовой части – департамент Product Development, релизами и поддержкой – операционная команда RCS.
Стоит отметить, что задача по определению функциональных требований к той или иной фиче лежит на департаменте Product Management, в который помимо продуктологов входят также аналитики и дизайнеры. Далее требования поступают в Product development департамент, перед которым стоит сложная задача по декомпозии фичей по компонентам системы, включая встроенное ПО устройства. Эту задачу решает Архитектор департамента Product Development вместе с командой системных аналитиков.
Как выглядит планирование продукта? С недавнего времени product management стал частью инжиниринговой команды. И такая оргструктура нашла отражение в том, как мы начали работать. PM-команда определяет, какой продукт должен быть в целом, какие у него должны быть функции безотносительно компонентов системы. Получается бриф – поверхностное описание того, что надо сделать в задаче. После этого готовятся функциональные спецификации, которые мы называем FSD, или набор job stories — например, возможность в продукте отправить заявку «записаться на ТО». Каждая фича у нас описана набором подобных job stories.
PM-ы также занимаются техническим дизайном. Они выполняют технический анализ функциональной спецификации и создают технический дизайн – TDD (Technical Design Document), обсуждают этот технический дизайн с разработчиками, приземляют его под их понимание. После того, как написаны функциональные требования и технический дизайн, мы начинаем работать над интерфейсом – это user experience интерфейс.
Таким образом, продуктологи формируют определенный набор «единиц» полезности для клиента (“записатьcя на ТО” может быть такой единицей полезности) и передают специалисту, описывающему логику в этом наборе. Полезность в заявке на ТО означает, что клиент может заполнить форму с нужной информацией, совпадающую с тем, что ожидают дилеры при подаче заявки на ТО. Продуктолог также анализирует рынок, изучает, что должно быть в продукте и какую это дает ценность клиентам.
Наши продуктологи сегодня больше общаются с бизнесом внутри компании либо с клиентами напрямую. Формированием roadmap занимается roadmap комитет, в который входят ТОП менеджеры компании, чтобы учесть все направления развития компании. Комитет собирается раз в квартал.
Это делается для того, чтобы координировать общие договоренности и обеспечивать целостность продукта, чтобы фичи плавно ложились в текущее видение продукта.
Есть отдельный сервис – cyber security, который взаимодействует с людьми, работающими с устройствами и специалистами из отдела бэкенда с целью выявления уязвимостей, их закрытия и оценке рисков, к чему эти риски могут привести. Сегодня этому подразделению задачи ставит Chief Engineering Officer, который возглавляет также продуктовую команду, а та в свою очередь общается с клиентом и понимает, что сейчас нужно для того, чтобы соответствовать всем нормам cyber security. Всё это включается в план релизов, закрываются уязвимости, получаются сертификаты и в целом устраняется gap в плане безопасности.
После того, как функциональность отработана инжинирингом и оценена отделом безопасности, ее спецификация поступает к product development team, где рабочая группа декомпозирует функции по компонентам системы – что относится к backend, что к устройству, что должно уметь мобильное приложение. Product development team и HW engineering team договариваются по взаимодействию, всё сводится в совместный план и расходится по командам.
Как мы деплоим
В конце разработки собранный результат проходит интеграционное тестирование и выкатка в релиз на облачную платформу. На облачной платформе, где мы хостимся (Azure), размещены окружения для клиентов. За окружения отвечает операционная команда, в которой работают инженеры, DevOps-ы и поддержка.
Комментарий от Владимира Глазкова, Senior DevOps Engineer:
Вся наша инфраструктура описана в виде кода. Все изменения мы делаем только через код. Данный подход позволяет снизить риск человеческого фактора при обновлениях. Также это позволяет быстро развернуть дополнительный экземпляр окружения для неких временных срочных нужд. В случае отказа вычислительных мощностей (VM/VMSS), можно быстро развернуть новый инстанс.
О CI/CD – на данный момент мы используем связку TeamCity/Octopus Deploy. В TeamCity идет процесс сборки .net проектов, запускаются Unit-тесты, после чего создается релиз в Octopus и деплоится в соответствующие таргеты (VM / VMSS / K8S). После удачного деплоя запускаются acceptance-тесты. Если какой-то из тестов упал, команда разработки получит уведомление.
Изначально под каждый бизнес-проект создавались отдельные наборы ресурсов, в том числе инструменты CI/CD. Достаточно быстро пришло осознание, что при росте количества проектов данный подход обречен на провал – администрировать такой зоопарк эффективно просто невозможно. Два года назад был запущен проект унификации, который завершился 4 месяца спустя. В его процессе были выделены core-компоненты системы, для них процесс сборки и деплоя един для всех окружений. Также была описана и внедрена возможность добавления сборки/деплоя дополнительных компонентов специфичных для конкретного бизнес-проекта. При создании новых окружений отныне не требуются отдельные экземпляры TeamCity & Octopus. Были написаны скрипты, которые через API создают и конфигурируют все необходимые для сборки и деплоя вещи.
Мы пришли к следующему использованию окружений: для разработки каждая команда использует два окружения:
- первое для, собственно, разработки нового функционала, проверки фич автором и т.п.;
- второе для стабилизации.
Таких наборов окружений может быть много, обслуживать их достаточно просто в виду проведенной унификации.
Также имеется окружение для приемки релиза командой, отвечающей за боевое окружение. На нем проходит финальное тестирование перед деплоем в продакшн.
Мы имеем договоренность с разработчиками насчет устройства трансформаций конфигурационных файлов. В каждом проекте существует файл, который содержит набор параметров, имеющих разное значение на разных окружениях. Разработчики заполняют файл необходимыми параметрами (строками подключения к БД, ключами подключений и т.п.), значениями этих параметров являются переменные. Для каждой среды значения этих переменных индивидуальны. При таком подходе разработчикам ничего не мешает собирать локально и проверять у себя. Переменные хранятся в Octopus Deploy.
Для мониторинга мы используем Azure Monitor, Application Insights и Log Analytics. Доживает свое время Zabbix, вероятно, в будущем ему будет отведена почетная роль внешних проверок.
Когда я присоединился к компании, создание нового окружения занимало три недели. Инструкций почти не было, изменения делались вручную и нигде не фиксировались. Наш путь к IaaC начался с простой автоматизации, которая позволила сократить процесс до 1 недели. Сейчас создание нового окружения занимает 4 часа. Автоматизировано около 95% действий.
Наш бекенд написан на .net (4.6/4.7 и core), фронт – JS. Для хостинга используем Virtual Machine Scale Sets и K8S. Соответсвенно, масштабироваться под изменение нагрузки очень легко.
Как устроена система внутри
Рассказывает Иван Столет, Head of Platform Development Bright Box:
Вы всегда можете найти схему текущей архитектуры на сайте.
Все данные в системе хранятся распределенно. Существуют отдельные базы по хранению персональных данных с привязкой к региону и организованные в соответствии с местным законодательством. Есть базы данных, в которых аккамулируется контентная часть сервисов customer retention, хранение новостей, заявок, данных из различных систем интеграций дилеров и автопроизводителей. Отдельно собирается обработанная телеметрическая информация, а также настройки и другие данные, необходимые для обеспечения работоспособности сервисов Remoto и наших устройств. Холодные данные телеметрии мы собираем отдельно с использованием баз, предназначенных для хранения огромных объемов информации. В стороне построены отдельных хранилища данных, обеспечивающих возможность функционирования систем Remoto AI. С помощью так называемых crawler’ов собирается вся необходимая статистическая информация, на ее основе искуственный интеллект осуществляет выборку пользовательских групп и строит «предсказания».
Сбор данных с устройств осуществляется с использованием IoT решения от Microsoft. Устройства подключаются к платформе, платформа собирает всю телеметрию и складывает ее в промежуточное временное хранилище данных event hub. К event hub’ам уже подключаются наши worker’ы, обрабатывают телеметрию, записывают холодые данные и обработанные данные, такие как маршруты и дорожные события, выполняют команды. Отдельный сервис умеет запрашивать у устройства диагностические данные, анализировать состояние автомобиля и строить пользовательские отчеты.
Для пользовательских мобильных приложений реализовано API, с помощью которого пользователь получает доступ к обработанной телеметрии, а также возможность выполнения команд для устройства, установленного в автомобиле. Это же API используется для получения доступа к данным сервиса customer retention, пользователь в свое мобильное приложение получает новости, специальные предложения дилеров и автопроизводителей, имеет возможность воспользоваться сервисами, например, заполнить заявку на тест-драйв или кредит. Через мобильное приложение пользователь может выставить настройки для устройства, активировать телематические сервисы, такие как пуш об ударе, превышении скорости или выезда из зоны, а также настроить автоматический запуск двигателя по расписанию или температуре.
Диллеры в свою очередь с помощью предоставляемых порталов имеют возможность запустить диагностику на устройстве пользователя, заблокировать удаленный запуск двигателя, например, для проведения технических работ или сервисного обслуживания, сформировать специальное персональное предложение, а также обрабатывать заявки пользователей. Коммуникация с пользователем в таких случаях чаще всего осуществляется с использованием push-уведомлений.
Также у диллера есть возможность кастомизации мобильного приложения, дилер или автопроизводитель может выкрасить приложение в цвета своего брэнда, поменять ключевые иконки, определить набор доступных в приложении функций и некоторые другие косметические функции, для этого создан отдельный портал.
Для осуществления поддержки клиентов имеется технический портал, в котором можно провалидировать текущие настройки пользователей и их устройств, диагностировать работоспособность устройства, в случае необходимости данные можно скорректировать по запросу клиента, например, если пользователь при конфигурации выбрал другую модель автомобиля, специалист поддержки может это исправить. Также портал предоставляет возможность FOTA (firmware over the air) обновления прошивки устройства или группы устройств в случае выхода новой версии прошивки с новыми функциями или исправлениями дефектов.
И несколько слов про безопасность
Комментарий от Артема Нероба, CISO:
Cегодня команда безопасности компании находится в активном диалоге с бизнесом.
Мы стремимся соответствовать требованиям законодательства: закону о персональных данных и GDPR. Важно как никогда налаживание процесса цикла безопасной разработки, т.е. добавление в текущие процедуры разработки некоторых контрольных точек в виде проверки кода до выпуска приложения, дополнительного стороннего анализа кода, повышение осведомленности разработчиков в плане того, как писать безопасный код изначально. Мировые практики и стандарты крайне рекомендуют озаботиться безопасностью во время разработки, а не после нее. Потому что после релиза стоимость исправления уязвимости на 30% выше. У нас периодически происходят проверки безопасности продукта клиентами, т.е. penetration tests. С учетом усиления информационной безопасности эти тесты мы сейчас проходим достаточно успешно, и в продукте от релиза к релизу нет ни одной уязвимости с Critical или High рисками.
Сегодня у нас есть команда для проведения penetration tests, и мы ее рассматриваем как команду, которая будет помогать нам в процессе разработки делать некий обзор безопасности кода для учета в последующих релизах. Это будут не полноценные penetration тесты, а просто ревью, которое будет встроено в наш бизнес-процесс по разработке, что крайне правильно с точки зрения безопасного цикла разработки кода.
Кроме того, мы подтвердили сертификат ISO 27001, стандарт менеджмента информационной безопасности согласно аудиту со стороны BSI.
Как мы живём и что дальше?
Здесь, в Bright Box, мы постоянно ищем пути для развития Connected Car платформы Remoto.
И наши технологии уже помогли производителям, региональным офисам, импортерам и крупным дилерским сетям не только увеличить доход, но и существенно улучшить удержание клиентов и, что самое важное, снизить эксплуатационные расходы. За последние два года, нашими клиентами стали такие компании, как Honda, Motor Car, MINI. В конце 2017 года сама компания стала частью страховой группы Zurich.
Сотрудники компании шутят, что Bright Box работает в «атмосфере травли и завистничества». Конечно, это не так. Но поводы для зависти у тех, кто не работает с нами в команде, точно есть:
Гибкий соцпакет: каждый сотрудник сам в праве выбирать на что потратить выделенный на это бюджет в размере своего оклада, но не превышающий средний оклад в компании.
Здесь мы предоставляем широкие возможности выбора по типу «кафетерия»:
- ДМС (любые медицинские расходы от разовых посещений врачей до лекарств и медицинских препаратов), страхование жизни, стоматология (включая имплантологию);
- Любые занятия спортом (от скалолазания до йоги);
- ОСАГО/КАСКО, парковка на территории бизнес парка;
- Изучение любых иностранных языков;
- Софинансирование личных путешествий (визы/туры/билеты/гостиницы);
- Детский сад.
Стоит отметить, что сотрудники компании могут использовать социальный пакет и для членов своей семьи, будь то медицина, фитнес или отпуск.
Гибкий график начала рабочего дня и удалённые дни работы?
Кажется, что многие компании предоставляют гибкий график работы, но это далеко не так.
Мы не ограничиваем наших инженеров и разработчиков выделенным количеством дней удаленной работы в год, а предоставляем каждую неделю по вторникам и четвергам возможность работать удаленно. Нам знакомо понятие work-life баланс и мы не будем препятствовать забрать ребёнка из детского сада или посетить 1-е сентября в школе, как и не будем мешать посещениям выставок и прочих мероприятий. Сотрудники могут завершить срочные задачи из дома.
Командировки по всему миру и работа в офисах компании в Дубае, Будапеште, Цюрихе, Нью-Йорке по желанию.
Проекты запускаются довольно часто и наши инженеры и разработчики ездят в командировки по всему земному шару. А если занимаемая должность не предполагает командировок, то можно попросить своего менеджера об удаленной работе в одном из офисов компании.
Многие мечтают холодное время года провести в тёплом климате – к вашим услугам возможность уехать в Дубаи и работать из дубайского офиса удаленно.
Хотите в Европе пожить? Не вопрос, согласовывайте удаленную работу из офиса Будапешта.
Релокация в Будапешт
Для желающих работать в Европе или по зову службы мы находим место в нашем офисе в Будапеште, помогаем с оформлением документов для сотрудников и семьи, переездом и поиском жилья. Это достаточно длительный процесс, который занимает в среднем 3 месяца. Так что наберитесь терпения.
Бонусы
Сотрудники компании делятся на три типа, исходя из их задач. У каждого из них своя бонусная система:
Создатели – те, кто создают продукт. У Создателей достойный уровень зарплаты по рынку ИТ, поэтому в их случае бонусы могут быть за «сверх» результат. А определяет это непосредственный руководитель, который тесно взаимодействует с каждым из сотрудников и может оценить проделанную работу.
Викинги – те, кто завоёвывают новые территории и приносят прибыль компании. Есть Викинги, которые занимаются внедрением продукта – они участвуют в бонусном пуле, который определяется для каждого проекта индивидуально, в зависимости от сложности. Есть Викинги, которые занимаются продажами – они получают бонусы в размере 1-2% от стоимости реализованного проекта.
Фермеры – те, кто обслуживают Создателей и Викингов. У них бонусы составляют максимум до 1-го оклада в квартал, а итоговая сумма расчитывается исходя из личных достижений и командных целей.
Так что если вы всегда хотели быть викингом, но со временем и страной не сложилось – может стоит попробовать им стать в рамках нашей компании.
Будущим родителям
По случаю рождения ребенка у сотрудника – компания предоставляет приятный бонус в виде подарка детской коляски или же в виде выплаты денежной суммы.
А если вы готовы выйти из декрета, раньше положенного, то смело можете рассчитывать на бонусную доплату к своей заработной плате, которая установлена политикой компании.
Bright Box находится в поиске талантов. Если вам показалось близким то, что вы прочитали, и вы любите машины и искусственный интеллект, приходите.
Подписаться на регулярные новости, статьи и аналитику из мира Connected Cars вы можете здесь. Также есть официальный блог Driving to the future на Medium.