Как мы используем статистический анализ для контроля качества ПО

У каждого продукта есть жизненный цикл, который определяет интенсивность его развития и уровень качества. Классический цикл разработки программного обеспечения включает в себя постановку задачи, разработку, тестирование и деплой. QA-специалист, в определении профессии которого и заложено обеспечение качества, принимает участие в каждом из этих этапов.

В нашей практике есть класс «долгоживущих» проектов, на примере которых мы будем рассматривать статистический анализ (Прим. – не путать со статическим анализом кода). Это набор методов и подходов, позволяющий детектировать аномальные ситуации во всей системе. Статанализ можно применять и на обычных проектах, чтобы улучшить процесс обеспечения качества. Но эффективнее всего он подходит для долгосрочных проектов и для проектов с большим количеством интеграций.

Аспекты, затронутые в этой статье, будет полезно знать как членам команды разработки, так и владельцам продукта. Особенно это актуально, если планирование развития системы расписано более чем на 2-3 года. При этом она интегрируется с большим количеством других подсистем, которые могут вносить в нее изменения. Владельцу продукта важно понимать, не противоречат ли эти изменения его ожиданиям, оперативно выявлять такие моменты и быстро решать возникающие проблемы. Как показывает наша практика, де-факто мы всегда будем сталкиваться с изменениями, связанными с поведением пользователей или системы.

Говоря о качестве ИТ-продукта, стоит вспомнить, какой смысл заложен в этом определении. По сути, качество – гарантия того, что система будет четко работать на протяжении длительного времени, даже при периодических изменениях. Другими словами, это предсказуемость, стабильность и соответствие ожиданиям команды, клиента и пользователей. Разберем на примере.

Перед тем, как привести пример, сразу отметим, что нам досталась унаследованная система, которая передавалась между различными подрядчиками в течение 4 лет и только потом попала к нам. В процессе всех этих передач документирование было потеряно. Мы изучали систему и параллельно восстанавливали бизнес-правила. А теперь ближе к делу.

Наша компания работает с одним медицинским учреждением, в которое входит около 40 различных госпиталей и 15 различных интеграционных систем. При этом у каждого из них есть своя независимая IT-служба, которая предоставляет «железо» для нашего программного комплекса. Часть мощностей держит клиент и сам отвечает за них. За 8 лет работы на проекте было много случаев, когда в каком-то из учреждений меняли оборудование, интеграционную систему и прочее, не предупредив нас. Такие случаи оказывают влияние на поведение всей системы. При этом система организованно работает уже более 8 лет, несмотря на то, что кто-нибудь вносит в нее те или иные изменения.

Как говорит архитектор данного проекта Алексей, «написать систему, которая работает, легко. Написать систему, которая работает правильно, чуть сложнее. Написать систему, которая будет работать правильно 5 и более лет, сложно». Поэтому, работая на крупных и долгосрочных проектах, мы говорим о том, что важно контролировать соответствие реальности и ожиданий. В этом нам помогает статистический контроль качества.

С чего начать:

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

Рассмотрим на примере. Предположим, пациент должен получить результаты анализов, для примера на почту. Обычное дело. Но тут можно столкнуться и с другими ситуациями, например, когда результаты получают доверенные лица, опекуны. Поэтому при разработке системы нужно учесть, чтобы администратор при создании нового пациента мог добавлять иные категории лиц, которым разрешено получать результаты анализов. Если это не сделать, клиника будет работать с категорией граждан от 18 до 60 лет, что примерно составляет 92% от общего числа работоспособного населения, а остальные 8% были бы упущены.

С течением времени в любой системе накапливаются данные. Это может привести к ее деградации. Не допустить этого может карта мониторинга. В нашем проекте она представляет собой совокупность ожиданий всех членов команды о поведении системы на боевом сервере, которые заложены в специальную подсистему. Эта подсистема была разработана архитектором данного проекта. Примеры будут представлены ниже в статье.

