Привет, я Владислав Алмазов, директор по сопровождению информационных технологий (IT Operations) в Lamoda. Одно из направлений, за которое я отвечаю uptime. Это количественный показатель непрерывной работы нашей платформы.

Дать возможность клиенту найти товар в каталоге, положить его в корзину, выбрать способ доставки, рассчитать скидки и оплатить все это значит оформить заказ. Одноименная кнопка доступна на сайте 99,95% времени в году. Оставшиеся 0,05% это 4 часа в год, которые клиенты не замечают. Эта метрика отражает основное бизнес-требование к непрерывности самых критичных IT-систем. Час простоя для Lamoda это потери десятков миллионов рублей.

По итогам прошлого года мы превысили план и наш uptime составил 99,96%. Дальше я расскажу, за счет чего это удалось.

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

Еще три направления занимаются инфраструктурой:

• информационная безопасность (ИБ) отвечает за техническое обеспечение информационной безопасности, ее аудит и контроль;
• телекоммуникации и датацентр обеспечивают бесперебойную работу всего железа и телекоммуникаций, в том числе телефонии и корпоративной сети в датацентрах, офисах и контакт-центрах;
• DevOps отвечает за инфраструктуру прода и QA, непрерывную доставку кода на прод и бесперебойную работу этого самого прода.

Рецепт uptime

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

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

Обычно дежурят команда Devops, сетевики, безопасники, а также разработчики, так как часто для решения инцидента необходим hotfix. Мы умеем делать hotfix за считаные минуты и выкатывать его на прод, соблюдая все необходимые процедуры и сохраняя возможность сделать rollback. Это помогает нам сохранять высокие показатели uptime.

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

У Devops две команды дежурных: одна отвечает за uptime всех платформ онлайн-магазина, которые работают на Linux, а вторая занимается Windows-платформами, например, Active Directory. Дежурные ИБ (SecOps), отвечают за сегментацию сети и инциденты информационной безопасности, а также за управление доступами (IAM). Дежурные сетевые инженеры за сеть в ЦОД и распределенные сети. Дежурные разработчики отвечают за наборы микросервисов, в которых они обладают техническим лидерством.

Мы соблюдаем стандарты информационной безопасности NIST-800 и PCI DSS. Основные компоненты платформы изолированы друг от друга: нет открытой связности между 170 микросервисами онлайн-магазина, а также между другими системами, например ERP и платформой данных и аналитики. Следование таким стандартам позволяет нам снижать риски влияния угроз ИБ на наш uptime.

Команда информационной безопасности отвечает в том числе за сегментацию сети. Наш периметр защищен от DDoS и направленных атак. Ежегодно мы проводим тесты на проникновение, а также работаем с программой Bug Bounty, которая в этом году официально станет публичной на данный момент исследователи (белые хакеры, которые взламывают системы по заказу самой компании) работают по приглашению.

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

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

Вообще, мы очень любим темное волокно это относительно недорого и надежно. Например, у нас два канала волокна по 10 gbps до центрального офиса, фотостудии, сервиса защиты от DDoS, распределительного центра и других объектов. Также у нас есть своя автономная система (AS) и два блока провайдеронезависимых адресов, что позволяет подключаться к интернету у разных провайдеров и иметь пиринг на площадке MSK-IX со скоростью 10 gbps. Тут у нас стопроцентный uptime.

Что нужно, чтобы все работало

Достигать высоких показателей нам помогает резервирование сетевого оборудования: кластер ядра сети, кластеры фаерволов, по два top-of-rack коммутатора, четыре пограничных маршрутизатора. Также у нас есть протоколы отказоустойчивости, например, LACP и протоколы динамической маршрутизации EIGRP и BGP.

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

Система резервирования вычислительных ресурсов построена на гипервизорах, поэтому выход из строя одного сервера приводит к переводу всех виртуальных машин на другой. То же самое относится и к хранилищу данных, где мы используем CEPH.

На следующем уровне работы наших приложений, которые относятся к онлайн-магазину, все крутится в Docker и управляется Kubernetes, у которого высокий уровень отказоустойчивости. Тут могут быть лишь секундные потери, если ноды выйдут из строя. В качестве сетевого решения, а также для обеспечения сегментации микросервисов, мы используем Calico. У всех подов есть маршрутизируемые адреса, которые анонсируются по протоколу BGP (Border Gateway Protocol) в корпоративную сеть. Все микросервисы для обмена между собой работают по правилу deny-any-any, поэтому у нас тысячи строк yaml-конфигураций фаервольных правил, а каждый новый микросервис проходит строгую проверку ИБ.

Часто именно базы данных (DB) становятся точкой отказа и могут повлиять на uptime. Наша платформа построена так, что в определенный момент времени есть только одна Master DB, с которой работает конкретное приложение. Но также есть еще от одной до шести Slave DB, у которых есть полная копия Master, но они работают только на чтение. В результате помимо распределения нагрузки, у нас присутствует избыточность данных, в том числе в целях реализации плана непрерывности бизнеса (BCP/DRP).

Для автоматического переключения в случае отказа Master DB мы используем решение Patroni, которое все делает автоматически. Это позволяет снизить downtime до минимальных значений. Был случай, когда до внедрения системы резервирования, сервер, на котором крутилась одна из критических баз данных, вышел из строя. Это случилось в полночь и нам потребовалось всего 9 минут на решение этой проблемы. Три минуты ушли на реакцию инцидент-менеджера, системы мониторинга и подъем дежурного инженера DevOps. Шесть минут ушло на подключение к сети, оперативный анализ ситуации на основе уже имеющихся данных мониторинга и переключение на Master DB.

Не наступать второй раз на одни и те же грабли помогает глубокий post mortem анализ. Мы детально разбираем каждый случай: определяем масштаб проблемы, хронологию событий и системы, которые были вовлечены, затем проводим анализ действий и вводим превентивные меры.

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

4 часа тишины

И тут вы спросите меня, где же прячутся эти четыре часа в год вашего downtime? Примерно половина, то есть два часа это устранение проблем с багами в инфраструктурном софте и отказы железа. Тут, как правило, все решает перезагрузка и последующий анализ инцидента.

Еще четверть инцидентов или один час последствия bad release, когда некачественно протестированный код попадает в прод. У нас выстроен серьезный процесс разработки, который проходит code review, unit- и интеграционные тестирования в автоматическом и ручном режиме. Перед релизом мы отправляем все на препрод: софт полностью обкатывается на продуктовых данных и только потом попадает в прод. Релизов может быть несколько штук в день, и в таком потоке случаются неожиданные неприятности.

