Русский
Русский
English
Статистика
Реклама

Анализ и проектирование систем

Второй день 3DEXPERIENCE World 2021 как это было

26.02.2021 16:11:32 | Автор: admin

На пленарном заседании было сказано много нового о смещении акцентов с промышленных изделий как таковых на впечатления от их использования. В этой части конференции, а также на последующих тематических секциях участники узнали, как 3DEXPERIENCE Works объединяет в реальном времени людей, приложения и данные то есть охватывает практически все аспекты деятельности предприятия. Это открывает путь к повышению производительности, упрощает совместную работу и позволяет быстрее внедрять инновации.

Прозвучало несколько убедительных отзывов от компаний-клиентов, которые интенсивно используют инструменты 3DEXPERIENCE Works для воплощения своих задумок в реальность. Одной из таких компаний стартапу Skinny Guy Campers 3DEXPERIENCE SOLIDWORKS помогает реализовать планы по расширению бизнеса.

Представитель компании Square Robot рассказал, как им удалось укрепить свои конкурентные преимущества, расширив возможности проектирования и производства с помощью инструментов комплекса 3DEXPERIENCE Works. Далее участникам представили компанию Seed Terminator, которая использует 3DEXPERIENCE Works для адаптации своей продукции к различным сельскохозяйственным машинам и сорности посевов.

Выступление Фрэнка Стивенсона, в послужном списке которого должности ведущего дизайнера и директора по дизайну в крупных автоконцернах, таких как McLaren, Ferrari, Maserati, Fiat и MINI, было (что вполне предсказуемо) посвящено скорости. Он рассказал, как сократить циклы разработки, как использовать стремительно развивающиеся инструменты проектирования и что нужно сделать для поддержки человеческого звена в системе человек-машина.

Хотите увидеть гонку на Луне или прокатиться на летающем такси? Стивенсон показал примеры своих текущих проектов и действительно, это что-то за рамками привычного нам мира! Смотрите запись его презентации на платформе виртуального мероприятия (вкладка Agenda).

Глубокое погружение

После пленарного заседания участники получили возможность глубже погрузиться в конкретные производственные области. На секции Виртуальные испытания путь к совершенству говорили о том, почему так важен всесторонний анализ поведения изделий в эксплуатации уже на ранних стадиях их разработки. Были продемонстрированы масштабируемые, подключенные решения SIMULIA, настроенные на работу совместно с SOLIDWORKS.

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

Секция Будущее проектирования и производства проводилась совместно с создателями телепрограммы Titans of CNC. Они рассказали о компании, которая смогла выполнить проект в чрезвычайно сжатые сроки, организовав безопасное и надежное взаимодействие всех сторон с использованием SOLIDWORKS и мощной платформы 3DEXPERIENCE.

Еще на одну секцию был приглашен Джейсон Пол признанный промышленный дизайнер, которого все знают по реалити-шоу Американский мотоцикл на канале Discovery.Он провел краткий обзор удивительных проектов, над которыми сейчас работает.

Отдельные секции Паспорт экосистемы стартапов для регионов Северной Америки, Европы, Азии и южной части Тихого океана были посвящены проблемам и перспективам, возникающим у основателей стартапов при запуске новой продукции, а также динамике современного рынка. Участники поделились информацией о том, чего ожидают инвесторы, каковы текущие тенденции в отрасли и как стартапы переходят от идей к производству.

Во второй день 3DEXPERIENCE World мы обсудили много вопросов. Мы научились анализировать потребительские впечатления. Завтра, как гласит программа третьего дня, мы глубже погрузимся в связи и отношения и совсем не важно, что физически мы находимся далеко друг от друга.

Рекомендуем вам посмотреть видео ниже, чтобы не пропустить ни одного яркого момента.

Хотите узнать больше? Скачайте бесплатно электронную книгу о ключевых обновлениях и технических преимуществах SOLIDWORKS 2021

Подробнее..

Архитектура архитектуры архитектора

28.02.2021 04:04:14 | Автор: admin

Архитектор это звучит Звучит как-то не понятно. Наверное, поэтому всегда добавляют что-то. Ну типа системный архитектор или там программный архитектор. Не то чтоб так стало понятно, что он делает, но точно кто-то важный. Я вообще пишу архитектор информационных систем и программного обеспечения. Это ж как назовёшься -так и поплывешь! С архитекторами тут вообще такое дело это как бы и не профессия. Ведь архитектором как стать? Либо тебя назовут таковым, либо сам назовёшься. Другого пути нет. Ни школы, ни спец. образования, никаких то там универсальных сертификатов нету. Только название и есть.

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

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

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

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

От теории к практике. Линия на картинке плевое дело. А как насчет реальной архитектуры то? Вот тут бы хотелось немного поподробней. Тем более, что картинка глупая. Если фича нужна, то её запилят. Как и положено, зеленой пересекающей параллельной линией прозрачного цвета. Поэтому и архитектуру нужно гибкую и разноцветную. Но сначала прямые линии на голубом листе и ярылчки с брендами. Blueprint и tech. stack. И это вообще не архитектура, а дизайн. Набросок.

Как это в Agile устроено при построении задания, так и здесь: цель, средства, что дано. Для этого шага есть много сапог. Померяв несколько, я решил быть в тренде. На одной ноге IDesign, на другой DDD. Вот только не надо мне тут про микросервисы, клиент-сервер и всякие распределенки. Мы не на этом этапе. Нас интересует то, что нужно клиенту, а не как. В старом добром UML мы бы сейчас построили use-case и block диаграммы. Нам нужно определить основных игроков и функции - расставить точки на карте. Я обычно не углубляюсь пытаюсь рисовать человечков пользователи разные, но система одна. Так что я просто отрезаю интерфейс от сценариев. Грубый план обычно - такой синий пирог с разноцветными цукатами.

набросок для внутреннего обсуждениянабросок для внутреннего обсуждения

Опытный инженер сразу заметит, что как-то попахивает заданием для продуктового отдела нашего супермаркета. Все вот эти Product Owner и Business Analyst должны дать те самые юзкейсы и фитчи. Хотя нет, опытный инженер вообще это читать не будет. И уж тем более кто как не он, должен знать, что архитектуру сначала надо продать своим. Начальству, инженерам, поддержке и тд. Поэтому и диаграмма должна говорить на их языке. Что же важно мне на данном этапе определить блоки, которые будут служить основой. Те, что ближе к константам, чем к переменным. Несущие конструкции. Количество стен, не углубляясь из чего они сделаны.

Продали колонны? Что теперь интересно вашим клиентам? Цвет труб! То что они увидят, только в случае серьёзного чп. Логично же. Большой и неповоротливый энтерпрайз любит, чтоб о нём говорили как о динамичном и энергичном. Так чтоб в тренде, вон с тем стратапом. Но только, чтоб надёжно. Вам нужны жужалки и стразики - buzz words. Вот тут уже надо начать набрасывать распределенные микросервисы на облако. После первого этапа все должны в курсе будет ли эта закрытая ли система, с доступом в сеть или нет, количество пользователей и срок жизни, дискретность окружения и всё такое. Это, однако, не помешает клиентам требовать cloud для системы в offline. Нет, я не преувеличиваю. И вот чтоб были автономные микромодули, но только монолитом. Актуальные и верные данные в любое время в постоянно доступной, разрозненной системе. Привет кэп! Можно обнаружить (в копилке личного опыта), что клиент в северной Африке на диалапе, лучший пинг в ближайшее облако больше 300, а хотят они реалтайм для управления дронами по видео с бортовой камеры. Инженеры, работающие с клиентами напрямую, в цирке не смеются.

Значит теперь задача набросать много звучных и цветных иконок трендовых технологий. Универсального рецепта нет, так как готовить всё равно придётся из того, что есть в холодильнике. Вряд ли вам дадут нанять новую команду специалистов. Энтерпрайз проекты живут десяток лет и года 2-3 в разработке. Так что в одну клавиатуру такое не поднимешь. Необходимы готовые команды, а у них уже есть какой-то опыт и знания. Если у вас 5 команд бэкенда пишет на Java, то переводить их Python нет не времени не смысла. Играете с теми кубиками что есть, и будьте любезны собрать слово счастье. Однако стоит всё-таки делать выбор и не пускать на самотёк. Если у вас есть клиент (UI/UX), и он не слишком мудрёный и жирный, то тут можно вставить свежачок. Лицо системы долго без изменений не живёт, да и фронтэнд технологии тоже. Так что, если актуален сейчас React бери его и найдите одного специалиста. Бэкхэнд на 10 лет вперёд требует и технологию, которая не исчезнет. Поэтому то и популярны .NET и Java. Если есть место микросервисам, то каждая команда может взять свою технологию. Но они же в том же холодильнике, так что сюрпризов не будет. Только помните, что микросервисы не всегда уместны. А иногда и совсем не уместны. Нет у вас центра и не нужно динамическое масштабирование, то может и не надо городить огород? Люди десятки лет, работавшие на поддержке монолита, не обрадуются тому, что им придётся содержать зоопарк. Они даже не понимают, что это надо выкатывать и содержать вручную в случае частного закрытого решения (on-premises project). Нельзя поехать и поменять или подключиться по RDP и залезть ручками в базу данных. А потом они всё равно это сделают через какой-нибудь джампер бастион и поменяют что-то, как-то не догадавшись, что это лишь одна из 12 баз и теперь данные всей системы не стыкуются - прощай выходные!

Немного оффтопа. Клиент как кит в океане, только старый, не грациозный, с тремя головами и вяло текущей деменцией. Но и корпорации, которые его обслуживают не лучше. У них старые связи с клиентом. Они когда-то поставляли/производили железо и пытаются видеть в софте всё те же станки. Сделали рабочий прототип фигачим еще миллион и поставляем. Долгая проектирование, потом немного допилим, в производство и на моментально на полки/клиентам. Они же всегда так делали. Как это roll-out это долгий процесс? Ведь copy-paste и в продакшн! В общем, как много нам открытий чудных Поэтому решение надо не только продать и утвердить внутри своей компании, нужно еще удостовериться, что сама компания будет соответствовать решению.

И так наша следующая диаграмма будет всё еще аморфной, но уже на технологиях. Точность компонентов и связей здесь не столь важна, а вот обоснование выбора картинок необходима. Именно здесь впервые затронут бюджет. Лицензии, специалисты, обучение, поддержка, система. Много иконок клиент радуется, большие траты клиент дуется. Есть, конечно, горячие пирожки. Не важно куда и как, но нужен Kubernetes. Даже если и нет масштабирования засуньте в автоматическое тестирование как часть CI-CD. Но иконка должна быть. Бесплатные пирожки ещё вкусней. Вам понятно, что Kubernetes будет с контейнерами Docker, но заказчик будет брызгать деньгами, если вы добавите и этот образок. И безопасность туда же прилепите https.

технологиитехнологии

Ну и конечно, как только нам удаётся найти и протолкнуть решение мы идём по пути наименьшего сопротивления. Повторяющиеся паттерны во всё меньшем масштабе. Архитектура Мандельброта.

монотонное множество архитектурымонотонное множество архитектуры

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

Подробнее..

Как катать релизы несколько раз в день и спать спокойно. Доклад Яндекса

26.02.2021 12:14:08 | Автор: admin
Высокие темпы разработки сопряжены с рисками, влияющими на отказоустойчивость и стабильность особенно если хочется экспериментировать и пробовать разное. Разработчик Маркета Мария Кузнецова рассказала о релизном цикле своей команды от и до, а также о мониторингах и других вещах, позволяющих обновлять сервис со скоростью три релиза в день.



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

(...) Сейчас у нас в среднем выкатывается по три релиза в день.



Стек технологий, которые мы используем типичен для Java-приложений Маркета. Мы используем 11-ю Java, Spring, PostgreSQL для хранения данных, Liquibase для накатывания миграций и Quartz для регулярных Cron-задач. Конечно, у нас реализовано много интеграций с внутренними сервисами.

Начать я хочу с того, как у нас устроен процесс релиза.

1. Релизы


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

Среды у нас сейчас только две продакшен и тестинг. Когда код-ревью пройдено и код попал в trunk, запускается вот такой релизный пайплайн.



Дальше я покажу все шаги подробнее.



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



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

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

Конечно, у нас есть ограничения при выкатке релиза. Парадигма trunk-based development диктует то, что не должно быть долго живущих feature branches, и получается так, что в trunk может оказаться незаконченная функциональность.

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

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

Но такой подход звучит дорого.

2. Feature toggles


Поэтому мы пришли к тому, что стали использовать feature toggles. Toggles с английского переводится как переключатель, и это в точности описывает его предназначение.

