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

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

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

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

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

Аналогично, установленные в команде правила распределения (а не размазывания!) ответственности повышают производительность команды и снижают затраты на избыточные коммуникации.

В ШСМ пишут, что открыли бесплатный доступ к учебникам по всем курсам. Налетай, пока дают :)

Бесплатный доступ к онлайн-программе «Бесконечное развитие»
В Aisystant появился бесплатный тариф, который предоставляет доступ к учебникам (текстам) всех онлайн-курсов Школы. Если же вы хотите получить полный доступ к изучению онлайн-курсов, которые включают в себя еще и упражнения и практические задания, то это возможно только за плату. Стоимость платных тарифов начинается от 600 руб. в месяц.

Наша онлайн-программа «Бесконечное развитие» рассчитана на то, чтобы помогать взрослым людям решать проблемы. Причем обучение нацелено и на тех, кто давно закончил вуз и не обучался новым фундаментальным дисциплинам, лежащим в основе сильного интеллекта. Однако важно помнить, что только сильному интеллекту по зубам справиться с неожиданностями в бизнесе, неожиданностями в инженерии, неожиданностями в менеджменте. Профессионал решает заранее известный класс задач, а интеллектуал сталкивается с новыми проблемами и ситуациями. Хорошо быть одновременно профессионалом и интеллектуалом.

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

Чтобы получить бесплатный доступ к учебникам программы «Бесконечное развитие» теперь достаточно просто зарегистрироваться на сайте ШСМ: aisystant.system-school.ru/. Тариф активируется автоматически для всех зарегистрированных студентов.

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

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

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

К сожалению ли, к удовольствию ли - не знаю, но сменил работу и теперь тружусь архитектором в МТС Диджитал. Переход из небольшой компании-вендора на несколько десятков человек в гигантскую экосистемную компанию - это конечно, некоторый стресс. Много нового и пока непонятного.
Главные ощущения прошедших двух недель:
- Ваще непонятно, как удается координировать совместную работу огромного количества разных подразделений. Ну т.е. теоретически понятно, есть большая стратегия, есть совместные синк-сессии, какие-то роадмапы, но, объективно говоря, каждое подразделение существует относительно независимо, выполняет поставленные ему задачи. Судя по косвенным признакам, многое работает благодаря горизонтальным связям, но я этим связями пока не оброс, поэтому пребываю немного в подвешенном состоянии. Часто даже непонятно куда идти и о чем спрашивать.
- Понятие "продукт" сильно отличается от того, к которому я привык, работая в вендорах. У меня в голове "продукт" - это нечто в коробочке, что мы произвели и продаем наружу, что будет использовать какой-то внешний потребитель. Тут "продукт" - это конкретная система, работающая здесь и сейчас, на конкретном оборудование, на конкретных данных и выполняющая конкретные задачи для не менее конкретных потребителей - других продуктов более высоких системных уровней. С одной стороны, это немного упрощает задачу, так как не нужно думать про "доставку и развертывание вообще", нужно доставить решение в конкретное место и заставить работать в конкретном окружении. А с другой стороны - в чем-то усложняет, так как нужно думать не об обобщенных требованиях и классах задач, а о конкретных проблемах конкретных потребителей.
В общем, привыкаю, осваиваюсь, формулирую для себя правила игры в новых для себя условиях.

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

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

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

Ваше мнение?

#напамять
https://habr.com/ru/articles/583314/
Автоматизация экспорта Archimate модели в HTML в пайплайнах

#вопросыиответы
Вопрос. Есть вариант взаимодействия двух ИС по api, а есть через брокер (кролик, кафка и т.д). В чем принципиальные отличия? Как я понимаю, в первом случае в одной ИС (например на бэкенде МП) нужно написать какой-то контроллер, отвечающий за определенный сервис. А в случае с брокером как? По идее должно быть примерно тоже самое. А если так, то в чем смысл вообще от брокера?

Ответ
основное отличие - синхронное или асинхронное взаимодействие. Когда по API - ты метод вызвал и сидишь, ждешь ответа. А через брокер - ты сообщение отправил и пошел дальше. Разница примерно как общение по телефону или через мессенджер :)
смысл брокера в том, что, например, если связь прервана, то ты до собеседника не доорешься, твой вызов потерян и ты должен сам думать о том, а не надо ли перезвонить/вызвать еще раз, когда это делать и т.п. А с брокером - ты сообщение туда закинул - и свободен. Брокер берет на себя задачу доставки сообщения до адресата, когда он снова будет "в сети"

К вопросу о моделировании баз данных в Archimate
#archimate #database

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

