Чего я не нашёл в ТРИЗ

ТРИЗ очень интересная теория. На практике активно применяю алгоритм АРИЗ, и честно говоря, доволен результатом.

Суть алгоритма можно выразить простой последовательностью (см. АРИЗ-77):
АП → ТП → ИКР → ФП → Р
где
- АП - административное противоречие
чего хочет стейкхолдер: требование, user story
- ТП - техническое противоречие
что мешает получить желаемое: технические ограничения, другие требования, принципы
- ИКР - идеальный конечный результат
как можно было бы решить проблему не имея ограничений, например обладая неограниченными ресурсами.
- ФП - физическое противоречие
какой элемент системы является причиной противоречия, например должен выполнять несовместимые функции
- Р - решение
некоторые, считают, что доведя задачу до осознания физических противоречий решение приходит само )

Более подробно расписывал этот процесс на ArchDays
И все казалось бы понятно, но ...

Где тут архитектурные задачи?!

Вместо административного противоречия
("я как ... хочу ... для того чтобы ...")
имеем риск
("при условии ... может случиться ... что приведёт к .... ")

Архитектор именно тот, кто выявляет риски и драйвит задачи по их смягчению.

Возможно ли административные противоречия обобщить на риски?
То есть к понятному "хочу чтобы всегда" добавить "хочу чтобы никогда"

Задумался 🤔

Долгая жизнь проекта
- Часть 1. Проблема

Все проходит.

На картинке жизненный цикл всего, так называемая S-кривая.

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

Отсюда глобальная цель архитектора - вытянуть S-ку, продлить жизнь продукту.

В чём проблема?

В каждом продукте есть решения, которые не возможно или очень сложно переиграть.
Фактически эти решения представляют собой закрытую (от модификации) систему, которая в силу объективных законов склонна к саморазрушению (2НТ).

Это как запрограммировать автомобильчик на долгую дорогу от Москвы до Владивостока и запустить его в путь. Чем больше изменений и не предсказанных событий - тем призрачнее шанс добраться до пункта назначения.

В архитектуре это выглядит примерно так:
Полгода разрабатывали продукт, вышли в прод. а там нагрузка. Требуется 40 инстансов PostgreSQL в режиме master-master. Переписываем.

Естественно, архитектор, используя опыт и знания может предсказать многие проблемы и заложить максимальную живучесть.
Предсказать и предвидеть всего архитектор не сумеет. Продукт рано или поздно умрёт.

Хотя есть альтернативное мнение )

Выступление с ArchDays добралось до ютюба )

Изобретение архитектурного решения

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

В докладе рассматриваются популярные методы принятия архитектурных решений с привязкой к теории решения изобретательских задач (ТРИЗ).

Пытаемся вместе ответить на вопросы:
— Правильно ли мы ставим архитектурные задачи?
— Достаточно ли знания паттернов и архитектурных тактик для решения сложных задач?
— Каковы ограничения выбора решения из множества вариантов?
— Является ли выбор варианта единственным доступным методом проектирования?
— Существует ли алгоритм, позволяющий выйти на оптимальное решение?

Смотреть: https://youtu.be/tmoOTqPgbFM

Долгая жизнь проекта
- Часть 2. Панацея
Первая часть - https://news.1rj.ru/str/rect_arrow/148

Как можно продлить жизнь проекта?
Очевидное решение - сократить число неподдающихся пересмотру решений (до нуля).

Машинка, из предыдущего поста, проехав метров сто останавливается, сообщает ситуацию и может быть полностью перепрошита.

В архитектуре это:
Разбить систему на кучу маленьких независимых сервисов, каждый из которых может быть полностью переписан в две недели.

Архитектура как набор неизменяемых решений больше не нужна!

Долгая жизнь проекта
- Часть 3. Отрезвление

Озвученная в предыдущем посте идея - это основная идея так называемой эволюционной архитектуры от Нила Форда и к.

Разбиваем продукт на микросервисы. Так как каждый переписывается легко, можем дальше двигаться методом проб и ошибок.
Нет ничего, что мы не могли по быстрому переписать!

Но точно ли так?

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

Разбиение на сервисы становится тем решением, которое сложно, или невозможно изменить.

И даже если вы достаточно удачно провели декомпозицию на старте проекта,
изменение условий может привести к тому, что изначальное, грамотное разделение окажется неадекватным.

