Презентация с HL++
С тремя бонусными слайдами )

Еще одна версия на туже тему.
Докладывал сегодня в IT-one.


Добавил карту, для навигации по качествам

Are We Really Engineers?
https://www.hillelwayne.com/post/are-we-really-engineers/

☝☝☝

Гилель Уэйн провел исследование по теме является ли разработка ПО инженерией.
Пришел к ожидаемому выводу - в общем случае нет.
Большинство разработчиков не инженера.

Результат деятельности архитектора

Коротко:
архитектура

Развёрнуто (много букв):
Архитектура никому кроме архитектора не нужна и даже не доступна.
Обоснование:
1. Изначально архитектурой называли структуру некоторых взаимодействующих элементов + принципы развития этой структуры.
2. Чуть позже зафиксировали, что у программного продукта подобных структур множество, в разных плоскостях и под разные потребности (т. н. системный подход)
3. Были сформированы сложные алгоритмы фиксации этих структур через модели и представления, отображающие разные аспекты.
4. Фактически одновременно с этим было замечено, что эти представления бесполезны. Если представление фиксирует ситуацию как есть, то в скором времени оно становится не актуальным. Если фиксирует целевую картинку, то висит гирей на ногах разработки. Особенно если подписано и сдано вместе с ТЗ. Большое предварительное проектирование отливало эти гири в граните.
5. Сторонники гибкого сервисного подхода, предпочитают рассматривать архитектуру с т. з. потребителя. Т.е. архитектура это набор значимых решений.
Многие уточняют, что значимыми являются необратимые или сложно обратимые решения, сильно влияющие на судьбу продукта.
6. Архитектора свели к проектировщику поставляющему решения, и архитектор оказался не нужен.
7. Однако, вскоре выяснилось, что решения могут быть приняты только человеком глубоко погруженным в контекст задачи. "Решатель" должен пропитаться информацией о продукте.
8. То есть на входе набор разнообразных фактов, а на выходе решения. Что между? Между мозг Архитектора нейронные связи которого построили модель продукта из множества информационных осколков. (Ну почти АИ)
9. Аджайл сразу предложил механизм формирования метафор - первичных представлений продукта, которые потом разрастаются в красивую модель. Очень близко первоначальному понимаю архитектурного стиля.
10. Вот эта самая модель и является архитектурой, на базе которой принимаются решения.

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

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

☝️☝️☝️Некоторые следствия

1. Архитектор нужен в системах где
- сложность не позволяет свести структуру к нескольким простым моделям
- требуется значимые решения, то есть от решений зависит судьба продукта
(и соответственно, очень часто архитектор избыточен)
2. Шапочки архитектора и программного инженера - две разные шапочки
- Архитектор, творец который принимает решение на основе слабо формализуемых представлений
- Программный инженер - логик, который из А выводит Б, предсказывая характеристики системы до ее построения.
Это впрочем не исключает процесса перевода одного подхода в другой.
С накоплением опыта интуитивные практики можно формализовать.
3. На системе может быть только один архитектор, либо система должна быть декомпозирована, под разных архитекторов.
Два архитектора над одной системой - две разные ментальные модели, по которым строятся разные решения.
4. Большинство книг/курсов по архитектуре заточены на инженерные практики.
Практика формирования ментальной модели либо вообще аут оф скоуп либо рассмотрена крайне поверхностно.
Это и понятно. То что слабо формализуется, то и плохо передается.
(Хотя в последнем случае, я могу быть не прав. Возможно я просто не попадал на стоящие курсы по этой тематике.)
5. Архитектор, отчётливо проявляющийся в ИТ сфере, должен присутствовать и в других областях связанных со слабо формализуемыми моделями.
И чем дальше от цифр и железок, тем важнее его роль.
Тот же самый "главный конструктор", принимающий не только инженерные решения, тоже архитектор - только еще и отягощенный властью.
6. Для чего я погружаюсь во все эти аспекты мета-архитектуры? Для того чтобы делать значимые выводы )

