Forwarded from mtsepkov (Maxim Tsepkov)
#lafest Евгений Скориков. Нефункциональные требования? Модели обеспечения качества! Очень хороший доклад, о том, что нефункциональные требования в их привычном виде "отказоустойчивость 99.5%" или "отклик системы 5 секунд" - совершенно бесполезная вещь: непонятна осмысленность, способы удовлетворения и тестирования и риски. 99.5% - это 0.5% сбоев, если система не работает в год 1.5 суток подряд - это как, нормально? Для многих - ненормально, хотя в норматив формально укладывается. В общем, эта критика - понятная, эти требования часто берут произвольно. Например, по производительности, кстати, нет достоверных исследований: как именно скорость работы сайта влияет на бизнес. Понятно, что если ваш сайт жутко тормозит, и есть сайт конкурента, который делает все тоже самое и быстро, то люди уйдут туда. Но в реальной жизни сайт конкурента делает НЕ тоже самое, там есть чего-то меньше и чего-то больше, у него есть другая эргономика. И как это влияет? Исследований нет. Честное исследование - замедлить сайт для части клиентов и сравнить, но на это ни один бизнес не пойдет.
Гораздо интереснее, что в докладе был рассказ, чем их следует заменять, чтобы это имело смысл и реально работало. С практическими примерами, которые в интерактиве обсуждали с аудиторией. Общая схема такова.
1) Берем аспекты работы с системами: отказоустойчивость, производительность, масштабируемость, эргономичность интерфейса и другие.
2) Для каждого аспекта есть специфические проблемы, и мы декомпозируем систему с точки зрения этих проблем. Например, для отказоустойчисовти смотрим на отказы базы данных, серверов приложений, сетевой инфраструктуры, клиентских приложений. Для производительности - деградацию на выполнении различных функций. И так далее.
3) Выписываем возможные проблемы в каждой части, оцениваем их значимость: если это случится - каковы последствия, потери для бизнеса.
4) Для проблем - есть специфические тактики предотвращения, которые снижают ущерб и имеют определенную стоимость. Выбираем тактики и проектируем варианты решения.
5) Выбор решения - по балансу потерь против стоимости.
6) Проектируем тест выбранного решения.
Например, если мы рассматриваем физический отказ базы данных, то есть тактика резервирования с вариантами: холодный бэкап, горячий резерв и катастрофоустойчивость с быстрым переключением, для каждого вое время восстановления после сбоя и своя стоимость в виде дополнительных серверов, дисков и так далее. И мы выбираем из баланса времени восстановления и стоимости резервирования. А для проблемы отказа по исчерпанию дисков тактикой может быть мониторинг с аллертами и людьми, которые своевременно на эти алерты прореагируют, и это тоже имеет стоимость. И так далее. И эти решения можно протестировать: проверить, что из бэкапа база восстановится за предполагаемые сроки, что мониторинг действительно даст алерт в нужной ситуации и на него смогут прореагировать.
Это - тестируемо.
В поиске решения - большое поле работы аналитика, не разработчика. Так как многие проблемы имеют бизнес-последствия, сценарии надо согласовывать с бизнесом. Решения часто частичные, например, если приложение выдает QR-код для показа на кассе, то именно для него хорошо бы применить паттерн автономной работы с периодическим обновлением - чтобы если сеть затупила в тот момент, когда покупатель выбивает чек, не создавалась очередь других покупателей. А вот все остальное может работать только при приемлемой сети - за счет этого можно использовать шаблон тонкого клиента, обновляя преимущественно серверную часть. Отметим, что способ преодоления в этом случае, как и во многих других, необходимо заложить в архитектуру решения. И, возможно, обсудить с бизнесом.
Гораздо интереснее, что в докладе был рассказ, чем их следует заменять, чтобы это имело смысл и реально работало. С практическими примерами, которые в интерактиве обсуждали с аудиторией. Общая схема такова.
1) Берем аспекты работы с системами: отказоустойчивость, производительность, масштабируемость, эргономичность интерфейса и другие.
2) Для каждого аспекта есть специфические проблемы, и мы декомпозируем систему с точки зрения этих проблем. Например, для отказоустойчисовти смотрим на отказы базы данных, серверов приложений, сетевой инфраструктуры, клиентских приложений. Для производительности - деградацию на выполнении различных функций. И так далее.
3) Выписываем возможные проблемы в каждой части, оцениваем их значимость: если это случится - каковы последствия, потери для бизнеса.
4) Для проблем - есть специфические тактики предотвращения, которые снижают ущерб и имеют определенную стоимость. Выбираем тактики и проектируем варианты решения.
5) Выбор решения - по балансу потерь против стоимости.
6) Проектируем тест выбранного решения.
Например, если мы рассматриваем физический отказ базы данных, то есть тактика резервирования с вариантами: холодный бэкап, горячий резерв и катастрофоустойчивость с быстрым переключением, для каждого вое время восстановления после сбоя и своя стоимость в виде дополнительных серверов, дисков и так далее. И мы выбираем из баланса времени восстановления и стоимости резервирования. А для проблемы отказа по исчерпанию дисков тактикой может быть мониторинг с аллертами и людьми, которые своевременно на эти алерты прореагируют, и это тоже имеет стоимость. И так далее. И эти решения можно протестировать: проверить, что из бэкапа база восстановится за предполагаемые сроки, что мониторинг действительно даст алерт в нужной ситуации и на него смогут прореагировать.
Это - тестируемо.
В поиске решения - большое поле работы аналитика, не разработчика. Так как многие проблемы имеют бизнес-последствия, сценарии надо согласовывать с бизнесом. Решения часто частичные, например, если приложение выдает QR-код для показа на кассе, то именно для него хорошо бы применить паттерн автономной работы с периодическим обновлением - чтобы если сеть затупила в тот момент, когда покупатель выбивает чек, не создавалась очередь других покупателей. А вот все остальное может работать только при приемлемой сети - за счет этого можно использовать шаблон тонкого клиента, обновляя преимущественно серверную часть. Отметим, что способ преодоления в этом случае, как и во многих других, необходимо заложить в архитектуру решения. И, возможно, обсудить с бизнесом.