И еще один час downtime это человеческий фактор. Был случай, когда наш новый инженер по информационной безопасности, выполняя достаточно рутинную операцию, внес в конфигурацию файервола ядра некорректное правило фильтрации. Это привело к остановке всего трафика в датацентре. Благодаря системе оперативного мониторинга изменений, мы выяснили причину и пофиксили это за 25 минут, а инженер даже не понял, что по его вине произошел инцидент, так как он случился с задержкой во времени. После этого появилось правило 4eyes-review. То есть все подобные изменения катятся не в одни руки, а только двумя инженерами совместно, как и во многих других процессах.

Чтобы избежать downtime, все инфраструктурные изменения проводятся через так называемый RFC (Request for change). Этот набор правил касается выкатки на прод: чтобы внести изменения в инфраструктуре, инициатор описывает план действий, получает подтверждение другого инженера, и обозначает downtime в минутах. Для таких изменений мы выделяем определенное временное окно. Если нужно обновить софт на ядре и это приведет к downtime в 10 минут, то я согласую время с 4 до 6 утра. В это время происходит минимальное количество заказов, соответственно, импакт для бизнеса будет меньше.

RFC проводится несколько раз в неделю, чтобы минимизировать downtime. Тут у нас строгая дисциплинa: если все же downtime возможен, то он по факту он не должен оказаться выше, чем планировалось. Это учит грамотно оценивать уровень риска и не занижать его, даже если его вероятность 0,01%. От того, насколько мы уложились в прогноз, зависит и наш KPI.

---

Напоследок скажу, что работа над uptime это непрерывный процесс, требующий внимания, с учетом того, что любая онлайн-платформа растет и развивается очень быстро. В основном, управление инфраструктурой и рисками, кроме влияния на time-to-market, не зарабатывает деньги для бизнеса, но позволяет контролировать его расходы, снижая издержки и предотвращая резкие влияния серьезных инцидентов на финансовые показатели компании.

Технологический радар диаграмма, на которой можно увидеть IT технологии и инструменты, которые мы используем в Lamoda, разделенные по областям применения и статусам. В 2018 году мы выкладывали здесь на Хабре подробную статью с расшифровкой актуального на тот момент техрадара. Что изменилось за два года, и зачем мы продолжаем регулярно обновлять радар читайте в этой статье.



На самом деле, технологический радар не просто картинка, которую мы можем показать на конференции. Хотя мы используем его и так тоже он отлично подходит, чтобы составить быстрое впечатление об IT-составляющей нашей компании. В 2018 году мы были единственной компанией, которая использовала для представления такой инструмент визуализации а сейчас на каждой конференции мы с радостью замечаем по 2-3 новых радара у различных компаний. Что сказать это действительно очень наглядно и удобно!

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

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

Конкретный специалист просто не может знать всё, что уже применяется где-то в компании. Часто оказывается, что инструмент, нужный ему для решения задачи, уже внедрен другой командой. Тогда ему конечно лучше пойти за экспертизой к коллегам, чем самому придумывать велосипед. При таком размере IT-подразделения информация уже не распространяется достаточно хорошо сама по себе, по этой причине мы внедрили практики обмена знаниями. Техрадар одна из таких практик.

Я буду подробнее говорить про это дальше, но хочу подчеркнуть сразу: политика Архитектурного комитета направлена не на то, чтобы запрещать экспериментировать с новыми технологиями, а на то, чтобы эти эксперименты были более осознанными и управляемыми. Наши специалисты не оказываются зажаты в узкие рамки конкретных языков и инструментов на всё время работы в компании. Наоборот, благодаря понятному циклу внедрения новых (или хорошо забытых старых) технологий, если специалисту становится скучно с теми инструментами, с которыми он работает, мы практически всегда можем предложить ему принять участие в экспериментальном проекте. При этом ему не придётся полностью менять направление, и он сможет использовать накопленную экспертизу по той системе, над которой работал.

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

Пройдем последовательно по четырем секторам радара, соответствующим основным IT-направлениям: Языки, Управление данными, Платформы и Инфраструктура, Фреймворки и Инструменты.

Но сначала напомню, что означают четыре слоя (статуса принятия технологии) на нашем радаре:

• ADOPT технологии и инструменты, которые внедрены и активно используются;
• TRIAL технологии и инструменты, которые уже прошли этап тестирования и готовятся к тому, чтобы работать с продакшн (или даже уже работают там);
• ASSESS пробные инструменты, которые в данный момент оцениваются и пока не влияют на продакшн. С их участием реализуются только тестовые проекты;
• HOLD в этой категории у нас есть экспертиза, но упомянутые инструменты используются только при поддержке существующих систем новые проекты на них не запускаются.

Языки

Как видите, по сравнению с 2018 годом точек в этом секторе стало меньше. Прямо сейчас у нас нет никаких языков в статусе Assess или Trial. Почему так получилось? Для каждой задачи у нас уже есть язык, который нас устраивает. Конечно, мы следим за развитием области и знаем интересные и перспективные языки, которые не используются сейчас в Lamoda, например Rust, но по своим возможностям они являются по сути дублирующими для тех, на которых написаны наши системы. Собственно, одна из целей ведения радара как раз в том, чтобы внедрение новых технологий происходило осознанно и с четким пониманием, какие плюсы нам это принесёт а не просто потому, что язык модный и о нем все говорят.

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

Именно так у нас произошло с Go. Когда мы начали активно развивать микросервисную архитектуру, то поняли, что Go для решения многих задач подходит лучше, чем PHP, на котором мы привыкли писать. Да, потребовалось приложить некоторые усилия, чтобы всей командой перейти на него (подробнее мы писали об этом тут). Но в результате очень выросла скорость работы приложений, да и по другим параметрам язык оказался удобен. За два года его стало у нас гораздо больше, в частности он практически полностью вытеснил Python из веб-разработки (но, конечно, Python остался в Data Science и других местах, где необходимо работать с большими массивами данных в таких задачах он однозначно лидер).

На радаре 2018 года видно, что мы пробуем Kotlin, но в 2020 мы уверенно присваиваем ему статус Adopt. Больше двух лет назад мы решили перевести часть Android-разработки на Kotlin язык казался очень перспективным, а наше мобильное приложение только развивалось и мы могли позволить себе эксперимент. Сейчас мы однозначно рады, что приняли такое решение. Не только все наши приложения под Android написаны на этом языке, но также часть бэкенда пока что это эксперимент, но мы возлагаем на него большие надежды. Помимо других очевидных достоинств, Kotlin очень универсальный язык а это значит, что на нем можно писать разные части систем, и передача экспертизы между командами сильно упрощается. И находить новых специалистов на рынке тоже становится проще.

