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

Что порадовало:
✔️ Вопросы противоречивости возникшие у меня при чтении второй главы тут более-менее разрешаются.
✔️ Подтвердил свой старый тезис, что смысл работы архитектора в том, чтобы "давать имена". Т.е. создавать/выделять понятие, насыщать их смыслами, и контролировать эту историю.
✔️В очередной раз убедился, что "Перспектива"(viewpoint) для "Модели" - неотъемлемая часть.
✔️Без воды, на пальцах, раскидано как работать с ограниченными контекстами.
✔️Описаны свойства Ед.Языка и его сопоставление с Огр.Конт.
✔️Закон Конвея учтён, что есть круто)

Чего хотелось бы добавить или сделать лучше:
✔️Примеров единого языка хотелось бы пореальнее. Можно внешними ссылками на статьи, или работы. Чтобы набрать больше эмпирик.
✔️Очень спорный для меня тезис, что разработчик не определяет требования. С моей точки зрения "ограничения" - это вид требований, которые как раз задаются возможностями команды разработки. Да, они в свою очередь настраиваются другими ресурсами, но...
✔️Тезис "системные требования предметной области" - выглядит крайне странно. Мне сходу не удалось его достаточно однозначно интерпретировать. Кажется, требует раскрытия.

Какие выводы:
✔️ Каждый раз, когда кто-то рисует квадратики и спрашивать с него "А какую ты задачу решал этой моделью".
✔️ Хочу практикум по ограниченным контекстам. Чуть ли не учебник. Очень.
✔️ Хочу практикум по моделированию. Опять же, чуть ли не учебник. Тоже очень.
✔️ Пора читать теорию распределённых вычислений. Похоже, что согласование ментальных моделей экспертов Пр.Обл. - задачка из этой области.

Что дальше:
✔️Классно было бы подумать над тем, какие из популярных моделей какие задачи решают в реальности, и как это соотносится с их начальным назначением, или тем, что пишут в статьях.
✔️Похоже, что такая штука как DSM - это неплохой способ выделения Огр.Конт. на множестве сценариев (а может быть и над семантической областью ). Надо бы проверить.
✔️Решать задачки.

P/S. Репу пока не сделал. Каюсь.

#книжное #DDD #ПОП #глава3 #Хононов

Заметка на полях. Четвёртая глава "Изучаем DDD". Способы сопряжения ограниченных контекстов.

Что порадовало:

✔️Первая книжка, где я вижу прямой учёт правила Конвея в части проектирования.
✔️Наконец-то кто-то учёл, что процессы - это люди, а не "нечто, что рожает код". Поэтому фокус дан в т.ч. на необходимые качества отношений между людьми, для применения подхода к сопряжению компонентов=доменов.
✔️Язык изложения продолжает радовать. Всё так же мало воды, по сравнению с другими книгами, и высокая насыщенность смыслами.
✔️Полезную модельку дали =) Причём сразу сказали для каких задач её точно можно использовать.

Чего хотелось бы добавить или сделать лучше:
✔️Очень нехватает упражнений и задач. Хоть семинары открывай.
✔️Чтобы понимать ценность материала, нужно иметь нетривиальный опыт. Для новичка бы это выглядело как "10 заповедей на каменных скрижалях". А хотелось бы обоснования, раскрытия. Например примеров неудачных решений.
✔️Немножко структурировать разделы, кажется, что в некоторых местах есть перескакивание между мыслями, и из-за этого мне приходилось напрягаться. Но это так, ворчание ленивого.


Какие выводы:

✔️Если мы - архитекторы, и хотим хорошо эволюционировать со своей системой - следим за динамикой развития интерфейсов как между кусками комплекса системы, так и между командами.
✔️Если даём какие-то модели - сразу нужно говорить для решения какой задачи они подходят. Уже было, но повторить не лень.

Что дальше:

