Заметки на инженерных полях – Telegram
Заметки на инженерных полях
71 subscribers
3 photos
17 links
Ежедневная инженерная работа одного архитектора. Что бывает, происходит, и зачем.
Download Telegram
Заметка на полях. Что есть относительно современного в SCM (Software Configuration Management).

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

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

#управлениеконфигурацией #рабочее
Forwarded from Книжный куб (Alexander Polomodov)
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
👍1
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Поступил запрос:

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

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

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

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

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

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

Условие
⁃ Не должно быть прессинга на внутренних специалистов
Заметка на полях. Моделирование и типы моделей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#рабочее #системотехника #стандарты #SEBOK
👍1
Forwarded from Книжный куб (Alexander Polomodov)
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: Благодарю автора доклада за улучшенную версию!)
За что отвечает архитектура?

1. За выявление наиболее существенных требований и за разрешение противоречивых (конфликтующих или обратно-коррелирующих требований).

2. За устранение напряжения между требованиями и конструкцией (это когда то, что хотим, - не можем, а то, что можем, - не хотим).

3. За выбор способа разрешения неопределенности требований путем выбора соответствующей SDLC-модели разработки. Т.е. за выбор соотношения предиктивного и адаптивного способов разрешения неопределенности.

4. В случае выбора адаптивного способа обработки неопределенности (итеративная SDLC-модель разработки и её производные) - за достижение Quality Attribute Modifiability. Т.е. за максимизацию количества открытых решений, где открытость определяется стоимостью изменения решения. Т.е. за опеспечение постоянства скорости разработки по мере роста размера системы. На практике этот график обычно обретает характер роста близкий к логарифмическому, и задача архитектуры - предотвратить экспоненциальный рост. Достигается это путем минимизации когнитивной нагрузки, т.е. путем управления сложностью, и локализацией изменений. Если этого не сделать, то адаптивный способ разрешения неопределенности утратит экономическую целесообразность, поскольку стоимость реализации будет существенно зависеть от момента принятия решения.

5. В случае выбора многокомандной инкрементальной SDLC-модели разработки и её производных (Scaled Agile) - за обеспечение постоянства скорости разработки по мере увеличения количества команд разработки, т.е. за решение Проблемы Брукса. Достигается это путем минимизации коммуникативной нагрузки на команды разработки за счет выявления правильных границ Bounded Contexts.

Это те функции, для осуществления которых нанимается архитектор.

Теперь подойдем к часто обсуждаемому в профессиональных сообществах вопросу.

Давайте представим пациента, госпитализированного с острым воспалительным процессом, которому доктор назначил лечение в виде курса антибиотиков. Пока еще можно обойтись консервативным лечением, но если его не осуществить вовремя, то потребуется уже хирургическое вмешательство. А если и его не осуществить, то возможен летальный исход. И тут пациент говорит, что у него сегодня важная бизнес-встреча, и нужно бухнуть вискаря, тем самым нейтрализовав антибиотики. Что делает в таком случае доктор? Он выписывает пациента из стационара за нарушение предписанного режима, и тем самым он снимает с себя ответственность за последствия, которые от него не зависят. Потому что иначе это будет называться преступная халатность. Она не может быть оправдана тем, что доктор получил за халатность деньги (т.е. наличием корыстного умысла). Доктор-убийца никому не нужен. Он получает деньги за исполнение возложенных на него функций.

Размытость в понимании своих функций иногда на практике приводит к тому, что архитектор начинает противодействует им, оправдываясь тем, что "кто платит, тот и танцует". Такое, конечно, тоже может быть, только это уже не функции архитектуры. И если человек не осуществляет функций архитектуры, то называть его архитектором уже ошибочно.
👍2
Нашел чек-лист для проверки опровержения CAP теоремы. Если вы считаете, что сумели придумать решение, сочетающее в себе доступность, согласованность и устойчивость к разделению (consistency-availability-partition tolerance), то загляните сюда https://ferd.ca/beating-the-cap-theorem-checklist.html
👍21
Forwarded from Книжный куб (Alexander Polomodov)
AI для разработки - базовый навык для 2024 - Владислава Куклева - Agile Days 2024 (Рубрика #AI)

Интересный доклад Владислава Куклева, CEO агенства Agentcy, про AI тулинг. Понятно по названию его компании, что финальным аккордом является история про мультиагнетные системы, но до это Владислаав успевает пробежаться по вопросам
- Архитектуры языковых моделей (рассказ про LLM на уровне сложности для обывателей)
- Проблемы LLM (галлюцинации и угадывание), но OpenAI дотюнила модели обучая на размеченных диалогах с пользователем + появился промпт инжиниринг, про который рассказывает автор. Правда, он не упоминает, что по новейшим исследованиям промты для LLM сами LLM пишут лучше, чем люди:)
- Создание при помощи LLMs дизайна, слайдов, диаграмм (mermaid.js)
- Помощники для написания кода: GitHub Copilot, Cursor, Phind
- Цепочки запросов и AI-агенты - как это устроено и почему сейчас это очень перспективное направление
- Мультиагентские системы и как отдельные агенты могут объединятся в команду - подробнее в whitepaper "ChatDev: Communicative Agents for Software Development"

