Краткий справочник по Non-functional Requirement.
Перед разработкой архитектуры системы или на ранней стадии ее проектирования,
всегда следует уделять внимание так называемым нефункциональным показателям (Non-functional QoS). Они определяют характеристики, которые не связаны с конкретным поведением системы, но при этом задают требования с точки зрения бизнеса.
Как и для любых показателей, которые определяются на этапе проектирования, кроме желаемых характеристик, следует также, в первую очередь, выявить их минимально допустимые значения. Например, если система будет доступна в рабочем состоянии меньше 100 часов в неделю (Availability = 100/168 ~ 59.52%), то такая система для бизнеса будет не интересна (убыточна, не приносить никакой пользы). Зачем это нужно?
Дело в том, что далеко не все базы данных, сервера приложений или технологические платформы могут обеспечить необходимые показатели доступности (availability), масштабируемости, надежности и т.д.. Выбор тех или иных решений должен зависеть от этих характеристик.
Краткий список нефункциональных показатели системы (Non-functional QoS):
Scalabitlity – Масштабируемость. Возможность увеличивать производительность системы пропорционально выделенным ресурсам. Бывает горизонтальная и вертикальная. Вертикальная – докупаем более быструю память, более шустрый жесткий диск или переносим всё на один еще более мощный сервер. Горизонтальная – покупаем еще один сервер и запускаем приложения в кластерном режиме, в случае необходимости – докупаем еще один сервер и втыкаем к двум уже работающим и так далее.
Extensibility – Расширяемость. Возможность добавление дополнительного функционала.
Flexibility – Гибкость. Возможность менять существующую архитектуру (например в зависимости от ценовой политики). В отличие от Extensibility, речь идет только об изменениях без дополнительного функционала. Например у заказчика нет денег на нормальную СУБД (допустим ORACLE). Наша задача сделать систему настолько гибкой, чтобы в случае необходимости мы смогли её подпилить так, чтобы она смогла бы обойтись чем-нибудь бесплатным (MySQL или PostgreSQL).
Насколько должна уметь прогибаться система, желательно, по мере возможности, определить по-раньше…
Maintainablity – Поддерживаемость, ремонтопригодность. Способность поддерживать систему в работоспособном состоянии. Показатель определяет насколько легко (или сложно) вносить исправления в работающую систему, возможно ли повторное развертывание и запуск системы после сбоя, возможность восстановить из резервных хранилищ и т.д.
Availability – коэффициент доступности(готовности). Процент времени проведенного системой в работоспособном состоянии к общему времени работы системы.
часто высоко доступные (High Availability) системы меряются девятками:
- 99,9 % (три девятки) = система недоступна не более 8,76 часов/год
- 99,99 % (четыре девятки)= не более 52,6 минуты/год
- 99,999 % (пять девяток) = не более 5,26 минуты/год
Manageability – управляемость. Возможность отслеживать и предотвращать возможные сбои в системе. Это в первую очередь наличие логирование (журналирование), системы оповещения о сбоях, возможность предотвратить возникновения ошибки.
Reliability – надежность. Вероятность безошибочного выполнения операций в определенный период времени в определенном окружении.