✔️Похоже, что кому-нибудь стоит заняться задачником по DDD. Если некому, значит пока не время.
✔️Нужно развивать практикумы. Возможно, сделаю регулярный семинар, правда не очень понятно, в каком виде это может полететь, и кому нужно. Я так точно этим в какой-то момент займусь.

#книжное #DDD #ПОП #глава4 #Хононов

Заметка на полях. Пятая глава "Изучаем DDD". Реализация простой логики предметной деятельности.

Что порадовало:
✔️Методы рассматриваются, на мой взгляд, достаточно подробно. Как человеку не имеющему большого опыта непосредственной разработки ПО (классы-методы-код), смотрится здраво.
✔️Хорошо описаны критерии применимости. Но от недостатка опыта мне может быть сложно оценить полноту и значимость описания.
✔️Есть задачки к этой главе.

Чего хотелось бы добавить или сделать лучше:
✔️Поскольку есть ссылки на Фаулера, наверное стоило бы дать какой-то перечень способов реализации логики. Пока выглядит как достаточно вырванное из контекста. Нехватает отсылок к кругозору, и где копать для желающих большего.
✔️Хотелось бы различения простой и сложной логики деятельности. Мне кажется, это различение крайне важно. Даже CRUD может быть достаточно сложно реализуемым под капотом в некоторых случаях.

Какие выводы:
✔️В целом идёт хорошо.

Что дальше:
✔️Поставить в задачи посмотреть Фаулера "Patterns of enterprise application architecture".
✔️Было бы неплохо найти куски кода, и сформулировать вокруг них задачи на различение паттернов. Может сойти за кандидатскую работу к.м.к.

#книжное #DDD #ПОП #глава5 #Хононов

Заметка на полях. Пятая глава "Изучаем DDD". Проработка сложной логики предметной деятельности

Что порадовало:
✔️Всё ещё хорошо понятный язык изложений сложных концепций. Правда возможно это следствие моей общей подготовки и кругозора. Поэтому нужно проверять на других коллегах. На мой взгляд это редкость для таких книг.
✔️Указания на некоторые типичные ошибки допускаемые при проектировании.
✔️Хорошо видно, что сложность коммуникаций между людьми в процессе разработки можно перенести на формальные инструменты за счёт оптимального выстраивания поля понятий, которыми участники коммуникации оперируют. Язык действительно многое решает. Очень. Интересно до каких пределов это возможно?

Чего хотелось бы добавить или сделать лучше:
✔️Указание на то, какими практиками или приёмами выделять те, или иные типы объектов. Хотя бы ссылочно. Например про EvStorm упоминаний нет, а про события П.О. - есть. Мне кажется это было бы полезно.
✔️Описаны агрегаты, доменные сервисы и объекты-значения. При этом во введении упоминались инварианты и бизнес-правила. А на них ссылок по ходу главы нет. Возможно я чего-то недопонял и это будет дальше, но пока не заметил где про это можно прочитать.

Какие выводы:
✔️Мне не очевидно сходу, какими навыками должен обладать инженер проектирующий системотехнические решения с применением П.О.Пр. Поскольку тут и "контроль системного уровня" ( о чём кстати явно не говорится), и разделение объектов по множеству оснований, и удержание множества аспектов приложения внимания одновременно.
✔️Похоже про практические задачи надо действительно делать отдельную книжку) Мне вопросы для самоконтроля показались слабыми, и не требующими закрепления материала.
✔️Пошли главы по большей части именно для программистов. А хотелось бы больше про системотехнический уровень. Ещё интересно было бы про программно-аппаратное проектирование почитать, насколько П.О.Пр применимо в этой сфере. Хотя похоже такой перенос это предмет для исследования.
✔️Вроде бы, у меня создаётся впечатление, что при заходе на ООП через П.О.Пр сложновато что-то новое изобрести.