Также по сравнению с 2018 годом из Trial в Adopt переместился TypeScript.
Он сильно расширяет возможности JavaScript, а весь наш огромный сервис доставки написан на нём, работает отлично, и мы пока не планируем это менять.

Управление данными

Практически все базы данных у нас по-прежнему реализованы на PostgreSQL (также мы используем MongoDB, а вот MySQL окончательно перевели в статус Hold).

Но за прошедшие два года у нас появились и новые технологии. В настоящий момент мы пилотируем использование СУБД Greenplum для задач развития нашей платформы данных. В нашем арсенале есть Oracle и Vertica прекрасные базы, но мы ищем способы удешевить стоимость владения инфраструктурой, поэтому рассматриваем Opensource решения. Возможно, это будет не замена, а дополнение время покажет.

Мы решили заменить Tableau на Microsoft Power BI как средство создания BI дашбордов, и уже завершили эту миграцию. Мы посчитали, что хотим дать доступ к дашбордам всем желающим, и в Power BI это выходит дешевле, так как на просмотр отчетов покупать лицензии не нужно.

Также мы внедрили Oracle APEX в качестве создания Web интерфейсов для ведения ручных справочников в хранилище данных. Ранее для этого использовались XLS-файлы, загружаемые с сетевого диска. Oracle APEX позволил нам сделать удобный интерфейс для бизнес-пользователей, теперь они могут самостоятельно обновлять данные в удобном Web приложении.

На радаре изменений в этом месте нет, но стоит отметить еще более глубокое проникновение Apache Airflow в процессы создания платформы данных. Сейчас это основной оркестратор задач обработки данных, он пришел у нас на замену Luigi.

Интересно произошло с RabbitMQ в свое время мы внедрили его, но он не всем нас устраивал, и мы даже думали совсем от него отказаться. Но потом пришли новые специалисты в команду администрирования, и оказалось, что RabbitMQ хорош, мы просто не умели его готовить. После того, как мы перешли с FreeBSD на Linux, RabbitMQ уверенно находится в статусе Adopt.

Платформы и инфраструктура

Вот здесь большие изменения произошли. Когда мы первоначально выбирали инструменты для деплоя, то остановились на связке Nomad + Consul. У нас был большой кредит доверия к компании Hashicorp, которая их выпускает, и в целом решение нас устраивало пока не произошло несколько критических падений при апгрейдах оборудования. Устранение неполадок каждый раз требовало много времени и ресурсов, а компания понесла определенные убытки. Тогда мы перешли на ставший более популярным Kubernetes.
Возможно, новые версии Nomad работают более стабильно, но у нас после той истории, можно сказать, остался шрам так что нет желания проверять. Тем более, что Kubernetes в связке с Docker нас полностью устраивают.

Фреймворки и инструменты

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


Например, мы пробовали разные фреймфорки для JavaScript, но старались экспериментировать на некритичных для бизнеса задачах. А главное, мы помнили, что это эксперимент, и в итоге мы хотим выбрать минимальный набор подходящих нам инструментов. Такая политика привела к тому, что React, например, так и не стал использоваться на проде. Angular и другие фреймворки ушли в статус Hold, и в основном на фронтенде мы используем vue.js, который показал себя в этом соревновании лучше остальных.

Естественно, какие-то фреймворки уходят вместе с языками, для которых их использовали. Так например произошло у нас с Django, когда Go почти полностью вытеснил Python из веб-разработки.

Это нам подходит!

В заключении статьи 2018 года мы сказали в двух словах мы пишем на GO, PHP, Java, JavaScript, держим базы на PostgreSQL, а деплоим на Docker и Kubernetes.
Такое обобщение верно и сейчас единственное, в список основных языков однозначно ворвался Kotlin.

Получается, что выбранные нами два года назад основные инструменты и технологии оказались действительно подходящими под наши задачи и наш подход к разработке.

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

Конечно, на рынке будут появляться новые инструменты, которые подходят нам больше тех, что мы используем сейчас.
Мы рассчитываем, что в нашей системе естественного отбора технологий эти инструменты пройдут свой путь от Assess до Adopt и при необходимости заменят текущие.

Привет, Хабр! Меня зовут Евгений Сальников, я тимлид одной из команд доставки в компании Lamoda. В нашей команде используются сразу пять языков программирования: PHP, Go, Vue, Typescript, Java и Kotlin. Когда я впервые услышал об этом на собеседовании, подумал, что так работать невозможно все слишком разное. Но спустя год мое мнение кардинально изменилось, и я нашел много преимуществ в таком подходе.

В этой статье я расскажу:

• о нашем направлении и системах, обслуживающих доставку;
• как мы живем с таким разнообразием технологий;
• как планируем работу над разноплановыми задачами;
• как растим экспертизу в fullstack-команде и расширяем направление.

Почему fullstack?

Мы часто слышим про fullstack это устоявшееся понятие, даже избитое. Оно подразумевает, что один человек может пилить и бекенд, и фронтенд все в одном флаконе. Сейчас в нашем направлении уже четыре команды из 27 человек, пять языков и четыре системы.

1. DataMatrix это система для маркировки товаров. В нашей стране существует закон 487-ФЗ, по которому мы обязаны помечать ряд товаров QR-кодом. Маркировка содержит информацию о том, кто произвел этот товар, кто ввез в страну, когда он поступил в продажу. Это помогает понять, насколько легальная вещь лежит перед нами. Подробнее о DataMatrix рассказывали в отдельной статье.
2. Система Express стоит в каждом пункте выдачи заказов и во всех транзитных складах. Она целиком написана с нуля внутри Lamoda, поэтому там учтены все наши процессы и потребности. На текущий момент вся система доставки построена на Express.
3. Система XDC взаимодействует с внешними службами доставки с Почтой России, DPD и остальными.
4. Также в зоне ответственности нашего направления мобильное приложение для торговых представителей, у которых есть планшет или телефон с ПО нашей разработки.

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

Мой любимый пример Apache Camel. Это интеграционный фреймворк на Java, который, грубо говоря, перекладывает данные из одного места в другое. У нас в компании эта технология обеспечивает взаимодействие с внешними курьерскими службами: мы получаем данные о заказе из API, преобразовываем их и отправляем в курьерскую службу. Написать эту задачу на РНР возможно, но будет неоправданно, потому что Apache Camel и так уже создан для этих целей. Такой подход позволяет легче адаптировать новые службы и новые API, тратить меньше времени на преобразование запроса из Json в XML. В Lamoda это адаптированная технология: если одна команда научилась ее готовить, мы делимся знаниями с коллегами. Сейчас Apache Camel используется уже в четырех командах.