Увы, MSA не панацея.
Вечная жизнь проекту не грозит (

Все проходит.

Активаторы (Enablers)

Как вводить архитектурные задачи в бэклог?

Популярный фреймворк (каркас) SAFe предлагает особый вид задач, называемых Enablers (Активаторы).
Точнее, Architectural enablers - инструменты архитектуры.

По описанию Enabler - это активность, позволяющая реализовать определённую функцию, поддерживающую бизнес-функции.

Все бы хорошо, но, обосновывая архитектурные задачи, я часто иду от рисков.

Если я скажу, что эта активность добавит нам доступности (99.99) под функцию получения списков, то буду звучать неубедительно.

Если я скажу, что если мы НЕ выполним эту активность, то не выполним SLA и попадём под штрафы - меня как минимум выслушают.

Так что для меня Enablers формулируются как Disablers.

Профессиональная деформация )

Активности SA по формированию архитектуры. Версия 5

Небольшая презентация по использованию законов развития систем ТРИЗ при проектировании архитектуры ПО

В работе "TRIZ for Digital Systems Engineering" Kari Lippert и Robert Cloutier предложили матрицу противоречий для построения программной архитектуры.

Предложены основные качества, но к сожалению не заполнено поле решений.

Выложу здесь, возможно кого-нибудь заинтересует, как заготовка.

Сам я несколько скептически отношусь к использованию матриц противоречий в нашей области.

#ТРИЗ

Матрица противоречий в архитектуре ПО

На прикреплённой картинке дерево атрибутов качества используемых мною в работе.
Простых комбинаций типа FURPS мне, увы, не хватает.

Если бы я строил матрицу противоречий, то потянул бы все эти качества.

Почему я даже не пытаюсь построить такую матрицу?

1. При формировании решения я получаю противоречие, но в этом противоречии участвует сразу несколько качеств.
Например, классическое: нужны одновременно низкое время отклика (responsiveness) и высокая пропускная способность (capacity) при высокой эффективности, то есть против ресурсоёмкости (resource consumption)
В двумерной матрице искать решение на троих не удобно. На пять качеств это уже мучение (

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

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

Подожду, пока что-то подобное построят другие )

#ТРИЗ

Механизация архитектуры. Матрица противоречий

В тему предыдущего поста - несколько разъяснений.

- Матрица противоречий (ТРИЗ) используется при решении типовых задач, "механизируя" поиск решений.
- Если нам удалось свести задачу к простому противоречию, то в матрице мы найдём список приемов, решающих проблему.
- Строки матрицы представляют позитивные типовые параметры (что хотим улучшить)
- Столбцы матрицы представляют негативные типовые параметры (что при этом ухудшается)
- Номера приемов в ячейках на пересечениях противоречащих параметров.

Классическая матрица ТРИЗ была построена Альтшуллером для технических систем на основе анализа более 40000 идей и решений.

Существуют попытки построить подобную матрицу для решения архитектурных задач.
Здесь авторы в качестве типовых параметров выбирают качества проектируемой системы.

На прикреплённом рисунке фрагмент такой матрицы для основных качеств производительности.

Здесь каждое качество определено, количественно измеряемо и положительно, с т.з стейкхолдера.

Эффективность показывает насколько оптимально используется железо. Чем больше ресурсов при прочих равных метриках, тем ниже эффективность

Мощность - предельная пропускная способность.

Отзывчивость определяется временем отклика.

В теории, построив такую матрицу, мы механизируем активность архитектора по поиску решения процентов на 90.
Если, конечно, архитектор не использует принцип Technology First )

#ТРИЗ

Книга по теории массового обслуживания

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

Когда-то распространялась бесплатно. Сейчас сайт перепрофилировался.

Выложу тут.



#Книга #Производительность

Как правильно масштабировать микросервисы?

Существует два подхода:
1. Исключительно горизонтально. По одному потоку (ядру) на сервис. (Прям как в Redis)
2. По возможности вертикально. То есть добавлять побольше ядер и настраивать параллелизм в самом сервисе.
При этом потоки (threads) всё чаще уступают место сопрограммам (корутинам)

За первый подход
1. 8й фактор (из тех 12-ти): VIII. Параллелизм. Где сказано: "Масштабируйте приложение с помощью процессов".
2. Предсказуемость масштабирования. Контролируемая балансировка между ядрами на уровне сервисов.
3. Низкая когнитивная нагрузка. Разработчику сервиса не нужно заботиться о гонках и тупиках (deadlock).
4. Простая модель конкурентного доступа к ресурсам (чаще всего Actor Model).