Что дальше:
✔️Пока фиксируем хотелки, но похоже, что можно планировать семинар по обсуждению книги и её аспектов, чтобы вынести на обсуждение что там хотели бы получить. Я вот задачник по П.О.Пр. хочу, чтобы можно было практиковаться.

#книжное #DDD #ПОП #глава6 #Хононов

Заметка на полях 9.11.2023.

Организовали с коллегами небольшой семинар системных инженеров (они же инженеры-системотехники, не путать со схемотехниками). Посмотрим как пойдёт. Сюда же буду публиковать некоторые результаты обсуждений. Примеры тем, которые у нас возникают:

- Методическое пособие «Методы исследований в области системной инженерии»
- Понятие системы. Системный подход в ARCADIA. Что такое Миссия и Операционная возможность, зачем они в анализе? Их эквиваленты в русском мире.
- Учебный план магистратуры системных инженеров. Конкретные шаги к развитию хороших практик и снижению влияния плохих. Вопросы отбора в магистратуру.

#рабочее #incose #системотехника #семинар #МИРЭА #банда

Заметка на полях. Седьмая глава "Изучаем DDD". Моделирование фактора времени.

Что порадовало:
✔️Много кода. Псевдязык значительно облегчает понимание подходов.
✔️Хорошие пояснения к терминам. Ощущения запутанности - нет по прочтению.
✔️Хорошо раскрыт подход к проектированию основанный на событиях. Мне понятно.
✔️ЧАВО на тему "А чо так сложна? Давай сделаем попроще!" - мне кажется, это вообще во всех главах надо бы добавить.

Чего хотелось бы добавить или сделать лучше:
✔️ Я бы хотел посмотреть где-то более конкретные примеры и модели решений основанных на описываемый в этой главе. Схемки, обоснования, результаты применения. Поскольку здесь для всего связанного с Событиями Как Источником Данных приводится достаточно много аргументов за и ограничений, мне кажется важно больше практических примеров на эту тему было бы дать. Но может быть это от моей безграмотности (хотя книжка вроде бы для таких как я, не?)

Какие выводы:
✔️Пошли главы по большей части именно для программистов. А хотелось бы больше про системотехнический уровень. Ещё интересно было бы про программно-аппаратное проектирование почитать, насколько П.О.Пр применимо в этой сфере. Хотя похоже такой перенос это предмет для исследования.
✔️Вроде бы, у меня создаётся впечатление, что при заходе на ООП через П.О.Пр сложновато что-то новое изобрести.

Что дальше:
✔️Буду просить добавить примеров, и выносить такие штуки в арх этюды. Мне кажется - это непочатая тема для.

#книжное #DDD #ПОП #глава7 #Хононов

Заметка на полях. Образование в ИТ. DevOps.

Поскольку я нынче руководитель программы ДПП на цифровой кафедре МГТУ им. Баумана, некоторое время сижу и думаю, а чему именно и ради чего учить. По ходу дела сформировал некоторое количество рассуждений в отношении зачем учить и чему учить. Основаниями были мои личные рассуждения, память и заметки накопленные за период работы в этой сфере. Да, я в курсе, что DevOps - это культурный феномен. Но он выражается в конкретных ценностях, целевых показателях деятельности, применямых практиках, наборах навыков и знаниях. Поэтому я буду рассуждать о последних, по сути о том, что формирует профессию.

1. DevOps в настоящий момент всё больше про автоматизацию процессов жизненного цикла ИТ-систем. Не только и не столько "собрать, послать, прикрутить, посмотреть, пнуть" сколько все 15 (а то и больше) "технических" процессов жизненного цикла описанные в ISO/IEC/IEEE 15288-2015 (2023-го года стандарт пока не посмотрел). Поскольку ВНЕЗАПНО оказалось, что в циклы проверок нужно включать всякое сложное про безопасность, соответствие требованиям. Например оценку соответствия целевой ИТ-системы критериям качества исполнения бизнес-функций предприятия. А ещё внезапно там же появился мониторинг фитнесс-функций команд и автоматизация оценок "velocity" и подобных вещей. Встраивание в пайплайны интеграционных тестов, генерации наборов данных и в принципе всё остальное.

