ШБР 2023 — Вводная лекция про бэкенд

• Николай Смирнов приветствует участников и представляет лекцию по бэкенд-разработке в Яндексе.  

• Лекция охватывает все треки: Python и Java, без углубления в детали.  

• Цель лекции - показать полный путь разработки фичи в Яндексе.  

• Фича - это законченная функциональность, которую можно оценить по вкладу в продукт.  

• Процесс включает идею, формирование продуктовой гипотезы, MVP, архитектуру, кодирование, тестирование и оценку влияния на продукт.  

• Пример: добавление фото водителя в Яндекс.Такси.  

• Гипотезы строятся в форме "действие - ожидаемый результат".  

• Примеры гипотез: увеличение чаевых, повышение безопасности.  

• Важно быстро проверить гипотезы, чтобы понять, приносит ли фича пользу пользователям.  

• Архитектура включает множество микросервисов и приложений.  

• MVP позволяет быстро проверить гипотезы и минимизировать изменения в архитектуре.  

• Пример MVP: загрузка фотографий водителей вручную и проверка их значимости для пользователей.  

• Варианты реализации: использование существующего микросервиса или создание нового.  

• Преимущества и недостатки каждого подхода.  

• Решение: создание отдельного микросервиса для новой функциональности.  

• Выбор базы данных зависит от разрешенных технологий.  

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

• Решение: создание нового микросервиса для хранения фотографий водителей.  

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

• В инфраструктуре Яндекса все базы данных поддерживаются как сервисы.  

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

• Для хранения фотографий используется S3 хранилище.  

• Для метаданных о ресурсах будет использоваться база данных.  

• Для написания микросервисов выбираются языки C++ и Python.  

• C++ используется для микросервисной архитектуры благодаря фреймворку YouServer.  

• Python подходит для быстрого тестирования гипотез и решения задач.  

• Важно учитывать нагрузку на сервис: CPU или IO Bound.  

• Интерфейс должен быть согласован с разработчиками клиентских приложений.  

• Используется Open API для описания интерфейсов.  

• Важно учитывать расширяемость сервиса для будущих изменений.  

• Архитектурное ревью помогает выявить и исправить ошибки в архитектуре.  

• Важно проводить ревью на ранних этапах разработки.  

• Тестирование проводится на разных уровнях: юнит, интеграционные и системные тесты.  

• Тестирование производительности включает нагрузочное тестирование.  

• Цель тестирования – определить уровень нагрузки, при котором сервис перестает отвечать.  

• Это помогает оценить, сколько запросов в секунду может обработать сервис.  

• Тестирование производительности включает проверку устойчивости к отключению дата-центров и деградации сервиса.  

• Автоматизированное тестирование проверяет выполнение заказов в Яндекс.Такси.  

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

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

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

• Проводится нагрузочное тестирование для проверки безопасности кода.  

• Прогнозируется входящая нагрузка и количество экземпляров микросервисов.  

• Сервисы разворачиваются в дата-центрах, где запросы балансируются с помощью L3 и L7 балансировщиков.  

• Сервисы общаются друг с другом через сервис registry и механизм сервис discovery.  

• Новая функциональность выкатывается постепенно, начиная с пресейбл серверов.  

• Если на пресейбл все хорошо, сервис раскатывается на все дата-центры.  

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

• Новая функциональность проверяется на небольшой группе пользователей с помощью тумблеров.  

• Тумблеры позволяют быстро отключать функциональность и проводить A/B-тесты.  

• A/B-тесты помогают проверить, как новая функциональность влияет на пользователей.  

• Инженеры следят за работоспособностью сервиса, контролируя ресурсные метрики и коды ответов.  

• Автоматика настраивается для оповещения дежурного инженера при достижении порогов.  

• Мониторинг включает контроль очередей, времени ожидания и выполнения задач.  

• Проблемы делятся на три группы: warning, critical и disaster.  

• Warning проблемы можно отложить на ночь или выходные.  

• Critical проблемы требуют немедленного внимания.  

• Disaster проблемы требуют немедленного устранения.  

• Метрики и логи помогают понять причины проблем.  

• Админки помогают быстро анализировать логи и ошибки.  

• Админки имеют интерфейс и настраиваемую безопасность.  

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

• Метрики и эксперименты помогают понять полезность фич.  

• В Яндексе используются свои инструменты для хранения и анализа метрик.  

• Используется асинхронная модерация фотографий.  

• Толокеры проверяют фотографии по инструкциям.  

• Водитель не сразу видит свою фотографию в заказах.  

• Использование признака импотентности операции предотвращает дублирование.  

• Клиент формирует идентификатор для фиксации успешной операции.  

• Повторные попытки с тем же идентификатором игнорируются.  

• Запросы пользователей идут в распределенную систему.  

• Консистентность данных важна для некоторых систем.  

• Асинхронная репликация данных обеспечивает быструю работоспособность.  

• Документация важна для разработчиков.  

• Документируемый код помогает в процессе код-стайла и код-ревью.  

• Команды сохраняют знания в базу знаний, которая может быть Вики.  

• Документация помогает новым сотрудникам быстрее вливаться в работу.  

• Хорошая документация экономит время и снижает количество вопросов.  

• Продуктовая разработка отличается от инфраструктуры.  

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

• Культура компании и процессы влияют на разработку.  

• Смешивание функциональности может привести к монолиту.  

• Архитектурные ревью помогают избежать этого.  

• Опыт и знания опытных разработчиков помогают предотвратить монолит.  

• grpc используется для взаимодействия между сервисами.  

• В Яндексе можно менять языки программирования в зависимости от проекта.  

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

• Разработчики участвуют в разбиении фич и принятии архитектурных решений.  

• Продуктовые менеджеры и аналитики также играют ключевую роль.  

• Инициативы снизу и сверху помогают развивать продукт.  

• В бэкенде можно совмещать языки, но это зависит от команды.  

• Full-stack разработчики востребованы, но разделение на фронтенд и бэкенд остается.  

• Аналитики и продуктовые менеджеры также играют важные роли.  

• Фреймворк на плюсах может быть высоконагруженным решением.  

• Ответы на 10 вопросов и пожелания удачи в обучении.  

• Впереди много интересного и нового.