Распределение ролей, покер-планирование и рост экспертизы

Раньше мне казалось, что существует жесткое разделение по системам. Например, пять человек занимаются одной системой, еще пять занимаются другой и просто взаимодействуют друг с другом. У нас такого нет. Каждый инженер команды может дорабатывать любую систему.

Например, у нас есть задача сделать удобную форму возврата. Для контроля технической стороны этого проекта мы назначаем техлида, которым может стать любой инженер из команды. Уже заранее он понимает, что для поставленной цели придется затронуть две системы: Express и XDC.

На схеме видно, что у Express и XDC также есть техлиды. У Express их даже два это очень большая система. Таким образом, техлид проекта сообщает техлидам систем о необходимых доработках, составляет и декомпозирует задачи, следит за тем, чтобы работа шла консистентно.

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

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

Как я уже упоминал ранее, любой инженер может дорабатывать каждую из наших систем. Допустим, человек начинал работать только с одной из них чаще всего с Express, так как все наши системы и процессы так или иначе связаны с доставкой. Новичку мало понимать ее технически, требуется знать предметную область и разбираться в процессах, которые там происходят. Таким образом, человеку, который изучил одну систему, будет намного проще работать над задачками по доработке другой. Порог вхождения во что-то новое становится гораздо ниже.

Приведу несколько примеров нашего подхода к работе:

• Раньше я часто сталкивался с тем, что есть отдельная команда для бэкенда и API мобильного приложения, а другая команда дорабатывает само приложение. Это требует формализации всех процессов и задач. У нас же один и тот же человек в одном спринте дорабатывает бэкенд и API мобильного приложения, да и само мобильное приложение. И это не разные задачи, а один проект по общим изменениям. На мой взгляд, это позволяет двигаться быстрее.
• Следующий пример о том, как мы близки к инфраструктуре. В нашем направлении используется K8s и Atlassian. Все скрипты для разворачивания новых серверов или деплоя приложения также создаются внутри команды. Любой из наших инженеров может поправить скрипт деплоя или что-то написать на Ansible, чтобы развернуть новый сервер. Благодаря этому мы быстрее делаем доработки.
• В нашей команде есть сервисы, написанные на Go, но исключительно утилиты. Часто бывает так, что нам нужно запросить миллион Data matrix у внешнего API. В этом случае писать большие истории на РНР невыгодно, потому что для этих целей создан Go. Это бы усложнило ситуацию, если инженер совсем не знаком со сторонними API и с нашими процессами. Но наши ребята могут написать нужную утилиту на подходящем языке. Go адаптирован к нашей компании. У нас есть экспертиза в этом, мы можем пойти к соседним командам и уточнить у них все вопросы.

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

Мои итоги спустя год: как расширять fullstack-команду

Fullstack-программист стоит дороже, чем остальные. В HR-отделе на вас посмотрят с недоумением, когда вы попросите найти специалиста, который умеет Go, Java, Kotlin и отлично знает РНР.

Есть три способа увеличить команду:

1. Брать со стороны. Чтобы попасть в нашу команду, не нужно знать все пять языков. На старте большинство из нас были с ними не знакомы. Достаточно знать РНР и SQL и не бояться работы с остальными технологиями и языками. Мы на каждом интервью сразу же говорим о том, что у нас используется несколько языков.

Также у нас выстроен процесс онбординга он длится 3 месяца. Каждый новичок получает план из набора технических задач, которые в совокупности охватывают все наши системы и технологии. Например, сначала РНР-разработчик начинает знакомиться с системой Express, а потом может выбрать другие задачи, исходя из своих интересов: кому-то больше интересен Kotlin, кто-то уже имеет экспертизу на Go. Также происходит постепенное погружение и в процессы команды: дежурства, знакомство с системой мониторинга, выполнение саппорт-задач.

2. Растить внутри. Процесс, запущенный на онбординге, не заканчивается ровно через 3 месяца. Человек по-прежнему продолжает погружаться в наши процессы, а его технологическая экспертиза растет. Со временем он может занять роль техлида. Для этого инженер знакомится сначала с системой, потом с бизнес-требованиями к ней, а со временем понимает, что бизнес-требования слишком велики для одной задачи. В таком случае он может стать техлидом этого проекта или системы. Погружение в такую работу происходит только через практику.

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

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

3. Смена технологий. Это тоже отличный путь развития. Сначала я познакомился с РНР, и казалось, что на нем можно сделать абсолютно все. Но сейчас будет странно писать на РНР постоянно живущие воркеры. Для этого можно использовать другие языки. Или, например, когда я познакомился с Go, это казалось крутым, но чего-то не хватало, зная количество готовых библиотек для Java. Новые инструменты помогают лучше понять те, которыми уже владеешь.

За неполный год в мою команду добавилось еще 10 инженеров. Сейчас это уже целое направление. Но не все готовы работать в таком подходе: кому-то не зашёл фронтенд, кому-то не заходит разнообразие технологий. Это не значит, что ушедшие люди плохие инженеры. Мы работаем в огромной компании, поэтому возможен переход в другие команды внутри Lamoda. Бывают и обратные случаи, когда люди из других команд переходят в наше направление, и это тоже круто.

Новые языки и комплектность команды

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

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

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

Привет, Хабр! Меня зовут Влад Кошкин, я java-разработчик в Lamoda. С 25 по 28 ноября наша команда впервые примет участие в онлайн-конференции Joker 2020.

У Lamoda огромный и сложный склад: 40 000 м, миллионы товаров на полках, тысячи людей и все это мы автоматизируем на Java через WMS (Warehouse Management System).



На нашем стенде мы рассказываем о том, как подружили Kotlin с бэкендом, строим модульную архитектуру, позволяем разработчикам разрабатывать, избегая лишних встреч. А еще мы будем травить байки на стенде под катом расписание и игра-квест, где можно почувствовать себя частью команды.

Расписание активностей

Мы записали мини-доклады, чтобы вы могли посмотреть их на стенде в любое время, а не пытались попасть в определенный слот :)

Как мы подружили Kotlin и склад, а также другие технические потребности WMS Влад Кошкин, java-разработчик.

Поговорим о том, почему мы обратили внимание на Kotlin и как он прижился в бекенде. Узнаем, как сейчас решаются проблемы с балансировкой и обновлением клиентских устройств на складе. Я расскажу про планы на систему WMS на ближайший год.


Как мы строим модульную архитектуру без микросервисов Женя Рябышев, java-разработчик.

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

Без лишних встреч: как мы позволяем разработчикам разрабатывать Костя Карусев, тимлид команды Acinonyx.

