Как должна работать система

Задача

  • Определять ограничения создаваемой системы

  • Определять размер и стоимость системы на ранних этапах проектирования

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

Пример

Соответствие системы федеральному закону

Виды нефункциональных требований

  • Защищенность – Хранится или передается в рамках системы конфиденциальная информация?

  • Вместимость - Как ваша система будет масштабироваться в соответствии с растущими требованиями к объему?

  • Совместимость - На каком оборудовании, каких операционные системы/браузеры и их версии должны поддерживаться?

  • Надежность и доступность - Какое критическое время отказа при нормальном использовании?

  • Управляемость и удобство обслуживания - Сколько времени уходит на изменение компонентов и насколько легко можно управлять системой?

  • Масштабируемость – Какие ожидаются самые высокие рабочие нагрузки, при которых система по-прежнему будет работать должным образом?

  • Удобство использования - Насколько легко использовать продукт?

  • Производительность - Насколько быстро система реагирует на действия пользователей или как долго пользователь ожидает выполнения определенной операции?

  • Нормативно-правовые требования - Существуют ли требования, которые необходимо выполнить для соответствия требованиям?

Есть явные и неявные

Сценарий качества (шаблон)

  • Стимул: что происходит (нагрузка, отказ, рост данных).

  • Контекст: состояние системы/окружения.

  • Ожидаемое поведение: как система должна реагировать/деградировать.

  • Метрика: чем измеряем (p95 latency, ошибка в %, RTO/RPO, аптайм) и при каком пороге нагрузки.

  • Условия проверки: стенд/инструменты/допущения.

Метрики

  • SLA SLO SLI

  • SLI — измерение (например, p95 300 мс на RPS 100; ошибка < 0.1% за 5 мин).

  • SLO — цель для SLI (p95 ≤ 300 мс, аптайм ≥ 99.9% в месяц).

  • SLA — контрактные обязательства и штрафы; обычно строже формулируются на базе SLO.

Валидация

  • Ревью архитектуры и решений против НФТ (кэш, очереди, репликации).

  • Нагрузочные/стресс/chaos-тесты под оговорённой нагрузкой и отказами.

  • Проверка деградации: таймауты, ретраи, circuit breaker, очереди.

  • Мониторинг: метрики/логи/трейсы; оповещения на выход за SLO.

Трассировка

  • Требование → архитектурное решение (ADR) → реализация → тест/мониторинг.

  • Для каждой метрики: источник данных, период сбора, ответственный за реакцию.

  • Приёмка по НФТ: контрольные сценарии качества + проверка оповещений.

Последнее обновление