2. Прямым следствием из п.1 является необходимость для DevOps инженеров участия в формировании этих самых процессов, как внутренного "соисполнителя", для которого "команда" является "заказчиком". Т.е. DevOps инженер должен уметь выстраивать жизненные циклы подконтрольных ему систем. Начиная с выявления потребностей, поиска проблем, подбора технических решений и заканчивая менеджерскими практиками а-ля "управлять программой развития инструментов CI/CD в своей компании" (если такое вообще возможно).

3. Следующий этап рассуждения, приводит меня к тому, что задачей того, что нынче называется DevOps инженер в пределе будет являться так называемая область Интеграции данных жизненного цикла системы. Что-то подобное описывается вот тут. И поэтому учить нужно в своей сути не тому, как контейнеры в кубик засовывать, а в первую очередь тому, как создавать ценность для всех заинтересованных сторон процесса разработки. А их у нас как минимум: владелец предприятия, команда, потребитель продукта и кто-то там ещё. Тут нужно разбираться (#исследовать).

4. Далее интересный вопрос, что команда разработки считает для себя ценностью и в каких аспектах. Вот тут большое поле для раскопок и исследований (#исследовать). Девопс, например, своей работой может способствовать удовлетворять пресловутое желание разработчиков видеть свои решения "красивыми" (ну или красивше, чем у них это получается). И таким образом развивать технологическое совершенство подконтрольных ему систем.

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

В связи с чем имею желание провести семинар на тему: "Чему нам сейчас учить стремящихся в DevOps, чтобы в будущем с ними продуктивно было сотрудничать". В повестку хорошо бы включить обсуждение следующих тезисов:
- Расширение области ответственности DevOps инженеров и разделение труда. Риски и последствия.
- Что есть в мировой практике инженерной деятельности похожего, что мы могли бы перенести в область DevOps.
- Какая базовая подготовка должна быть у стремящегося в DevOps-инженеры?

#devops #рабочее #МГТУ #идейное

Заметка на полях. Управление конфигурациями продукта.

Мой личный интерес в конечных продуктах для "простых пользователей" всегда был ниже, чем в инструментах для кручения гаек. Мне лично всегда интереснее точить карандаши, чем рисовать гравюры. В связи с этим я заморочен на разных видах инструментов поддержки разработки. DevOps - это как раз то, где у меня больше всего интереса в работе. Но поскольку нужно хорошо изучить предмета работы я закапываюсь в достаточно большое количество разных тем.

Одна из таких - это управление конфигурациями продукта. Прекрасный пример продукта требующего управления конфигурацией - самолёт. Или автомобиль.

В современном варианте этот самый самолёт/автомобиль совокупность следующих вещей:
1. Платформы.
2. Вариантов групп "опций"/"фич" и т.п.
3. Различного, что позволяет платформу+фичи использовать в целевой среде.

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

А поскольку нынче идёт, и надеюсь будет идти импортозамещение, мне кажется стоит начать копать в эту тему поглубже. Я тут буду периодически постить всякое по теме: #управлениеконфигурацией.

#идейное #исследовать

Заметка на полях. Models and Methods of Software Configuration Management

В поисках того, что вообще есть на тему, решил начать с поиска статей. В качестве отправной точки попалась [статья]. Что лично меня подкупило:
✅ В качестве ключевого слова указан Model-driven approach
✅ Множество родных DevOps-у слов во введении.

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

Что вынес полезного:
Корни сложностей при работе с управлением конфигурациями:
1. Мало кто знает, что такое "управление конфигурациями" кроме глубоко погружённых в сложные проекты.
2. Существующие инструменты как раз для сложных проекта, и внедрять их сходу - жесть.
3. В связи с быстротой изменения процессов и прочего один раз разработанные инструменты и сценарии нуждаются в постоянном сопровождении [1].
4. Инструменты позволяющие что-то моделировать слабо поддерживают процессы управления конфигурацией и слишком сложны или не применимы в общем случае [2].

Помимо этого можно отметить следующее:
1. Понятно, что управление конфигурацией, похоже, будет вотчиной девопсов. Или уже стало, но мы пока не заметили.
2. Можно говорить, что подходов к снаряду сделано достаточно много, и есть куда копать, прежде чем пытаться сходу решать проблемы.
3. Видно, что могут пригодиться знания CMMI и ITIL.
4. Придётся заниматься интеграцией множества тулов, а следовательно и моделей в них лежащих.

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

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

#идейное #управлениеконфигурацией #рабочее

Заметка на полях. Управление конфигурацией.

Наткнулся на цикл статей пол CM 12-ти летней давности. Интересно бы было ретроспективно рассмотреть.

Ссылки:
•Начало
•Опорные срезы
•Изменения
•Контроль версий
•Метрики и документация
•Средства контроля версий
•Книжки рекомендуемые автором (2010-й год)

Очевидно, что проблема старая, но почему-то я про неё вообще не слышу ничего в публичном поле. Как будто либо не забота архитектора, либо решённая проблема. Но последнее очевидно не так.

#управлениеконфигурацией #рабочее

Заметка на полях. Восьмая глава "Изучаем DDD". Архитектурные паттерны.

Что порадовало:
✔️Даётся набор конкретных инструментов.
✔️Сказано какова ценность применения паттернов.
✔️Как и обычно указаны границы применимости.

Чего хотелось бы добавить или сделать лучше:
✔️Мне, как человеку напрямую не разрабатывающему ПО главы 5-9 кажутся слабоинтересными. Да, понятны рассуждения, но конкретной практической применимости я пока для себя не вижу.
✔️Как мне кажется в восьмой главе много крутится вокруг CAP-теоремы, но при этом основные выборы между С, А, Р - не указаны. Наверное стоит про это рассказать больше.
✔️Мало уделено внимания аспектам вычислительной сложности (ресурсоёмкости) с другими подходами. Хотя может быть это тема другой книги.

Какие выводы:
✔️Сложно делать конкретные выводы, поскольку это не моя тема.

Что дальше:
✔️Читаем дальше. Копим обратную связь.

#книжное #DDD #ПОП #глава8 #Хононов

Заметка на полях. Что есть относительно современного в SCM (Software Configuration Management).

Все материалы, которые нынче мне попадаются по теме УК ПО достаточно старые. Примерно года до 2016 выпуска. Заход через поиск статей и описаний готовых методов решений показал, что найти хорошую статью по интересной теме нынче проблема. Поскольку за последние лет 5-6 достаточно много поменялось в этой теме, решил попробовать зайти с раскопок обзоров имеющихся публикаций. Хотя, поскольку инженерная работа в основном не про академические публикации, самое лучшее, что я надеюсь там найти - это широко обсуждаемые темы, и интересные источники по основаниям этой предметной области. О практически применимых теориях и результатах работы я в настоящий момент не надеюсь найти сильно.

В результате поиска через google scholar не получилось найти ни одного современного обзора литературы по этой теме. Похоже, что тема на данный момент ещё пока не признана областью содержащей какую-то проблематику привлекающую внимание, либо считается, что все задачи уже давно решены. Что достаточно удивительно.

#управлениеконфигурацией #рабочее

Programming's Greatest Mistakes • Mark Rendle • GOTO 2023

Превосходный стендап на тему ошибок в разработке софта, от которого я действительно смеялся. Суть в том, что автор - опытный разработчик софта, который всю дорогу рассказывает про факапы, причем начинает со своего, а дальше раскручивает спираль дальше и упоминает многие известные истории. Давайте я кратко опишу факапы, которые обсуждаются
- The med file Unf*cker - факап автора, где он для устранения бага в повреждении сохраненных файлов сделал софт для их исправления (с интересным неймингом)
- Y2K - проблема 2000 года, когда год должен был помещаться в YY, но в 2000 году надо было перейти к YYYY. И дальше весь софт надо было доработать под эти изменения
- The Kennel club "Dog 38" - забавный пример с хранением чисел в римском формате
- Agile в enterprise в виде SAFe, AutoScrum 1.1 от Accenture и The Agile Landscape v3 от Deloitte - по картинкам видно, что Agile в корпорациях тут зашел куда-то не туда:)
- The Pentium FPU - проблема с плавающей точкой в процессорах Intel, эту ситацию прикольно описал Энди Гроув в книге "Выживают только параноики", про которую я уже писал
- Null - история про появление nullable значений и как там поучаствовал Tony Hoare, который это назвал "Null References: The Billion Dollar Mistake"
- Hartford Center - история про то, что спроектированное в CAD не всегда хорошо чувствует себя в реалььности (тут про обрушение здания из-за снега)
- Knight Capital - эпичная история про high frequency trading и как экстренное обновление программного обеспечения с багом и отключенной защитой от дурака обанкротило за несколько часов большой хедж фонд
- Mariner1 - про баг в формуле, которую транслировали в Fortran, что привело к крушению
- Mars Climate Orbiter - про имперскую и метрическую системы (дюймы и футы) и как из-за этого космический аппарат для исследования Марса вместо того, чтобы исследовать его с орбиты, решил примарсится:)
- Ariane 5 - про то, как при миграции софта с Ariane4 на Ariane5 в 16 битное float поле положили 64 битное значение и к чему это привело
- The Big Rewrite - про факап самого автора
- Javanoscript - язык, который собрали за 10 дней, а дальше он стал супер-популярным и настолько же неконсистентным:)
- Лейтенант Станислав Петров - как советский офицер предотвратил 26 сентября 1983 года потенциальную ядерную войну после ложного срабатывания системы предупреждения о ракетном нападении со стороны США.

