Краткий справочник по Non-functional QoS
Внимание! Я перенес свой блог. Дальнейшее редактирование и обсуждение этой статьи будет осуществляться по адресу programador.ru
Перед разработкой архитектуры системы или на ранней стадии ее проектирования,
всегда следует уделять внимание так называемым нефункциональным показателям (Non-functional QoS). Они определяют характеристики, которые не связаны с конкретным поведением системы, но при этом задают требования с точки зрения бизнеса.
Как и для любых показателей, которые определяются на этапе проектирования, кроме желаемых характеристик, следует также, в первую очередь, выявить их минимально допустимые значения. Например, если система будет доступна в рабочем состоянии меньше 100 часов в неделю (Availability = 100/168 ~ 59.52%), то такая система для бизнеса будет не интересна (убыточна, не приносить никакой пользы). Зачем это нужно?
Дело в том, что далеко не все базы данных, сервера приложений или технологические платформы могут обеспечить необходимые показатели доступности (availability), масштабируемости, надежности и т.д.. Выбор тех или иных решений должен зависеть от этих характеристик.
Краткий список нефункциональных показатели системы (Non-functional QoS):
Scalabitlity - Масштабируемость. Возможность увеличивать производительность системы пропорционально выделенным ресурсам. Бывает горизонтальная и вертикальная. Вертикальная - докупаем более быструю память, более шустрый жесткий диск или переносим всё на один еще более мощный сервер. Горизонтальная - покупаем еще один сервер и запускаем приложения в кластерном режиме, в случае необходимости - докупаем еще один сервер и втыкаем к двум уже работающим и так далее.
Extensibility - Расширяемость. Возможность добавление дополнительного функционала.
Flexibility - Гибкость. Возможность менять существующую архитектуру (например в зависимости от ценовой политики). В отличие от Extensibility, речь идет только об изменениях без дополнительного функционала. Например у заказчика нет денег на нормальную СУБД (допустим ORACLE). Наша задача сделать систему настолько гибкой, чтобы в случае необходимости мы смогли её подпилить так, чтобы она смогла бы обойтись чем-нибудь бесплатным (MySQL или PostgreSQL).
Насколько должна уметь прогибаться система, желательно, по мере возможности, определить по-раньше...
Maintainablity - Поддерживаемость, ремонтопригодность. Способность поддерживать систему в работоспособном состоянии. Показатель определяет насколько легко (или сложно) вносить исправления в работающую систему, возможно ли повторное развертывание и запуск системы после сбоя, возможность восстановить из резервных хранилищ и т.д.
Availability - коэффициент доступности(готовности). Процент времени проведенного системой в работоспособном состоянии к общему времени работы системы.
часто высоко доступные (High Availability) системы меряются девятками:
Reliability - надежность. Вероятность без ошибочного выполнения операций в определенный период времени в определенном окружении.
Внимание! Я перенес свой блог. Дальнейшее редактирование и обсуждение этой статьи будет осуществляться по адресу programador.ru
Перед разработкой архитектуры системы или на ранней стадии ее проектирования,
всегда следует уделять внимание так называемым нефункциональным показателям (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 минуты/год
Reliability - надежность. Вероятность без ошибочного выполнения операций в определенный период времени в определенном окружении.
Комментариев нет:
Отправить комментарий