Привет! Мы команда Туту. У нас сервис путешествий, мы каждый день отправляем флот самолётов, несколько поездов и много автобусов. Сервис помогает путешественникам с билетами, расписаниями, отелями и всем прочим для поездок.
Среди всего этого есть расписания электричек и покупка билетов на часть этих самых электричек. Там около 600 тысяч пользователей дневной аудитории, и это лидирующий продукт рынка. Это очень точное расписание, которым пользуются сами машинисты поездов, плюс вокруг расписания есть модели расчёта опозданий, которые по изменению движения одного поезда пересчитывают в реальном времени ожидания для всех других с учётом архитектуры железных дорог на участке.
С точки зрения наполнения расписания продукт очень крутой. С технической точки зрения ситуация немного другая. Два года, фактически, продукт копил техдолг, и настало время что-то с этим делать. Сейчас электрички отделены от основого направления ж/д (поездов дальнего следования), что довольно странно для пользователя — два разных приложения, два разных интерфейса и т.п. Мы в перспективе собираемся объединять всё это в единый сервис со всеми видами транспорта. С электричками ситуация особенная, потому что это один из первых сервисов компании, и там большой легаси-монолит, вокруг которого есть более современные, но, увы, тоже уже устаревшие микросервисы.
Кого мы ищем
Мы собираем команду заново, и вам вместе с Senior Backend Developer предстоит приводить это в порядок, чтобы Make Elektrichka Great Again. Конкретно мы не питаем иллюзий про всеобщий рефакторинг, а пока ставим цели банально разобраться в связке монолита и сервисов, сделать себе рабочее окружение, настроить инструменты и потихоньку начать всё это упорядочивать. Победа над хаосом предполагается через всю новую разработку на Go сразу в правильном ключе. Если всё пойдёт хорошо, рефакторинг возможен позже.
Немного про стек
- Монолит: PHP 7.2 монолит, собственный framework (там наши крафтовые библиотеки), MariaDB. Монолит не самое страшное, самое страшное - это взаимодействие монолита и сервисов, там пугающий дебаг.
- Собственно, сервисы: SOA (PHP), PHP > 7, Go 1.12, Next.js v13.
- CУБД: MariaDB, MongoDB, Redis (кэш и хранилки временные), ClickHouse для дата-команды.
- Очереди: RabbitMQ, Kafka.
- Соотношение языков в работе: Go — 20%, PHP — 80%.
Основные задачи
- Разобраться в проекте и кодовой базе. Архитектура — солянка, там несколько исторических слоёв. Основные компоненты — админка для управления контентом (полностью в монолите с использованием части сервисов) и сама часть электричек (70 в сервисах, которые устарели на 30 монолита).
- Брать задачи беклога. Ближайшие — интеграции с перевозчиками (продажа новых билетов прямо из приложения в разных городах) и платёжными шлюзами, СБП.
- Есть ряд задач от инфраструктурных команд уровня “почините баг с доставкой данных до датасатанистов”, есть срочные задачи при изменениях нормативки или законодательства, есть внезапные критикал-баги.
- Позже надо будет перебирать весь сценарий покупки, чтобы интегрироваться с едиными компонентами, которые используют другие вертикали.
- Покрытие кода тестами (юнит, интеграционные, e2e) в соответствии с внутренними требованиями.
- Можно взять и лидировать лучший сервис электричек в известной части галактики :)
От вас нужно
- Опыт коммерческой разработки веб-приложений на PHP от 4 лет.
- Опыт работы с Go от года.
- Опыт работы с монолитными и сервисными архитектурами.
- Опыт работы с MongoDB, MySQL.
- Опыт проектирования архитектуры приложения, взаимодействия сервисов и описания интерфейсов (REST openapi, grpc protobuf).
- Понимание CI/CD, Docker, Kubernetes.
- Базовые знания по unit-тестированию.
- Способность работать в кросс-функциональной Scrum-команде.
Про команду и рабочий процесс
- Команда собирается заново. Уже есть продуктовый менеджер, мобильный разработчик и бэкенд-разработчик уровня Senior. Есть наставник из смежной команды и руководитель, который поможет вникнуть в предстоящие задачи (он застал несколько лет дебага монолита), процессы работы в нашей команде и познакомит с рабочими инструментами.
- Живём по Скраму. Product owner в процессе регулярных планирований спринта рассказывает, чего хочется достичь в продукте. Дальше приоритезация беклога. Потом цель спринта. Задачи трекаем в Jira, документацию ведём в Confluence. Из встреч есть ежедневный утренний стендап ж/д команды (30 минут), Sprint planning (2 часа), PBR — обсуждение/прояснение задач (2–4 часа), Sprint review (1 час), Retro (1 час). Спринты по 2 недели.
- Ревью проходит совместно с командой ж/д, между всеми backend-разработчиками. Для слияния кода в мастер-ветку требуется как минимум 2 апрува от backend-разработчиков и 1 от мейнтейнера библиотеки.
- Ответственность за качество продукта лежит на всей команде. Разработчики пишут новый код и покрывают тестами по пирамиде тестирования. Стараемся писать больше юнит-тестов, чем интеграционных и e2e. QA-инженер обучает команду практикам тестирования, помогает составлять тест-кейсы, подключается к проверке выпускаемых задач, пишет интеграционные- и e2e-тесты в случае необходимости, участвует в развитии подходов обеспечения качества.
- Монолит релизится 2 раза в неделю. Сервисы доставляются на бой регулярно, без использования релизного цикла.
- Мы ценим работу в команде, самостоятельность, умение давать обратную связь и получать её.