7. Топология "Архитектура как сервис" подходит под инженеров программистов. Им для работы достаточно чёткой постановки задачи и недолгого погружения в контекст.
Архитектор должен работать по схеме плотного взаимодействия с командой.

Граф противоречий: Производительность

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

Работаю так:
1. Выбираю хотелку (потребность). На графе розовые
2. По стрелкам нахожу связанные параметры и определяю:
а. Что из этих параметров сильнее влияет на нужную характеристику
б. Что из этих параметров проще всего изменить
3. Фиксирую пару хотелка-параметр как противоречие
4. Из списка концептов, соответствующих выбранной паре, выбираю более-менее подходящие (короткий список)
5. Взвешиваю концепты исходя из понимания системы (архитектурное решение) и фиксирую вывод в ADR
6. Если решение не найдено, перехожу на фазу "изобретения", которую начинаю с представления идеального решения задачи.

В общем вполне себе механический процесс, который при желании можно легко воспроизвести.

Если интересны детали, могу рассказать или показать на примере.

Пишите )

Тенденции 2023

Вышел свежий Trends Report от InfoQ

Микросервисы продолжают закатываться.

Банальная математика в помощь архитектору

Предположим нужно оптимизировать время отклика (R).
Чаще всего сразу предполагают, что время отклика эквивалентно времени пребывания (RT, обработка в системе) + транспортные расходы.
Ну или, если пренебречь транспортными расходами, R = RT.

Дальше в плане оптимизации ищем подходящее тактики.
Тут как в аптеке - подход рецепторный.
Чаще всего вспоминают про оптимизацию времени обработки (RT) и кэширование.

А что если пойти от математики и попытаться поиграть параметрами ?

Распишем R:
R = T_end - T_start (тут очевидно)

Что у нас T_start и T_end ?

По определению времени отклика
T_start - время окончания передачи запроса
T_end - время начала получения ответа

Забавный факт - эти времена принадлежат разным "дорожкам"
T_start - клиенту, T_end - системе
и, кроме того, никак не привязаны ко времени обработки.

То есть T_end жестко не привязан к T_start и мы можем двигать его влево

Сколько возможностей открывается:

1. Начинаем обработку ДО события T_start
Тут всевозможные предикативные тактики, предсказывающие действия пользователя, на основании модели пользователя или доменной модели
2. Выполняем всю обработку ДО T_start
Тут тактики раннего связывания, в частности уже упомянутое кэширование
3. Опять же оптимизируем время обработки (а с ним и транспортные расходы)
4. Таймаут ограничивающий время T_end справа, в случае всяких неприятностей.
5. Предсказываем ответ и выдаем его не дожидаясь окончания обработки.
Тактики оптимистичного дизайна и совершенного оптимизма.
6. И наконец, выдаем ответ по кусочку. Если нам важен момент получения первого байта ответа, незачем ждать завершения всей обработки.
(Было бы забавно если бы строители ждали пока завод ЖБИ заготовит все плиты перед поставкой их на стройку)
Тут тактики потоковой обработки

