Качество компьютерных систем: характеристики и метрики

Качество — это не только отсутствие ошибок

Представьте сервис электронного журнала колледжа «Кампус». В нём студент просматривает оценки, преподаватель выставляет результаты, а администратор создаёт учётные записи. Сегодня вход работает, но загрузка страницы занимает 25 секунд; завтра сервис быстро открывается, однако показывает чужие оценки. В обоих случаях система неудовлетворительна, хотя причина совершенно разная.

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

Характеристики качества по ISO/IEC 25010

В стандарте ISO/IEC 25010:2023 модель качества продукта содержит девять характеристик. Для начального курса полезно связывать каждую не с абстрактным названием, а с конкретным риском для «Кампуса». Стандарт используется как ориентир, а не как обещание, что все характеристики можно измерить одним числом.

Требование: измеримое или расплывчатое?

Фраза «сайт должен работать быстро» не позволяет проверить результат однозначно. Одному пользователю достаточно 5 секунд, другой считает долгим ожидание более секунды. Поэтому требование формулируют с операцией, условиями, измерением, порогом и способом проверки.

Критерий приёмки описывает наблюдаемый результат проверки. Требования должны быть реалистичны: способ измерения и границы ответственности согласуются заранее. Например, задержка ответа сервера и полная загрузка страницы в браузере — не одно и то же.

SLI, SLO, SLA: как не путать три понятия

SLI — измеряемый индикатор (например, доля успешных запросов). SLO — выбранная цель для индикатора (например, не менее 99,9% за 30 дней). SLA — договорное обязательство, которое может включать условия и последствия невыполнения. SLO автоматически не превращается в SLA.

Доступность и бюджет недоступности

Для учебных расчётов по времени используем формулу: доступность = (плановое время наблюдения − недоступность) / плановое время × 100%. Такой расчёт применим, если договорились измерять именно временную доступность. Другой SLI может считать долю успешных запросов, и итог будет другим.

Как собирать доказательства качества

Метрика полезна только при понятном источнике данных. Для производительности снимают распределение задержек, для доступности — результаты синтетических или пользовательских запросов, для защиты данных — результаты проверки ролей, для восстановления — реальные испытания резервных копий.

Почему среднее время ответа может обманывать

Из 100 запросов 95 могли завершиться за 100 мс, а пять — за 10 секунд. Среднее около 595 мс скрывает проблему для «медленной» части аудитории. p95 помогает оценивать хвост распределения, но трактовка зависит от способа расчёта. Точность сбора и период наблюдения необходимо фиксировать.

Бюджет ошибок: как качество влияет на темп изменений

Допустим, «Кампус» обещает SLO 99,9% успешных запросов за 30 дней. Бюджет ошибок равен 0,1% запросов в том же окне. Если за период поступил миллион подходящих запросов, в бюджете условно допускается до 1000 неуспешных. Если выбрать временной SLI, бюджет будет выражен минутами, а не запросами. Нельзя смешивать эти модели в одном расчёте.

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

Как выбирать измерения и не искажать выводы

Сильная метрика имеет чёткий числитель, знаменатель, интервал и источник. Для успешности запросов потребуется договориться, какие HTTP-коды считаются успехом, включать ли сетевые тайм-ауты и считать ли ошибки, вызванные самим клиентом. Например, не все ответы 4xx — дефекты системы: пользователь мог запросить несуществующую страницу.

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

Типичная ошибка

Сервис обработал 950 успешных запросов из 1000. Доля успеха равна 95%. Не следует писать «доступность 95% за месяц», если эти запросы пришли лишь в течение пяти минут: измерена выборка запросов, а не весь месяц работы.

Матрица требований и приоритизация проверок

Прослеживаемость связывает требование с тестами, метриками, дефектами и принятым решением. Без неё команда может пройти сотню тестов и не заметить, что самое опасное требование никто не проверял. Для учебного проекта достаточно небольшого реестра: идентификатор, формулировка, способ проверки, критерий и ответственный.

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

Практика: паспорт качества системы «Кампус»

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