#AI #ML #Software #Processes #Management
👍3
Гена хороший. К Гене надо сходить.
Заметки на полях. Прочитал тут оригинал "MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS" Dr. Winston W. Rovce. E WESCON, August 1970, page 8-9. Institute of Electrical and Electronics Et)gineers,,
.328 Inc. Originally published by TRW.

Поводом стал очередной холивар в сообществе одном из крупнейших сообществ айтишников РФ про "ажайл-версус-вадапад". Собственно это одна из основополагающих статей про "программную инженерию". Первое ,что бросилось в глаза - количество ссылок на источники представлений о прекрасном. Их ровно 0. Т.е. товарищ описывает "ВАДАПАД" не ссылаясь вообще ни на что. Типа "Ну вот всё сложное софтовое создаётся так. Я сказал". Хотя надо заметить, что прослеживается отсылка на Гуда, Маккола "System's Engeneering". Она же "Системотехника" (перевод под редакцией Тарасенко, Перегудова).

И дальше товарищ начинает рассуждение о том, что неплохо бы (ОБОЖАЖМОЙ) проверять, что именно на каждом "ЭТАЖЕ". Более того, он утверждает, что единственное место, где производится тестирование - это самый конец разработки, перед вводом в эксплуатацию. Опять же, исходя из того, что он обсуждает свой собственно придуманный концепт.

А весь смысл статьи в том, что "Давайте проверять, что то, что мы делаем в софте - оно хорошее, и достаточно зрелое".

Т.е. он сразу говорит, что работать без обратных связей и проверки качества постановки задачи - дело гиблое.

Но камон! Кто сказал, что так вообще кто-то когда-то делал в сложных системах? Перед тем, как что-то сделать сложное всегда проходила куча экспертиз. Плюс в 1970-м году вообще машинное время - это ппц дорогой ресурс, там одна ЭВМ - это холодильник.

В общем у меня такое ощущение, что мы до сих пор говоря про "ВАДАПАД ПРОТИВ АЖАЙЛА" обсуждаем фантазию деда 50-ти летней давности, про которую он сам сказал, что: - "Нинада так делать".

Жесть)
👍1
Заметка на полях. Статья подъехала. Ребята нашли достаточно сильное статистическое подтверждение тому, что неоднородность вселенной и наблюдаемое расширение - следствие гравитационного взаимодействия и не требует введения "тёмной энергии". И вообще, расширение вселенной может быть иллюзией наблюдателя) В самой статье они заявили достаточно громко, что требуется некоторый пересмотр стандартной Фридмановской модели. Так что, покупаем попкорн и ждём шуток про физиков в тёмной комнате, которой нет.

Для меня примечателен оказался и метод исследования в т.ч. Обрабатывались исходные данные Байесовскими статистическими методами. Генеративная АИшечка в таких вопросах, кстати, должна давать достаточно серьёзные преимущества в построении предсказаний на моделях с достаточно большим количеством весов. Если кто-то думает в эту сторону (обработка данных наблюдений всякими корелляционными методами и построение предсказаний LLMами) попрошу ещё прокомментировать это предположение. Что там есть перспективного нынче.
Заметки на полях, как фиксация некоторых размышлений на тему.

В профильных чатах разработчиков всяких ИТшненьких систем пронеслись несколько мыслей, которые стоит для себя зафиксировать:
1. Современная разработка скорее строится на народных приметах вида: "Скрам-мастер без татух - к беде"
2. В итоговом ИТ-продукте будут реализованы только те качества, за каждый из которых есть выгодополучатель.