Рассмотрим на примере. У одной из наших систем было определенное количество пользователей: одни сотрудники уходили, другие приходили. Со временем их число стало расти, но было не особо заметно – система продолжала работать без проблем в течение четырех лет. Но на пятый год объем передаваемых данных вырос до критических значений для доступной памяти системы. И в какой-то момент на клиенте начала заканчиваться память при обработке этих данных. В результате стабильно работающая система стала «падать» из-за объема накопленных данных. Со временем мы внедрили карту мониторинга, которая помогает нам оперативно решать проблемы, возникающие в этой части системы.

При работе с системой у доктора есть возможность внести записи на диктофон, чтобы потом внести данные в историю болезни пациента. Одна из частей нашей системы – API для обработки этих аудиофайлов. При этом API должен вызываться каждый час, а аудиофайл не должен быть пустой. Логику API подробнее описывали тут.

Случай 1. У нас есть API, который должен вызывать клиент в течение каждого часа, поскольку имеется постоянный поток работ. В связи с чем в системе определено правило: «вызов в течение каждого часа». Когда вызов не приходил, проблема фиксировалась на карте мониторинга, клиент получал информацию. Всё это помогало быстро исправить ситуацию. Такая ситуация возникала 3 раза за последние 5 лет.

Случай 2. Система обрабатывала аудиофайлы со следующим требованием: «файл не должен = 0 Мб». Всё работало стабильно. Но внезапно алерт стал срабатывать, что приходят аудиофайлы = 0 Мб. Оказалось, что пользователь загрузил новый аудио формат, который не был предусмотрен изначально. Этот аудио формат появился из-за нового типа выпуска устройств для докторов. В итоге мы его добавили и без проблем обрабатываем этот тип аудиоформата.

На старте разработки технического задания (далее – ТЗ) важно определить, какие ключевые характеристики и бизнес-показатели нужно отслеживать в приложении. А также учесть области для аналитики: ожидания пользователей, поведение пользователей, бизнес-ожидания от программы. Например:

В зависимости от наличия требований к системе карта мониторинга может делиться на 2 кейса.

Ситуация 1. Требований к продукту нет или они не определены.

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

Анализируя доступные данные, мы определим, какие ожидания имеют представители разных ролей (клиент, QA, разработчик, аналитик и др.):

Эти моменты нужно добавить в карту мониторинга, и после этого они будут контролироваться на боевом сервере.

Ситуация 2. Все требования к системе есть (идеальный вариант).

Важно понимать, что при распределении значений мы не можем взять 100%, т.к. это реальная система и на больших интервалах времени будут происходить непредвиденные события. Для примера распределением значений может быть распределение времени выполнения функции API.

Поэтому мы вдохновились идеей “6 сигм” и стали брать 99,99%. Например, в одной из наших интеграционных систем, согласно требованиям SLA не менее 99,5% операций должны быть завершены успешно. И мы знаем, что 0,5% может не обработаться из-за специфического формата файла, документа и прочего. При этом у нас есть внутренний SLA, который регулярно мониторится и равен 99,8%. И как только показатели опускаются до этого значения, у нас появляется алерта и мы проводим проверку на боевом сервере, выясняем причину. В таком положении SLA клиента не нарушен.

100% кейсов никогда не будет выполнено, если у системы есть пользователи и хотя бы одна из внешних интеграционных систем. На то, какого уровня SLA реалистично достигнуть, влияет тип распределения системы. В мире есть много распределений: экспоненциальное, обратно экспоненциальное, нормальное. Мы рассмотрим пример нормального распределения, когда у нас есть определенные числовые показатели требования: верхний и нижний пределы, а также среднее значение.

Как всё это проверить? Перевернем график на 90* и получим нашу карту мониторинга:

Оставив верхний и нижний предел, получим более привычный для нас график. На нем видно, что есть отклонения. Их нужно исследовать и понять, почему они такие большие. Исправляя «большое зло», мы будем уменьшать разброс данных и, как следствие, повышать качество системы. В зависимости от того, какое распределение большое (пологое) или нормальное (более острое), качество будет ниже или выше.

В центре – самое популярное среднее значение. Нам нужно обратить внимание на верхнюю и нижнюю границу, какие значения вышли за ее пределы. Назовем это «неожиданное поведение системы» или баг. Далее путем анализа нужно выявить причину такого поведения и наметить план его исправления.