Поговорим о том, почему мы не используем полноценный SCRUM, что такое feature-team и как эта концепция сосуществует с привычными командами. О том, как процессы помогают разработке двигаться предсказуемыми темпами, а разработчикам не перерабатывать по ночам и на выходных.

Мы будем на стенде три дня, приходите пообщаться с нами в перерывах конференции.

Байки со склада: Автоматизация

26 ноября 12:00 12:30

Будем говорить про автоматизацию склада: что мы ей доверяем, а что нет. Какие используем алгоритмы сборки и упаковки, какую логику в данных.

Байки со склада: Черная Пятница

27 ноября 18:00 18:30

Для e-commerce сегодня главный день в году Black Friday. В этот вечер будем травить байки о том, как мы обычно справляемся с пиковыми нагрузками.

Байки со склада: Внутренняя продуктовая разработка

28 ноября 12:00 12:30

Обсудим разницу между inhouse разработкой и софтом на продажу.

Квест: Расследуй самые сложные случаи на складе.

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



До встречи на Joker 2020!

Привет, Хабр! Меня зовут Даниил Зиненко и я руководитель направления разработки Online Shop в Lamoda. С 14 по 17 октября наша Go-команда будет на онлайн-конференции GolangLive со стендом, на который мы и хотим вас пригласить.

Ниже расписание мини-докладов от наших инженеров и игра-квест, где можно выиграть электросамокат Ninebot KickScooter MAX G30P.



Мы будем рады пообщаться с вами на профильные темы. Обсуждение каждого топика состоит из мини-доклада на 10-15 минут, после чего инженеры готовы открыто дискутировать и отвечать на вопросы.

Расписание активностей

14 октября (11:30)
17 октября (12:50)

Как написать 100 микросервисов и не сойти с ума, мини-доклад Даниила Зиненко, руководителя направления разработки Online Shop.

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

15 октября (14:30)
17 октября (14:40)

Зачем мы сделали собственный инструмент Gonkey для тестирования микросервисов, мини-доклад Кирилла Полякова, QA инженера.

Расскажу, почему мы решили сделать собственный инструмент и как он упростил нам задачу автоматизации тестирования.

14 октября (13:30)

Событийно-ориентированная архитектура систем в Lamoda, интервью с Алексеем Скоробогатым, системным архитектором.

Парадигменный сдвиг при моделировании событий и взаимодействий между сервисами. Согласованность состояний отдельных сервисов, которые работают как одно целое.

14 октября (14:20)
17 октября (13:50)

Как мы учим PHP/Python разработчиков писать на Go, мини-доклад Михаила Мохначева, тимлида команды разработки.

Как написание собственного сервиса с нуля помогает новичку разобраться за две недели в языке и экосистеме. Поэтапно рассмотрим наш технический онбординг.

Квест Напиши свой микросервис

А сможешь ли ты написать свой микросервис в Lamoda? За 5 минут телеграм-бот проведет вас по таким этапам создания микросервиса как архитектурный комитет, тестирование, настройка деплоя и другие. А вот, насколько хорошим получится результат, зависит только от ваших решений. Главное, не воспринимать игру слишком серьезно.

• Все участники получат в подарок защитную маску.
• Самые креативные названия микросервисов отметим брендированными фляжками Code Mode.
• Святой рандом поможет выбрать из всех участников счастливого владельца электросамоката. Победителя определим в последний день конференции.

До встречи на GolangLive 2020!

Привет! Меня зовут Михаил Мохначев, я тимлид команды Core в Lamoda.

Наша команда занимается обеспечением работы сайта и системы приема заказов, что бы ни случилось. Мы очень активно используем язык Go 95% трафика идет через сервисы, которые написаны на нем. Но также есть сервисы на РНР и Python.

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

Найти кандидата, чьи навыки идеально подходили бы под наш запрос, очень сложно. Go-разработчиков в принципе мало на рынке, а Go-разработчиков, хорошо знающих к тому же PHP/Python, еще меньше. Поэтому мы решили подойти к этой задаче по-другому: мы нанимаем РНР или Python-разработчиков, и сами учим их писать сервисы на Go по рецепту Lamoda.

Технический онбординг: структура

Для новых членов нашей команды, независимо от уровня их профессиональных навыков, мы обязательно проводим технический онбординг. Дело в том, что сам язык Go достаточно простой, но инфраструктура вокруг него не очень проработана. В разных компаниях, где его используют, могут сильно отличаться методологии. И во время технического онбординга человек знакомится с тем, как мы пишем на Go именно в нашей компании.

Технический онбординг по Go в Lamoda:

1. Представляет из себя статью-путеводитель в Confluence.
2. Состоит из нескольких этапов.
3. Рассчитан на прохождение за 2 недели.

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

Этап 1: предварительный

Время прохождения этапа: 1 день.

Заведение задачи онбординга, в которой сотрудник логирует время и учится работать с нашим таск-трекером.

Настройка окружения на новом рабочем ноутбуке сотрудника.

Проверка доступов ко всем системам, которые потребуются в будущем для разработки новых сервисов.

Этап 2: теоретический

Время прохождения этапа: примерно 2 дня.

Теория Go знакомство с документацией языка и основными практиками. Все нужные ссылки собраны в нашем путеводителе в Confluence.

A tour of Go каждый сотрудник, изучающий язык, проходит этот вводный курс, который является стандартом в обучении разработке на Go.

Знакомство с нашими внутренними спецификациями и требованиями (например, с соглашением о наименовании API-методов), которые будет необходимо соблюдать в дальнейшем при разработке.

Этап 3: создание собственного сервиса

Время прохождения этапа: неделя или чуть больше.

Сотрудник сам придумывает тему для сервиса. Это может быть, что угодно: от некоторого подобия Redis до игр типа морского боя и т.п. Но есть обязательные требования: у сервиса должны быть ручки для общения с другими сервисами, и он должен взаимодействовать с базой данных.

В нашем путеводителе в Confluence есть пошаговая инструкция для создания нового сервиса, которой мы следуем при реальной разработке. Свой тренировочный сервис новичок создает по этой же инструкции.

Так как мы используем подход Specification First, то первым делом сотрудник пишет OpenAPI спецификацию своего сервиса.

Затем на ее основе создается базовый код приложения при помощи генератора gogi.

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

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

Следующий этап тестирование. С unit-тестированием в Go все хорошо оно по сути встроено в язык и описано в документации. А для функционального тестирования мы используем инструмент Gonkey (про автотесты с помощью Gonkey у нас есть целая статья). Он не требует написания кода, лишь интеграции и новичок знакомится с ним, тестируя свой сервис.

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

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

Этап 4: инфраструктурный