Если ещё плюсом немного подытожить наблюдения, то можно построить типовую модель качества ИТ-системы примерно так:

- Функциональное качество (а-ля UX)
- Инфраструктурная доступность сервиса
- Стоимость вывода в пром.применение "следующей версии"

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

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

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

Т.е. если пользователей продукта в моменте достаточно для его поддержания, то качество продукта - ПРИЕМЛЕМО. И для владельца актива по производству продукта важно защитить основных поставщиков качества. А в нашем случае это: Кодописатели, админы инфраструктуры, менеджеры с палками, которые штрафуют ФОТ.

Лично меня эта картинка подвигает на то, чтобы снижать порог толерантности, выражающийся в безусловном принятии как допустимого, и последующем бездействии к тому, что меня не устраивает в используемых мною продуктах.
👍2
Заметки на полях. Про промпты. Кажется, в ближайшее время с нейросетями будет успешно работать тот кто сможет:

1. Концептуализировать процессы, и их алгоритмы
2. Концептуализировать предметную область
3. Ставить корректно задачи

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

С другой стороны, очевидно, что будет запрос на такие нейросетки, которые смогут учить их пользователя пользоваться нейросетками =)

Отсюда для себя сделаю вывод чему стоит учиться:

1. Разрабатывать целостные, непротиворечивые описания мира
2. Описывать процессы (алгоритмизация)
3. Соблюдать контекст ведения рассуждения
4. Формулировать цели,
5 Декомпозировать цели на задачи
🔥3💯2
Заметки на инженерных полях. Был в 2023-м году на конференции "Стачка" и делал там доклад про то, какие инструменты есть и должны быть у архитектора. С тех пор значительно продвинулся в понимании этого вопроса, и на основании недавно прочитанного для себя заметочка:

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

- Как распознать, что архитектурное решение отражает проблему, как субъективное восприятие заинтересованной стороной некоторого объективно существующего противоречия между желаемым и действительным/прогнозируемым действительным?
- Как распознать, что решение - оно вообще принято в работу и корректно понято?
- Как распознать, что решение правильно разработано?
- Как распознать, что решение правильно оценено на реализуемость?
- Как распознать, что реализация решения идёт по плану?
- Как распознать, что есть отклонения?
- Как распознать, что решение выполнено в достаточной мере, чтобы устранить исходную проблему, стимул для принятия решения?
- Как распознать, что реализованное решение действительно устранило исходную проблему/стимул?
- Как спланировать действия в будущем, на возникающие аналогичные проблемы/стимулы?
👍1
Заметки на полях. Сегодня имел беседу про то, что такое управление конфигурацией. Как всегда. Две поляны между собой перекидываются какахами, кто более прав, а кто Лев...

1. Управление конфигурацией продукта (мутная тема достаточно, и крутится вокруг маркетинговых понятий в основном. Что-то типа "фича", "сторя","бизнес-ценность"... В русском понятийном пространстве это вообще заклинания, так-то).

2. Управление конфигурацией системы. А это про тяжёлые методологические абстракции высокого уровня вложенности.

Вы уже догадались, кто и чем может управлять? Правильно! Кто что в руках держит, тот и управляет. Если программист щупает код - то для него вся эта история про "бизнес-ценность" - это про подписанный акт приёмки. Точка. Если акт подписали, морду не разбили, руки не отрубили - бизнес ценность есть! Доказывать, что то, что я делаю сейчас соответствует ожиданиям "бизнеса"? Так код напишу, он сам себя и докажет! Это ж математика! Если работает и акт подписан - значит всё ок, ничего никому доказывать не надо! (Л - Логика ушла поспать на определении транзитивности отношений. Это второй курс. Дискретная математика. Разделы логика предикатов. Если что.)

А на уровне "Продуктовых аналитиков" есть что угодно, затем трактуемое как угодно. Зачем формализовывать потребности? Достаточно же написать "должна быть безопасная фича". И "квалифицированная, мотивированная команда экспертов".... У нас же все кто в ИТ высококвалифицированные, мотивированные команды профессионалов, да?)
В итоге имеем "аналитиков", которые сидят за плечами у "программистов" и говорят:

- А тут кароч кнопку такую, филолетовенькую, нарисуй, Василич просил, у него жена будет на показе, а она в таких туфлях ходить любит.

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

Поэтому пока впечатление такое:

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

#идейное #управление_конфигурацией
😁1