if (configurationService.isBooleanEnabled(NEW_FEATURE_ENABLED)) {    //new feature here} else {        //old logic}

Можно выкатить код и пока не использовать его в продашкене, например, ждать поддержки фронтенда или же дальше его реализовывать.

Нам очень важно уметь включать-выключать функциональность по отмашке от коллег. Поэтому свой toggles мы сложили в базу.

public class User {    private Map<String, UserProperty> properties = new HashMap<>();    String getPropertyValue(String key) {        UserPropertyEntity userProperty = properties.get(key);        return userProperty == null ? null : userProperty.getValue();    }}

Поскольку функциональность не всегда нужно сразу включать на всех пользователей, сделали feature toggles на пользователя и тоже положили их в базу. Так мы можем точечно включать функциональность, и это дает возможность провести эксперименты. Например, мы делали новую функциональность под кодовым названием Звонки. Это напоминание курьеру о том, что у него скоро доставка. (...) Такая функциональность сильно перестраивала процесс работы курьера, и нам было важно проверить, как процесс летит в реальном времени, в реальной жизни.

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



Конечно, у такого подхода есть минусы. Toggles скапливаются, и здесь ничего не остается, кроме как их убирать. Также увеличивается сложность тестов, потому что проверять свой код нужно во всех режимах работы toggles. Кроме того, toggles лежат в базе, поэтому получается лишний поход в БД. Здесь ничего не остается, кроме как поставить кэш. Какие плюсы мы за это получаем?



Мы получаем возможность спокойно жить в парадигме trunk based development. Также можем проводить точечные эксперименты на пользователях.

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

Мобильное приложение обычно тоже раскатывается не сразу на всех пользователей, а вначале на какой-то процент из них. И мы можем получить такую ситуацию, что в зависимости от пользователя бэкенд должен иметь разную логику. Это не только изменения в API, но и именно изменения в бизнес-логике. Toggles нам тоже помогают решить такую задачу.

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

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

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

3. Метрики и мониторинги


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

Какую информацию мы собираем? На слайд я выписала формальное определение метрик и мониторинга.



Но предлагаю рассмотреть, что это такое, на примере.



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

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



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

На слайде пример, как нам в базе перестало хватать CPU.

Окей, у нас Java-приложение, и, конечно, стоит собирать информацию о состоянии JVM.



Мы используем Spring, поэтому для решения такой задачи хорошо подходит библиотека Spring Boot Actuator. Она добавляет endpoint в ваше приложение, и к этому endpoint можно обратиться по http и получить необходимую информацию о памяти или что-то еще. Окей, приложение запущено. Дальше оно вообще работает или нет? Что с ним происходит? Можно отправлять запросы в это приложение или нет?

@RestController@RequiredArgsConstructorpublic class MonitoringController {    private final ComplexMonitoring generalMonitoring;    private final ComplexMonitoring pingMonitoring;    @RequestMapping(value = "/ping")    public String ping() {        return pingMonitoring.getResult();    }    @RequestMapping(value = "/monitoring")    public String monitoring() {        return generalMonitoring.getResult();    }}

Такие вещи нужно понимать не только нам, но и балансеру. Для этого мы добавляем в приложение контроллер с двумя методами Ping и Monitoring. Рассмотрим вначале Ping. Он отвечает на вопросы, живо ли приложение, можно ли отправлять на него запросы. И отвечает он это в первую очередь не нам, но балансеру. Но мы же используем этот метод для мониторинга того, живо приложение или нет.

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

public enum MonitoringStatus { OK, WARNING, CRITICAL;}@RequiredArgsConstructorpublic class MonitoringEvent { private final String name; private volatile long validTill; private volatile MonitoringStatus status;}

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

public interface ComplexMonitoring { void addTemporary(String name, MonitoringStatus status, long validTillMilis); Result getResult(); //тут можно делать проверку для статусов в MonitoringEvent} 

Получается такой простейший интерфейс мониторинга. Добавить или обновить событие и вернуть текущее состояние мониторинга в оговоренном формате.

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



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

Чтобы рассказать, что это такое, на слайде есть нижний график, на нем выделена точка в 400 мс. Это график 99 перцентиля какого-то метода из нашего API. Что значат эти 400 мс? Что в этот момент 99% запросов отрабатывали не хуже 400 мс.

Остались пятисотки. Не стоит мерить просто количество пятисоток, потому что не будет понятен масштаб. Стоит мерить долю или процент. Но собирать можно не только пятисотые коды ответа, но и любые другие коды, которые вам могут быть интересны.

Как мы собираем RPS, тайминги и пятисотки? Когда запрос оказался у нас в инфраструктуру, он попадает на L7 balancer. А дальше он не сразу попадает в приложение, перед этим есть nginx.



А вот уже из nginx он попадает в приложение. У nginx есть access.log, в который можно собирать всю необходимую информацию. Это коды ответа, время ответа и сам запрос.



Часто, когда возникают проблемы с временем ответа или пятисотки, стоит посмотреть, что в это время было с хранилищем.

У нас PostgreSQL, поэтому мы именно его мониторим и смотрим. Мы строим все эти графики не сами они нам предоставляются облаком, в котором развернута наша база. Что у нас есть? Количество запросов, транзакций, лаг репликации, среднее время транзакции и так далее. На самом деле на этих графиках представлен факап, который у нас произошел.



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

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

public class MetricQueryRealJobExecutor { private static final RowMapper<Metric> METRIC_ROW_MAPPER = BeanPropertyRowMapper.newInstance(Metric.class); private final JdbcTemplate jdbcTemplate; public void doJob(MetricQuery task) { List<Metric> metrics = jdbcTemplate.query(task.getQuery(), METRIC_ROW_MAPPER); metrics.forEach(metric -> KEY_VALUE_LOG.info(KeyValueLogFormat.format(metric)) ); } @Data private static class Metric { private String key; private double value; }} 

Но далеко не всегда на такие мониторинги должна реагировать разработка. Очень часто на них вначале нужна реакция бизнеса. Вообще задача получения статистики по хранилищу выходит однотипной. Нужно сходить в базу, рассчитать статистику, а результат записать в key-value-лог. Поэтому мы сделали обертку для таких задач.

Сложили в базу такую тройку: уникальный ключ для метрики, сам запрос, в котором можно эту метрику посчитать, и Cron-выражение, когда считать. То есть в базе получилась тройка: ключ запрос cron expression. А над всей этой тройкой сделали Cron-задачу, которая достает ее из хранилища и добавляет к общему пулу Cron-задач. Дальше эта задача выполняется.

Итого, что мы получаем?

  • Плохой код не должен попадать в продакшен, для этого мы ставим всевозможные преграды: тесты, стрельбы, мониторинги. Задача без тестов не считается сделанной. Лучше заниматься оптимизацией работы тестов, чем получить проблему в продакшене.
  • Feature toggles помогают нам управлять логикой работы бэкенда, а мы, в свою очередь, можем легко управлять toggles, и их плюсы все-таки перевешивают минусы.
  • Мы должны уметь быстро обнаруживать проблему, в идеале раньше, чем ее заметят наши пользователи. Но ее мало обнаружить, нужно еще ее интерпретировать. Поэтому собирайте много метрик о состоянии системы. Это помогает в поиске проблемы.

И, конечно, давайте будем писать код без багов, тогда у нас вообще все будет хорошо. На этом у меня все.
Подробнее..

Recovery mode Нужна ли России своя операционная система и другое ПО?

28.02.2021 12:13:00 | Автор: admin

Нужно ли России делать свою особую операционку и другое ПО?
Не спешите с выводами.

Изображение с сайтаcorchaosis.ru

В мире программного обеспечения важны:

  • Понятность, знакомость интерфейса пользователю. Если пользователю требуется три часа на то чтобы освоить ваш продукт, а у пользователя зарплата в месяц 100 000 рублей, то это эквивалентно тому что пользователь заплатил за ваш продукт больше на 1785.71 рублей.

    Как посчитал: (100 000 (зарплата) / 21 (рабочих дней))*(3 (часа)/8 (часов в рабочем дне)) = 1785.71 рублей. Это если вы раздаёте бесплатно свой продукт. Если за плату, то плюс его цена.

  • Совместимость с оборудованием и другими программами. В том числе тем что ещё не выпушено. Если вы делаете свою ОС, с которой не совместимы стандартные виндовые или линуксовые драйвера, значит, для каждого нового оборудования вам их придётся писать самим. Это тупик.

  • Кто разработчик и какова цена?

    - Плохо: Разработчик зарубежный, программа платная и дорогая. Примеры: Windows, MS Office, Photoshop, Oracle.

    - Лучше: Разработчик отечественный, программа дешёвая.

    - Хорошо: Проект опенсорсный (т.е. с публичным исходным кодом), программа бесплатная.

    - Совсем хорошо: Проект опенсорсный, программа бесплатная для России, разработчики ядра системы живут в России.

Что требуется сделать, чтобы в России было своё высококачественное ПО:

Берёте опенсорсные продукты (ОС, OpenOffice, PostgreSQL) и начинаете их улучшать силами программистов в России. [ Как требуется развивать PostgreSQL ] Максимально входим в каждый проект, подключаем самых квалифицированных профессионалов, цель - чтобы максимальную часть системы писали наши программисты, без права выезда из России. Если нас не пускают к ядру системы - анализируем, можем ли мы в своём отдельном продукте сделать лучше чем у них. Если да - создаём свою отдельную ветку продукта, если нет - создаём задачи для решения которых нужно знать ядро системы и сажаем программистов делать эти задачи, даже если они не особо актуальны.

Максимизируем совместимость. Я не понимаю почему Линукс не работает на Win32API. Свою третью систему команд - не линукс и не виндовс - точно делать не следует. Это же касается и процессоров Эльбрус - система команд должна быть общепринятой а не своей отдельной.

Никому не захочется покупать оборудование или игру специальной модификации для совместимости с конкретным ОС.

И никому не захочется переучиваться под не привычный экранный интерфейс. А это значит, российское законодательство надо модифицировать, явным образом прописав что копирование экранных интерфейсов компьютерных программ (кроме графики игр и мульмедийных систем) не запрещено. А затем на этой основе создавать специальные сборки OpenOffice с интерфейсом, идентичным программам от майкрософт. Создать операционку, которая будет выглядеть как MS Windows и иметь нативную, без wine, систему команд Win32API, можно наряду с линкувыми. Создать офисный пакет, который будет выглядеть и работать как MS Word, Excel, PowerPoint. Создать графический редактор, который будет выглядеть и работать как Adobe Photoshop. Желательно силами государства и в режиме опенсорс, максимально совместимо с примочками и драйверами других систем.

Пусть эта статься попадёт на глаза тому, кто принимает безотвестственные решения на ниве патритизма.

Подробнее..

Грубая оценка проблемности GitHub-проектов

18.02.2021 20:14:00 | Автор: admin

Здравствуйте, меня зовут Дмитрий Карловский и я практикую терморектальную ароматерапию. Понимаю, что каждый любит своё болото, и будет защищать его до последней капли жижи. Тем не менее, высокая инженерная культура требует объективности в оценке инструментов.


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


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


Проблемы


Ошибки в коде


Никому не нужен инструмент, который глючит или попросту не работает. На них обычно заводятся issue c тегом "bug".


Грабли в архитектуре


Архитектура может быть не заточена под нужный вам способ использования. Более того, порой архитектура никуда не годиться, даже в казалось бы основных сценариях использования. Issue в таком случае если и заводятся, то пространные в духе "как сделать то-то?" или "почему работает не так, как я ожидаю?".


Документация


Если документация не полна, не актуальна или её вовсе нет, то освоение инструмента будет сопряжено с трудностями. На неё обычно заводятся issue с тегом "documentation".


Несовершенство


Если какая-либо фича реализована не очень удобно или вообще не реализована, то приходится писать свои фасады, декораторы, адаптеры и прочие прокси, чтобы приспособить инструмент к реалиям своего проекта. На них обычно заводятся issue с тегом "improvement".


Поддержка


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


Сравниваем


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


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


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


TypeScript или FlowJS?



Правильный ответ Haxe. Во всяком случае проблемность его существенно ниже. Хотя и тоже далеко не блещет.


React или Angular?



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


Redux или MobX?



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


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


MomentJS или Luxon?



Ага, красный флаг у date-fns. А ведь именно её часто рекомендуют любители функциональных многоножек и шатания деревьев.


Выводы


К сожалению, если за инструментом стоит большая корпорация, то это вовсе не значит, что огребёте вы с ним меньше, чем с другим, который поддерживает один разраб на голом энтузиазме. Более того, крупная корпорация с гораздо большей вероятностью сделает неповоротливого монстра, которого благополучно закопает через несколько лет, оставив вас с тонной легаси (привет, AngularJS, здарова, Polymer, виват, GWT, алоха, GCT). Малые же команды более мотивированы сделать что-то простое, что они смогут поддерживать своими небольшими ресурсами.


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


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


Моя тулза для сравнения доступна на compare.github.hyoo.ru. Имейте ввиду, что она использует API гитхаба с вашего IP, а у него довольно жёсткие лимиты. Так что если гитхаб начнёт сыпать 403 ошибками, то можете либо подождать немного, либо поменять IP через VPN.


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

Подробнее..

Перевод Эффективная конструкция агрегатов. Моделирование одиночного агрегата

21.02.2021 12:18:25 | Автор: admin

Эта статья является конспектом материала Effective Aggregate Design Part I: Modeling a Single Aggregate.

Объединение сущностей (entities) и объектов значений (value objects) в агрегат с тщательно продуманными границами согласованности может показаться простым, но из всех тактических DDD шаблонов, агрегат является одним из самых сложных.

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

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

Разработка приложения ProjectOvation

Давайте рассмотрим агрегаты на примере. Наша фиктивная компания разрабатывает приложение для поддержки проектов, основанных на методологии Scrum. Приложение следует традиционной модели управления проектами по методологии Scrum, то есть имеются продукт (product), владелец продукта (product owner), команды (team), элементы бэклога (backlog items), запланированные релизы (planned releases), спринты (sprints). Терминология Scrum формирует стартовую точку единого языка (ubiquitous language). Каждая организация, которая покупает подписку, регистрируется как арендатор (tenant), это еще один термин для нашего единого языка.

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

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

  • Продукты имеют элементы бэклога, релизы и спринты.

  • Можно добавлять новые элементы бэклога.

  • Можно добавлять новые релизы.

  • Можно добавлять новые спринты.

  • Запланированный элемент бэклога можно привязать к релизу.

  • Запланированный элемент бэклога можно привязать к спринту.

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

Первая попытка: большой агрегат

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

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

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

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

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

В результате Product был смоделирован как очень большой агрегат. Корневой объект, Product, содержит все BacklogItem, все Release, все Sprint экземпляры, связанные с ним. Такой интерфейс защищал все детали от случайного удаления клиента. Эта конструкция показана в следующем коде и в виде UML-диаграммы ниже.

public class Product extends ConcurrencySafeEntity {    private Set<BacklogItem> backlogItems;    private String description;    private String name;    private ProductId productId;    private Set<Release> releases;    private Set<Sprint> sprints;    private TenantId tenantId;    ...}
Рис. 1. Product смоделирован как очень большой агрегат.Рис. 1. Product смоделирован как очень большой агрегат.

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

Рассмотрим общий многопользовательский сценарий:

  • Два пользователя, Билл и Джо, смотрят одинаковый Product c версией 1 и начинают работать с ним.

  • Билл планирует новый BacklogItem и сохраняет. Версия становится 2.

  • Джо планирует новый Release и пытается сохранить, но он получает ошибку, так как версия его копии Product устарела и равнялась 1.

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

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

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

Вторая попытка: несколько агрегатов

Теперь рассмотрим альтернативную модель, которая показана на рисунке 2. У нас есть четыре агрегата. Каждая зависимость использует ProductId, который является идентификатором Product-а.

Рис. 2. Product и связанные с ним понятия моделируются как отдельные агрегаты.Рис. 2. Product и связанные с ним понятия моделируются как отдельные агрегаты.

Разбиение большого агрегата на четыре изменит контракт метода для Product. С большим агрегатом сигнатуры методов выглядели следующим образом:

public class Product ... {    ...      public void planBacklogItem(        String aSummary, String aCategory,        BacklogItemType aType, StoryPoints aStoryPoints) {      ...      }    ...      public void scheduleRelease(        String aName, String aDescription,        Date aBegins, Date anEnds) {      ...      }      public void scheduleSprint(        String aName, String aGoals,        Date aBegins, Date anEnds) {        ...      }      ...}

Все эти методы являются командами. То есть они модифицируют состояние Product, добавляя новый элемент в коллекцию, поэтому их возвращаемый тип void. Но с отдельными агрегатами мы имеем:

public class Product ... {    ...      public BacklogItem planBacklogItem(        String aSummary, String aCategory,        BacklogItemType aType, StoryPoints aStoryPoints) {      ...      }        public Release scheduleRelease(        String aName, String aDescription,        Date aBegins, Date anEnds) {        ...      }      public Sprint scheduleSprint(        String aName, String aGoals,        Date aBegins, Date anEnds) {        ...      }      ...}

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

public class ProductBacklogItemService ... {     ...     @Transactional     public void planProductBacklogItem(           String aTenantId, String aProductId,           String aSummary, String aCategory,           String aBacklogItemType, String aStoryPoints) {           Product product =                   productRepository.productOfId(                                 new TenantId(aTenantId),                                new ProductId(aProductId));           BacklogItem plannedBacklogItem =                  product.planBacklogItem(                            aSummary,                            aCategory,                            BacklogItemType.valueOf(aBacklogItemType),                            StoryPoints.valueOf(aStoryPoints));                    backlogItemRepository.add(plannedBacklogItem);      }      ...}

Таким образом, мы решили проблему сбоя транзакции. Теперь любое количество экземпляров BacklogItem, Release и Sprint можно безопасно создавать с помощью одновременных запросов.

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

Моделируйте истинные инварианты в контексте согласованности

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

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

c = a + b

Поэтому, когда, а = 2 и b = 3, с должно равняться 5. Согласно этому правилу, если с не равняется 5, то нарушается инвариант. Чтобы убедиться, что значение с согласовано, мы моделируем границу вокруг этих атрибутов модели.

AggregateType1 {    int a; int b; int c;    operations...}

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

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

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

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

Проектируйте небольшие агрегаты

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

Что произойдет, когда пользователь захочет добавить элемент бэклога в продукт, которому уже много лет и у которого уже тысячи таких элементов бэклога? Предположим, что в механизме персистентности доступна ленивая загрузка (lazy loading). Мы почти никогда не загружаем все элементы бэклога, релизы и спринты сразу. Тем не менее, тысячи элементов бэклога будут загружены в память, чтобы добавить еще один новый элемент в коллекцию. Хуже, если механизм персистентности не поддерживает ленивую загрузку. Иногда нам приходится загружать несколько коллекций, например, во время добавления элемента бэклога в релиз или в спринт. Все элементы бэклога, а также все релизы или все спринты будут загружены.

Чтобы увидеть это более наглядно, посмотрим на диаграмму на рисунке 3. Не позволяйте 0..* обмануть вас. Число ассоциаций почти никогда не будет равным нулю и будет постоянно расти с течением времени. Скорее всего, нам придется загружать тысячи и тысячи объектов в память одновременно для выполнения относительно простых операций. И это только для одного члена команды одного арендатора. Мы должны иметь в виду, что это подобная ситуация может произойти одновременно с сотнями и тысячами арендаторов, каждый из которых имеет несколько команд и множество продуктов. И со временем ситуация будет только ухудшаться.

Рис. 3. Модель Product. Несколько больших коллекций загружается во время множества простых операций.Рис. 3. Модель Product. Несколько больших коллекций загружается во время множества простых операций.

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

Если мы собираемся проектировать небольшие агрегаты, то нам необходимо выяснить, что значит небольшой. Крайним случаем будет агрегат с его глобальным идентификатором и одним дополнительным атрибутом, что не рекомендуется делать, если только это действительно не то, что требуется одному конкретному агрегату. Лучше будет, если ограничим агрегат только корневой сущностью (root entity), минимальным количеством атрибутов и/или объектов значений (object value).

Однако, какие именно данные (атрибуты, объекты значения) необходимы? Ответ прост: те, что должны иметь согласованность друг с другом. Например, Product имеет атрибуты name и description. Мы не можем представить эти атрибуты несогласованными, смоделированными в отдельных агрегатах. Если вы изменяете только один из этих атрибутов, то вероятно, потому что вы исправляете ошибку. Даже если эксперты предметной области не будут думать об этом как о явном бизнес-правиле, это неявное правило.

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

Однако иногда использования нескольких сущностей имеет смысл. Например, сумма заказа не должна превышать максимально допустимое значение. Из этого следует, что и сумма всех элементов заказа не должна превышать допустимое значение. Если заказ и элементы заказа будут находиться в разных агрегатах, то одновременное добавление элемента заказа несколькими пользователями может превысить этот лимит. В этом случае лучше объединить сущности Order и OrderItem в один агрегат. Но следует подчеркнуть, что в большинстве случаев инвариантами бизнес-моделей управлять проще, чем в этом примере. Признавая это, помогает нам моделировать агрегаты с как можно меньшим количеством свойств.

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

Не доверяйте каждому сценарию использования

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

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

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

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

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

Подробнее..

Перевод Эффективная конструкция агрегата. Заставляем агрегаты работать вместе

23.02.2021 10:12:21 | Автор: admin

Эта статья является конспектом материала Effective Aggregate DesignPart II: Making Aggregates Work Together.

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

Мы можем захотеть использовать композиционную структуру во время проектирования агрегатов. Такая структура позволит нам обходить глубокие графы объектов. Однако это не должно быть целью. DDD утверждает, что один агрегат может содержать ссылки на корень других агрегатов. Но это не значит то, что агрегаты входят в границу согласованности другого агрегата, который на них ссылается. Ссылка не приводит к образованию единого агрегата.

Рис. 1. Изображено два агрегата, а не один.Рис. 1. Изображено два агрегата, а не один.

На Java это выглядело бы следующим образом:

public class BacklogItem extends ConcurrencySafeEntity {  ...  private Product product;  ...}

BacklogItem содержит прямую связь с объектом Product.

Это имеет несколько последствий:

  • BacklogItem и Product не должны вместе изменяться в рамках одной транзакции, а только один из них.

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

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

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

Ссылайтесь на другие агрегаты по идентификатору

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

Рис. 2. BacklogItem содержит связи с другими агрегатами за пределами своей границы с помощью идентификаторов.Рис. 2. BacklogItem содержит связи с другими агрегатами за пределами своей границы с помощью идентификаторов.
public class BacklogItem extends ConcurrencySafeEntity {  ...  private ProductId productId;  ...}

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

Модель навигации

Ссылки по идентификатору полностью не исключают доступ к другим агрегатам. Можно использовать репозиторий изнутри агрегата для поиска. Такой метод называется автономной доменной моделью (disconnected domain model). Однако существуют другие рекомендуемые подходы. Используйте репозиторий или доменную службу для поиска зависимых объектов снаружи агрегата, то есть, например, в службах уровня приложения (application service).

public class ProductBacklogItemService ... {    ...    @Transactional    public void assignTeamMemberToTask( String aTenantId,        String aBacklogItemId, String aTaskId,        String aTeamMemberId) {        BacklogItem backlogItem = backlogItemRepository.backlogItemOfId(          new TenantId(aTenantId),          new BacklogItemId(aBacklogItemId)        );        Team ofTeam =        teamRepository.teamOfId( backlogItem.tenantId(), backlogItem.teamId());        backlogItem.assignTeamMemberToTask(          new TeamMemberId(aTeamMemberId), ofTeam,          new TaskId(aTaskId)        );      }      ...}

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

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

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

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

Используйте конечную согласованность за пределами границ

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

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

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

public class BacklogItem extends ConcurrencySafeEntity {  ...  public void commitTo(Sprint aSprint) {    ...    DomainEventPublisher    .instance()    .publish(      new BacklogItemCommitted(             this.tenantId(),             this.backlogItemId(),             this.sprintId()          )    );  }  ...}

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

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

В некоторых сценариях предметной области сложно определить, следует ли использовать транзакционную или конечную согласованность. Те, кто использует DDD классическим способом, могут склоняться к транзакционной согласованности. Те, кто используют CQRS, могут склоняться к конечной согласованности. Но что правильно в итоге? По правде говоря, ни один из этих подходов не дает конкретного ответа, только техническое предпочтение. Есть ли лучше способ решить эту проблему?

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

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

Причины нарушения правил

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

Причина первая: удобство пользовательского интерфейса

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

public class ProductBacklogItemService ... {    ...    @Transactional    public void planBatchOfProductBacklogItems(       String aTenantId, String productId,       BacklogItemDescription[] aDescriptions) {        Product product = productRepository.productOfId(          new TenantId(aTenantId), new ProductId(productId)        );        for (BacklogItemDescription desc : aDescriptions) {           BacklogItem plannedBacklogItem = product.planBacklogItem(             desc.summary(), desc.category(),             BacklogItemType.valueOf(desc.backlogItemType()),             StoryPoints.valueOf(desc.storyPoints())          );            backlogItemRepository.add(plannedBacklogItem);        }    }    ...}

Это вызывает проблемы с управлением инвариантов? В данном случае нет, поскольку не имеет значения, были ли они созданы по одному или сразу все вместе. Создаваемые экземпляры объектов являются агрегатами, которые сами поддерживают собственные инварианты. Таким образом, если создание нескольких экземпляров агрегата за один раз семантически ничем не отличается от многократного создания одного за раз, это является первой причиной нарушения правил.

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

Причина вторая: отсутствие технических инструментов

Конечная согласованность требует дополнительные инструменты для внепроцессорной обработки, таких как обмен сообщениями или таймеры. Что делать, если проект, над которым вы работаете, не предусматривает такого механизма? Хотя большинство из нас сочло бы это странным, но автор оригинала сталкивался именно с таким ограничением. Без механизма обмена сообщениями, без таймеров и другого, что можно было бы сделать?

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

Автор упомянул еще один фактор, который способствует нарушению правил - user-aggregate affinity. Я не до конца понял, о чем идет речь, поэтому не стал добавлять его в конспект. Если интересно, можно посмотреть в оригинале.

Причина третья: глобальные транзакции

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

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

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

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

Вывод

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

Ссылки на все части

Подробнее..

Перевод Эффективная конструкция агрегатов. Понимание через исследование

28.02.2021 10:04:21 | Автор: admin

Эта статья является конспектом материала Effective Aggregate DesignPart III: Gaining Insight Through Discovery.

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

Переосмысление конструкции модели

После итерации рефакторинга, благодаря которой избавились от большого агрегата Product, BacklogItem стал отдельным агрегатом. Новую версию модели можно увидеть на рисунке 1. Агрегат BacklogItem содержит коллекцию экземпляров Task. Каждый BacklogItem имеет глобальный уникальный идентификатор BacklogItemId. Ассоциация с другими агрегатами происходит через идентификаторы. Агрегат BacklogItem кажется довольно небольшим.

Рис.1. Схема модели агрегата BacklogItemРис.1. Схема модели агрегата BacklogItem

Несмотря на положительный результат после первой итерации, некоторые опасения все же существуют. Например, атрибут story позволяет вмещать в себя большой объем текста. Из-за этого могут возникнуть возможные накладные расходы.

Учитывая эти потенциальные накладные расходы и ошибки, которые были допущены при проектировании большого кластерного агрегата, поставим перед собой цель уменьшить размер каждого агрегата в ограниченном контексте. Возникают некоторые вопросы. Существует ли истинный инвариант между BacklogItem и Task? Или эту связь можно разбить на две? Какова цена сохранения такой модели?

Ответ лежит в едином языке. Имеются следующие инварианты:

  • После достижения прогресса в задаче элемента бэклога, член команды должен оценить оставшееся время выполнения задачи.

  • Когда член команды оценивает время в 0 часов, элемент бэклога проверяет все задачи на наличие оставшихся часов. Если их нет, то статус элемента бэклога автоматически меняется на done.

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

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

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

Оценка стоимости агрегата

Как показано на рисунке 1, каждый Task содержит коллекцию экземпляров EstimationLogEntry. Этот журнал фиксирует конкретные случаи, когда член команды выполняет новую оценку оставшихся часов. На практике, сколько элементов Task может содержать BacklogItem, и сколько элементов EstimationLogEntry будет содержать Task? Точно сказать сложно. Во многом это показатель того, насколько сложна задача и сколько будет длиться спринт. Но некоторые расчеты все же могут помочь.

Часы работы обычно пересчитываются каждый день после того, как член команды закончил работать над определенной задачей. Предположим, что большинство спринтов длится две или три недели. Давайте выберем количество дней от 10 до 15, например, пусть будет 12 дней.

Теперь рассмотрим количество часов, выделенных на каждую задачу. Обычно используют количество часов от 4 до 16. Часто, если задача превышает 12 часов, то эксперты Scrum предлагают разбить ее на более мелкие. В качестве теста предположим, что задачи оцениваются в 12 часов (1 час на каждый день спринта). Итак, получается 12 пересчетов для каждой задачи, предполагая, что каждая задача начинается с 12 часов, выделенные на нее.

Остается вопрос: сколько задач потребуется всего для одного элемента бэклога? Пусть будет, например, тоже 12 (я не стал расписывать, как автор пришел к такому числу; можно самому глянуть в оригинале). В итоге получается 12 задач, каждая из которых содержит 12 оценок в журнале, или 144 (12*12) на элемент бэклога. Хотя это может быть больше чем обычно, но это дает нам конкретную оценку для анализа.

Есть еще одно, что следует учесть. Если следовать рекомендациям экспертов Scrum по определению более мелких задач, это бы несколько изменило ситуацию. Удвоение числа задач (24) и уменьшение вдвое числа записей журнала (6) все равно дают 144. Однако это приведет к загрузке большего количества задач (24 вместо 12) во время запроса на оценку часов, потребляя при этом больше памяти. Но для начала давайте использовать 12 задач по 12 часов каждая.

Общие сценарии использования

Теперь важно рассмотреть общие сценарии использования. Как часто в одном пользовательском запросе нужно будет загружать в память все 144 объекта одновременно? Произойдет ли вообще это когда-то? Если нет, то каково максимальное количество объектов? Кроме того, будет ли многопользовательские запросы, которые могут привести к транзакционной конкуренции? Давайте посмотрим.

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

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

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

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

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

Будут ли ежедневные оценки приводить к проблемам? В первый день спринта обычно нет журналов оценки по заданной задаче элемента бэклога. В конце первого дня каждый член команды, работающий над задачей, сокращает расчетное количество часов на один. Это добавляет новую запись в журнал оценки к каждой задаче, но статус элемента бэклога не изменяется. При этом только один член команды корректирует часы определенной задачи. Только на 12-й день происходит изменение статуса. После того, как будет добавлена последняя 144 запись в журнал для 12 задаче, происходит автоматический переход статуса в done.

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

Потребление памяти

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

Что насчет общего количества задач и оценок в памяти во время каждого повторного оценивания? При использовании ленивой загрузки для задач и журналов оценки у нас будет до 12 + 12 объектов в памяти во время одного запроса, поскольку все 12 задач будут загружены во время обращения к этой коллекции. Чтобы добавить последнюю запись в журнал оценки к одной из задач, нужно загрузить коллекцию записей журнала и это дает еще до 12 объектов. В конечном итоге агрегат содержит один элемент бэклога, до 12 задач и до 12 записей в журнале, что в сумме дает максимум 25 объектов. Это не очень много. Другой факт заключается в том, что максимальное количество объектов не достигается до последнего дня спринта. В течение большей части спринта агрегат будет еще меньше.

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

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

Альтернативная конструкция

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

Рис. 2. BacklogItem и Task как отдельные агрегатыРис. 2. BacklogItem и Task как отдельные агрегаты

Однако в этом случае, если придерживаться правил, то нельзя изменять в одной транзакции Tak и BacklogItem. Следовательно, при необходимости автоматической смены статуса согласованность между задачей и элементом бэклога будет конечной, а не транзакционной.

Реализация конечной согласованности

Когда Task выполняет команду estimateHoursRemaining(), она публикует соответствующие доменное событие для достижения конечной согласованности. Событие имеет следующие свойства:

public class TaskHoursRemainingEstimated implements DomainEvent {     private Date occurredOn;    private TenantId tenantId;    private BacklogItemId backlogItemId;     private TaskId taskId;    private int hoursRemaining;    ...}

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

  • Использует BacklogItemRepository для получения BacklogItem по идентификатору.

  • Использует TaskRepository для получения всех экземпляров Task, связанных с конкретным BacklogItem

  • Выполняет BacklogItem команду estimateTaskHoursRemaining(), передавав ей значение hoursRemaining и определенный экземпляр Task. BacklogItem может менять свой статус в зависимости от параметров.

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

public class TaskRepositoryImpl implements TaskRepository {    ...    public int totalBacklogItemTaskHoursRemaining(       TenantId aTenantId,        BacklogItemId aBacklogItemId) {            Query query = session.createQuery(            "select sum(task.hoursRemaining) from Task task "            + "where task.tenantId = ? and "            + "task.backlogItemId = ?");            ...    }}

Конечная согласованность немного усложняет пользовательский интерфейс. Если согласование состояния не произойдет в течение нескольких сотен миллисекунд, как пользовательский интерфейс отобразит новое состояние? Необходимо ли размещать бизнес-логику в представлении для определения текущего статуса? Это был бы антипаттерн умный UI. В противном случае представление отобразит устаревший статус. Это легко может быть воспринято как ошибка.

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

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

Время принимать решение

Исходя из всего этого анализа, возможно будет лучше отказаться от разделения Task и BacklogItem. Сейчас оно не стоит дополнительных усилий, риска нарушения истинного инварианта или возможности столкнутся с устаревшим статусом в представлении. Текущий агрегат довольно мал. Даже если в худшем случае будет загружено 50 объектов, а не 25, это все равно кластер небольшого размера.

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

Вывод

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

  • Моделируйте истинные инварианты в границах согласованности.

  • Проектируйте небольшие агрегаты.

  • Ссылайтесь на другие агрегаты по идентификатору.

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

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

Ссылки на все части

Подробнее..

Перевод Погружение в CQRS

03.03.2021 10:13:29 | Автор: admin

Эта статья является конспектом материала Clarified CQRS.

Прежде чем начать разбираться с CQRS, нужно понять две основные движущие силы, стоящие за ним: сотрудничество и устаревание.

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

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

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

Рис.1. Модель CQRSРис.1. Модель CQRS

Компоненты на рисунке с названием AC являются автономными системами. Позже будет описано, что делает их автономными во время обсуждения команд (Commands CQRS). Но для начала давайте разберемся с запросами (Queries CQRS)

Запросы (Queries)

Если данные, которые собираемся показывать пользователям, все равно устаревшие, нужно ли идти в основную БД и получать их из нее? Зачем преобразовывать эти структуры в доменные объекты, если нам нужны только данные, а не поведение?

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

Как насчет того, чтобы создать дополнительное хранилище данных, данные которого могут быть немного не синхронизированы с основной БД имеется в виду, что данные, которые показываются пользователям, все равно устарели, так почему бы не отразить их в самом хранилище данных?

Какая же будет структура такого хранилища данных? Как на счет по одной таблице для каждого представления? Данные формируются с помощью одного запроса SELECT * FROM MyViewTable и передаются пользователю на экран. Это было бы максимально просто. Можно при необходимости это обернуть тонким фасадом. В итоге данные для представления уже будут готовы и не нужно преобразовывать их во что-то другое (например, в доменные объекты).

Хранилище данных для запросов

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

Масштабирование запросов

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

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

Модификация данных

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

Допустим, у нас есть представитель службы поддержки клиентов, который разговаривает по телефону с клиентом. Этот пользователь смотрит на данные клиента на экране и хочет их изменить (адрес, ФИО и др.). Однако пользователь не знает, что после отображения данных на экране произошло некое событие. Из отдела выставления счетов пришло уведомление, что этот же клиент не оплачивает свои счета они просроченные. На данном этапе пользователь отправляет данные для изменения. Стоит ли принимать эти изменения?

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

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

Чтобы предоставить правильный уровень детализации данных и избежать конфликтов используются команды (CQRS).

Команды (Commands)

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

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

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

Команды и валидация

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

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

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

Переосмысление UIs и команды с точки зрения валидации

Клиент может использовать хранилище запросов (Queries) для проверки команд. Например, перед отправкой команды, мы можем проверить, существует ли название улицы в хранилище запросов.

В этот момент мы можем переосмыслить UI и сделать автоматическое заполнение текстового поля для названия улицы, таким образом, гарантируя, что название улицы, которое мы передадим в команде, будет действительным. Но почему бы не пойти дальше, например, указывать ID улицы вместо ее названия. Пусть команда представляет улицу не в виде строки, а в виде ID (int, guid или др.).

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

Причины сбоя валидных команд и что с этим делать

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

В приведенном выше примере отклонение происходит только потому, что событие биллинга пришло первым. Но первый может быть за миллисекунду до команды. Что, если пользователь нажал кнопку на миллисекунду раньше? Должно ли это на самом деле изменить бизнес-результат?

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

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

Команды и автономность

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

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

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

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

Автономные компоненты

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

Уровень обслуживания (service layer)

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

Смотря на уровень обслуживания с точки зрения команд мы видим, что объекты обрабатываются различными командами. Каждая команда не зависит от другой, так почему мы должны позволять объектам, которые их обрабатывают, зависеть друг от друга? Зависимости это вещи, которых следует избегать, если для них нет веской причины.

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

Где доменная модель?

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

Еще одна вещь, которую следует понять это то, что доменная модель не использует запросы (CQRS). Итак, вопрос в том, зачем нужно иметь так много связей между сущностями в доменной модели?

Действительно ли нам нужна коллекция заказов для сущности клиент? В какой команде нам нужно перемещаться по этой коллекции? Нужно ли в самом деле для команды отношение один ко многим?

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

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

Персистентность для обработки команд

Учитывая, что БД, используемая для обработки команд, не используется для запросов и что большинство команд содержат идентификаторы строк, на которые они будут влиять, действительно ли нужен столбец для каждого отдельного свойства объекта домена? Что, если просто сериализовать доменную сущность и поместить ее в один столбец, а другой столбец будет содержать идентификатор? Это звучит очень похоже на хранилище key-value. В таком случае действительно ли нужно объектно-реляционное преобразование данных? Также можно выделить дополнительные свойства для каждого фрагмента данных, которое требует обеспечения уникальности.

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

Синхронизация хранилища запросов

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

MakeCustomerPerferredCommand CustomerHasBeenMadePerferredEvent

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

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

Ограниченный контекст

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

Пользовательский интерфейс, находящийся в каждом бизнес-компоненте, может быть собран в одно приложение, которое предоставляет пользователям единое составное представление обо всех частях предметной области.

Вывод

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

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

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

Подробнее..

Recovery mode Создаём компанию мечты мастер-данные и интеграция

03.03.2021 00:13:52 | Автор: admin
Есть легенда, что когда Билл Гейтс с коллегами продумывали архитектуру будущей Windows 3.1, они рисовали её от руки на склеенных ватманах. Маленькие квадратики обозначали блоки и модули системы, а стрелочки между ними потоки данных из одной системы в другую. Эта схема поместилась целиком на полу в кабинете у самого Гейтса, правда, пришлось вынести в коридор стол и стулья.

Год спустя, при проектировании новой операционки Windows 95, ребята вынесли целую столовую. Но через пару месяцев работы стало понятно, что и в ней места уже не хватит. И если позволить приложениям и дальше общаться с операционной системой и друг с другом по-старому, получится истинный ад бесконечных взаимосвязей и зависимостей. Нужен был принципиально другой подход

image

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

Интеграция

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

Особенно остро ситуация проявляется в крупных компаниях, где в интеграционном контуре может оказаться 10-20 разных информационных систем, и необходимо обеспечить непрерывность бизнес-процессов при передаче данных во всех направлениях.

image

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

В этой статье я хочу описать основные этапы процесса, как он обычно стихийно складывается в крупных компаниях. Ввести шкалу интеграционного развития компании от 1 до 10. Эта шкала, конечно, будет отражать и сам рост компании, рост уровня развития административных технологий в компании. А также хочу наметить основные векторы развития: куда бежать, что делать и кто во всём этом виноват. Шутка.

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

Также в статье почти нет названий конкретных продуктов или технологий, т.к. в области интеграции нет дорог, есть направления. Нет конкретного продукта, который просто поставил и пользуешься. Речь всегда будет идти о разработке, как минимум, коннекторов. Упоминаются 1С, Windows, Office как широко распространённое ПО, но вместо них без потери смысла можно подставить SAP, Linux и т.д.

Конечно, примеры упрощены в целях наглядности. Несколько вопросов останутся открытыми. И сам подход, как это всегда бывает в IT, не является единственно верным, поэтому приглашаю всех к дискуссии.

Эта статья будет особенно интересна руководителям IT, архитекторам, интеграторам, а также всем, кто работает в достаточно крупных компаниях.

Уровень 0

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

Чтобы платить налоги (если у вас не вменённый доход), вам нужно как-то посчитать, сколько денег вы всего заработали за период. Маловероятно, что ИП сразу начнёт работать по безналу, а при работе с налом с недавних пор в России требуется кассовый аппарат.

Конечно, вы захотите составить каталог своих товаров и услуг, чтобы можно было сразу выбрать его из списка и пробить чек. А в конце месяца посчитать и увидеть, что позиция А вам приносит на х% больше, чем позиция Б.

Так на вашем ноутбуке появляется простенькая 1С-ка или любой другой аналогичный продукт.

image

image


Уровень 1: отрицание

Бизнес идёт отлично, у вас появился помощник, затем ещё один.

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

Вы читаете инструкцию к кассе, настраиваете подключение через мобильный интернет. Либо обращаетесь в компанию, где купили её, там вам с удовольствием помогают. Про какую-либо интеграцию речи пока не идёт.

image

image


Уровень 2

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

И ещё один договор, третий, с поставщиком, а то как-то с устными договорённостями о поставках у него не очень: нарушает сроки, есть вопросы по качеству.

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

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

image


Уровень 3: гнев

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

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

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

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

Затем раздался звонок. Нет, не так. ЗВОНОК. Не так пошло не только лишь всё, вам пришлось в срочном порядке возвращаться домой и восстанавливать всё, что без вас чуть не поломали: отношения с клиентами, процессы, учёт.

С самым смышлёным пришлось расстаться, а для себя вы сделали два вывода:

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

2. Вы понимаете, что нужен инструмент, который позволит вам в любой момент понимать, как сейчас идёт бизнес. Регулярные отчёты. Ну, ладно, не в любой момент, но хотя бы раз в неделю? Нет? Хорошо, раз в месяц.

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

Недавно нанятый менеджер привел в компанию толковую бухгалтершу пока на неполный рабочий день, конечно. Она же объяснила, что для работы вам нужно будет заказать у франчайзи 1С разработку пары отчётов, без которых вот совсем никак. Также она взяла на себя расчёт зарплаты и кадровое делопроизводство, только начала вести их не в 1С, а в другой программе, которой их учили в колледже.

image

image


Уровень 4

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

У вас сформировалась репутация надёжного партнёра, число клиентов превысило 20, а в компании трудится уже около 50 человек. Появилось несколько отделов!

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

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

Начали думать о программе для управления складом и поставками (было пару кейсов увезли товар не тому клиенту), но 1С-ник подсказал, что можно купить модуль склада для 1С. Или вообще ничего не покупать, он сам напишет лучше и именно с учётом ваших потребностей.

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

Паренёк-айтишник недавно закончил университет и предложил написать свою CRM, которая включала бы в себя и весь ваш производственный цикл. 1С-ник обещал ему помочь. И буквально за пару недель они набросали работающий прототип, им вполне можно было пользоваться!

Оба говорили и вели себя достаточно уверенно, и в этот момент вы серьёзно задумались: развивать ли свою собственную IT-службу, разрабатывать ли собственные решения или обратиться к какому-нибудь интегратору, воспользоваться услугами аутсорсинга?

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

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

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

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

image

image


Уровень 5: торг

С ростом бизнеса был открыт офис в соседнем областном центре, потом в северной столице. Настал очередной критический момент в развитии бизнеса и компании региональное масштабирование.

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

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

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

Разработчик 1С *) вышел с предложением купить и внедрить модуль для учёта мастер-данных это когда вся информация по всем общим справочникам (например, по структуре, сотрудникам, контрагентам) собирается и контролируется в одной системе. А также чтобы все обмены информацией шли через эту систему, тогда этот процесс будет наглядным и управляемым. Если будут какие-то ошибки, их сразу заметят а это особенно важно. Пару месяцев назад уже был прецедент, когда информация о зарплате не выгрузилась из кадровой системы в 1С, и зарплату сотрудникам не перечислили вовремя.

Что для этого нужно? Выбрать такую систему. Разработчики советуют решение на платформе 1С это конструктор, который нужно дорабатывать для себя. Будущее этого решения пока не очень понятно, но обоснование его нужности звучит понятно и логично. Берём!

*) повторю, что 1С здесь только для примера. Решения класса MDM (управление мастер-данными) и ESB (интеграционная шина предприятия) доступны почти у всех платформ и вендоров. Это может быть и SAP, IBM, Oracle, и бесплатные решения Fuse, Mule и др.


