Шутка! На самом деле платформу мы сделали, чтобы измерять здоровье компонентов в отделе фронтенд-разработки ЮMoney. А на бананах с печеньем (и на кофемашинах) объяснили коллегам, как всё это работает.
Меня зовут Борис Рябов, я руководитель отдела разработки интерфейсов в ЮMoney. Расскажу, какие задачи нам помогает решать Health Check Dashboard во фронтенд-разработке, и покажу, как выглядит платформа изнутри.
Какая была проблема
В отделе фронтенд-разработки более 80 компонентов, за которыми нужно следить.
Есть много технологий, которые надо регулярно обновлять: React, Redux, TypeScript, Node.js и другие. Весь список можно посмотреть здесь.
Идёт параллельная работа над техдолгом в разных командах.
При этом мониторинга технического состояния компонентов недостаточно.
Слишком много ручных таблиц (по командам и компонентам), которые не обновляются автоматически.
Какие были требования к будущему инструменту
Нам хотелось:
Видеть все виды метрик (статистические, динамические, метрики качества кода) с разных инструментов (Grafana, Kibana, SonarQube) и дашбордов.
Выработать единый подход для разных технологий и отделов, чтобы инструмент подходил не только фронтенд-разработчикам, но и другим командам. Для этого нужно обеспечить независимость от разных языков программирования и стека.
Сделать инструмент, подходящий для всех. Чтобы у него был красивый и удобный интерфейс, с помощью которого можно строить отчёты, отслеживать статистику в динамике и наблюдать, как конкретная команда улучшила показатели за определённый промежуток времени.
Чтобы полученными данными можно было управлять, например фильтровать их.
Что у нас получилось
Универсальный инструмент для отслеживания здоровья компонент во всех командах и по всем продуктам. ? Разберём, что у него внутри.
Вот health-чеки для приложений и библиотек во фронтенде и бэкенде, которые у нас есть сейчас.
Можно перейти в любой раздел и посмотреть состояние каждого компонента. Например, так выглядит вкладка frontend-applications.
В строках отображается набор компонент — это наши репозитории, а в столбцах — набор правил. Правил сейчас немного, мы постоянно их дополняем, но те, что есть, самые важные для нас.
Как формируются оценки
Перейдём на страницу компонента checkout-client. Видим, что суммарная оценка у него не самая высокая — C.
У каждого набора правил есть своя оценка — A, B, C и D. Мы считаем среднее арифметическое этих оценок и выводим результат на страницу компонента — так формируется суммарная оценка.
Правило состоит из трёх основных сущностей:
Описание: что это за правило и для чего оно нужно.
Обоснование: почему важно это правило соблюдать.
Решение: что нужно делать, чтобы оценка повышалась.
Также в соответствующей вкладке можно посмотреть оценки в разрезе конкретных правил.
Где много красного цвета, там всё плохо. На эти правила стоит обратить пристальное внимание. Оценки можно смотреть для конкретных команд, правил и временных интервалов.
Как мы используем инструмент
Например, мы видим, что есть какая-то проблема, но не понимаем её масштабов. Могут быть проблемы, связанные с отставанием версий, использованием устаревшего кода, несоответствием практикам, принятым в отделе, и так далее.
Внедряем правило, таким образом подсвечивая нашу проблему для всех команд.
Идём по списку — от самых проблемных и значимых мест к менее важным, заносим тезисы по решению проблем в планы команды.
Доносим до бизнеса, почему эти проблемы нужно исправить, и показываем, как мы будем это делать.
Директивно решаем проблемы с конкретными командами и компонентами.
Через время анализируем, что у нас получилось, и думаем, что делать дальше.
Разберём на конкретном примере.
Есть проблема с использованием deprecated-зависимостей.
Пишем правило, которое проверяет наличие таких зависимостей и считает их количество.
Проверяем в каждом компоненте, как соблюдаем это правило. Смотрим, что нужно проработать и улучшить. Решаем, как перейти на принятые в отделе версии.
Большое преимущество инструмента — удобство для платформенных команд
Допустим, нужно раскатать большое обновление на весь отдел, чтобы все компоненты обновились. Для этого мы делаем несколько шагов:
Создаём правило для нашего обновления и расписываем, что должна сделать каждая команда.
Внедряем это правило.
Собираем информацию обо всех приложениях.
Отслеживаем, насколько каждое приложение соответствует этому правилу. Постепенно обновляем правило.
Надо уделить внимание и самим командам — чтобы они понимали, почему важно выполнять правила. Поэтому мы:
Уведомляем разработчиков о проблемах со здоровьем сервисов, где оценка в результате работы правила оказалась низкой.
Берём задачи на контроль и приоритезируем их.
Наблюдаем в health-чеке, как они меняются в динамике.
Помогаем командам там, где больше всего проблем.
Тот самый пример с печеньками и бананами на кофепоинте ЮMoney (вдруг вам тоже интересно)
Допустим, мы хотим оценить, какой из трёх кофепоинтов в петербургском офисе ЮMoney самый классный.
У всех кофепоинтов будет одинаковый набор правил:
на каждом должны быть вкусные печеньки,
рабочая кофемашина,
бананы в количестве 15 или 20 штук.
У этого правила будут такие оценки:
Вкусные печеньки: есть (А) или нет (D).
Кофемашина: работает (А) или нет (D).
Бананы: 20 штук (A), 15 (B) или вообще нет (D).
В зависимости от критериев будет меняться и оценка.
Мы создадим правило, а когда запустим его, увидим, что в конкретный день на конкретном кофепоинте были печеньки (А) и 20 бананов (А), но не работала кофемашина (D).
Исходя из этого мы определим общую оценку, например C, как в примере выше. И так cделаем cо всеми тремя кофепоинтами в офисе.
Затем понаблюдаем, как будут меняться показатели на протяжении определённого времени — скажем, одного месяца.
Определим самый проблемный кофепоинт и будем следить, чтобы там всегда было 20 бананов и много печенья, а кофемашина работала.
А вы читали о том, как мы следим за здоровьем компонентов в бэкенде? Статья об этом — здесь.
Вывод
Как видите, в компании нашу платформу может использовать кто угодно и для любых задач — даже для того, чтобы оценить состояние кофепоинтов. Важно не просто внедрить такой инструмент, но и поддерживать его: регулярно следить за тем, чтобы оценки не понижались, а если так произошло, то выяснить причину и исправить это. Наблюдать за тем, как сотрудники выполняют задачи, как меняется статус этих задач и влияет ли это на состояние продуктов и команд.
Подписывайтесь на наш блог, чтобы не пропускать новые материалы от команды ЮMoney.