#Fackup #Humor #Reliability #SRE

Поступил запрос:

Нужен внешний архитектурный наблюдательный совет, – проверять наши решения на корректность, предлагать альтернативы.

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

Кто желает, может высказать свое мнение, риски, предложения.

Консультативный совет, как площадка для дискуссий и выработки предложений

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

Риски
⁃ Требование проектирования без работ по проектированию на уровне «скажите нам как надо»
⁃ Не вовлеченные в повседневную работу люди будут восприниматься как противники, как следствие - возможен саботаж
⁃ Интересы совета будут расходится с интересами команды
⁃ Отсутствие полного контекста снижает возможности по обоснованию решений и доверию к ним
⁃ Контекст меняется быстрее погружения в контекст

Условие
⁃ Не должно быть прессинга на внутренних специалистов

Заметка на полях. Моделирование и типы моделей.

Интересная статья на habr-e. Где один из аналитиков рассуждает о типах моделей с которыми приходится сталкиваться и с их особенностями. Главные выводы:

1. Нужно различать когда мы моделируем реальный объект в мире, а когда моделируем представление о реальном объекте. Т.е. можно выделить модели "объектные" и "мнимые". Первое - про штуки, второе - про то, что мы об этих думаем в голове.

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

3. Запоминаем как "Отче наш...", что модели предназначены для коммуникации, и важно не то, что мы напишем в модель, а то, что там прочитают. Поэтому писать надо не себе будущему, а "ему" прошлому =)