Вот сколько всего.
Больше из этой кошечки мне выжать не удалось (

Но даже этот скромный результат с лихвой покрывает все, что написано в методичках SEI.

Теперь каждый раз, перед поиском подходящих тактик, я прикидываю простейшую, банальную мат. модель для интересующей меня метрики. ИМХО это эффективнее чем вспоминать слабо-структуированные каталоги тактик разных арх. школ.

Чуть более сложная математика в довесок
(Кисонька, ну еще капельку)

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

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

На графике представлены возможные распределения при времени обработки 1 сек.

Замечу, что пик двух распределений (т. н. мода) одинаков.

Тактики изложенные выше позволяют сдвигать моду влево.

Хотелось бы еще иметь тактики вытягивающие график вверх (зеленый в синий)

Зеленый график имеет существенно худшие показания SLA и на верхних перцентилях ведет себя недостойно.

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

Если браузеру нужно скачать не один файл а сто, распределение просядет вниз.

Отсюда еще одна - седьмая тактика:
7. Уменьшение количества запросов требуемых на выполнение одной операции.
Если слабо влияет на метрики центральной тенденции (среднее, медиану, моду), то может существенно улучшить статистику (высшие перцентили)

Забавно, но факт.

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

Референсные архитектуры

Референсная архитектура - это архитектура "из коробки"
Берём чьё-то готовое решение и используем у себя как некоторый baseline.

Часто спрашивают где брать.
В основном ищем в интернете. Интересные решения демонстрируются на разных конференциях.

Или, например, в приложенной книге.

Производительность и ТОС

Многие считают, что теория ограничений систем Голдратта (ТОС) хорошо справляется с задачей повышения производительности информационных систем.

ТОС даёт нам план:
1. Разбиваем процесс на этапы.
2. Находим бутылочное горлышко.
3. Определяем ограничение.
4. Устраняем ограничение.
5. Повторяем с первого шага.

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

Однако не всё так однозначно.

Если у нас другой concern, например, если нам необходимо улучшить отзывчивость, то план не работает:
1. Разбиваем процесс на шаги.
2. Находим участок с максимальной потребностью в ресурсе (bottleneck)
3. Определяем ограничение/ресурс (например SSD)
4. Устраняем...

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

Оптимизация же соседнего участка, может оказаться не столь эффективной, но очень дешевой.

То есть правило работающее на пропускную способность, не работает на отзывчивость или, например, справедливость.

Теория ограничений имеет ограниченную область применения при проектировании программных систем.)

#ТОС

Пост в оправдание

Коллеги, если у вас сложилось впечатление, что я против ТОС, сильно каюсь.
👆Выше я хотел сказать, что ТОС имеет свою область применения (scope) и не стоит рассматривать его алгоритмы как универсальный инструмент оптимизации (многие грешат).
К тому же современный ТОС это не только про слабые звенья.)

В оправдание приведу несколько интересных и не очевидных выводов из ТОС относящихся к оптимизации пропускной способности системы под нагрузкой:
1. В открытой/полуоткрытой модели оптимизировать надо бутылочное горлышко. Остальные участки оптимизировать бесполезно.
2. Узкое место нужно постоянно мониторить. Оно может переместиться. Лучший показатель - длина очереди запросов перед узким местом.
3. Умный планировщик имеет смысл только на узком участке. На других участках приоритет должен отдаваться запросам которые уйдут на узкое место.
4. Важно отслеживать очередь запросов к узкому месту. Плохо если очередь велика. Очень плохо если длина очереди под нагрузкой 0.

#ТОС

Снова про ТОС

И снова возвращаюсь к теме ТОС и оптимизации производительности. Вышел спор/разговор с коллегами по поводу поста выше.
Конкретно по пункту 4.

Аргумент коллеги:
Узкое место перегружено. Важно его разгрузить. Идеально разгруженное узкое место имеет очередь длиной 0.

Аргумент ТОС:
Под нагрузкой производительность всей системы определяется узким местом.
Поэтому ресурс на бутылочном горлышке должен задействовать все свои возможности.
Нельзя чтобы бутылочное горлышко простаивало. Перед ним нужен заполненный буфер.

Остальные участки должны обеспечить бутылочное горлышко работой (приоритет сообщений идущих в узкое место). И только когда буфер сформирован могут простаивать или заниматься чем либо другим.

ИМХО аргументы ТОС убедительны.

#TOC

Обеспечение низких задержек в высоконагруженной системе: разбор реального кейса.

PR-отдел IT-One опубликовал статью по моему докладу на HL++.

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

https://tproger.ru/articles/obespechenie-nizkih-zaderzhek-v-vysokonagruzhennoj-sisteme--razbor-realnogo-kejsa?ysclid=lsbmqtasd5413958027