На этом этапе сотрудник встраивает созданный им сервис в нашу систему.

Он узнает, зачем нужны Makefile, и какие команды должны в них присутствовать.

А также какие docker и docker compose файлы нужно создать, чтобы приложение могло развернуться через Bamboo на боевом окружении, и чтобы другой разработчик мог развернуть его у себя локально.

Результат технического онбординга

Что получает новый сотрудник?

• Он изучает Go, причем не только теоретически, но и практически. Так, как это работает у нас.
• Познает все наши инструменты для создания сервисов.
• Осознает инфраструктуру.

Причем это происходит в комфортном режиме обучения: без стрессов и дедлайнов.

Что получает Lamoda?

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

Хочу подчеркнуть, что при помощи технического онбординга мы не пытаемся создать Go-гуру, который знает все от и до. Наша задача научить человека писать сервисы по рецепту Lamoda.

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

Меня зовут Виталий Хмелёв, с 2019 года я работаю в команде Аndroid-разработки в Lamoda, а до того почти семь лет проработал здесь же программистом 1C. В этой статье хочу поделиться своим опытом и дать некоторые советы, которые, я надеюсь, помогут, если вы тоже задумываетесь заняться разработкой на Android.

Как я попал в программирование

Я учился в универе по айтишной специальности, немного поработал системным администратором, а после универа устроился WEB-разработчиком в строительную компанию. Но работы было немного, а вот в соседнем отделе, который занимался 1С-разработкой, было задач предостаточно. Я начал постепенно им помогать и в итоге стал работать с этим языком.

В 2012 году я пришёл в Lamoda в отдел 1С-разработки и остался в нем на целых 7 лет. В самом начале моей работы все процессы товародвижения были автоматизированы на 1С. На нём же работала наша собственная фотостудия. Это всё входило в одну большую конфигурацию, основанную на решении 1С: Комплексная Автоматизация. В ней же были бухгалтерия и кадровый учёт.

Постепенно какие-то части стали выводить из состава большой конфигурации. Первой стала фотостудия, которую переписали на PHP. Затем в компании начали внедрять Microsoft Dynamics AX, и товародвижение и бухгалтерия перешли на нее. Кадровый учёт переехал в отдельное готовое решение 1С: ЗУП.

Но одновременно с этим происходило расширение компании, открывались новые филиалы в странах СНГ, и в большинстве из них кадровый учёт и бухгалтерия велись на 1С, а поддержкой занимался наш московский отдел 1С-разработки. Большая часть задач решалась удаленно, но как-то раз я даже ездил в командировку в Казахстан для внедрение проекта в филиале.

Карьера складывалась успешно почему же я решил заняться чем-то другим?

В нашей команде в Lamoda мы старались писать на 1С качественно и применять современные подходы. Ориентировались на рекомендации самой компании 1С и на то, как написаны базовые конфигурации.

Мне нравилась моя работа. Хотелось глубже погружаться в разработку, профессионально расти в программировании. Я читал книги, статьи, но из-за особенностей самого языка 1С, и среды разработки, многие концепции для него просто неприменимы. По сравнению с другими популярными языками PHP, Java, С 1С достаточно простой, и в нем много чего нет.

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

Я не знал, как я буду развиваться дальше, если останусь в 1С. У меня были основные сертификации (несколько Профессионалов, Специалист по платформе 1С). Следующая ступень сертификация как Эксперта 1С. Экзамен там достаточно сложный, и либо мне надо было начинать готовиться к нему, либо уходить в какую-то другую сферу.

В итоге я признался себе, что да, мне нравится 1С, но не настолько, чтобы идти с ним до уровня Эксперта =)

Как я выбирал, в какую область перейти?

У 1С есть большой плюс высокая востребованность разработчиков. Практически в любом городе России можно найти себе работу. Мне хотелось выбрать новую область тоже достаточно популярную, чтобы пусть не в каждом городе, но в крупных городах были вакансии причем не только в России, но и на Западе.

Хотелось выбрать мощный язык, не нишевый. Чтобы можно было использовать удобную среду разработки в 1С с этим не очень. Есть решение 1С:EDT, которое позволяет приложить некоторые дополнительные усилия и пользоваться не встроенной средой (Конфигуратором), а Eclipse. Однако в 2018 году мы посчитали его достаточно сырым и неподходящим для каждодневной разработки, поэтому в Lamoda мы продолжали писать в Конфигураторе.

Мобильная разработка показалась мне очень перспективной областью (и я не поменял свое мнение до сих пор). Осталось выбрать между Android и iOS, что было достаточно легко, потому что я уже имел опыт разработки на Java в институте и писал небольшой личный проект для Android еще в 2011 году. Поэтому я решил, что проще будет восстановить и углубить знания именно в этой сфере.

Подготовка к переходу самообучение

Я начал активно учить теорию, на которую ушло чуть больше года. Занимался сам после работы и в выходные. Изначально я был настроен очень серьезно, выбирал такой темп, чтобы не перегореть и довести план до конца.

Сразу решил, что платные курсы проходить не буду, но старался, чтобы мое самообучение было достаточно структурированным. Начал с курса Гугла, потом добавил ютуб курсы от Яндекса и Mail.ru, плюс книги (в основном по Java). Конечно, изучал официальные гайды по Android от Google их много, они качественные и постоянно обновляются. В какой-то момент Google официально рекомендовал Kotlin как язык для разработки под Android. Я понимал, что работать буду, скорее всего, на Kotlin, и добавил его в свою программу обучения.

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

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

Переход на новое (?) место работы

Найти хорошее место работы, не имея опыта по новой специальности, казалось непростой задачей. Я сразу подумал о том, чтобы попробовать перейти в команду Android-разработки внутри Lamoda. Мои руководители по 1С-разработке могли дать рекомендации, что должно было помочь.

Хотелось узнать, как вообще выглядит Android-разработка в Lamoda. Я установил и изучил приложение компании как пользователь, но хотелось больше узнать про техническую сторону. В Lamoda есть TechTalks встречи внутри компании, где разные команды выступают с докладами о том, чем они занимаются, какие технологии используют. Они открыты для всех желающих, и я стал слушать доклады команды Android-разработки. После внутренних выступлений специалисты с этими же докладами идут во внешний мир. Вот, например, запись того доклада, что я слушал, но уже с конференции Mosdroid. Из докладов я узнал, какие у них в принципе задачи, а заодно стал изучать именно те технологии, которые используются в компании это помогло мне в дальнейшем с переходом.

В июле 2019 года, через год с небольшим после начала изучения Android, я решил, что готов работать в новой области. Написал письмо тимлиду Android-разработки, прошел техническое интервью, и меня взяли в команду. И уже с августа 2019 я работаю как Android-разработчик.