image

image


Уровень 6

Территориальную экспансию компании можно сравнить со взрывом! За пару лет было открыто несколько десятков офисов, штат компании увеличился в несколько раз. Были открыты первые зарубежные офисы в нескольких странах бывшего СССР. Люди там, в общем-то, нашенские, процессы все понятные, законодательство и налогообложение практически не отличаются от России.

Главный вопрос в планировании IT-ландшафта и интеграции на этот момент есть ли возможность каждой информационной системе работать для всех стран одновременно? На практике у каждой системы оказались свои нюансы. Бухгалтерская и кадровая системы их нужно вести строго в разных базах. MDM и ESB пришлось доработать таким образом, что в большинстве справочников появилась страновая привязка. Причём некоторые элементы (например, ФИО, должности, названия контрагентов) пришлось хранить сразу на нескольких языках.

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

На самом деле, вы довольны ситуацией в IT и IT-командой. Заложенные когда-то основы позволили без особых трудностей и стоп-факторов осуществить экспансию. Трудно представить, сколько сил и ресурсов у вас ушло бы сейчас, если бы в компании не было мастер-данных и шины данных. Про CRM вообще молчим!

image

image


Уровень 7: депрессия

Казалось бы, всё прекрасно. Обмены работают, данные ходят, бизнес-процессы выполняются. Но.