1. Проверить, что система способна выдержать ожидаемые (или требуемые) нагрузки. В этом случае составляют профили нагрузки исходя из ожидаемой реальной нагрузки, моделируют настоящее поведение пользователей и контролируют показатели работы системы (время отклика, объемы потребляемых ресурсов и т.п.) под заданной нагрузкой (например, RPS или количество одновременно подключенных пользователей).

2. Измерить предельно допустимую нагрузку на систему. Применяется для планирования нагрузки и, например, обоснования увеличения КТС. При таком тестировании используют профили нагрузки, аналогичные первому случаю, но нагрузку устанавливают не целевую, а плавно поднимают от минимальной до тех пор, пока показатели работы системы остаются в приемлемом диапазоне. В результате не только выявляется допустимая нагрузка, но и выявляются ограничения, которые её определяют - объем памяти, производительность системы хранения или количество процессорных ядер.

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

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

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

#performance #load #testing

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

Вот есть сервис, он что-то делает, к примеру, читает сообщения из очереди Кафки, как-то их обрабатывает и записывает результат в какую-то СУБД. И вот, допустим, он не смог прочитать сообщение из Кафки, сетка там, к примеру, отказала, или Кафка призадумалась, не важно.

Что делает в такой ситуации благовоспитанный сервис? Правильно, ждет немножко и пробует ткнуться ещё раз. Если не помогло, то и еще раз. Особо интеллигентные сервисы умеют даже варьировать время ожидания между попытками. Но все это хорошо, когда отказ внешних подсистем относительно кратковременный.

А если связанный компонент прилег надолго - то как должен вести себя сервис в части повторных попыток? Продолжать долбиться до бесконечности и гадить в логи, как отвергнутый ухажер мучает соседей красавицы, источая гнусавые серенады под её окном?
Или все же через какое-то время он должен понять и признать, что его отвергли, смириться с этим и перестать изображать из себя сумасшедшего дятла?
А как потом правильно вывести сервис из депрессии и вернуть к активной жизни?

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

А как вы реализуете повторы при отказах?
#мысливслух

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

Обсуждение рабочего кейса.
Как надежно и отказоустойчиво реализовать массовые операции над большим количеством сущностей?
https://news.1rj.ru/str/archicases/2484/2485

Что важнее процесс архитектурной работы или артефакты, которые получаются в итоге?

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

Архитектурные инструменты сильно различаются по сложности использования. Популярные рисовалки вроде Visio, Draw.IO или Excalidraw не требуют почти никакой предварительной подготовки, бери и рисуй. Инструментарий класса "text 2 diagram" навроде PlantUML или специализированные моделеры вроде SparxEA или Archi существенно менее популярны, ведь их освоение требует немалых усилий - выучить "птичий язык" на котором описываются диаграммы PlantUML, освоить нотацию Archimate и осознать интерфейс и логику работы Sparx EA быстро не получится. Так нафига нужны эти сложные инструменты, если есть простые и понятные?

Когда-то, в эпоху расцвета автоматических пленочных камер, я учился фотографии у одного древнего и опытного фотографа. Он давал нам задание и раз в месяц мы приносили ему пачку фотографий, он показывал нам наши ошибки и давал рекомендации. Это все-таки была еще не цифра, пленка, печать и проявка стоили денег, но 2-4 пленки по 36 кадров за месяц уходили.
И вот в какой-то момент преподаватель говорит: "Слушайте, как вы умудряетесь столько снимать? Я вот за месяц отснял всего 12 кадров." Достает конвертик с фотографиями и показывает результат. Действительно, 12 кадров. Все разные, сюжетные, четкие, проработанные, лаконичные и понятные снимки. "Вы со своими автоматическими камерами" - говорит он - "щелкаете все подряд почти не глядя. А если с ручной камерой ходить, то пока посмотришь, пока наведешься, подумаешь... а надо ли вообще это снимать?"

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

Наткнулся на прикольный сервис для рисования BPMN диаграмм. https://bpmn.io/
Навскидку ничем особенно не лучше https://app.diagrams.net/, но выглядит симпатично.
Картинки получаются изящные, чистенькие и аккуратные.

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

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

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

Вот пример отличной программы, которая делает одну функцию и делает её хорошо!

Печаль 😢, но в Windows до сих пор не добавили встроенную возможность закреплять окно поверх других окон!
Есть всякие менеджеры окон, типа AquaSnap, которые умеют делать много всего и в том числе закрепление поверх. Но бесплатная редакция AquaSnap отказалась работать на двух мониторах, а вот бесплатная OpenSource программка DeskPins (https://efotinis.neocities.org/deskpins/) делает только закрепление окон поверх и прекрасно делает свою работу.