За второй подход
1. Экономия памяти. (например, одна общая jdk)
2. Синергия, возможность переиспользования данных других потоков (например, общий кэш)
3. "Размазано" влияние служебных процессов. (GC - на одном потоке из одного или из 16-ти ?)

Каждому из этих аргументов легко можно противопоставить контраргумент и с удовольствием похоливарить.

Chat GPT ответит: "it depends" )

Я же зайду от производительности и закину свой кейс.

Предположим, вам нужна высокая пропускная способность при низкой задержке.
Существует точка Кляйнрока (Kleinrock), в которой пропускная способность максимальна, и время отклика минимально (см. рисунок)
- левее – зона недозагрузки
- правее - зона высокой латентности

Мы должны удерживать сервис в точке Кляйнрока, нагружая его M задачами.
Где М = Dmax/D. D - потребность в ресурсе (время).

Забавное следствие
Если сервис использует только один ресурс (например CPU), то Dmax=D, и самым эффективным будет однопоточный вариант.

#Производительность #Микросервисы #Масштабирование

Книга по "быстрым данным"

Fast Data Architectures for Streaming Applications (2nd Edition)
Dean Wampler, Ph.D., VP of Fast Data Engineering, Lightbend, Inc.

В свободном доступе тут
https://go.lightbend.com/fast-data-architectures-for-streaming-applications-oreilly-2nd-edition

Отдают после заполнения анкеты.

#Book #Книга

Как я теперь рассчитываю масштабируемость

Открыл для себя язык R и с успехом заменяю Excel в задачах по моделированию производительности.
(см. картинку)

По шагам:
1. Установил R
choco install r
2. Установил R-Studio
choco install r.studio
3. Взял данные с нагрузочного теста
( Вадим Ткаченко провел на сервере Cisco, описано в "Practical Scalability Analysis With The Universal Scalability Law", VividCortex) закинул в файл
4. Открыл R-Studio
5. Загрузил файл
benchmark <- read.csv("D:/benchmark.txt", sep=" ")
6. Использовал non-linear least squares над формулой USL (универсальный закон масштабирования)
usl <- nls(tput ~ lambda * size/(1 + sigma * (size - 1) + kappa * size * (size - 1)), benchmark, start = c(sigma=0.1, kappa=0.1, lambda=1000))
7. Нашёл коэффициенты
summary(usl)
8. Инициализировал переменные
sigma <- coef(usl)['sigma']
kappa <- coef(usl)['kappa']
lambda <- coef(usl)['lambda']
9. Вывел график
u=function(x){y=x*lambda/(1+sigma*(x-1)+kappa*x*(x-1))}
plot(u,0, max(benchmark$size)*2, xlab="Size", ylab="Thtoughput",lty="dashed")
points(benchmark$size, benchmark$tput)

Профит!

15 минут времени и я знаю, что сервер Cisco масштабирутся до 30 инстансов

Измеряем мощность системы

В очередной раз встала задача померить мощность системы.
Напомню, что под мощностью (capacity) подразумевают максимальную пропускную способность (throughput).

Покажу варианты, с которыми сталкивался

1. Банальная ошибка. Запускаем JMeter. Даем нагрузку в один поток. Смотрим пропускную способность (X). Называем это мощностью.
Понятно, что, в этом случае, при наличии в системе более одного ресурса (например нескольких ядер CPU), мы явно недогрузили систему (левая часть графика). При задержке ответа Z=0, эта область аппроксимируется выражением X=M/D, где M - число клиентов (потоков jMeter), а D - общая потребность в ресурсах.

Кстати, этот замер полезен, так как позволяет определить D (D=1/X).

2. Кладем систему на полку. Начинаем накидывать потоки пока не выйдем на плато справа (аппроксимируется формулой X=1/Dmax, где Dmax - потребность в ресурсе, являющемся узким местом)
Фиксируем точку на плато называем её мощностью Xmax.

Однако это плато - плато только в теории , в жизни это скат. Цифры экспериментов пляшут. Точность так себе.

3. Добавим математики. Замерили несколько точек (минимум 6) с разным количеством потоков. Аппроксимировали через USL (см. предыдущий пост) получили красивую точку Xmax (в предыдущем посте 12 krps)

Всё вроде хорошо, но на практике вы не захотите работать в системе нагруженной на Xmax. Время отклика будет запредельным.

4. Практически полезное значение. Всё таки мощностью лучше называть приемлемую максимальную пропускную способность. То есть ту, что до колена на графике R от X.
Но как ее найти ?