В последнее время всё чаще слышится с разных сторон, что данные неправильные. Все системы, всю интеграция многократно проверили, протестировали. Нет, никаких технических ошибок и сбоев нет, всё работает как часы.

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

Что-то пошло не так. Разработчики пошли разбираться, подняли историю. Оказалось, что при каком-то перезаключении трудового договора кадровик опечатался, ввёл неправильную дату. Понятно, обычный человеческий фактор, ничего страшного.

На следующий день вы заключили важный контракт. Предоплата? Нет, несколько дней деньги на счёт не поступают. Точно перечислили? Точно перечислили! А что не так? Звонок в банк, те говорят: ошибка! Оказалось, что в системе MDM устарели данные о реквизитах: они поменялись. А сотрудник, который должен был их исправить, заболел.

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

У вас даже возникли мысли, а не заменить ли используемые продукты. Вот, на одной презентации рассказывали, что продукты SAP (Oracle, IBM) не глючат! Разработчики возражают: нет, дело не в продуктах, дело в процессах. Провели внешний аудит, он подтвердил: технически системы работают корректно.

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

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

Проблема с качеством данных? Хорошо, у разработчиков, наверное, есть множество инструментов для контроля качества данных, для автоматизации процесса. Сколько-сколько? И что, только руками писать проверки?

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

image


Уровень 8

Есть решение проблемы качества данных!

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

Появилось понятие ответственного за данные (очевидно, что им не может быть IT-департамент), за каждую конкретную запись в каждом справочнике. Были проанализированы все процессы и разработан механизм классификации ошибок, механизм создания проверок данных. Ведь по мере накопления данных появляются всё новые и новые виды ошибок, а, значит, процесс заведения правил и проверок должен быть встроен, по сути, в сам процесс ввода данных.

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

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

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

Была разработана система контроля качества данных DQS, как модуль MDM. Она запускала проверки (по расписанию и при добавлении каждой записи) и сообщала об ошибке персонально тому, кто эту ошибку допустил. С описанием возможных последствий.

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

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

image

image


Уровень 9: принятие

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

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

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

Оставим за скобками административную часть и бизнес-процессы. Если говорить про интеграцию, технически сама задача не очень сложная. Проводится обучение новых сотрудников, затем фиксируется некоторая точка во времени, час Икс. После часа Икс все вновь запускаемые процессы, новые контрагенты, новые договоры должны вестись строго в ваших основных системах. Рост на 10-20%, даже на 50% эти системы выдержат без особых проблем. Все современные системы класса MDM, ESB, CRM и др. позволяют масштабировать себя, просто докупая новое серверное оборудование.

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

image

image


Уровень 10

Выгрузив в очередной раз отчётность из BI-системы, вы загляделись на цифры и задумались. Численность сотрудников в вашей компании скоро будет шестизначной, это население целого города. Годовой оборот близок к 0.1% ВВП России и превысил ВВП республик Алтай и Тува. На территории бывш. СССР рынок весь ваш! И, честно говоря, он занят полностью. На нём расти больше некуда.

Недавно свершилось событие, о котором вы мечтали много лет! Вы поглотили небольшую компанию, работающую на рынке Евросоюза и поставили несколько новых флажков на карте.

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

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

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

И самое главное: данные должны храниться на серверах на территории Евросоюза. В дальнейшем эти или похожие требования будет появляться во всё новых и новых странах, а за их нарушение предусматриваются просто огромные штрафы. В случае Евросоюза это до 20 млн евро или до 4% от мирового оборота компании.

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

Местная компания, региональная, федеральная, что дальше? Глобальная?

Весь мир ждёт вас!

image

image


Итоги

Хочу поделиться несколькими выводами из рассказа выше. Не все выводы однозначные и предположу, что они могут вызвать возражения. Основное:

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

2. Важны не только сами мастер-данные, но и их качество. По мере роста вопрос качества данных выходит на первое место.

3. В то же время, каждый следующий уровень развития MDM, ESB, DQS дорог и влечёт за собой дополнительные расходы. Есть чёткая шкала, ориентируясь на которую, можно формировать текущую инфраструктуру. Создавать её с запасом больше, чем на 1-2 уровня не нужно.

4. Ответственность за качество данных должна нести не IT-служба, а сам бизнес. Задача IT предоставить удобные инструменты для реализации этой ответственности.

5. Функция управления качеством данных должна быть централизована. Процесс контроля качества распределён между всеми участниками работы с данными, начиная с их первичного ввода.

Приглашаю к дискуссии!
Подробнее..

Третий день 3DEXPIRIENCE World 2021 как это было

01.03.2021 14:22:08 | Автор: admin

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

Пленарное заседание под названием От связей к отношениям открыл Сучит Джайн, вице-президент отдела стратегического планирования и коммуникаций бизнеса SOLIDWORKS. Он подтвердил то, что многим уже известно: SOLIDWORKS по-прежнему присутствует везде.

Более шести миллионов новаторов, среди которых дизайнеры, инженеры, специалисты по производству и готовящиеся к будущей карьере студенты, проектируют и воплощают в реальность вещи, которые мы видим вокруг себя каждый день. Многие представители отрасли, столкнувшись с пандемией COVID-19, воспользовались возможностью переоснастить заводы под выпуск медицинского оборудования и организовать быструю 3D-печать средств индивидуальной защиты (СИЗ).

Своими историями поделились два наших клиента: Мэтт Карни и Тедж Матель. Карни, используя платформу 3DEXPERIENCE Works, подключил сотни инженеров к разработке проектов медицинских масок, вносить вклад в которые может каждый участник. В рассказе Мателя было подчеркнуто, как важно разработчику иметь доступ к информации о тестах, проводимых для диагностики COVID-19.

Тему продолжила Мари Планшар, директор по образовательным программам и раннему взаимодействию. Она побеседовала с двумя известными инженерами, работающими с SOLIDWORKS. Их инженерная карьера складывается по-разному, но оба едины в стремлении передать свой накопленный за многие годы опыт новому поколению специалистов. Эрик Битти, лидер сети групп пользователей SWUGN, рассказал о том, как делится своими знаниями на ежегодных встречах SLUGME. Пол Вентимилья напомнил, что в свободное от основной работы время он участвует в телешоу BattleBots и является наставником одной из соперничающих команд робототехников.

Основным событием дня стала экспертная дискуссия, в которой приняли участие Брент Бушнелл, основатель и председатель Two Bit Circus, Нолан Бушнелл, основатель и генеральный директор Atari и Chuck E. Cheese, а также Грант Дельгатти, заведующий кафедрой инноваций в академии USC Iovine and Young. Нолан Бушнелл познакомил аудиторию с историей создания Atari, а Брент рассказал, как он создавал Two Bit Circus. Все эксперты были единодушны в одном: не нужно бояться неудач, они тоже неотъемлемая часть инновационного процесса.

Если вы пропустили какие-либо пленарные заседания или встречи, то можете наверстать упущенное, разыскав их записи на вкладке Agenda платформы виртуального мероприятия. Не забудьте посмотреть встречу с Джимом Капобьянко сценаристом хита Pixar Рататуй и лауреатом премии Оскар в номинации Лучший сценарий. На конференции этого года Капобьянко рассказал о новом мультфильме Изобретатель. В своих анимационных работах он часто обращается к проектам Леонардо да Винчи, моделируя движение механизмов компьютерными средствами.

Технических секций на конференции было более 130, и мы уверены, что вы все сможете найти среди них полезные для себя и поднять свою квалификацию на новый уровень. Хотите хорошую новость? Записи технических секций будут доступны примерно месяц на платформе виртуального мероприятия 3DEXPERIENCE, так что время для ознакомления с ними у вас еще есть!

Что-то пропустили? Не беспокойтесь. Посмотрите видео ниже, чтобы узнать о происходившем в этот день, и не забывайте о записях, выложенных на виртуальном портале. Благодарим вас за то, что присоединились к нам на виртуальной конференции 3DEXPERIENCE World 2021. Будем надеяться, что встретимся лично через год на 3DEXPERIENCE World 2022 в Атланте!

Хотите узнать больше? Скачайте бесплатно электронную книгу о ключевых обновлениях и технических преимуществах SOLIDWORKS 2021

Подробнее..

Взаимодействия. RPC vs REST vs MQ

15.02.2021 14:04:42 | Автор: admin

По работе мне довелось провести ряд собеседований на позицию Backend-разработчика. Особо важным для оценки архитектурных навыков мне кажется следующий вопрос:


Если вам необходимо спроектировать взаимодействие двух систем, в каких случаях вы выберете RPC, в каких REST, а в каких MQ?


Если ответ на этот вопрос у вас вызывает затруднения, загляните в мой небольшой ЛикБез на тему.




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


Во-первых, вызовы могут быть синхронные и асинхронные. Сам по себе вопрос об этом выборе интересен. И я думаю, что очень многие всегда будут отдавать предпочтение асинхронному async/await без конкретной причины тоже хороший вопрос для интервью.


Во-вторых, модель взаимодействий может быть однонаправленная (one-way) и вызовы вида запрос-ответ. Если вы исповедуете CQS, соблюдаете требование идемпотентности, то скорее всего вызовы будут однонаправленными.


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


Выбор


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


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


Сценарий транзакции


Организует бизнес-логику в процедуры, которые управляют каждая своим запросом.
TS


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


Исходя из определения, данного Мартином Фаулером, вызывать необходимо определённый сценарий и в определённой последовательности. RPC подход появился именно отсюда. Т.е. подойдут такие протоколы как: Sockets, WebSockets, gRPC, SOAP и другие.


Обработчик таблицы


Одна сущность обрабатывает всю бизнес-логику для всех строк таблицы БД или представления.
TM


Для данной формы организации доменной логики характерна работа над отдельными таблицами, с помощью репозиториев, реализующих CRUD-операции. Сервис строится с использованием API-Controller адаптера к репозиторию реализующий удалённый вызов CRUD-процедур с использование протокола HTTP. Таким образом, если ваше приложение базируется на БД с отдельными репозиториями, вам наиболее подходит REST протокол. В ряде случаев, особенно полезным становится использование протокола OData, расширяющего REST.


Модель предметной области


Объектная модель домена, объединяющая данные и поведение.
DDD


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


Агрегат