На новом месте

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

Я переходил в новую область во многом потому, что хотел развивать навыки программирования на мощном современном языке. Переход в Android полностью оправдал мои ожидания. Наша команда пишет новый код только на Kotlin, Java нужна для доработки уже написанного. Мне Kotlin очень нравится, у него приятный синтаксис, и он не такой многословный, как Java. Также язык молодой, и сделан с учетом современных паттернов программирования.

Совершенно новым для меня оказался принцип работы по дизайну. В 1С разработке дизайн дело десятое. Об удобстве интерфейса для пользователя заботится сам разработчик, так, как он это понимает. И вся аудитория тех, кто увидит твои формы, отчеты и обработки, по сути, ограничена сотрудниками собственного отдела кадров и бухгалтерии.

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

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

Мне нравится, что в нашей команде организована постоянная работа с техдолгом. Мы регулярно занимаемся рефакторингом старого кода, переписываем с Java на Kotlin. Это погружение в чистое программирование, когда нет необходимости думать даже про дизайн: берешь старый legacy код, и переписываешь его в удобный, быстрый, легко читаемый, в соответствии с современными подходами. Привычка сразу задумываться о качестве и удобстве кода, которую я получил еще в команде 1С-разработки, сильно помогла мне здесь.

По чему из 1С-разработки я скучаю больше всего, так это по хорошей подробной документации полностью на русском языке =) И русскоязычному профессиональному сообществу в интернете. В Android в 9 случаях из 10 ответ на какой-то вопрос есть только на английском. На английском я читаю пока что медленнее, чем на русском, и времени на то, чтобы в чем-то разобраться, уходит больше.

Кратко: как перейти в Android из какой-то другой области?

1. Изучить теорию. Либо на платных курсах, сейчас их достаточно много. Либо заниматься самообучением. Есть хорошие бесплатные вводные курсы от Google и целые плейлисты на ютубе . Объем теории большой (посмотрите, например, на эту дорожную карту), но если это ваше вам будет интересно.
2. Написать свое демо-приложение, которое можно будет приложить к резюме. Опыта коммерческой разработки у вас нет, но будущим работодателям нужно хоть как-то оценить ваши навыки. Приложение даст им возможность это сделать. Код нужно выложить в открытый репозиторий, например, на GitHub.
3. Хорошо подготовиться к техническому интервью. Первые два пункта нужны, чтобы вас позвали на собеседование, но потом его нужно еще пройти =)
4. Готовиться я советую по телеграм-каналам. Есть хорошие каналы отдельно для подготовки к общим IT-вопросам, вопросам по Android и по Java. Там разбираются все основные вопросы, которые задают на собеседованиях. Многие из них и мы в Lamoda задаем кандидатам. Сейчас я сам принимаю участие в собеседованиях, и когда видно, что человек подготовился это всегда создает хорошее впечатление.

Эти три пункта должны помочь найти первую работу в Android.
Если у вас появились какие-то вопросы буду рад ответить на них в комментариях!

Меня зовут Никита Василюк, я инженер по работе с данными в департаменте данных и аналитики Lamoda. Я и моя команда занимаемся всем, что связано с распределенной системой хранения и обработки данных.

Периодически нам приходится отвечать на вопросы, где у нас лежат те или иные данные. Поэтому однажды мы решили провести эксперимент и внедрить Data Catalog, чтобы запросы приходили уже не к нам, а в систему. Например, если человеку понадобилась информация, связанная с заказами, он может перейти в систему, ввести слово order и найти все, что ему нужно по этой теме. Мы рассмотрели три инструмента и в итоге не стали ничего менять. Рассказываю почему.

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

Мы решили поставить небольшой эксперимент и представить, что было бы, если роль Data Catalog исполнял не Confluence, а другая система.

Требования к системе

Мы определили несколько важных требований к потенциальной системе, в которой бы начали строить Data Catalog:

• Автоматический сбор данных из разных СУБД. Это позволит нам избавить аналитиков от ручного обновления описаний таблиц.
• Отображение структуры датасета с понятными описаниями и полнотекстовым поиском по этой информации.
• Web UI с поиском. Это очень важное требование, поскольку в первую очередь Data Catalog задумывается как инструмент для поиска метаданных.
• Визуализация data lineage от системы-источника до отчета в BI-системе.
• Отображение data owner. С помощью этого можно понять, к какому человеку обратиться по всем вопросам, связанных с данными.

Остальные требования входят в разряд хотелок их наличие упростило бы жизнь, однако отсутствие не так критично:

• SSO SAML авторизация;
• визуализация Data Profiling;
• визуализация Data Quality;
• добавление кастомной информации для отображения;
• трекинг изменения датасетов.

Мы решили рассмотреть три популярных open source проекта: Amundsen, LinkedIn DataHub и Marquez.

Amundsen

Amundsen это типичный справочник. То есть просто хорошая штука, чтобы поискать информацию по имеющимся таблицам. Он состоит из следующих сервисов:

• neo4j хранилище метаданных (также может использоваться Apache Atlas);
• elasticsearch поисковый движок;
• amundsensearch сервис для поиска по данным в Elasticsearch;
• amundsenfrontendlibrary Web UI (написан на Flask);
• amundsenmetadatalibrary отвечает за работу с метаданными в Neo4j или Atlas;
• amundsendatabuilder библиотека для извлечения данных из различных СУБД.

Принцип работы довольно простой. ETL-процесс сбора метаданных состоит из извлечения записей из источника при помощи выполнения SQL-запросов, преобразования записей и их загрузки в хранилище метаданных. Extractor выполняет запрос к хранилищу метаданных и преобразует их в набор вершин и связей между ними. Промежуточные результаты сохраняются в локальную директорию. Transformer преобразует загруженные данные в нужную структуру. Loader подхватывает промежуточные данные и складывает их либо во временный слой, либо сразу в финальное хранилище. Publisher подхватывает промежуточные данные и отправляет в хранилище.

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

Во время тестирования Amundsen показался достаточно сырым например, из коробки не было авторизации, а поиск работал только по тегам и названиям баз, таблиц и колонок, не было возможности искать по описаниям. Но он действительно хорошо работает, когда нужно посмотреть, какие данные есть у нас в схемах.

Плюсы:

• автоматический сбор данных из разных СУБД;
• API для добавления или редактирования данных в автоматическом режиме за счет обращения напрямую к Metastore/information_schema;
• Web UI с полнотекстовым поиском;
• поиск по базам, таблицам, полям и тэгам;
• добавление кастомной информации для отображения (programmatic description)
• визуализация data profiling (например, количество записей, дата последнего обновления, исторические значения);
• визуализация data quality (какие проверки навешаны на датасет, история результатов проверок);
• отображение data owner.