#идейное #моделирование #boro

Заметка на полях. Системотехника в забугорьях.

Откопал курс по основам системной инженерии в MIT. 10 лекций, про то, как в Масачусетсе понимают "Systems engeneering". Да, 2015-й год. Да, не такое свежее. Но вряд ли что-то там радикально меняется в основаниях.

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

На всякий случай там же рядом лежат презентации с этого курса.

#рабочее #системотехника #MIT #учебное

Заметки на полях. Системотехника в забугорьях

Я тут задремал, и пропустил обновление SEBoK!
А оказывается он тут обновился 20.11.2023!

В ближайшее время попробую построить diff между версиями 2.8 и 2.9!

Коротко, что нового:

✔️Добавили статью о реверс-инженерке с применением ажаля на примере беспилотной машинки. Мне кажется будет интересно почитать;
✔️ Заменили статью про безопасность в системотехнике на новую;
✔️Заменили статью с обзором руководства по программной инженерии;
✔️Обновили статью о "Системотехнике движимой потерями" про метод наблюдения за атрибутами качества.
✔️ Обновление статьи про "Самовосстановление" систем (System Resilience)
✔️ Набросали новых сценариев применения самого SEBoK для конечных пользователей. Говорят, что будет более дружелюбен к читателям.
✔️ Всякого по мелочи