Шаблон доменная модели, как можно видеть, очень похож на сценарий транзакции, но (1) имеет очерченные границы (Bounded Context), и (2) связан с доменной сущностью (агрегатом). Структура данных при этом сокрыта за абстракцией и может быть реляционном виде, а ещё проще когда в нереляционном.


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


Совершенно по-новому в этом отношении смотрится gRPC замена Windows Comunication Foundation. С последним очень часто бывают существенные проблемы соразвития, особенно если интеграция происходит с командой, интеграция с которой оставляет желать лучшего (т.е. худшие варианты карты контекстов тут не подходят). В рамках же смыслового ядра считаю технологию оправданной. А сам RPC подход был бы наиболее верным.


Отдельные возможности открываются для брокеров сообщений как средство получения ответа от сервиса, ведь доменная модель идеально подходит для получения очень чистых событий предметной области, потребителями которых могут быть любые другие сервисы, а сама ШИНА ДОМЕННХ СОБТИЙ может стать превосходным средством масштабирования. Организуя архитектуру определяемую событиями, важно не забывать про возможность циклического вызова, про маркеры корреляции.




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


Просто подумайте




Что почитать


Подробнее..

Перевод Почему стоит обратить внимание на подход low-codeno-code

16.02.2021 16:13:42 | Автор: admin

Все мы в последнее время довольно много слышим о платформах low-code/no-code. Платформы без кода обещают сделать разработку программного обеспечения столь же простой, как использование Wordа или PowerPointа, чтобы обычный бизнес-пользователь смог продвигать проекты без дополнительных затрат (денег и времени) на команду инженеров. В отличие от платформ без кода, low-code по-прежнему требует определенных навыков программирования, однако обещает ускорить разработку программного обеспечения, позволяя разработчикам работать с предварительно написанными компонентами кода.

Согласно Gartner, к 2024 году 65% разработанных приложений будут относиться low-code.

Еще в 2017 году я участвовал в раннем сравнительном тестировании производительности традиционной разработки (с использованием Java) и проектом low-code/no-code, основанном на моделях. Результаты были впечатляющими: при использовании метода low-code/no-code производительность увеличивалась в 5-7 раз. Опрос, проведенный компанией No-Code Census в 2020 году, показал прирост производительности в 4,6 раза по сравнению с традиционным программированием.

Low-code/no-code: Фрагментация платформы

Область low-code/no-code довольна сложна и включает в себя многочисленные решения, платформы и субрынки. Например, существуют субрынки, ориентированные на крупные, средние и малые предприятия. Корпоративные платформы low-code/no-code обеспечивают высокую масштабируемость, производительность, безопасность и интеграцию с приложениями предприятия. Они, как правило, дороже остальных. Ниже представлен Магический Квадрант Gartner для корпоративных low-code платформ:

Gartner дает платформе low-code (LCAP) следующее определение: Это платформа, которая поддерживает быструю разработку приложений, одноэтапную раскатку, выполнение и управление с использованием декларативных абстракций программирования высокого уровня, таких как языки программирования на основе моделей и метаданных.

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

Неудивительно, что многие платформы low-code являются платформами управления бизнес-процессами. BPM уже давно поддерживает разработку на основе моделей (Model-driven Development), где нужно нарисовать диаграммы, объясняющие, как должно работать программное обеспечение, прежде чем его создавать. Эта схема похожа на процессный подход BPM, при котором для задания бизнес-процесса необходимо в правильном порядке расположить блоки, представляющие собой подпроцессы. (Самым популярным стандартом отображения процессов, поддерживаемым большинством BPM-платформ, является BPMN). Поэтому процессно-ориентированные решения достаточно популярны. Примерами low-code/no-code платформ для BPM являются Appian, Pega, Outsystems.

Но существуют и другие примеры под эгидой low-code/no-code:

Веб-платформы для использования предприятиями любого размера. Ведущими конкурентами являются WordPress, Wix, Squarespace и WebFlow.

Платформы управления базами данных, начиная от таких, как Mendix, и заканчивая такими, как Airtable. Существуют также low-code/no-code платформы баз данных NoSQL, например, KgBase, предназначенная для построения графов знаний.

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

Разработка мобильных приложений. Большинство платформ low-code/no-code, таких как Bubble, предоставляют возможности адаптивного пользовательского интерфейса, другие предлагают встроенную поддержку ведущих мобильных OC (iOS и Android). Thunkable пожалуй, лучший пример low-code/no-code платформы для разработки мобильных приложений.

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

Другие категории платформ нацелены на определенные области или ниши приложений:

  • E-commerce и онлайн-магазины: лидирующим примером здесь является Shopify.

  • Управление рабочим процессом: отличный пример Monday.com.

  • Приложения ERP (планирование ресурсов предприятия): в качестве интересного примера (также указанного в MQ Gartner) можно привести Zoho. Еще одна важная и впечатляющая платформа для ERP и CRM это Salesforce.

  • Блокчейн и Интернет вещей: Atra.

  • Искусственный интеллект: сейчас мы начинаем наблюдать появление таких инструментов, как C3 AI Ex Machina.

Челленджи low-code/no-code

Платформы low-code/no-code имеют множество преимуществ, но в то же времясоздают определенные трудности и требуют обучения для работы с ними. Многие передовые практики только появляются и относительно незрелы, и следовательно, растет ответственность при их использовании. Что касается традиционного программирования, здесь накоплен огромный опыт, существуют сильные сообщества, а передовые практики задокументированы. Во многих отношениях low code/no-code находится в зачаточном состоянии даже несмотря на то, что разработка на основе моделей существует уже давно (особенно платформы BPM).

Вот некоторые из наиболее серьезных проблем:

1. Необходимость изменения культуры: low-code/no-code требует изменения культуры организации, будь то корпорация или стартап. Изменить культуру для избавления от лишних процессов непросто, это требует схожего видения и одобрения руководства, а также выделения бюджета и полномочий для центра компетенций по цифровой трансформации low-code/no-code.

2. Время и усилия на изучение платформ: low-code/no-code увеличивает скорость и производительность, но инструменты и платформы нетривиальны, и для развития необходимого уровня владения ими требуется время. Это один из наиболее неправильно понимаемых аспектов low-code/no-code. Сложные программные конструкции, такие как вложенные циклы, не так уж и просты на любой платформе.

3. Необходимость использования нескольких платформ: одни платформы имеют более полную функциональность, другие нет. Unqork и Bubble, например, предназначены для любого сценария использования и поэтому предлагают множество вариантов интеграции с корпоративными системами. Кроме того, они могут взять много полезного из других компонентов, специализирующихся в определенных областях; например, Bubble вместе, скажем, с Parabola или плагином Zapier можно использовать для автоматической интеграции. С возможностями управления данными и интеграциями в Parabola или Zapier работать легче, чем с нативными от Bubble. Существуют и другие плагины или технологические компоненты, дополняющие платформы low-code/no-code: посмотрите, например, список технологических партнеров Unqork или полный список плагинов для Bubble.

4. Недостаточность ресурсов и поддержки сообщества: в мире существуют миллионы, или даже десятки миллионов разработчиков обычных языков программирования, множество онлайн-курсов, а также книги и материалы, доступные для таких языков, как Java или C#, есть множество сообществ и ресурсов для аутсорсинга. Совсем иначе дела обстоят для low-code/no-code, особенно для более новых платформ.

5. Сбивающее с толку ценообразование: корпоративные low-code/no-code платформы, как правило, неоправданно дороги. Платформы для среднего и малого рынка менее затратны, но, как правило, менее масштабируемы. А использование нескольких платформ для создания комплексного решения еще больше усложняет вопросы ценообразования.

Это лишь некоторые из основных проблем. Они ясно дают понять, что low-code/no-code не панацея. Тем не менее, такой подход остается серьезной тенденцией для разработки инновационных решений как для действующих предприятий, так и для стартапов.

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

Готовы ли вы к переходу на low-code/no-code?

Примечание переводчика: наша компания предоставляет как low-code/no-code омниканальный облачный контакт-центр Voximplant Kit с широкими возможностями автоматизации обслуживания клиентов, так и serverless-платформу Voximplant для традиционной разработки с набором API для создания голосовых, видео- и текстовых коммуникаций.

Подробнее..

Как мы используем Confluence для разработки требований к продукту

17.02.2021 14:23:34 | Автор: admin


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

Все изменения в требованиях к новой фиче на одной странице


Мы разрабатываем сложные Enterprise-продукты, которые тиражируются для сотен корпоративных заказчиков. В одном из наших продуктов больше ста функциональных модулей и у каждого модуля есть отдельный документ с требованиями. Фичи нового релиза, как правило, затрагивают несколько (от 3 до 20) функциональных модулей.



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

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



Примерно так это выглядит в жизни:



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

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

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


На странице документа с новой функциональностью:
Добавляем макрос Multiexcerpt include. В нём указываем, какой блок из какой страницы нужно вставлять:


Готовая страница фичи в режиме редактирования выглядит примерно так:


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



Делается это с помощью стандартных макросов Отчёт о свойствах страницы и Свойства страницы.

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



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



Трассировка требований


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

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



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

Для этого мы используем стандартную функциональность меток в Confluence и макрос Результаты поиска.