Для системы на одном ресурсе всё просто X=0.5*Xmax.
Для сложных систем существует множество вариантов решения.

Математики всё еще спорят.
Практики давно решили этот вопрос:
Считаем мощностью 0.7 * Xmax (то есть 70 процентов от предельной)
Для примера из предыдущего поста получается 0.7*12000 ~ 8500 rps

Вот собственно и всё.

Можно показывать этот пост тестировщикам перед очередным замером )

#Производительность

Колено

Закрывая тему предыдущего поста 👆

1. Почему мощность это значение пропускной способности в точке Knee (колено) ?
Потому что за коленом "жизни нет" )
Незначительные изменения нагрузки на этом участке приводят к большим скачкам времени отклика.
Здесь огромный джиттер и полная непредсказуемость. Держать SLA на этом участке нереально.
2. Математически колено это утилизация, при которой время отклика деленное на утилизацию минимально т.е. d(R/U)/dU = 0
3. И покаюсь 😏.
Искать колено, умножая максимальную пропускную способность на 0.7 (см. предыдущий пост) - подход распространённый, но не верный.

При умножении лучше воспользоваться вот этой таблицей:

Число ресурсов Значение
1 0.5
2 0.57
4 0.66
8 0.74
16 0.81
32 0.86
64 0.89
128 0.92

Где число ресурсов это число ресурсов используемых параллельно, например, ядра CPU.

#Производительность

Оценка трудозатрат

Оценка трудозатрат - одна из сложнейших задач планирования.

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

Популярные формальные техники:
- PERT
E = (O+4M+P)/6 (O - Optimistic, P- Pessimistic, M - Most Likely)
- FP
Ключевыми компонентами, которые рассматриваются здесь, являются внешний ввод, внешний вывод, внешние запросы, внутренние логические файлы и файлы внешнего интерфейса/
- UCP
UCP = TCF * ECF * UUCP * PF (Коэффициент технической сложности (TCF), Коэффициент сложности среды (ECF), нескорректированные точки варианта использования (UUCP), коэффициент производительности (PF))

Эти техники хорошо проработаны и описаны. Если вы решили формализовать процесс, вряд ли стоит изобретать велосипед. Любые "кубики" будут хуже.

Другой вопрос: а стоит ли вообще формализовать процесс?

Зайдем с другой стороны.
От чего зависит время разработки?

1. Анализ, т.е. условно понимание куда воткнуть код (зависит от чистоты/ясности системы)
2. Неизбежный рефакторинг, подгонка системы под новый функционал (зависит от накопленного тех. долга)
3. Собственно кодирование функционала (зависит от технической сложности, может быть оценено формально)
4. Подстройка под существующие решения/библиотеки (зависит от вязкости)
5. Исправление зависимостей (зависит от связанности/коннасценции)
6. Опциональный рефакторинг (можем оставить как долг на следующую итерацию)
7. Тестирование (зависит от тестируемости)

Таким образом, методы оценки сложности дадут оценку трудозатрат только для чистого кодинга.
Большую часть времени занимают другие активности, никоем образом не связанные с требованиями и сложностью.

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

В большинстве случаев понимание требуемых накладных расходов есть только у разработчика (максимум двух), знающих модифицируемый участок.

И как вывод - единственный надежный способ оценки выглядит так:
1. разбиваем задачу на части (WBS), до атомов, умещающихся в скоупе отдельного разработчика
2. получаем экспертную оценку (можно три точки)
3. умножаем на Pi ) (ну или PERT для солидности)

Всё остальное, увы, профанация

#оценка

Еще одна книга от Baron Schwartz.

Practical Scalability Analysis With The
Universal Scalability Law (Масштабируемость)

Короткая и очень полезная)

#Книги #Производительность #Масштабируемость

Выбор архитектурного стиля

В пятницу описывал коллегам метод выбора архитектурного стиля на основе атрибутов качества.

Этот подход проповедуют многие. В частности:
- SEI со своим ABAS (Attribute-Based Architectural Styles, https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=13505)
- Нил Фор в новой модной книжке "Фундаментальный подход к программной архитектуре".

Поймал себя на мысли, что сам я этим методом не пользуюсь. Да и результат может получиться несколько странным.

Решил накидать "дерево принятия решений по стилю". Получился граф )

Очень драфтово, поэтому
буду рад любым комментариям.

#АрхитектурныйСтиль