Меня зовут Лена Матвеенко, я бэкенд-разработчик в ЮMoney. Сегодня расскажу о здоровье сервисов и о том, как мы его измеряем. Рассмотрим, что такое здоровье, чем оно отличается от качества, зачем его оценивать и как это сделать, если в отделе несколько десятков разработчиков и более ста сервисов.
Что такое здоровье сервиса
Это состояние его полного благополучия. Чтобы понять, благополучен сервис или нет, нужно это оценить, поэтому мы мониторим три показателя:
качество программного обеспечения;
технический долг;
эффективность команды, которая работает над сервисом.
Рассмотрим каждый показатель.
Качество программного обеспечения
Стандарт описывает определение качества как способность при заданных условиях удовлетворять установленным или предполагаемым характеристикам и требованиям, чтобы:
снизить ошибки и простои в системе;
удешевить стоимость разработки;
упростить внедрение новых фич и понимание системы;
улучшить разработческий опыт.
В рамках наиболее актуальных стандартов ISO/IEC 25000 существуют три модели качества:
Модель качества данных (Data Quality). Определяет общую модель качества данных сервиса.
Модель качества при использовании (Quality in Use). Это степень, в которой сервис используют конкретные пользователи для удовлетворения своих потребностей.
Модель качества продукта (Product Quality). Описывает свойства с помощью восьми характеристик, которые перечислены в стандарте (динамические и статические).
Как эти три модели связаны между собой
У нас есть качество процесса, которое влияет на внутренние свойства продукта, внутренние свойства влияют на внешние, а внешние — на качество при использовании.
Разберём на примере процесса код-ревью. От того, насколько корректно мы провели код-ревью, зависит, правильно ли будут работать наши тесты в потоках. От правильности работы тестов зависит скорость сборки и выкладки релизов, а от этой скорости — время простоя.
Какова связь между здоровьем и качеством
Определение здоровья очень похоже на определение качества. Так почему же мы говорим про оценку здоровья, а не качества? Дело в том, что понятие качества довольно стандартизировано, и это ставит нас в определённые рамки. И если мы хотим выйти за рамки стандартов, то понятия качества просто недостаточно. Поэтому мы стали использовать более широкое понятие — здоровье.
Технический долг
Это накопленные проблемы в коде и архитектуре сервиса, требующие внимания и исправления. Работа над техническим долгом улучшает общее состояние сервиса, уменьшает риски инцидентов и повышает его эффективность.
Оценка команд
Это анализ эффективности разработчиков сервиса. Здоровье сервиса — это не только про технические характеристики. Оно включает в себя также благополучие людей, которые работают над этим сервисом.
Здоровый сервис = здоровое взаимодействие между разработчиками.
Зачем оценивать здоровье сервиса
Оценка здоровья помогает решать два типа задач — инженерные и менеджерские.
Вот в каких инженерных задачах помогает оценка здоровья сервисов:
поиск узких мест в их работе;
поиск пространства для оптимизации;
расширение мониторинга;
создание более ясного представления о состоянии системы и понимание её потребностей.
Оценка помогает ускорить доставку конечного продукта пользователю и способствует стандартизации процессов разработки и эксплуатации.
Если говорить про менеджерские задачи, то оценка здоровья сервисов позволяет:
снизить количество ошибок (впоследствии это влияет на управление стоимостью разработки);
оценить работу сотрудников и команд;
принимать более обоснованные решения о ротациях в команде;
планировать ресурсы в компании.
Почему мы занялись оценкой здоровья сервисов
Как было до этого:
Много разрозненных метрик, на основании которых можно было бы сделать вывод о здоровье.
Метрики мы измеряли разными инструментами, из-за этого у нас не было единого подхода и точки для оценки сервисов.
В отделе много формальных и неформальных соглашений. Из-за автоматизации проверки соблюдения соглашений появлялось всё больше метрик.
Для начала мы разработали показатели качества. За основу взяли стандартную модель ICO/IEC 5055, совместимую с ICO/IEC 25010. Она состоит из четырёх метрик:
Надёжность (Reliability);
Эффективность работы (Performance Efficiency);
Безопасность (Security);
Сопровождаемость (Maintainability).
К каждой метрике мы добавили:
Описание — информацию об измеряемой метрике.
Обоснование — причину, по которой мы хотим оценивать нашу метрику.
Решение — то, как можно улучшить измеряемую метрику.
Шкалу оценки. Для оценки здоровья использовали буквенную шкалу от А до D. У каждой измеряемой метрики был диапазон значений или иная шкала, позволяющая произвести оценку, но с основой от A до D, где:
А (4) — очень хорошо;
В (3) — скорее хорошо, чем плохо;
С (2) — скорее плохо, чем хорошо;
D (1) — очень плохо;
NA — неприменимо.
Есть показатели, которые нельзя оценить для одного сервиса, но можно для другого. Например, если сервис не взаимодействует с базой данных, мы не можем измерить скорость такого взаимодействия. А если мы не можем оценить этот показатель для сервиса, то мы просто не берём его в расчёт при оценке здоровья сервиса и отмечаем его как NA. Но здоровье этого сервиса, естественно, учитывается при общей оценке здоровья системы.
Какие типы метрик у нас есть
Метрики мы собираем отдельно для сервисов и для библиотек. Вот несколько примеров:
Динамические. С помощью этих метрик измеряются динамические показатели сервиса. Например, мы измеряем количество error-логов, ошибок входящих и исходящих запросов, скорость выполнения запросов в базе данных, скорость выпуска релиза и процент успешных сборок релизов.
Статические. С помощью этих метрик измеряются статические показатели сервиса. Например, мы измеряем количество Sonar Issues с уровнем Critical и полноту документации, проверяем, что PostgreSQL для наших тестов запускается в Docker и что наши тесты выполняются в нескольких потоках.
Экспериментальные. Когда мы хотим добавить в оценку здоровья новую метрику, она сначала попадает в категорию экспериментальных. Какое-то время мы за ней наблюдаем, возможно, меняем шкалу, а иногда даже совсем отказываемся от этой метрики, если нам кажется, что она недостаточно отражает данные либо что они ни на что не влияют.
Когда нас устраивает то, что получилось, и по значениям метрики можно делать какие-то выводы о состоянии сервиса, метрика становится статической или динамической — зависит от её изначального типа.
Как мы анализируем метрики
У нас есть внутренний сервис, анализирующий здоровье. Он ежедневно собирает данные из разных источников — Sonar, Grafana, исходного кода и всего того, что отображает метрики. Сервис анализирует наши данные, после чего собирает результаты в следующие таблицы и графики:
описание измеряемых метрик;
распределение оценок;
результаты по сервисам;
результаты по командам.
Каждый вид этих графиков разберём на конкретных примерах.
Пример оценки здоровья
Рассмотрим примеры оценки отдельной метрики и здоровья в целом.
Оцениваем метрику: количество error-логов
Измерим среднее значение количества логов с уровнем ERROR за час в течение суток.
Почему мы измеряем это в рамках оценки здоровья? Если у нас много error-логов, это может означать, что есть какие-то проблемы в работе приложения или что сервис использует неправильный уровень логирования. Это может создать фон ошибок с информационным шумом и не позволит увидеть критичные ошибки, требующие срочного исправления.
Решение: как улучшить показатель? В зависимости от причин: либо устраняем ошибки, либо, если мы определим, что у нас некорректный уровень логирования, меняем его на правильный.
Шкала оценки. Допустим, что для всех сервисов она одинаковая. (В реальности может быть иначе.) В качестве значений шкалы выберем следующие:
А — значение больше 0;
B — значение больше 10;
С — значение больше 100;
D — значение больше 300.
Посмотрим на распределение оценок нашей метрики:
Выводы по распределению оценок метрики
У большей части сервисов нет проблем с избыточным количеством error-логов.
Для 4% сервисов нужно рассмотреть дополнительные метрики. Возможно, в работе этих сервисов были проблемы.
Ещё 8% сервисов требуют уделить пристальное внимание логированию. Вероятно, был выбран некорректный уровень логирования.
Теперь посмотрим результаты error-логов по командам.
У нас в отделе за каждой командой закреплены свои сервисы, есть чёткое разделение зон ответственности. На графике представлены только шесть команд — я подобрала их таким образом, чтобы у всех было сопоставимое количество сервисов в зоне ответственности. Так можно увидеть, насколько разная у нас картина по всем командам.
Выводы по оценке метрики в командах
У Команды 2 нет выраженных проблем с error-логами.
У Команд 3, 4 и 6 есть проблемы, связанные с error-логами.
Для Команд 1 и 5 нужно рассмотреть динамику изменений показателя. Возможно, был какой-то релиз, который всё испортил, или есть другие проблемы.
Как посмотреть динамику изменений показателя за определённый промежуток времени
Это изменение оценки метрики по error-логам за три недели сентября (за исключением выходных дней):
Мы собираем статистику по одной и той же команде и по всем её сервисам за каждый день. Эту статистику отображаем на графике.
Вывод по изменению метрики в одной команде
Несмотря на рост оценок А, команде нужна дополнительная работа с error-логами, так как в среднем значение показателя здоровья не улучшается. Что-то меняется, но в целом лучше не становится.
Оцениваем здоровье сервисов
Общее здоровье сервиса вычисляем как среднее арифметическое от всех производимых проверок. Оцениваем здоровье по четырёхбалльной шкале, где A — 4, B — 3, C — 2, а D — 1.
Пример оценки здоровья сервисов
Можно увидеть, что у Сервиса 4 со здоровьем всё в порядке, а у Сервиса 1 оценка ближе к уровню B, хотя всё ещё находится в диапазоне уровня А.
Теперь посмотрим на результаты оценки здоровья сервисов по всему отделу бэкенд-разработки.
На графике нет сервисов с оценкой D, потому что мы исправили критические проблемы. Но у нас всё ещё есть небольшой процент сервисов с оценкой C, и с этим нужно работать.
Выводы по результатам оценки здоровья
У большей части сервисов нет проблем со здоровьем.
У 6% сервисов есть выраженные проблемы, надо поработать над улучшением здоровья.
Сервисов, чьё здоровье требует срочного вмешательства, сейчас нет.
Теперь рассмотрим результаты оценки здоровья сервисов по командам.
Выводы по этому графику такие:
Команды 2 и 6 не имеют выраженных проблем со здоровьем сервисов.
У Команд 1, 3 и 5 много оценок B, нужно пристально наблюдать за динамикой.
У Команды 4 много низких оценок здоровья, нужно обязательно разобраться в причинах.
Несмотря на хорошую общую картину по отделу и большое количество высоких оценок, при общей оценке сервисов это не значит, что внутри команд вообще нет проблем. Есть смысл рассматривать отдельные случаи по командам.
Теперь посмотрим на изменение оценки здоровья за сентябрь на примере одной команды:
Видно, что в начале месяца у нас было несколько низких оценок (уровень D), но к середине они пропали.
Выводы по изменению оценки здоровья
Если смотреть оценку вне динамики, то можно увидеть много сервисов с оценкой С. Зато в динамике видно, как растёт количество сервисов с высокими оценками, а команды становятся лучше.
Важный фактор оценки — команды видят конкретные проблемы в своих сервисах. Это не абстрактный бэклог или техдолг, а конкретные проблемы, которые оцениваются на регулярной основе. Когда вы видите свою оценку относительно других команд, у вас появляется мотивация её улучшать, ставить себе задачи. Люди в команде заинтересованы, чтобы их сервисы были здоровыми.
Подведём итоги
Оценка здоровья расширяет привычную оценку качества и позволяет посмотреть с другой стороны на проблему технического долга, работу с командами и планирование.
Оценка здоровья помогает принимать более обоснованные решения и оценивать работу по улучшению сервисов в условиях большого количества разработчиков, команд и взаимодействий в них. В итоге продукт становится лучше.
В следующей статье мы расскажем, как мониторим здоровье компонент во фронтенде.
А пока пишите в комментариях, как вы отслеживаете проблемы внутри команд и какой инструмент для этого используете.