Подробнее...
На примере функционального модуля Карточка Персоны:
  • Находим все функциональные модули, на которые может повлиять изменения требований к карточке Персоны
  • Добавляем в них соответствующий тег (в нашем случае это #person)
  • Добавляем макрос Результаты поиска на странице требований к карточке Персоны



В режиме редактирования это выглядит так:



А читатель видит так:



Версионирование требований по релизам


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



Так выглядит в жизни переключение между версиями релизов:



Комментирование


Для работы с комментариями мы используем плагин Talk.



Его плюсы:

  • Можно видеть комментарии и отвечать на них в режиме редактирования документа. Это очень удобно, когда надо вносить правки в требования по результатам ревью
  • Нет проблем с параллельным комментированием (особенно если вы планируете переход с MS Word + Sharepoint: не нужно блокировать документ целиком), требования может рецензировать одновременно вся проектная команда
  • Если комментарий оставляют на странице с фичей в блоке с Multi Excerpt, он автоматически появляется в исходном документе требований

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

От стандартного функционала комментирования в Confluence мы отказались, потому что у него были критичные для нас минусы:

  • Нельзя использовать в связке с плагином Multi Excerpt
  • Не видно комментариев в режиме редактирования документа
  • Пропадают комментарии, если изменить текст, к которому они были привязаны

Создание диаграмм и мокапов


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

Как оказалось, в Confluence есть множество плагинов для работы с разного рода графическими объектами (диаграммы, схемы, мокапы и пр). Balsamiq Wireframes for Confluence и Draw.io Diagrams for Confluence позволяют редактировать графические объекты, не выходя из Confluence. На данный момент эти плагины почти полностью покрывают наши потребности.
image

Базовые возможности


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

  • Сравнение версий документов. Можно быстро понять, как менялась функциональность от релиза к релизу.
  • Параллельное редактирование одного документа и автоматическое разрешение конфликтов. Ревью документа могут делать одновременно несколько человек и при этом не нужно ждать своей очереди, пока документ заблокирован на редактирование другим сотрудником (как было, когда мы использовали Sharepoint и требования хранились в виде Word-файлов).
  • Шаблоны документов. Мы создали шаблоны по всем основным типам документов (функциональный модуль, фича, протокол совещания)
  • Гибкие возможности разграничения доступа (вплоть до уровня страницы). Это удобно, например, для аутсорсных сотрудников, которым нельзя предоставлять доступ сразу ко всем требованиям
  • Экспорт документов в различные форматы. Очень выручает в тех редких случаях, когда возникает необходимость передачи документов наружу.
  • Интеграция с JIRA. Можно автоматически вставлять статус задач, сроки согласований и прочей информации из тикетов JIRA.

Переход с MS Word


Есть несколько неочевидных вещей, с которыми почти сразу сталкиваешься после перехода с Word на Confluence.

Нумерация заголовков


Чтобы добавить автоматическую нумерацию заголовков, нужно обрамить текст макросом Numbering headings.



Гиперссылка на раздел


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

Подробнее...
Добавляем макрос Anchor и указываем его имя (Вставить -> Другие макросы -> Anchor):



Так он выглядит в документе в режиме редактирования:



Затем вставляем ссылку на этот якорь в документе (Вставить -> Ссылка -> Дополнительно):

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



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

Цвет фона текста


Сделать нестандартное визуальное оформление текста, в частности выделить фон текста
заливкой, можно с помощью Markdown-разметки (Вставить -> Разметка, Markdown).



Используйте этот код
Для заливки мы используем такой код:
<span style="background-color: rgb(202,225,255);">текст</span>

Подставьте RGB-код нужного вам цвета.

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

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

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

На этом всё. Задавайте вопросы в комментариях!

P.S. Статья основана на базе доклада Лайфхаки Confluence для разработки требований на конференции Analyst Days, видео версию этого доклада можно посмотреть по этой ссылке.

Автор статьи: Ильшат Габдуллин g1r
Подробнее..

Опыт знакомства с MDM решением компании Юнидата (UniData)

17.02.2021 20:19:33 | Автор: admin

Уважаемые коллеги, всем доброго дня.

В данной статье хочу поделитьсясобственным опытом знакомства с MDM решением компании Юнидата (UniData). Попытаюсь сделать акцент на конкретные трудности и особенности платформы, с которыми столкнулся при переходе с SAP MDM на ЮниДата MDM.

Предыстория проекта

К моменту старта проекта по переходу на UniData MDM в Компании уже примерно 5 лет функционировала корпоративная система управления нормативно-справочной информацией (КСУ НСИ) на базе SAP MDM. Проект внедрения SAP MDM был по-настоящему успешным и эксплуатация системы практически не создавала проблем.

В КСУ НСИ велись два общекорпоративных справочника:

  • материально-технических ресурсов, работ и услуг (МТРиУ), 200000 записей

  • контрагентов, 40000 записей

Применялась модель централизованного ведения НСИ с единой точкой ввода через механизм заявок от пользователей. MDM выступал мастер-системой для ряда информационных систем Дочерних обществ, обслуживающих различные бизнес-процессы (бухгалтерский и налоговый учет, планирование и централизованные закупки, техническое обслуживание и ремонт оборудования и другие).

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

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

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

В силу разных причин перед Компанией встала задача импортозамещения системы SAP MDM с полным сохранением существующей функциональности.

В рассмотрение брались все самые распространенные отечественные решения, из которых, в силу различных причин,отсеялисьвсе, кроме Unidata MDM.

В пользу Unidata сыграл западный опыт (в дальнейшем авторитетное международное аналитическое агентствоGartner даже включило Unidata в свой "Магический квадрант"), универсальность решения (рассматривались и смежные проекты внедрения MDM под другие данные с иными моделями ведения), основа технологического стека на свободном ПО с открытым исходным кодом и лицензионная политика, в которой метрикой выступило количество справочников.

Перейду к конкретике, все дальнейшее сравнение и ожидания от функциональности платформы будут опираться на решение SAP MDM. Условно разделю выявленные проблемы на 3 блока:

Архитектурные особенности и базовая функциональность

  • Отсутствие понятия "легитимное состояние записи".

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

    Отображение еще не согласованных заявок как записей в справочнОтображение еще не согласованных заявок как записей в справочн
  • Ведение классификаторов без бизнес-процесса как часть модели данных.

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

  • Изначально одним из плюсов платформы нам виделась работа с данными в одном интерфейсе (в отличие от SAP MDM, где данные велись в 2 интерфейсах - "тонком" и "толстом" клиентах), как выяснилось от чего хотели уйти к тому и вернулись.

    Интерфейс редактирования классификатораИнтерфейс редактирования классификатора
  • Множественная классификация.

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

    Отображение множественной классификации записи справочника в табличной формеОтображение множественной классификации записи справочника в табличной форме
  • Нет сортировки по полям с классификацией и отбора неклассифицированных записей, выбора нескольких классов.

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

  • Правила качества нельзя задавать на шаги бизнес-процесса.

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

    Сверху пример табличной формы в SAP MDM, снизу те же данные в ЮниДата (транспонированы в строки)zСверху пример табличной формы в SAP MDM, снизу те же данные в ЮниДата (транспонированы в строки)z
  • Не задаются ограничения длины строки на атрибуты (поля).

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

    Форма настройки атрибутовФорма настройки атрибутов
  • Нет настроек для создания типовых предустановленных фильтров, отражающих срезы для работы с заявками.В платформе отсутствует возможность создавать и задавать настройками в моделиданных для разных ролей фильтры, отражающие типовые срезы для работы с заявками. Например, ответственному за распределение заявок в работу экспертам необходимо видеть все поступившие, но не распределенные заявки, инициатору заявок необходимо видеть заявки, которые вернулись ему для устранения замечаний, эксперту все заявки, находящиеся у него в работе и т.д.
    Данный инструментарий реализован во всех зрелых MDM-решениях, нужен для стандартизации и упорядочения процесса обработки заявок, снимает много вопросов со стороны пользователей и позволяет гибко реагировать на изменения в BPM. В рамках нашего проекта платформа была доработана и сущность "Предустановленный фильтр" была впервые введена, однако настроек по отдельным ролям для него нет, то есть пользователи видят все предустановленные фильтры, даже если для них они не предназначены, а сама разработка одного предустановленного фильтра не относится к настройке системы, тарифицируется в более чем в 10 человеко-дней.

    Предустановленные фильтры для заявокПредустановленные фильтры для заявок
  • Персональные настройки хранятся в кэше браузера.

    В системе не реализовано хранение персональных настроек на сервере, как следствие после некоторых изменений системы приходится очищатькэш, после релизов настройки сбрасываются. C учетом текущего гибридного режима работы, работа в системе осуществляется как с рабочих компьютеров, так и удаленно с персональных, по прямой ссылке браузера и через виртуальное приложение в Citrix со своими независимо хранимыми настройками. Гораздо более удобным вариантом было бы хранить персональные настройки на сервере, как это было реализовано в SAP MDM.

  • Отсутствует развитой инструментарий выгрузки и загрузки данных.

  • В платформе не предусмотрены развитые штатные средства для пользовательской выгрузки и загрузки справочников. Выгрузка осуществляется только в Excel в одном немодифицируемом системном формате, без возможности настройки атрибутного состава (полей), все ссылочные данные представлены в виде id на вспомогательные справочники и классификаторы, выгрузка ограничена пакетами в 50000 записей, выгрузка с учетом фасетно-иерархической классификации не реализована в принципе.
    Например, для того чтобы выгрузить весь справочник МТРиУ и привести его в понятный для пользователя форматпотребуется потратить несколько часов на выгрузку 5 фрагментов основного справочника, всех вспомогательных справочников и классификаторов, потом свести воедино все фрагменты основного справочника, удалить лишние атрибуты, через id подтянуть значения из вспомогательных справочников, в ручных операциях с учетом особенностей Excel весьма вероятно допустить ошибку. В SAP MDM выгрузка из толстого клиента осуществляется в файлы разных форматов, с настройкой полей, в атрибуты вспомогательных справочников указываются истинные значения, а не их id, скорость выгрузки 250 записей в секунду.
    C загрузкой процесс такой же непростой, для загрузки новых записей придется отключить репликацию, остановить правила качества, сначала загрузить часть информации для получения внешнего id, потом выгрузить загруженные данные, подтянуть внешний id в исходный загрузочный файл, потом вторым проходом догрузитьклассификацию, запустить репликацию, правила качества. На практике на дозагрузку 150 записей уйдет не менее 2 часов времени и операцию можно проводить только в технологическое окно, пользователи параллельно не могут создавать новые записи. В пакете инструментов SAP есть Import Manager и Syndicator позволяющие быстро и эффективно делать пользовательское карты загрузки, в один проход прогружать справочники, выбирая любой ключ для загрузки, и получать всевозможные выгрузки.

    Пример стандартной выгрузки из системы, связи и классификация приведены в отдельных вкладкахПример стандартной выгрузки из системы, связи и классификация приведены в отдельных вкладках
  • Бизнес-процесс (BPM) для заявок - кастомизационная часть кода.

    В платформе не предусмотренавозможность настраивать некоторые или все бизнес-процессы через модуль BPM. По каким-то неизвестным мне причинам не удалось без программирования реализовать достаточно типовой процесс для 4 основных ролей: Инициатор заявки, ЭкспертНСИ, Старший эксперт НСИ, Куратор, с шагами: черновик, подан в обработку, в обработке, направлен на уточнение, возвращен с уточнения, направлен куратору, возвращен куратором, завершен, отклонен. Если один из основных блоков MDM реализован таким образом это вызывает вопросы о зрелости решения.

  • Нет ограничений на пакетные операции для пользователей.

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

  • Нет ограничений на отображение заявок для пользователей.

    Любой пользователь системы видит любые заявки в системе без всяких ограничений. Например, если пользователь имеет права на справочник контрагентов, то он все равно будет видеть все заявки и по другим справочникам, не смотря на то, что сами справочники он не видит и не может редактировать заявки. В нашем случае в SAP MDM также была реализована настройка видимости заявок пользователей только в рамках своего дочернего общества, платформа ЮниДата такое сделать не позволяет.

  • Права на редактирование атрибутов заявки не задаются на шаг бизнес-процесса или тип операции.

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

  • Проблемыс поисковыми возможностями.

    В платформе реализован поиск по справочникам на движке Elasticsearch. В интерфейсе представлена возможность поиска как по всем полям одновременно (атрибут "Ключевое наименование"), так и по отдельным полям.
    Первая проблема заключается в том, что нет возможности настроить поиск по сочетанию только требуемых содержательных полей (а не всех). Для решения такой проблемы можно только отключить поиск по отдельным полям в принципе, а не в совокупности с другими. На практике получается, что поиск по всем полям фактически не применим, так как в справочнике много атрибутов создающих фон. Например, ищем контрагента вводя ИНН, а находим запись, у которой ИНН другой, а ИНН из поискового запроса похож на код записи в локальной системе. Также стоит отметить что этот поиск выводится по умолчанию как основной в самом верху формы, и пользователю надо еще догадаться, что есть поиск по отдельным атрибутам.
    Вторая существенная проблема, что поиск по отдельным полям нельзя сочетать с поиском по всем полям, это хоть как-то могло решить первую обозначенную проблему.
    Третья проблема, выявленная в эксплуатации, поиск из коробочного решения никаким образом не учитывает взаимное расположение терм в поисковом запросе. Это крайне негативно влияет на результаты поиска по отдельным специфическим поискам. Например, поиск по обозначениям ТУ, возьмем для примера распространенные "ТУ 16.К71-310-2001" на кабели, Elasticsearch разбирает этот запрос на выражение типа '%ТУ%' and '%16%' and '%К71%' and '%310%' and '%2001%', то есть игнорирует символы разделителей (точки, дефисы) и их взаимное расположение, в результате из 200000 записей справочника выводится более 55000 найденных записей, кабелей с запрошенными ТУ на первых страницах нет (в самых релевантныхрезультатах), хотя в справочнике их сотни и поиск по "%ТУ 16.К71-310-2001%" сразу бы их нашел.
    Четвертая проблема в том, что некоторые поисковые запросы не просто не выводятся в топ, а не находятся в принципе. Например, в справочнике есть ряд приборов серии "Метран-300", поиск по данной серии, один в один входящей в наименование выводит почему-то только одну запись, также поиск по разным атрибутам выводит разные результаты. Например, в поле 1 и поле 2 есть точное соответствие поисковому запросу, поиск по полю один выведет одно количество, поиск по полю 2 другое количество.Пятая проблема, просили реализовать поиск с учетом латиницы и кириллицы, одинаковых по написанию. С учетом того, что решение идет в рамках "импортозамещения", была надежда, что отечественная компания уделить внимание проблеме с символами национального алфавита. Можно понять, когда западные компании игнорируют проблемы аборигенных нелатинских языков, но в русскоязычных справочниках это постоянная проблема, отечественный разработчик, который "в материале" мог бы понять важность проблемы и решить ее.
    Также обращались по возможностям настройки поиска в части применения кавычек. В современных поисковых системах давно уже используется полезный механизм точного поиска (содержит), путем заключения поискового запроса в кавычки, снова куча проблем и отказ в реализации.
    В SAP MDM аналогичный поиск настраивается по сочетанию полей и комбинируется с запросами по отдельным полям, реализован проще, но тем не менее дает релевантный результат. В целом этот ключевой модуль вызывает много вопросов, сложилось впечатление, что у разработчика нет компетенций в вопросе поисковых алгоритмов, предметную область справочников они не знают, предлагают нам самостоятельно ознакомиться с алгоритмами Elasticsearch и сказать какой алгоритм задать, проблема не решается уже более 3 месяцев. Очевидно слабое место системы.

    Слева форма поиска по умолчанию, справа с раскрытым меню поиска по группам атрибутовСлева форма поиска по умолчанию, справа с раскрытым меню поиска по группам атрибутов
  • Нет возможности добавления атрибутов заявки.

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

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

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

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

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

    Код КСУ НСИ формируется автоматически и не подлежит редактированиюКод КСУ НСИ формируется автоматически и не подлежит редактированию
  • В системе не предусмотрена фильтрация заявокпо операциям создание/изменение/удаление/восстановление.

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

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

    Простыми словами, для записи справочника или узла классификатора невозможно задать признак, отвечающий за его отображение и возможность выбора (ссылки на него) в других справочниках. Например, MDM выступает мастер-системой для справочника единиц измерения, часть единиц измерения используется в сугубо специфических прикладных бизнес-процессах (например, для оценки технического состояния оборудования в системе ТОРО), такие специфические ЕИ хотелось бы заблокировать для применения в справочнике МТРиУ, где используются только учетные и закупочные ЕИ, но настроить такое стандартными средствами возможности нет. Деление на отдельные справочники однотипных сущностей также не целесообразно.

  • Проблемы с разделением на понятия запрос на изменение и запрос на добавление записи.

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

  • Сырая проработка фасетно-иерархических классификаторов.

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

    Отображение названия свойства в карточке записи: слева ЮниДата, справа SAP MDMОтображение названия свойства в карточке записи: слева ЮниДата, справа SAP MDM
  • У пользователя, обрабатывающего заявки нет возможности выбора механизма изменения - через заявку или прямые изменения.

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

  • Запрос на изменение инициируется путем редактирования карточки записи.

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

  • Заявка декомпозирована на задачи.

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

    Декомпозиция заявок на задачи, в примере 1 запись, 3 заявки на нее, состоящие из 7 задач.Декомпозиция заявок на задачи, в примере 1 запись, 3 заявки на нее, состоящие из 7 задач.

Эргономика и интерфейспользователя

  • Основной тип отображения данных Плитка.

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

Слева приведена форма отображения записи справочника МТРиУ, справа форма отображения заявки (3 заявок)Слева приведена форма отображения записи справочника МТРиУ, справа форма отображения заявки (3 заявок)
  • Неудобная фильтрация и поиск заявок и записей, поисковые формы не хранятся в персональных настройках, их нельзя задавать в системных настройках.В системе реализован принцип единого интерфейса для обработки заявок пользователей и поиска по справочникам, то есть заявки на разные справочники и записи попадают в один универсальный интерфейс, без возможности разделить потоки на разные более специализированные интерфейсы. Эта универсальность серьезноухудшает эргономику отборов и фильтрации заявок и записей. Реализуется принцип раскрытия поисковых атрибутов, когда атрибуты для поиска появляются только после выбора ключевого значения (например, справочника). На практике Эксперт (Data Steward) вынужден при каждом входе персонализировать отображаемые атрибуты для поиска, так как в пользовательских настройках это не сохраняется.Настройка положения поисковых атрибутов в форме поиска не предусмотрена, операторы поиска также не настраиваются (безальтернативно задано "точное соответствие", хотя преимущественнотребуется "содержит"). Все это очень напоминает сказку про кощея, "На море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке заяц, в зайце утка, в утке яйцо, в яйце игла, смерть Кощея". Ситуацию не изменяет и права на справочники, даже если у пользователя права на один справочник, каждый раз он должен его выбирать, настраивать нужные ему атрибуты и операторы. На мой взгляд это серьезный просчет, правильнее было бы одновременно поддерживать 2 стратегии - специализированную, выделение заявок по отдельным справочникамв отдельные интерфейсы, где все нужные атрибуты отображены по умолчанию и универсальную, один общий интерфейс, где можно смотреть все заявки, так как зачастую, либо есть специализация у пользователей и экспертов или поток заявок по некоторым справочникам пренебрежимо мал, чтобы жертвовать эргономикой в самой массовой части ради них.Сама поисковая форма имеет вертикальную ориентацию, что на мой взгляд также неудачное решение, если бы она располагалась горизонтально, все атрибуты помещались в один экран не было бы необходимости использовать прокрутку.

    Форма поиска по заявкам, выбор справочника (МТРиУ, изображение слева) приводит к появлению в самом низу поисковой формы возможности отбора по атрибутам данного справочника (изображение справа)

  • Не настраиваетсярасположение блока атрибутов классификации.

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

    Верхняя часть карточки записиВерхняя часть карточки записи
  • При назначении заявок не обновляется их перечень.

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

  • В заголовки вкладок браузера не выводятся названия открытых разделов.

    Как правило, сценарий, когда пользователь работает только в одной вкладке системы не самый распространенный. Практика показывает, что для роли Эксперт (Data Steward) нужно около 3-4 вкладок под различные операции. В SAP MDM на вкладках браузера выводился заметный заголовок открытого раздела интерфейса, ориентироваться очень удобно. В решении Юнидата все вкладки неразличимы, а так как интерфейс работы с заявкой во вкладке "Запись" не отличается от карточки записи в справочнике, нередко пользователи начинают редактировать существующую запись справочника, случайно подавая запрос на изменение вместо запроса на добавление.

    Наименования вкладок портала SAP, отображаемые в браузереНаименования вкладок портала SAP, отображаемые в браузере
  • Нет возможности добавить несколько документов одним действием.

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

  • Не проработаны текстовые поля для редактирования.

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

    Всплывающее окно при редактировании текстовогоатрибутаВсплывающее окно при редактировании текстовогоатрибута
  • Повышенная трудоемкость ввода данных в атрибуты(поля).

    Согласно проведенным сравнительным испытаниям ввод одних и тех же заготовленных данных в систему UniData MDM занял на 75-100 % больше времени (в зависимости от кейса), чем в SAP MDM. После оптимизации как пользовательскогоинтерфейса (UI), так и производительности системы, удалось снизитьзначение до 50 %.

  • В форме выбора узла классификатора нет кнопки "раскрыть все".

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

    Форма поиска и выбора узла классификатора для раскрытия всех уровней нужно нажать кнопки "еще" 4 раза.Форма поиска и выбора узла классификатора для раскрытия всех уровней нужно нажать кнопки "еще" 4 раза.
  • В системе не предусмотрено хранение атрибуты "Отчество" для пользователя.

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

    Администрирование и доработки.

  • Проблемы с передачей данных в системы-получатели.

    С первого дня эксплуатации и по настоящий момент наблюдаются постоянные проблемы с передачей записей в системы-получатели, пользователи регулярно обращаются в службу поддержки с обращениями, что их заявка была отработана, но в их локальную систему изменения не реплицировались. Трудно сказать, в чем причина, за все время эксплуатации SAP MDM проблемы были точечными и быстроустранимыми, здесь же проблема на протяжении нескольких месяцев.

  • Модуль подписки и публикации (PubSub) не позволяет задавать id сообщения на пакет записей.

    Например, в нашем ландшафте есть "тяжелая" система-получатель, настройки которой позволяет принимать 1 пакет раз в 4 минуты. SAP MDM позволяет формировать пакеты по несколько записей, в Юнидата MessageID задается на запись, а не пакет. На практике это выливается в проблему прогрузки достаточно массовых изменений через интеграционную шину, например, чтобы передать в упомянутую систему изменения по 1000 записей понадобится 4000 минут.В самом модулеPubSub нет возможности важных для работы атрибутов (например, основного идентификатора, применяемого в системе, так как с GUID мы не работаем, исполнителя для понимания в чьей сфере ответственности задача по исправлению ошибки, нет расшифровок ошибок от систем-получателей, они только в почтовых сообщениях и еще ряд неудобств).

    Интерфейс модуля подписки и публикацииИнтерфейс модуля подписки и публикации
  • Качество программного кода.

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

  • Трудоемкость доработок на 30-50 % выше аналогичных в SAP MDM.

    В данном пункте стоит упомянуть, что поддержка SAP MDM осуществлялась своими силами, а поддержка платформы Юнидата осуществляется через подрядчика, возможно это накладные расходы, формируемые подрядчиком, тем не менее факт таков, трудоемкость в человеко-часах как правило выше на 30-50 % чем в SAP MDM.

Выводы*

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

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

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

Сказывается и малая практика внедрения данной платформы под задачи ведения промышленных справочников МТР. Насколько я понял, помимо нашей Группы компаний, чуть раньше, подобный проект стартовал в ОАО "РЖД", других аналогичныхвнедрений не было. Предстоит еще много внедрений и доработок, чтобы по функциональности и удобству приблизиться к SAP MDM или иной зрелой системе.

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

Александр Черевичин, специалист НСИ.

*Мнение автора может не совпадать с мнением Заказчика (работодателя).

Подробнее..

3. Частотные характеристики звеньев и систем автоматического управления. ч. 3.4 Апериодическое звено 2го порядка

24.02.2021 02:21:58 | Автор: admin

Предыдущая часть Апереодическое звено первого порядка.

3.4 Апереодическое звено второго порядка

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

У нас есть модель механического демпфера. Это поршень на пружине, он движется внутри цилиндра, может перемещается вверх-вниз. Его положение это интересующая нас функция Y(t), сверху на него воздействует возмущающая сила (U(t)), на стенках поршня действует сила вязкого трения. (См. рис. 3.4.1)

Рисунок 3.4.1. Расчетная схема амортизатора. Рисунок 3.4.1. Расчетная схема амортизатора.

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

m \cdot \frac{d^2Y(t)}{dt} = \sum F_j = P+ U(t) +F_{пр}+F_{тр}
  • где:

    m - масса поршня;

    Y(t)- положение поршня (выходная переменная);

    U(t) = X(t)- приложенная сила (входное воздействие);

    P = m \cdot g- сила тяжести;

    F_{пр} = k \cdot Y(t) сила сопротивления пружины;

    F_{тр} = с \cdot \frac{dY}{dt} сила вязкого трения (пропорциональная скорости движения поршня).

Считаем, что в нулевой момент времени поршень находится в равновесии. Тогда начальное положение поршня y0в равновесии, где скорость и ускорения равны 0, можно посчитать из уравнения 2.

0 = m \cdot g + u_0-k \cdot y_0 \Rightarrow y_0= \frac{1}{k} [m\cdot g+u_0]

Перепишем уравнение равновесия в отклонениях от нулевого состояния:

Y(t) =y_0+y(t); \ \ \ U(t) = u_0+u(t);

m \cdot \frac{d^2 y(t)}{dt^2} = \underbrace { m \cdot g+ u_0}+u(t)-\underbrace {k \cdot y_0} -k\cdot y(t) - c \cdot\frac{dy(t)}{dt}

Поскольку мы приняли, что в начальный момент у нас состояние равновесия, а сумма трех сил в состоянии равновесия равна нулю, их можно убрать из уравнения, и в итоге получим:

m \cdot y''(t)+c \cdot y'(t)+k \cdot y(t) = u(t) = x(t)

Приведем данное уравнение к классическому виду:

 \underbrace{\frac{m}{k}}_{T_2^2}\cdot y''(t)+\underbrace{\frac{c}{k}}_{T_1}\cdot y'(t)+y(t)=\underbrace{\frac{1}{k}}_K \cdot x(t)

Уравнение динамики апериодического звена 2го порядка имеет следующий вид:

T_2^2 \cdot y''(t)+T_1 \cdot y'(t)+y(t)=K \cdot x(t) \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.1)}

при этом:

D = T_1^2-4 \cdot T_2^2 \ge 0 \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.2)}

ЕслиD<0, то звено становится колебательным (см. раздел 3.5)

Переходя к изображениямx(t) \rightarrow X(s); \ \ \ y(t) \rightarrow Y(s)получаем уравнение динамики звена в изображениях:

(T_2^2\cdot s^2+ T_1 \cdot s+1) \cdot Y(s) = K \cdot X(s) \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.3)}

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

W(s) = \frac{Y(s)}{X(s)}= \frac{K}{T_2^2 \cdot s^2+T_1 \cdot s+1} \iff \frac{K}{(T_3 \cdot s+1)(T_4 \cdot s+1)}\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.4)}

где:

T_3 = \frac{T_1-\sqrt{D} }{2} ;\ \ T_4 = \frac{T_1+\sqrt{D}}{2}Рисунок 3.4.2 Апериодическое звено 2-го порядка (два варианта) Рисунок 3.4.2 Апериодическое звено 2-го порядка (два варианта)

Амплитудно-фазовая частотная характеристика (АФЧХ):

W(i \cdot \omega) = W(s)|_{s =i \cdot \omega} =\frac{K}{(1+i \cdot T_3 \cdot \omega)(1+ i \cdot T_4 \cdot \omega)} \Leftrightarrow \frac{K}{(1-T_2^2 \cdot \omega^2)+i \cdot T_1 \cdot \omega} \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.5)}

Домножив числитель и знаменатель формулы (3.4.5) на комплексно-сопряженные скобки (1-i \cdot T_3 \cdot \omega) и (1-i \cdot T_4 \cdot \omega) , получаем:

W(i\cdot\omega) = \frac{K(1- i \cdot T_3 \cdot \omega)(1- i \cdot T_4 \cdot \omega)}{(1 + T_3^2 \cdot \omega^2)(1+T_4^2\cdot \omega^2)} == \underbrace {\frac{K (1 -T_4\cdot T_3 \cdot \omega^2)}{(1+T^2_3 \cdot \omega^2)(1+T_4^2 \cdot \omega^2)}}_{u(\omega)}- i \cdot \underbrace {\frac{K(T_4+T_3)\omega}{(1+T_3^2\cdot \omega^2)(1+ T_4^2\cdot \omega^2)}}_{v(\omega)}

Диствительная и мнимая части передаточной функции:

u(\omega) = \frac{K(1- T_3 \cdot T_4 \cdot \omega^2)}{(1+T_3^2 \cdot \omega^2)(1+ T_4^2 \cdot \omega^2)}; \ \ \ \ \ v(\omega) = -\frac{K(T_4+ T_3)\omega}{(1+T_3^2 \cdot \omega^2)(1+T_4^2 \cdot \omega^2)} \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.6)}

Анализируя поведениеu()иv()при\omega \rightarrow 0 и при\omega \rightarrow \infty , получаем:

\lim_{\omega \to 0} u(\omega) = K; \ \ \ \ \ \lim_{\omega \to \infty}u(\omega) = 0\omega \rightarrow 0 \Rightarrow \left \{ \begin{gathered} u(\omega) \rightarrow K; \\ v(\omega) \rightarrow 0; \end{gathered} \right. \ \ \ \ \ \ \ \omega \rightarrow \infty \Rightarrow \left \{ \begin{gathered} u(\omega) \rightarrow 0; \\ v(\omega) \rightarrow 0; \end{gathered} \right.

Модуль АФЧХ (амплитуда), то естьmod(W(i)) = |W(i)| из формулы 3.4.5:

A(\omega) = |W(i\cdot \omega) | = \left | \frac{K}{(1+i\cdot T_3 \cdot \omega)(1+i \cdot T_4\cdot \omega)} \right | = \frac{K}{\sqrt{1+ T_3^2 \cdot \omega^2}\cdot \sqrt{1+ T_4^2\cdot \omega^2}}\ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.7)}

Подставляя в формулы (3.4.6) или в формулу (3.4.5) различные значения можно построить векторы, соответствующие различным значениям :

Рисунок 3.4.3 Годограф АФЧХ апериодического звена 2-го порядкаРисунок 3.4.3 Годограф АФЧХ апериодического звена 2-го порядка

Из формул 3.4.6 очевидно, что на рисунке годографа 3.4.3 :

1) \ \omega_6>\omega_5>\omega_4>\omega_3>\omega_2>\omega_1>0\\ 2) \ \ 0 >\varphi_1>\varphi_2>\varphi_3>\varphi_4>\varphi_5>\varphi_6

Используя формулу 3.4.6 можно показать что u(w_3)=0 при \omega_3 = \frac{1}{\sqrt{T_3\cdot T_4}}

Из рисунка видно, что \varphi(\omega) \in [-\pi;0] .

Формула фазового сдвига:

\varphi(\omega) = - \pi \cdot j+ arctg \frac{v(\omega)}{u(\omega)} \omega\leq \omega_3 \Rightarrow j = 0;\\ \omega>\omega_3 \Rightarrow j=1.

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

 \varphi(\omega)=\varphi_1(\omega)+\varphi_2(\omega) = -arctg (T_3\cdot \omega)-arctg(T_4 \cdot \omega)\ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.8)}

Логарифмическая амплитудная характеристика (ЛАХ)

Lm(\omega) = 20 \cdot lg \ A(\omega) = 20\cdot lg \ K - 20 \cdot lg \sqrt{1+T_3^2 \cdot \omega^2} - 20 \cdot lg \sqrt{1+T_4^2\cdot \omega^2}\ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.9)}

Графики А(), (),Lm() имеют вид:

Рисунок 3.4.4 АЧХ и ФЧХ апериодического звена 2-го порядкаРисунок 3.4.4 АЧХ и ФЧХ апериодического звена 2-го порядкаРисунок 3.4.5 ЛАХ и ЛФЧХ апериодического звена 2-го порядкаРисунок 3.4.5 ЛАХ и ЛФЧХ апериодического звена 2-го порядка

В инженерных расчетах часто графикLm() представляют виде отрезков ломаных, тогда:

при \omega < 1 /T_4 - звено близко к идеальному усилительному звену  W(s) \approx K

при  1/T_4 < \omega < 1/T_3 - звено близко к идеальному интегрирующему звену W(s) \approx K/(T\cdot s)

при \omega>1/T_3 - звено близко к дважды интегрирующему звену W(s)\approx K/(T^2 \cdot \omega^2)

В граничном случае (D=0 или T_1 = 2 \cdot T_2) \Rightarrow T_3 = T_4 отмеченные на графикеLm() (см. рис. 3.4.5 выше) точки излома совпадают:

Рисунок 3.4.6 ЛАХ и ЛФЧХ апериодического звена 2-го порядка в граничном случаеРисунок 3.4.6 ЛАХ и ЛФЧХ апериодического звена 2-го порядка в граничном случае

ЕслиD<0 \ (T_1 = 2T_2)звено переходит в разряд колебательных звеньев. Поэтому постоянная Т1в уравнении динамики (3.4.1) играет роль демпфирующего фактора, увеличение Т1(в колебательном звене) приводит к уменьшению или к полному исчезновению колебаний.

Найдем переходную функцию звена  h(t) - реакцию на воздействие единичное воздействие 1(t).

h(t) = L^{-1}[H(s)]=L^{-1} \left[ \frac{W(s)}{s} \right] =L^{-1} \left[ \frac{K}{s(T_3 \cdot s +1)(T_4 \cdot s+1)} \right]

Для нахождения функции по формуле Хэвисайда (см. раздел 2.8 Некоторые способы нахождения оригинала по известному изображению), запишем корни полюса изображения, т.е. те значения s при которых D_0(s) = s(T_3 \cdot s +1)(T_4 \cdot s +1) обращается в ноль:

s_1 = 0; \ \ s_2 =-\frac{1}{T_3}; \ \ s_3 = -\frac{1}{T_4}

Тогда по формуле Хэвисайда:

h(t) = \lim_{s \to 0} \left[ (s + 0) \frac{K}{s(T_3 \cdot s+1)(T_4 \cdot s+1)} \cdot e^{st}\right] \\+ \lim_{s \to -\frac{1}{T_3}} \left[ (s+\frac{1}{T_3}) \frac{K}{s(T_3 \cdot s+1)(T_4 \cdot s +1)}\cdot e^{st} \right] +\\+ \lim_{s \to -\frac{1}{T_4}} \left[ (s+\frac{1}{T_4}) \frac{K}{s(T_3 \cdot s+1)(T_4 \cdot s +1)}\cdot e^{st} \right]

Вычисляя пределы получим формулу для переходной функции звена:

h(t) = K \left[1+ \frac{T_3}{T_4-T3} \cdot e^{- \frac{t}{T_3}}-\frac{T_4}{T_4 -T_3} \cdot e^{-\frac{t}{T_4}} \right] \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.10)}

Весовая функция получается дифференцированием w(t) =h'(t) :

w(t) = \frac{K}{T_4 - T_3} \cdot \left[ e^{-\frac{t}{T_4}} - e^{- \frac{t}{T_3}} \right] \ \ \ \ \ \ \ \ \ \ \mathbf{(3.4.11)}Рисунок 3.4.7 Переходная функция апериодического звена 2-го порядкаРисунок 3.4.7 Переходная функция апериодического звена 2-го порядка

Примерами апериодического звена 2-го порядка являются:

1) двигатель постоянного тока при учете инерционности самого якоря (механической) и цепи якоря (электрической);

2) электрический усилитель с учетом инерционности (механической и электрической) ротора;

3) двойныеRCилиRLцепочки

Рисунок 3.4.9 Пример апериодического звена 2-го порядкаРисунок 3.4.9 Пример апериодического звена 2-го порядка

Если звено представлено в переменных состояния в матричной форме таким образом:

x' = A \cdot x + B \cdot u; \ \ \ A = \begin{pmatrix} a_{11} & a_{12} \\ a_{21} & a_{22} \\ \end{pmatrix} \Rightarrow \left \{ \begin{gathered} x_1' = a_{11} \cdot x_1+a_{12}\cdot x_2+ B \cdot u \\x_2'= a_{21} \cdot x_1+a_{22}\cdot x_2+ B \cdot u \end{gathered} \right.

то звено будет апериодическим 2-го порядка, если:

 D = (a_{11}+ a_{22})^2 - 4(a_{11}\cdot a_{22} -a_{12}\cdot a_{21}) \ge 0

Пример

В качестве примера возьмём модель демпфера, которую мы уже использовали в лекциях. (см. Рисунок 3.4.10) Структурная схема модели описывает уравнения динамики, описанные в начале статьи. Свойства системы заданы в списке общих сигналов проекта (см. рис. 3.4.11). Для получения из демпфера апериодического звена 2-го порядка необходимо увеличить силу трения таким образом, чтобы (как показано выше) коэффициентT1 был больше, чем 2 хT2. В этом случае D>0 и из колебательного звена мы получим апериодическое 2-го порядка.

Рисунок 3.4.10 Структурная схема модели демпфера.Рисунок 3.4.10 Структурная схема модели демпфера.Рисунок 3.4.11 Параметры моделиРисунок 3.4.11 Параметры модели

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

Рисунок 3.4.12. Параметры для модели демпфера в виде звенаРисунок 3.4.12. Параметры для модели демпфера в виде звена

Выполним моделирование переходного процесса при ступенчатом изменении приложенной силы и сравним переходные процессы в двух вариантах модели демпфера. График переходного процесса (см. рис. 3.4.13) показывает, что переходные процессы в двух моделях полностью идентичны:

Рисунок 3.4.13 Переходные процессы в двух моделях.Рисунок 3.4.13 Переходные процессы в двух моделях.

График частотных характеристик звена (ЛАХ и ФЧХ) представлен на рисунке 3.4.14На графике видно две точки излома характеристики ЛАХ в которых наклон последовательно меняетсяс 0, до 20дБ/дек и с 20дБ/дек до 40 дБ/дек.

Рисунок 3.4.14 Частотные характеристика ЛАХ и ФЧХРисунок 3.4.14 Частотные характеристика ЛАХ и ФЧХ

Для демонстрации влияния изменения Т1 на свойства звена выполним моделирование, в котором структурная схема является эталонной, а в модели звена будем уменьшать коэффициент силы трения (коэффициентT1).

Источником воздействия будет меандр, с периодом 3 секунды.

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

Общая схема модели приведена на рисунке 3.4.15.

Рисунок 3.4.15 Схема демпфера с изменения свойств блокаРисунок 3.4.15 Схема демпфера с изменения свойств блока

Меандр задает изменение приложенной силы 0 30 Н (входного воздействия) с полупериодом 1.5 сек. График изменения положения приведен на рисунке 3.4.16 Видно, что на первом изменении графики совпадают, но потом по мере накопления отличий в параметрах динамика изменения положения начинает меняться.

Рисунок 3.4.16 Графики положения демпферов.Рисунок 3.4.16 Графики положения демпферов.

Первая часть процесса изображена на рисунке 3.4.17 Видно, что снижение силы трения обеспечивает более быстрое изменении положения демпфера.

Рисунок 3.4.17 Начальная часть графикаРисунок 3.4.17 Начальная часть графика

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

Рисунок 3.4.18 Конечная часть моделированиРисунок 3.4.18 Конечная часть моделировани

ЗDповерхность отображает переходный процесс при ступенчатом увеличении воздействия в блоке меандр.По осиZ отражается положение демпфера, по осиY время после увеличения входного воздействия в блоки меандр, по осиX измененийT1 (уменьшение силы трения).

Рисунок 3.4.19 Поверхность переходного процесса при снижении тренияРисунок 3.4.19 Поверхность переходного процесса при снижении трения

В заключение, сравним переходные процессы для разных параметровT1 (разных коэффициентов трения). Поскольку все основные блоки вSimInTechявляются векторными, создадим модели 7-ми демпферов из одного звена. Для этого в главном окне программы подготовим 7 векторов значений с разными коэффициентами трения. Скрипт приведен на рисунке 3.4.20.

Рисунок 3.4.20 Скрипт модели для задания параметров 7 демпферовРисунок 3.4.20 Скрипт модели для задания параметров 7 демпферов

Четвертый вектор содержит переходное значение T1. Как было показано выше, переходное значениеT1, при котором апереодическое звено второго порядка превращается в колебательное расчитывается по формуле T1 = 2хT2.

В модели, в свойствах блока указываем эти векторы в столбце формулы, и теперь блок может рассчитывать одновременно7демпферов одним блоком. (см. рис. 3.4.21)

Рисунок 3.4.21 Настройка параметров блока для векторного расчетаРисунок 3.4.21 Настройка параметров блока для векторного расчета

Общая схема модели в этом случае будет выглядеть как показано на рисунке 3.4.22 Ступенчатое изменение силы передается в блок Размножитель, где преобразуется в вектор из 7 воздействий. Данный вектор передается в блок, где и происходит расчёт семи вариантов демпфера.

Рисунок 3.4.22 Схема модели 7-и демпферовРисунок 3.4.22 Схема модели 7-и демпферов

Результат переходного процесса представленна рисунке 3.4.23. Видно, что 3 демпфера ведут себя как апериодическое звено второго порядка, 3 демпфера явно превратились в колебательные.

Рисунок 3.4.23 Перемещение 7 демпферов при ступенчатом воздействииРисунок 3.4.23 Перемещение 7 демпферов при ступенчатом воздействии

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

Рисунок 3.4.25 Частотные характеристики 7-и демпферовРисунок 3.4.25 Частотные характеристики 7-и демпферов

Модели с примерами для самостоятельного изучения можно взять по ссылке.

Предыдущая лекция Апереодическое звено первого порядка.

Подробнее..

Удобное шифрование с удостоверяющим центром

25.02.2021 12:15:55 | Автор: admin

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

Наш продукт

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

Первая реализация шифрования