Например, у нас есть время вызова функции, которая измеряется в карте мониторинга. Каждый день мы строим распределения времени её выполнения (см. график ниже): от 0 до 50 мс – 20 вызовов функций, от 50 до 100 мс – 1 вызов функции, от 2500 и более – по 1 вызову функции. Как видно, у нас имеются 2 распределения с существенной разницей вызова, это говорит об ошибке.

Для решения этой ситуации мы убрали одну внешнюю библиотеку, а затем реализовали необходимый функционал без использования данной библиотеки. В результате «пологое распределение» (2500 мс и более) ушло, что привело к улучшению системы – в данном случае за счет уменьшения максимального времени выполнения функций.

Если в ТЗ не было прописано ожиданий к границам, их следует сформулировать самостоятельно. После исправления провести перерасчет границ. Их заметное сужение будет говорить о том, что качество данных улучшается.

Из опыта работы с APi мы также можем проанализировать:

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

Мы все задумываемся о том, что нужно выкатить на прод и как будет работать система через 5, 8 лет, когда сменится команда и, возможно, интеграционные системы. Но мало кто вшивает в саму систему контроль качества, чтобы она сама детектировала отклонения от ожиданий. Было бы хорошо иметь элемент жизненного цикла разработки, который добавляет точки в карту мониторинга и придает уверенность, что в будущем у нас не будет проблем. И система начинает работать 3 года, 6, 8 и более лет.

Например, за годы работы описанной выше медицинской системы происходило расширение API, добавление новых функций, интеграция клиентов с одной версии API, и долгое время принимаемых мер было достаточно. Но по прошествии трех лет клиент обращался к нам снова, чтобы обновить систему из-за добавления новых функций, происходил переход на новую версию API. В свою очередь, API должна обеспечить обратную совместимость. При этом в карте мониторинга при вызове функции логировалось не только время её выполнения, но и название. Данные собирались в течение 3 месяцев, и после анализа мы выявили, что около 24 функций не используется. Тем самым, мы убрали разрастание системы, оставив только рабочие функции.

После анализа карты мониторинга можно понять, работает ли система так, как мы ожидали, и будет ли все ли хорошо работать в будущем. Как правило, со временем система начинает постепенно деградировать (например, из-за накопленных данных, о чем мы приводили пример выше). И тут возникают сопутствующие вопросы, как отследить деградацию системы и проверить, что качество не ухудшается от версии к версии?

В гибких методологиях, которые мы используем на своих проектах, весь процесс разработки разбит на спринты, которые заканчиваются деплоем, и далее стартует новый этап. После деплоя всегда полезно проводить анализ на боевом сервере, понять, что:

Такой анализ помогает понять, насколько успешно мы движемся к реализации продукта, есть ли проблемные места на боевом сервере и, как следствие, в проекте. Поэтому в классический жизненный цикл разработки программного обеспечения мы добавляем систему мониторинга. Обновленный цикл с системой статистического контроля на проде, выглядит следующим образом:

Разработка правил мониторинга может входить в жизненный цикл. В этом случае команда не только создает фичу, но и уточняет, в каких местах и с каким ожиданием нужно мониторить показатели. Представим, что есть:

Вдруг в таблице с дополнительной информацией Users_Info появилось 4500 записей, хотя на каждого пользователя по логике должна быть одна запись. Добавляем data retention (правила очистки данных) и получаем около 1500 записей. Проблема задетектирована и исправлена до того, как она стала заметной для пользователей. После этого случая в нашу карту мониторинга мы добавили отчет в MS SQL по количеству строк в каждой таблице с частотой проверки – 1 раз в месяц.

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

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

И еще один положительный момент - если по каким-либо причинам специалист переходит на другой проект, то карта мониторинга все равно продолжает контролировать систему.

В завершение предлагаем несколько шагов, которые позволят лучше понимать реальное положения дел на проде:

Надеемся, статья была вам полезна! Больше кейсов о работе наших коллег, можете прочитать тут.