Я щасливый! Есть, что почитать на досуге и куда закопаться.

#рабочее #системотехника #стандарты #SEBOK

Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services

Я уже рассказывал про знаменитую CAP теорему за авторством Eric Brewer. А сегодня я расскажу про whitepaper 2002 года от Seth Gilbert и Nancy Lynch, в котором гипотеза стала теоремой. Сама гипотеза для доказательства звучит так

It is impossible for a web service to provide the following three guarantees: consistency, availability, partition-tolerance

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

1) Начать стоит с consistency, где авторы идут в сторону atomic data objects или линеаризуемой консистентности (linearizable consistency)

Under this consistency guarantee, there must exist a total order on all operations such that each operation looks as if it were completed at a single instant. This is equivalent to requiring requests of the distributed shared memory to act as if they were executing on a single node, responding to operations one at a time.

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

2) Второй характеристикой является availability, где для непрерывной доступности каждый запрос, попавший на несбойную ноду системы должен получить свой ответ. Таким образом любой алгоритм для генерации ответа сервисов должен оканчиваться в конечном счете (eventually terminate). Интересно, что это слабое определение доступности, так как нет верхней границы на время ответа - это позволяет unbounded computation. Но если рассматривать это с позиции устойчивости к разделению, то это может рассматриваться как сильное определение доступности - даже если происходят сбои в сети, каждый запрос должен завершиться.

3) Для моделирования partition-tolerance авторы предлагают считать, что в сети может теряться произвольное количество сообщений, что отправляются от одной ноде к другой. А значит мы можем моделировать любой паттерн потерь

When a network is partitioned, all messages sent from nodes in one component of the partition to nodes in another component are lost. (And any pattern of message loss can be modeled as a temporary partition separating the communicating nodes at the exact instant the message is lost.)

Дальше авторы переходят к доказательствам

1) Начнем сначала с асинхронных систем

Theorem 1 It is impossible in the asynchronous network model to implement a read/write data object that guarantees the following properties:
• Availability
• Atomic consistency
in all fair executions (including those in which messages are lost).

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

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

Theorem 2 It is impossible in the partially synchronous network model to
implement a read/write data object that guarantees the following properties:
• Availability
• Atomic consistency
in all executions (even those in which messages are lost).

Доказательство тут похоже на предыдущее как две капли воды:)

Оставшаяся часть white paper посвящена Delayed-t consistency в частично синхронных системах, про которую мы тут говорить не будем.

А в следующем посте поговорим про теорему PACELC.

#Software #Architecture #DistributedSystems #SystemDesign

Заметки на полях. Инженерное.

Нашёл интересный доклад на ютубе и украл к себе.

Это очень старая тема, но в разработке ПО пока не слишком развитая. Разбор доклада чутка попозже добавлю)

UPD: Благодарю автора доклада за улучшенную версию!)