Минусы:

• нет трекинга изменения датасетов (хранит только актуальное состояние и работает как справочник);
• нет data lineage (источник можно идентифицировать только в блоке с кастомной информацией);
• не нашли SSO-аутентификацию, доступна только OIDC;
• полнотекстовой поиск работает только для тегов, таблиц, баз и колонок (нет возможности искать по описаниям колонок).

LinkedIn DataHub

Как можно понять из названия, это платформа поиска и обнаружения метаданных от LinkedIn. Из коробки она состоит из целого зоопарка сервисов:

• kafka-broker брокер Kafka;
• zookeeper координатор для Kafka;
• kafka-rest-proxy RESTful интерфейс для Kafka;
• kafka-topics-ui Web UI для топиков Kafka;
• schema-registry Kafka Schema Registry;
• schema-registry-ui Kafka Schema Registry UI;
• elasticsearch поисковый движок;
• kibana дашборд для Elasticsearch;
• neo4j графовая база данных;
• datahub-gms Generalized Metadata Store;
• datahub-frontend Web UI;
• datahub-mae-consumer сервис для обработки сообщений Metadata Audit Events;
• datahub-mce-consumer сервис для обработки сообщений Metadata Change Events;
• mysql база данных для хранения метаданных.

Основная сущность DataHub dataset. Он может включать в себя таблицы (RDBMS и не только), топики в Kafka, директории на HDFS или другие сущности, имеющие схему.

Датасет имеет:

• схему (включая типы и комментарии к полям),
• статус (active или deprecated),
• владельцев,
• relationships (он же lineage),
• docs с указанием ссылок на документацию.

Метаданные обновляются через отправку сообщений Metadata Change Event (MCE) в Kafka. MCE это сообщение в формате AVRO с указанием пунктов, которые необходимо обновить. Гибкость обновления данных в системе достигается за счет возможности в одном сообщении обновить владельцев датасета, в другом обновить схему, в третьем upstream datasets.

Отличительная особенность DataHub приятный веб-интерфейс. Он нам сразу понравился и запал в душу. У него все хорошо в плане поиска, обновлений типов таблиц и типов датасетов, информация о схеме датасета выглядит очень приятно. Можно добавлять владельцев датасетов, можно зайти в профиль пользователя и посмотреть, какими датасетами он владеет. У DataHub есть lineage, для каждого датасета можно наблюдать его взаимосвязи с другими объектами. Также есть возможность к каждому датасету прикладывать ссылки на документацию или исходный код.

Самый большой минус DataHub он состоит из огромного числа компонентов. Плохо это тем, что за каждым надо следить и для каждого из них нужно настроить отказоустойчивость.

Плюсы:

• удобный UI с поиском;
• автоматический сбор данных из разных СУБД (большая гибкость, поддерживает сбор данных не только из СУБД, работает для всего, у чего есть схема);
• добавление или редактирование данных в автоматическом режиме через отправку AVRO-сообщений в Kafka;
• добавление ссылок на документацию к датасету;
• визуализация data lineage от источника до отчета в BI-системе (однако нет возможности отобразить всю цепочку сразу, отображается только upstream и downstream датасеты на один уровень вверх и вниз);
• отображение data owner;
• есть возможность сделать связку с интранетом компании.

Минусы:

• огромное количество внутренних сервисов, за каждым из которых нужно следить;
• отсутствует трекинг изменения датасетов;
• data lineage показывает только upstream и downstream датасеты;
• отсутствие визуализации data profiling;
• отсутствие визуализации data quality (в roadmap на Q2 2021 есть пункт про отображение визуализаций и интеграцию с такими системами, как Great Expectations и deequ);
• нет возможности добавить кастомную информацию для датасета;
• нет возможности прослеживать изменения в датасетах;
• поиск работает только для датасетов и пользователей.

Marquez

Третий инструмент Marquez. Он состоит из основного приложения, базы данных и веб-интерфейса для отображения датасетов, джобов и связей между ними.

Метаданные в Marquez отправляются с помощью REST API. Еще он поддерживает создание следующих типов объектов:

• data source системы-источники;
• dataset таблицы, из которых читаются и в которые пишутся данные, обрабатываемые джобами;
• job абстракция над процессом трансформации данных, которая принимает таблицы на вход и записывают в них данные;
• job run запуск конкретной джобы.

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

Его самый главный минус слишком минималистичный интерфейс, он плохо справляется с отображением lineage, в котором есть много таблиц и ветвлений. Нет возможности отображать владельца данных, нельзя в режиме справочника посмотреть, какие таблицы у нас есть. Нет возможности отображать информацию по качеству данных, по профилированию, невозможно добавить кастомную информацию. То есть Marquez максимально простой инструмент, который может подойти для каких-то простых use-caseов, но не подойдет для чего-то масштабного.

Плюсы:

• быстрый и минималистичный UI;
• поддержка airflow из коробки;
• простая, но гибкая модель данных, позволяет с минимальным набором абстракций описывать данные;
• понятный и простой API для добавления или редактирования данных;
• Web UI с поиском;
• есть lineage;
• минимум компонентов.

Минусы:

• слишком минималистичный UI;
• отсутствует авторизация;
• плохо работает в режиме пробежаться глазами и посмотреть, какие данные вообще есть;
• не отображается data owner;
• поиск работает только для датасетов и джобов;
• нет возможности прослеживать изменения в датасетах;
• отсутствует трекинг изменения датасетов;
• отсутствует визуализация data profiling;
• отсутствует визуализация data quality;
• нет возможности добавить кастомную информацию для датасета.

Бонус: загоняем lineage из DWH в Neo4j

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

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

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

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

Зеленые блоки джобы, серые таблицы. Можно выделить джоб или таблицу и подсветить его зависимости в обе стороны. Несмотря на то, что выглядит это мощно (и напоминает кусок производства из игры Factorio), ничего полезного из этого мы вынести тоже не можем.

Что мы выбрали в итоге и почему не стали внедрять

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

Проведя Customer Development среди потенциальных пользователей, мы пришли к выводу, что ни одна из систем не поможет сэкономить рабочее время тех людей, которые работают с данными. При этом сложность внедрения и перестройки процессов будет существенной. Поэтому мы решили на какое-то время отложить выбор.

Мы отслеживаем развитие рассмотренных в статье сервисов, изучаем платные варианты Data Catalog и их возможности. Если у вас есть успешный (или не очень) опыт внедрения подобных систем, то поделитесь им в комментариях.