Хабрахабр

Как в Kiwi.com тестируют 1000 проектов на Python

Original english version of this article is here.

До выступления еще две недели, но я, конечно, уже обо всем расспросил Алекса и под катом поделюсь спойлерами и бэкстейджем подготовки доклада: что это за опенсорсный Зоопарк такой, что он делает с нашим Python кодом и чем отличается от mypy сотоварищи. Это название доклада Alex Viscreanu на Moscow Python Conf ++.

— Расскажи немного о Kiwi, чем ты занимаешься в компании?

Компания основана в Чехии в 2012 под названием Skypicker, а в 2016 сервис сменил название и переехал на Kiwi.com. Kiwi.com — онлайн турагентство с секретным соусом. Сейчас Kiwi.com в пятерке крупнейших агрегаторов авиабилетов в Европе.

Классная фича Kiwi.com для пользователей в том, что мы находим варианты стыковок для рейсов авиакомпаний, которые обычно не работают вместе, и берем на себя решение всевозможных проблем при стыковке.

Чтобы вы оценили наши масштабы, вот цифры о Kiwi.com: 90 000 000+ ежедневных поисков, 25 000 ежедневно продаваемых мест и более 15 000 000 000 доступных комбинаций рейсов.

Что касается меня, я full-stack разработчик, переехал из Испании в Чехию, чтобы работать в Kiwi.com. На бэкенде я работал с Python, на фронтенде — JavaScript и зоопарк разного: Backbone.js, Angular, Vue.js.

Эта работа требует глубоких знаний об управлении инфраструктурой и инструментах деплоя, думаю, можно сказать, что на самом деле я занимаюсь DevOps, с небольшим уклоном в Dev часть. В Kiwi.com я пришел в инфраструктурную команду, поэтому в основном разрабатываю и поддерживаю внутренние инструменты для разработчиков.

Для каких проектов вы используете Python? — Сколько в Kiwi Python-разработчиков?

У Kiwi.com микросервисная архитектура, и каждая команда отвечает за несколько сервисов. У нас больше 350 разработчиков, из них человек 200 используют Python каждый день. Тем более у бэкенда закрытый код, и я не могу слишком подробно о нем говорить. Не думаю, что можно сказать, что какой-то из них самый главный, или что все разработчики работаю над чем-то одним.

Но у нас есть некоторые интересные открытые проекты, доступные на GitHub:

  • Phoenix — инструмент для оповещений в Slack об инцидентах;
  • Crane — скрипт для развертывания в Rancher непосредственно из GitLab;
  • The Zoo — набор сервисов поменьше, которые тем не менее могут быть очень полезными.

— Что насчет CI/CD и инфраструктуры для деплоя?

Это довольно хорошее решение, оно гибкое и позволяет строить производительные пайплайны. Мы используем GitLab в качестве репозитория исходного кода, и, естественно, лучше всего с ним интегрируется GitLab CI. А используя связку из GitLab CI и нашего инструмента Crane, мы можем разворачивать проекты в разных окружениях по нажатию кнопки (или полностью автоматически, если у вас достаточно смелости).

За счет этого можно легко добавлять мощности по необходимости, и экономить, не держа неиспользуемые сервера в нерабочее время. Весь CI обеспечиваем парком автомасштабируемых инстансов EC2.

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

А какие-нибудь другие языки у вас используются, и для чего? — Похоже, вы предпочитает Python.

Кроме того есть Kotlin и Java для Android приложений; Swift и Objective-C для iOS; для связки сервисов кое-где используется GoLang, и C/C++ для движка поиска перелетов. Второй самый используемый язык — JavaScript, в основном для фронтенда и GraphQL API.

Зачем Kiwi проекты с открытым исходным кодом? — Ты упомянул open source проект The Zoo. В чем ваша выгода?

Возможно, это прозвучит как клише, но, когда вы получаете так много, хорошо бы отдать что-то взамен. Как и многие другие компании, мы используем open source почти во всем, что разрабатываем. Это вклад в коллективное знание, которое помогает всем нам двигаться вперед.

Другие люди могут взглянуть на продукт под совсем другим углом и предложить что-то, о чем мы и не думали или не подозревали. Кроме того, что кому-то принесет пользу то, что мы выкладываем в open source, это полезно и для нас.

Сколько репозиториев вы проверяете с его помощью? — Расскажи немного подробнее о The Zoo.

Итого близко к 1500. У нас примерно 1 300 репозиториев во внутреннем GitLab и около 100 в публичном GitHub.

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

И сколько ошибок вы обычно находите? — Впечатляющее число! Запомнился какой-то особенный улов?

Правда большинство из них не «проблемы-проблемы», а просто рекомендации. Сейчас в нашей базе данных примерно 26 000 найденных проблем, то есть около 20 проблем на проект.

Здорово, когда можешь автоматически отловить существенные ошибки.

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

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

Он нужен, чтобы разработчику было удобно самому написать любые проверки, какие он захочет? — То есть в The Zoo как таковом нет никаких проверок по умолчанию? Можешь привести несколько примеров? Вы сделали The Zoo и проверяете множество всего с его помощью.

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

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

Расскажешь об этом подробнее в своем докладе на Moscow Python Conf++? — Звучит как «must have» для любой большой компании!

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

Я уверен, что в ней можно найти что-то вам подходящее. Я всячески призываю всех попробовать The Zoo, поиграть с ним, написать свои собственные проверки и таким образом расширить общую базу знаний.

Наконец, если бы ты мог вернуться на 5 лет назад, какой бы совет, связанный с Python, ты бы дал самому себе? — Спасибо!

Python 3 — это естественная эволюция языка, она определяет основы. Это непросто… Я начал писать на Python 3 только полтора года назад, но себе в прошлом я бы настоятельно рекомендовал начать как можно раньше. Дело не только в том, что близок конец его поддержки, а по большей части в том, что я уже привык к фичами новой версии. Сейчас я бы ни за что не вернулся к Python 2.

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

Приходите 5 апреля на Moscow Python Conf++, чтобы узнать подробности работы с этим интересным open source проектом и, может быть, в чем-то позаимствовать опыт Kiwi.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть