Дерево принятия решений по согласованности. Задача

Загорелся идеей нарисовать дерево принятия решений по согласованности (консистентности)

В моем понимании критериями принятия решения должны быть допустимые феномены/артефакты рассогласования по стандарту 95 года (https://arxiv.org/ftp/cs/papers/0701/0701157.pdf) и приемлемые уровни доступности (полная, постоянная, частичная).

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

Хотелось бы провести опрос (ниже)

#CAPТеорема

Выбор БД

Зачастую при выборе БД используется подход Technology First.
Причины:
1. Нас зацепила реклама и порожденный ею хайп
2. Мы хотим оставаться в тренде (разработка ведомая резюме)
3. Мы используем "проверенный" продукт. И в случае чего можем списать неверный выбор на общую тенденцию.
Ну и самое главное - мы зачастую не умеем выбирать, ориентируясь на задачи и цели.

Например:
Заказчик хочет сохранять метаданные в гео-распределенной системе с поддержкой протокола синхронизации RAFT или аналогичного (так в ТЗ ))
Варианты решения:
- У нас есть проверенный годами инструмент zookeeper. Зачем еще что-то придумывать ?
- Я очень хочу попробовать Cassandra. Возьмем ее
- В распределении хороша MongoDB. Да, все сидят на монге!

А как иначе ?

Если бы я делал ответственный выбор, я бы взвесил следующие качества:
1. Изолированность (на первом месте)
2. Согласованность (синхронизация копий)
2. Отказоустойчивость
3. Доступность
4. Производительность

И если уж начинать с изоляции, то нужно правильно сформулировать задачу.

Судя по опросу, да и по опыту, писать задачу от феноменов бессмысленно.

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

Например так:
5. В транзакциях могут быть операции вставки и операции чтения по предикату
Возможны фантомы, Phantom
Решения:
1. Модель акторов (сервис, обрабатывающий транзакции по очереди)
2. Предикативная блокировка
3. MVCC с откатом опасных транзакций нарушаемых вставкой
4. Транзакция от уровня Serializable

И это сразу бы сузило число претендентов на МОЮ БД )

#БД

🖕И да, MongoDB сразу отпала (

Выбор БД

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

http://jepsen.io/analyses

Коллеги, если знаете что-то аналогичное пишите в комменты.
Буду очень благодарен 😌

Архитектура как набор документов

По поводу документирования архитектурных решений существует широкий спектр мнений.
От "документировать ничего не нужно" до "архитектура это и есть документ".

Те, кто считают, что документирование имеет смысл выделяют три функции документа.

1. Объективизацию
Архитектор "отчуждается" от решения. Смотрит на него со стороны. Более объективно
2. Коммуникацию
Архитектор доносит свою мысль до стейкхолдеров.
3. Архивацию
Мысль архитектора сохраняется. Может быть многократно использована или пере-использована.

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

1. ADR (запись архитектурного решения)
Это объективизация. Используется в процессе решения конкретной задачи.
Здесь архитектор перебирает варианты, строит модели, фиксирует данные прототипирования.
Здесь же фиксируется решение.
Я предпочитаю фиксировать сразу несколько решений
- Как будет на следующей итерации
- Как будет в итоге (целевое решение)
- Идеальное (обычно недостижимое) решение
Ну и плюс миграция от одного к другому
Подход 4D

2. RFC (документ для обсуждения)
Многие предполагают, что это стадия ADR. То есть для обсуждения предлагается использовать законченую ARD.
Мы у себя в команде находим это несколько неудобным.
Почти так же не удобно как есть на кухне.
Зачем посвящать всех стейкхолдеров в детали и нюансы принятия решений.
Можно выхолостить ADR. Оставить только выводы и отдать на обсуждение.

3. AD (архитектурное описание)
Когда-то это был единственный документ, представляющий архитектуру. Обычно многотомник.
Здесь итоги решений сведены к описанию системы в целом. Уже без привязки к отдельным решаемым вопросам.
В принципе можно обойтись и без AD.
RFC содержат всю информацию по системе. Однако RFC это фрагменты - и их надо собрать.
Намного проще иметь диаграммы компонент и развертывания в одном месте.
Раньше этот документ распечатывался и раскидывался по столам стейкхолдеров.
Теперь он электронный и может быть фрагментирован.

#ArchDoc

Роль Архитектора

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

Было высказано два тезиса:
1. Архитектор не принимает решения. Это делают менеджеры. Роль архитектора переоценена.
2. Архитектурные решения хорошо принимаются и без архитектора.

Позволил себе не согласиться )

1. То, что менеджерам кажется разумным и единственно верным решением - это то же решение принятое каким-то архитектором. Только чужим.
2. Если это решение стало популярным или даже необходимым, значит это кому-нибудь нужно. То есть кто-то с этого зарабатывает. Не вы.
3. Свой архитектор мог бы разработать альтернативное решение для своего бизнеса. Тут нужны навыки и опыт.
4. Свой архитектор может хотя бы сбалансировать интересы чужого и своего бизнеса.
5. Если вы ещё не почувствовали зачем вам нужен архитектор, то он вам и не нужен. Для архитектуры нужно созреть.

А в общем как и везде. Можем взять свое решение, но кто его будет делать. Или платить за чужое, но дорого, и результат непредсказуем.

#РольАрхитектора

Obsidian
не реклама)

Хочу порекомендовать obsidian, как основной инструмент архитектора.
https://obsidian.md/
Я с большим удовольствием перенес в него:

1. Формирование ADR и RFC в формате md (до этого использовал intellij idea)
2. Захват интересного из Интернета (использовал Notion и Evernote)
3. Ведение заметок (использовал Evernote)
4. Записи в процессе проведения встреч (использовал Notepad++)
5. Подготовка кода для презентации (использовал разные утилиты и intellij idea)
6. Подготовку диаграмм в различных форматах (draw.io, excalidraw, plantUML)
7. Оформление и показ презентаций (использовал PowerPoint)
8. Управление списком дел (todoist)

Основной формат - md
Есть интеграция с Git
Есть мобильный клиент
Масса плагинов от комьюнити

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

#АрхитектурныеИнструменты

Две стадии развития системы

1. Черновик (прототип)
На этом этапе обкатываются интересные идеи. Втискиваются модные технологии.
Разработчики придумывают нестандартные ходы.
2. Чистовик (продукт)
На этом этапе система удовлетворяет потребности стейкхолдеров и приносит доход.

Переход от первой стадии ко второй часто происходит ВДРУГ.
Упс, наш прототип стал продуктом, и заявлено, что он умеет все, притом быстро и надёжно.

Архитектура как код (AaC)

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

Мой список:
1. Ведем модель как данные (архитектура как код) на основании которых можно автоматически сгенерировать любое требуемое представление
2. ADR - это commit в код архитектуры. Система должна помочь мне в формировании ADR исключив из процесса механическую составляющую (минимум - шаблонизатор)
3. Фиксация ADR приводит к автоматической интеграции новых решений в модель
4. Попытка зафиксировать ADR должна автоматически порождать задачу на проверку и согласование (RFC как merge request)

#AaC

Автоматизация архитектурного процесса

Что лично я ожидаю от инструментов автоматизации архитектурного процесса.

Презентовал доклад в IT-One

Выкладываю здесь:

https://disk.yandex.ru/d/_GIBNU85PSS4mQ

👆 Кстати презентация выше подготовлена с помощью того же obsidian.
Плагин Advanced Slides.

https://mszturc.github.io/obsidian-advanced-slides/

Скоро боты заменят технических писателей.

Компания «Яндекс» планирует заменить технических писателей на ботов. Об этом сообщает «Коммерсантъ». Предполагается, что боты будут писать тексты для внутренних проектов компании. Сейчас в компании работают 22 технических писателя, которые пишут тексты для «Яндекса». Боты, в свою очередь, смогут писать для «Яндекс.Карт», «Яндекс.Музыки» и «Яндекс.Такси».

Архитектурное совещание
или работа по контексту

Как известно, архитектор принимает осмысленные эффективные решения не так как проектировщик.
Проектировщик (разработчик) видит условия задачи (дано) и выводит решение (ответ).
Архитектор кроме "дано" имеет еще и понимание контекста задачи.
В контекст входят интересы стейкхолдеров, ограничения, понимание рисков и др.

Эффективность работы архитектора пропорциональна его погруженности в контекст.

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

Что делать если погруженность в контекст не произошло, а решение требуется?

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

Первый вариант обычно дает крайне неоптимальное решение.
Второй вариант - затратен.

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

Опубликована запись последнего архитектурного митапа в IT-one
https://www.youtube.com/watch?v=vD8ixHEugf0&ab_channel=IT_OneInnovation%26Technologies

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

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

Архитектора это касается в первую очередь.
Архитектор активно прогнозирует неприятности на всём пространстве будущей реализации.

Пример:
Дано:
Сотни тысяч клиентов. Каждый порождает небольшой трафик из сообщений, которые необходимо складывать на диск.
Задача:
Обеспечить приемлемую задержку записи.
Решение:
Пишем сообщения пакетами, смешивая в одном пакете сообщения различных клиентов (например в Apache Pulsar)
Порожденные проблемы:
1. Очевидное (классическое противоречие скорость против объем):
Пакет нельзя удалить с диска пока там находится хотя бы одно сообщение. Один медленный клиент будет удерживать большие объемы от утилизации.
2. Не очевидное и понятное только тому, кто с этим уже работал, то есть специалисту:
Служба эксплуатации не сможет определить, какой объем держит каждый конкретный клиент. Как настроить лимиты?

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

И да, про деформацию.
Постоянно приходится объяснять – что я не пессимист. Это работа такая )

О пользе эволюционной архитектуры

Предложив решение, архитектор анализирует возможные риски/проблемы от его внедрения
(где проблема это тот же риск, но который стрельнет наверняка)

Нил Форд описывает различные способы выявления риска:
1. Прототипирование
2. Моделирование (в том числе математическое)
3. Эволюционный подход (пустим в прод. и посмотрим, что получилось)

Кроме этого я бы добавил очевидное:
1. Выявление рисков на основании опыта (по аналогии с предыдущими проектами)
2. Выявление рисков на основании чужого опыта (изучая архитектурные концепты, в частности паттерны)

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

В плане скорости и стоимости принятия решения ранжировал бы так
1. Опыт
2. Паттерн
3. Модель
4. Прототип
5. Проба в проде

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

Единственно надежный вариант – попробовать.
Дорого и сердито.

Ещё одна классификация архитекторов

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

1. Специалист (опыт)
2. Теоретик (паттерны)
3. Инженер (модель)
4. Кодер (прототип)
5. Экспериментатор (проба в проде)

Надо бы протестировать эту модель на собеседованиях )

В продолжении темы.

Много более осмысленный текст:

Заменят ли боты технических писателей ?
PERPLEXITY
View Concise
It is unlikely that bots will completely replace technical writers in the near future
[2]
[3]
[5]
. While AI and automation tools can be used to assist with certain aspects of writing, such as generating content quickly and accurately
[1]
, they are not yet sophisticated enough to consider all the humanly factors important for good user manuals
[2]
. Additionally, AI tools are not yet able to communicate effectively with subject matter experts or other teams
[2]
.Therefore, while AI and automation tools may change the writing profession in a number of ways, such as making some roles redundant and creating new career opportunities for writers who use them
[3]
, it is unlikely that they will completely replace technical writers in the near future
[2]
[3]
[5]