Обязанности:
Pulse — это внутренний сервис для мониторинга скорости приложений и веб-сервисов до и после выпуска их в production. "Скорость" оценивается по значениям самых разнообразных метрик, главное требование к которым — быть измеримыми числом: время старта приложения, скорость различных действий (загрузка экранов, страниц), потребление ресурсов (CPU, памяти, диска, энергии) во время работы, плавность скроллинга и т.д. Сервис поддерживает все платформы (Linux, Android, iOS, Windows, macOS), главными клиентами являются мобильные и десктопные приложения Яндекса: Браузер, Карты, Маркет, Почта и другие, а пользователями сервиса — разработчики, менеджеры и другие наши коллеги, которым важно следить за производительностью их продуктов. Часть системы "до выпуска в production" чем-то напоминает CI/CD (например, GitHub Acitions): интегрируется с VCS проекта и специальными тестами, которые называются performance-тестами, и решает две основных задачи: Следить за производительностью приложения по мере его разработки и максимально быстро, полно и точно уведомлять авторов "проблемных" изменений (pull request-ов) о деградациях метрик. Это реализуется через прогон специальных сценариев в performance-тестах с замерами метрик в контролируемом окружении (на специально подготовленных устройствах, мобильных и десктопных). Измерять каждую метрику каждого приложения на каждом коммите очень накладно по ресурсам (приложений — десятки, метрик десятки тысяч, коммитов — тысячи в день), поэтому система реализует отложенный поиск проблемных коммитов через периодическое измерение скорости на свежей версии кода, поиск аномалий на получившихся графиках метрик и уточнение причин через бинарный поиск (бисект) с использованием методов математической статистики. Подавляющее большинство метрик производительности обладают шумом, важно отличать случайные выбросы от значимых отклонений. Дать возможность разработчикам проверять какие-то изменения, сравнивая две или больше конфигураций (срезов) приложения. Это может быть сравнение следующей версии приложения, которая готовится к выпуску в production, с предыдущей версией по основным сценариям и метрикам скорости, сравнение разных конфигураций экспериментальной функциональности или проверка того, как обновление библиотеки повлияет на производительность. Главная задача сервиса здесь — максимально точно найти значимые отклонения измеренных метрик и наглядно отобразить их пользователю. Часть системы "после выпуска в production" похожа на системы мониторинга ошибок в приложениях (например, Mozilla Socorro): при работе с приложением пользователь "вживую" проходит те же сценарии: запускает приложение, переключает экраны, загружает контент, скроллит и т.д. В подключённые к нашему сервису приложения встроены специальные клиентские библиотеки, которые при согласии пользователя в момент совершения тех или иных действий записывают значения метрик и отправляют их на наши сервера. Там эти отправки агрегируются, складываются в аналитическую базу данных и предоставляются в виде различных срезов пользователям сервиса. Например, система позволяет проверить, как новая версия приложения, которую выпустили на пользователей пару дней назад, ведёт себя по ключевым метрикам по сравнению с предыдущей (здесь мы стараемся точно так же выдерживать SLA по скорости сбора и анализа метрик, а также точности и полноте этого анализа), или как распределены значения метрики на интересующем срезе пользовательских устройств (скажем, с небольшим объёмом памяти и на свежей версии ОС). Данных с реальных пользователей несоизмеримо больше, чем данных с тестовой фермы (около 150 терабайт сырых данных в сутки), но эти данные гораздо сильнее зашумлены:— устройства пользователей очень разнообразны и по аппаратной, и по программной конфигурации;— измеряемое приложение, как правило, работает на устройстве одновременно с другими приложениями и сервисами, разделяя общие ресурсы;— скорость интернета и содержимое ответов API бекенда приложения постоянно меняются и являются ещё одним источником разброса в метриках, которые от этого зависят. Технологии Система использует Python 3 как язык для запуска различных автоматизаций и backend внутреннего веб-сервиса (синхронный, на Flask). Фронтенд написан на JS с использованием React и Redux. Критичные к производительности компоненты (например, расчёт данных с пользователей) написаны на C++. Клиентские библиотеки написаны на разных языках в зависимости от платформы: на десктопе это C++ или Python, на Android — Kotlin/Java, на iOS — Swift/Objective-C. В качестве БД для хранения конфигурации сервиса используется MongoDB, для хранения сырых данных performance-тестов и агрегированных данных с пользователей — ClickHouse, хранение и обработка сырых данных с пользователей происходит в MapReduce-системе YT, внутреннем аналоге Apache Hadoop (внешне известна как YTsaurus), в эту систему данные попадают через внутренний брокер сообщений LogBroker, а туда их от пользователей складывает HTTPS-бекенд на Go, развёрнутый в Деплое, внутреннем аналоге Kubernetes.Похожие вакансии