Изначально, когда разрабатывался продукт, для шифрования использовался симметричный алгоритм AES с использованием ключа. Данный способ не является удобным, так как нужно было всегда вводить ключ для получения доступа к документу. Также все сотрудники, которые имеют доступ к данным, должны были знать ключ для расшифровки. Такая реализация выглядит не очень удобно и небезопасно. Скорее всего, для простоты пользователи начнут использовать один ключ для шифрования всех документов, а чтобы не забыть - напишут его на стикере и приклеят к монитору. Жестко регулировать действия пользователя в данном случае - не лучшее решение. Можно заставить пользователей для каждого документа использовать уникальный ключ и с течением времени его изменять. Но тогда, при передаче документа другому пользователю, нужно будет передавать и ключ, и, наверняка, кто-нибудь при очередном обновлении ключа забудет его, и доступ к данным будет утерян. Разработка новой архитектуры, в которой учитывались бы все минусы предыдущей, напрашивалась сама собой.

Новая архитектура

Главной задачей для новой архитектуры был отказ от необходимости ввода ключа при расшифровке данных пользователями. Также имело место "пожелание" шифровать, используя сертификаты в новой версии от управляющего центра. Применение сертификата для шифрования означало использование ассиметричных алгоритмов с открытым и закрытым ключом, что немного не соответствовало концепции нашего продукта. Симметричный алгоритм позволяет расшифровывать данные любым пользователем, который знает ключ. Ассиметричный алгоритм же, в свою очередь, подразумевает, что расшифровать данные может только пользователь, имеющий парный закрытый ключ открытому ключу, которым, собственно, и были зашифрованы данные, что в корне нам не подходило. Документ, зашифрованный одним пользователем, должен был быть беспрепятственно расшифрован другим пользователем, который имел бы право доступа к данным.

Вы предложите решение, Вы же эксперт...

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

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

Эврика!

Внимательное изучение протокола HTTPS (или SSL) показывает интересную особенность, а именно то, что хоть протокол и использует асимметричное шифрование, на самом деле применяется этот алгоритм лишь для: "выработки сессионного ключа, который, в свою очередь, используется более быстрыми алгоритмами симметричной криптографии для шифрования большого объёма данных" (http://personeltest.ru/aways/ru.wikipedia.org/wiki/SSL). Таким образом можно сказать, что 2 клиента между собой при помощи асимметричного алгоритма шифрования договариваются о симметричном ключе, который и используют в дальнейшем для симметричного шифрования данных при передаче. Это сделано для увеличения скорости работы, ведь асимметричные алгоритмы работают намного медленнее, чем симметричные. Сама идея генерации симметричного ключа в нашем случае может выглядеть так, что данные будут шифроваться все также, используя симметричное шифрование одним ключом, который сгенерирован сервером. А вот сам ключ нужно будет зашифровать, используя асимметричный алгоритм и открытый ключ пользователя, которому затем и передаст сервер этот зашифрованный ключ (каждому свой соответственно). Пользователи, получив от сервера зашифрованный ключ, расшифровывают его своим закрытым ключом и используют его для расшифровки и зашифровки данных. Таким образом мы получаем, что ключ, который используется в симметричном шифровании данных, вводит не сам пользователь, а его генерирует сервер, для каждой метки свой уникальный. Далее пользователь при запросе сервера о доступных ему метках получает вместе с ними и зашифрованный ключ. Также была решена и проблема с недоступностью сервера, все полученные данные от сервера хранятся у пользователей, в том числе и зашифрованный ключ. Соответственно, при отсутствии связи с сервером, ключ берется из хранилища, и, тем самым, доступ к зашифрованным данным не пропадает.

Итог

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

P.S.

Надеюсь этот пост кому-нибудь пригодится и поможет сэкономить время.

Подробнее..

Как управлять транзакциями в микросервисной архитектуре

26.02.2021 16:11:32 | Автор: admin

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

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

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

Пара примеров, чем грозит несогласованность данных

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

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

Чтобы в микросервисном продукте не происходили такие конфликты, данные не терялись и были согласованными, мы используем шаблон проектирования Saga.

Как работает Saga

Технически Saga это отдельный микросервис, который через шину ловит сообщения о событиях в других микросервисах. Есть два варианта работы Saga:

  • Saga сверяется с шаблоном процесса и отдаёт команду другим модулям.

  • Другие модули сами подписываются на события, которые влияют на их активность и при наступлении события действуют по шаблону процесса.

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

Применение Saga в нашей практике

Пример 1. В системе для работы с медиафайлами класса DAM (Digital Asset Management), пользователи за раз могут загружать десятки фото- и видеоматериалов, каждый из которых при добавлении проходит через несколько микросервисов.

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

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

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

Альтернативные подходы, или почему мы выбрали Saga

Координатор распределённых транзакций. Принцип похож на Saga, только вместо того, чтобы слушать шину данных и отправлять через неё сообщения микросервисам, оркестратор работает напрямую с БД микросервисов.

Ограничения:

  • Этот вариант технически более сложен.

  • А если у микросервисов разный тип БД (например, MS SQL и MongoDB), этот метод в принципе не сработает.

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

Ограничения:

  • Это вполне работоспособный метод, но подходит только для простых процессов если в транзакции участвует три и более сервисов, контролировать их взаимодействие становится слишком затратным.

Здесь и стоит задуматься о Saga.

Подробнее..

Пример модели знаний о требованиях

01.03.2021 12:17:20 | Автор: admin

Зачем нужна модель знаний

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

Вот некоторые из них:

  • BABOK (A Guide to the Business Analysis Body of Knowledge) - руководство к своду знаний по бизнес-анализу от Международного института IIBA (International Institute of Business Analysis)

  • SWEBOK (Software Engineering Body of Knowledge) - международный стандарт ISO/IEC TR 19759 от 2015 г., в котором описана общепринятая сумма знаний о программной инженерии

  • SEBOK (Systems Engineering Body of Knowledge) - свод знаний в области системной инженерии, разработанный организацией BKCASE, которая контролируется Управляющим советом, состоящим из трех ассоциаций (т.е. Международного совета по системной инженерии, Центра исследований системной инженерии и Компьютерного общества IEEE)

  • BPM CBOK (Guide to the Business Process Management Body of Knowledge) - свод знаний по управлению бизнес-процессами Ассоциации профессионалов управления бизнес-процессами (ABPMP)

  • PMBOK (Project Management Body Of Knowledge) - свод профессиональных знаний по управлению проектами института управления проектами PMI

  • сертификация IREB CPRE (certification in Requirements Engineering) Foundation Level - методология инженерии требований сообщества IREB.

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

На текущий момент существует множество способов представления знаний: семантические сети, фреймы, языки и нотации и др. (Википедия).

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

  • извлечь существенные понятия о концепциях, описанных в своде знаний

  • получить структурированное системное представление о связях между концепциями

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

Что должна включать модель знаний

Cводы знаний и методологии инженерии требований и системного анализа описывают процессы, техники и подходы, применяемые в проектировании и создании информационных систем.

А раз это процессы, то классический подход к такой модели - ответить на основные вопросы:

  • кто? - какие действующие лица с какими наборами компетенций выполняют активности в процессах

  • как? - какие активности, техники и события включают в себя процессы, в какой последовательности выполняются; кроме описания самих активностей важно отразить:

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

    • ключевые свойства и аспекты активностей

    • основные ограничения

    • определения и факты, связанные с процессами

  • что? - какие поставляемые результаты и прочие сущности являются результатом активностей или поступают на вход активностей

  • зачем? - какую ценность вносят активности и процессы в общий процесс инженерии требований и системного анализа.

Кроме того, между концептами системы важно отразить связи:

  • структурные - отношение к группе, связь части и общего

  • зависимости - влияние концептов друг на друга или операции, связывающие концепты друг с другом

  • динамические - обозначить последовательность выполнения, направление потока информации

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

Archimate для представления знаний

Для практической реализации модели потребуется простой и удобный в использовании инструмент, который смог бы визуально (в графической форме) представить выявленные концепции, определения и связи.

Далее описана попытка представить методологию инженерии требований сообщества IREB в виде модели знаний в нотации ArchiMate.

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

Некоторые примеры описания модели знаний элементами нотации Archimate:

1. Активности, группы активностей и связи между ними

Цель описания: ответить на вопрос Как? - описать последовательность и структуру выполняемых в процессе активностей, а так же применяемые техники.

С помощью элемента слоя реализации Пакет работ (Work Package) можно отразить активности и техники используемые в процессах.

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

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

Элемент Ценность (Value) позволяет указать ценность или преимущества использования активности в общем процессе и ответить на вопрос модели Зачем?.

2. Результаты активностей

Цель описания: ответить на вопрос Что? - описать основные ключевые результаты активностей и процессов, информационные потоки.

Результаты активностей описываются элементом Поставляемые результаты (Deliverable).

С помощью связи Реализация (Realization) отражается - какая активность создает поставляемые результаты. Связь Доступ (Access) позволяет показать чтение или запись информации из/в поставляемые результаты. Связь Поток отражает факт передачи информации (без конкретизации сущностей) между активностями или событиям.

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

3. Свойства активностей

Цель описания: отразить основные принципы, свойства, ограничения и аспекты активностей, а так же определения, связанные с ними.

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

С помощью элемента Требование (Requirement) описываются свойства или аспекты, связанные с активностью или поставляемыми результатами процесса. Элемент Принцип (Principle) позволяет описать ключевые принципы, связанные с активностью. Элемент Понятие (Meaning) можно использовать для описания ключевых понятий и определений.

С помощью связи Ассоциация (Association) описанные артефакты связываются с активностями и поставляемыми результатами.

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

Факторы, каким то образом ограничивающие пространство свойств или оказывающие влияние на свойство отражаются элементом Ограничение (Constraint), а само влияние отражается связью Влияние (Influence).

4. Взаимосвязи между активностями и выполняющими их сущностями: роль или актор являются ответственными или выполняют некоторые активности

Цель описания: ответить на вопрос Кто? - описать наборы компетенций и основных действующих лиц, участвующих в процессах.

Элемент Роль (Business Role) позволяет отразить набор компетенций или зону ответственности, связанных с активностью. Элемент Актор (Business Actor) представляет бизнес-сущность, выполняющую активность. Это может быть как конкретное лицо, так и структурные единицы, например, подразделения.

С помощью связи Назначение (Assignment) устанавливается связь между соответствующим активным элементом и активностью, им выполняемой.

Например, Заинтересованные стороны формируют Потребность в изменениях, запускающую процесс инженерии требований, который выполняет роль Инженер по требованиям, обладающая некоторым набором компетенций (указаны в описании).

5. Структурные связи между сущностями. Обобщение и специализация

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

С использованием связи Композиция (Composition) отображаются случаи, когда один элемент является неотъемлемой частью другого (не может существовать без него). Например, активность по обучению пользователей является частью процесса выбора CASE-инструмента.

Отразить связь между абстрактным концептом и его конкретными реализациям позволяет связь Специализация (Specialization). Например, к концепту Модель относятся модели системного контекста, которые в свою очередь могут быть реализованы как DFD-диаграммы или UML-варианты использования.

6. Что еще может Archi

К каждому элементу может быть составлено описание или дано текстовое уточнение.

В состав ArchiMate входит инструмент для просмотра всех связей выбранного элемента. Глубина связей может настраиваться.

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

Заключение

Методология инженерии требований сообщества IREB описана моделью представления знаний в формате ArchiMate. Результат здесь:

Что удалось:

  • в графической форме представить знания об инженерии требований

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

  • реализовать простой и удобный доступ к модели в интернете.

Какие остались вопросы:

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

  • область применения модели - достаточность для описания других областей знаний системного анализа

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

Подробнее..

Root Cause Analysis как метод предотвращения багов

02.03.2021 22:15:14 | Автор: admin

Привет! Мое имя Юра Гомон, яBATech Lead вNIX ивот уже 8лет занимаюсь бизнес-анализом, помогая реализовывать веб- имобильные решения для бизнеса, атакже автоматизировать бизнес-процессы. Мое имя кажется Вам знакомым, т.к. недавно я опубликовал на Хабре свой BADigest.

Цель статьи напомнить бизнес-аналитикам ометоде Root Cause Analysis (далее RCA) иподелиться опытом его применения для предотвращения багов.

В сети очень много информации по RCA, потому не хочу повторяться в отношении теории. Если Вы еще не использовали Problem-solving техники и, в частности, RCA, рекомендую ознакомиться с материалами по ссылками ниже, а уже затем переходить к статье:

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

Кейс первый ополитиках

Вливной enterprise-системе на200+ пользователей все было хорошо: жили нетужили, работали три года после релиза. Новодин прекрасный день при попытке перейти поссылке всистему вместо желаемого результата пользователей ждало угрожающее сообщение

Аналог сообщения, которое увидели пользователи. Оригинал несохранился :) Источник:Bytebitebit

Разумеется, это вызвало, мягко говоря, недоумение. Вглазах пользователей работа оказалась заблокированной. Мало того, что угроза кражи паролей, так еще ипредложение продолжить, ноуже unsafe. Страшно.

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

Почему пользователи видят эту страницу?
Посмотрим А-а, так это заэкспайрился SSL-сертификат, продлим, ивсе будет впорядке.
Апочему это несделали заранее?
Никто непоставил напоминание, атри года быстро пролетели.
Резонно. Как думаете, почему непоставили?
Хм, по-моему, это первый проект, где была потребность виспользовании SSL. Это уже после вас стали сертификаты покупать идругим.
Так это ивдругих системах может случиться?
Пожалуй, пойдем везде проверим, поставим напоминалки ивгайдлайны внутренних систем добавим, что надо незабывать это делать.

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

Что изэтого стоит вынести? Ответственные, те, кто знаком сметодами RCA иFive Whys, нетолько исправили ошибку, ноначали задавать вопросы, чтобы найти истинную причину. Как только это случилось, проблему превентивно закрыли везде, где она могла произойти, тоесть предотвратили баг безопасности вдругих системах. Косвенно это привело ктому, что вкомпании стали уделять еще больше внимания безопасности.

Кейс второй олюдях

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

Менеджер вызвал человека наразговор, новсилу замкнутости последнего это непомогло докопаться досути. Максимум, что узнал нет настроения работать, сильно устаю. Чтобы все-таки разобраться сэтом ситуацией, менеджер использовал технику RCA, ивот что получилось:

  1. Менеджер задокументировал ключевые поинты разговора счеловеком названные импричины.

  2. Предположил варианты сосвоего опыта.

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

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

Граф причин проблемы, воссозданный сослов рассказчика

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

  1. Сначала человек стал засиживаться вофисе после работы почти каждый день.

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

  3. Следом вместо домашней еды онстал питаться подножным кормом.

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

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

Кейс третий оработе стребованиями

Когда БАвходит впроект, который идет уже некоторое время, первая задача разобраться стребованиями, тоесть провести аудит. Обэтом кейсе яделалдоклад наNIX Multiconfв2019году. Сегодня раскрою некоторые детали того случая сточки зрения применения RCA: как искали причины того, почему впроекте начало появляться много багов.

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

Коммуникация

Невозможно было найти ответ или решение через время. Обсуждение требований велось вAsana, Slack, JIRA, через почту, вонлайн- иофлайн-документах. Среди всех источников небыло единого:

  • клиент писал там, где ему было удобно втекущий момент;

  • остальные команды неподдержали нашу критику, поскольку имитак норм;

  • бюджет наведение SRS, митинг-минуток иструктурирование информации невыделялся.

Наша команда неполучала ответов вовремя. Другие команды непонимали наших вопросов:

  • трудности перевода;

  • если непинговать, томогли забы(и)вать нам ответить;

  • пинговать из-за большой разницы сдвумя другими таймзонами было затруднительно.

Стейкхолдеры

Наша команда получала разную информацию изразных источников.

Небыло обмена решениями сдругими командами:

  • небыло четких зон ответственности вплане шаринга информации;

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

Клиент часто менял требования/ принимал решения. Настолько часто, что одна команда успевала получить одно, авторая уже другое:

  • уклиента небыло четкой бизнес-идеи, онстарался быстро адаптироваться под нужды целевой аудитории;

  • клиент хотел реализовать как можно больше фич, невзирая наобщий концепт приложения, атакже удовлетворить всех пользователей;

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

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

Недожидаясь правок понескольким десяткам других пунктов, ЛПРы состороны команды реорганизовали перечень каналов связи иоставили всего три: обсуждение идей велось вAsana, дизайна итребований всоответствующих каналах Slack, тамже создали канал для общих вопросов. Кроме того, все решения покаждой функции стали фиксировать вJIRA, куда перевели только тетаски, которые должны были идти вразработку. Вдополнение ввели жесткие правила понеизменности скоупа врамках спринта (либо полной приостановке ипланированию спринта снуля) идлительности спринта.

Витоге чудесным образом количество дефектов стало резко уменьшаться. ЛПРы воодушевились успехом ипродолжили вносить изменения, которые также несли положительный результат. Но, как оказалось, положительным оноказался только для нас, т.к. вскоре клиент попрощался снами под предлогом того, что небыл готов ктакому уровню бюрократии :) Если заинтриговал, товдокладе поссылке выше больше подробностей.

Ичто?

Есть вещи, которые вот уже 8лет, смомента как явошел вIT, янеперестаю евангелизировать, поскольку нахожу имприменение либо вижу отражение вокружающем мире. Среди них философияпиши-сокращай, модель Кано, принцип Парето, think out ofthe box итак далее. Как выуже догадались, RCA входит вэтот перечень. Авсе потому, что важнейшая, если непервичная задачаБА заключается втом, чтобы понять почему. Будь топроблемная функция всистеме, ошибки вбизнес-процессах, нюансы человеческого поведения, негативные события вокруг все имеет глубокие корни.

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

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

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru