2025-05-31: Юбилейная AnalystDays - очень хороший контент

Короткая ссылка: AnalystDays-2025a

Ссылки сюда (4) →

О других конференциях

К своему 20 юбилею конференция AnalystDays выросла. После досрочного закрытия продаж на несколько последних конференциях организаторы сменили площадку. И новая позволила вместить почти 1300 участников. Шесть параллельных треков: четыре докладов и два мастер-классов. И очень хороший контент, реально было несколько докладов, которые для меня были очень ценными. Так бывает далеко не на каждой конференции. И, как обычно много общения и нетворкинга.

Дальше — обзор докладов, часть из них я публиковал в ходе конференции, а сейчас — дополняю.

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

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

Максим Цепков. Аналитик и legacy: как разобраться в устройстве старой системы?

Нескромно обзор со своего доклада. Я рассказывал о погружении в старую enterprise-систему. Эта задача может возникать по разным причинам: заказчик хочет ее заменить, или с сохранением старой заказчик хочет прекратить реализовать какой-то новый функционал рядом с тесной интеграцией, или просто возникла потребность в доработке давно стабильного функционала. В любом случае надо разобраться в системе. Мне приходилось решать такую задачу многократно и я делился своим опытом. Документы, если и есть, то сильно устаревшие. Но это не значит, что они бесполезны: сопоставляя их между собой и с тем, что слышишь от пользователей на интервью. А еще очень поможет знание типовой схемы enterprise-приложения — реализации бизнес-процессов через workflow документов. Но надо не только разобраться, надо еще рассказать об этом заказчикам и команде разработки, и тут помогают схемы в формальных и неформальных нотациях. Все это было в докладе, презентация? как обычно, доступна на странице доклада Аналитик и legacy: как разобраться в устройстве старой системы? и на сайте. А видео в общем доступе появится только через полгода.

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

Артем Кузнецов. Топ 15 трендов UX/UI дизайна на 2025—2027 год

Один из замечательных докладов конференции. Я сомневался, доклады про тренды часто поверхностны, а в этом — был глубокий разбор и содержания тренда и практических действий. Началось с минимализма — это старый тренд, но до сих пор актуальный. Потом были ИИ и ML, персонализация, кроссплатформенный UX, AR и VR, микровзаимодействие, голосовой интерфейс. Подробно пересказывать не буду, смотрите презентацию, они уже на сайте. Тем более, что 15 трендов Артем разобрать не успел, но у него есть статьи и подробная презентация на 100+ слайдов, в презентации были ссылки.

Ольга Павлова. Как аналитику участвовать в проектах по дизайну интерфейсов

Второй прекрасный доклад # Основная мысль: собственно аналитическая работа по извлечению знаний занимает 7 % работы аналитика и 99 % резюме. Почему так? Потому что важно не просто собрать знания, а эффективно донести их. Люди не читают документы на 10 страниц с UML-схемами, они это игнорируют. Лошадь можно подвести к воде, попробуйте заставить пить — это об этом. Аналитические методы совершенствовать нет смысла, если задача — синтез решений и донесение смыслов.

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

1. Есть реальность системы — и понимание этого — гигиенический фактор. Рассказывать об устройстве системы всем, документы не работают, работают мультики, видео. Реальность людей и реальность системы не связываются автоматом: связь настроек 1С с бухгалтерией — не очевидна.
2. Есть реальность системы и реальность профи — дизайнеров, разработчиков, менеджеров. Не очевидно, чем полезны аналитические практики. Не понятно, почему надо делать брейншторм или тщательные исследования в конкретных ситуациях — надо проговаривать, обосновывать.
3. Баланс сложности. Сложность мира бизнеса и мира технического. Нужна связь, не надо излишне упрощать.
4. Реальность клиентов. Это не про деньги, это про результат — спорт, достижения. В реальности системы и профи никакого спортивного духа достижения результата нет.

И нужен аудит: все виды реальности в результатах работы.

Как доносить информацию? Длинные простынки не работают, пройдут мимо. Истории. Их мало кто умеет рассказывать. Надо переупаковывать, чтобы дошло. Это отдельные навыки — голливудские сценаристы, Пропп.

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

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

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

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

Татьяна Половинкина. DataVault: разрывая звезды Кимбалла

Когда-то начиналось все с хранения широких таблиц — простые запросы, сложные изменения, если что-то меняется. Потом появилась звезда и снежинка, путь к третьей нормальной форме. А всего их 11, 6-я якорная. И надо выбирать, тут баланс скорости изменений и запросов. Потом пришла потребность в истории изменений — появились сначала интервалы действий в основной таблицы, а потом концепция DataVault: есть hub с бизнес-ключом, links между ними и satellite с историей изменений, их несколько, если разные атрибуты меняются в разном темпе, например, паспорт и фамилия меняют редко, а адрес и телефон — часто. И data vault решает проблемы множественности источников данных — делаем еще сателлиты. Для хранения историчности есть 7 форм, они различаются и надо выбирать. В докладе было много кейсов и историй, в пересказе это не воспроизведешь, так что ждите запись.

А я похвастаюсь, что в далеком 1999 году делал хранение объектов в якорной форме в АБС, позднее (в 2003) это ядро было доработано для гибридного хранения, когда часть атрибутов лежит в плоской таблице, а часть — как отдельные атрибуты, оно было использовано в нескольких проектах и до сих пор работает. В объектном хранении были атрибуты с историей изменения, а в гибридном варианте появились анкеты-сателлиты для хранения исторических атрибутов. При этом в системе коммунального биллинга нам надо было решить более сложную задачу — уметь показать описание истории изменений объекта в системе, которое было в прошлом, на момент выполнения расчета. То есть показать, какова была история проживающих в квартире (прописки и выписки) в 13:00 2 числа текущего месяца, когда была создана квитанция на оплату, чтобы обосновать правильность работы системы.

Спасибо Тане за хороший доклад!

Максим Шаломович и Евгений Асламов. Забудь про физику, думай о логике!

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

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

Если аналитик реально хочет сделать полезное разработчикам — то используйте DDD, организуйте Event Storming (и зовите разработчиков), проектируйте DTO и структуры для ORM. Это требует несколько других знаний, но на этом языке разработчики будут говорить. А если все-таки надо выбирать базу данных — то нужен процесс принятия архитектурного решения. Модели барин и вече — одинаково ущербны. Нужно документирования целей, оснований, рассмотренных аргументов и принятия решения, как для всякого решения. Организовывать может кто угодно. И за решение должна быть персональная ответственность: тот, кто его принимал совместно с командой разгребает последствия, если решение оказалось на совсем удачным. Хороший доклад, спасибо за него Максу и Жене!

Ильдар Гиматдинов. Как аналитику управлять Архитектурой, не привлекая внимания санитаров

Прикольный доклад с гротескным макросюжетом в стиле Кафки: в 2010 пришел scrum и аналитиков заморозили в криокапсуле, ведь команде они не нужны, а в 2025 начали размораживать — масштабирование SAFe, он сложный, без аналитиков не получается. Но это — макросюжет, а в докладе — история такого размороженного аналитика, которые осваивает микросервисную архитектуру, используя при этом старые подходы. Три такта, которые он осваивает, отчасти придумывает.

1. Декомпозируем схему данных предметной области, и не формально через метрики coupling и cohesion, а выделяя содержательные домены.
2. К традиционной схеме бизнес-процесса привешиваем микросервисы вместо обычного workflow документов, для реализации конкретных шагов. Получается похоже на archimate.
3. Проектирование RestAPI в виде mindmap: сервис — endpoint — чаcть url — query + create/update/delete. B к любому узлу — пояснение.

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

Ирина Гертовская. Гладко было на бумаге… Предпосылки успешного внедрения.

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

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

Анастасия Кайнова. Диаграммы, которые ожили: PlantUML и немного кода

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

Смотрела draw.io — там есть раскрытие, но получается не очень хорошо. Потом поискала и увидела — в PlantUML есть переменные и препроцессинг, который позволяет скрывать части диаграммы в зависимости от значений переменных. И принципиально решение есть — ты делаешь html-страницу, в которой настраиваешь переменные, а дальше меняешь картинку в зависимости от их значений. Встраиваешь это в конфлюенс, там есть макрос встройки html-страниц. Но как сделать генерацию картинки по тексту диаграммы? Для этого есть api PlantUML, туда надо в url отправить запакованный и закодированный текст диаграммы, и получить png-файл результата, который и показывается на странице.

В докладе были подробности и детали по тому, как она делала этот скрипт. Пришлось самой разбираться в JS чтобы доработать результат, выданный ИИ, исправив ошибки через сравнение с найденными на github примерами. Там есть много тонкостей, в том числе — с кодировками, PlantUML использует свою нестандартную версию base64, так исторически сложилось. В целом успешно, в конце доклада — ссылки на диаграммы, она выложила примеры с кодом и комментариями. Rendering выполняется внешним сервисом на plantuml.com, у нее работает. Но, наверное, если plantUML развернут локально, можно к нему обратиться вместо внешнего. Пока не доведено до продукта: если диаграмму меняешь, надо редактировать исходный текст, а дальше проходить цикл получения упакованной версии. Но тут можно сделать скрипт.

Анастасия Динерштейн. Переговоры в IT: скандалы, интриги, расследования

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

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

Андрей Москаленко. Автоматизация самообразования аналитика: от документации к картотеке знаний

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

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

Ольга Ведерникова. ИИ-агенты: вчера были слова, сегодня — действия

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

Может, у меня это личное впечатление, потому что я сам интересуюсь темой и делал обзорные доклады с кейсами на ПИР-2024 и WAW-2025. Видео, правда, доступно только для участников, но презентация — структурная и ссылки на кейсы там явно выделены. Так что если кого-то тема интересует — загляните.

Полина Силина из БСС. Цифровой рубль: особенности реализации

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

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

А еще надо освоить тонны документации, при этом не все документы в открытом доступе, и не все документы вам пришлют. Например, документ безопасности: там требование, что только одна авторизация на одну сессию. Внимательно читаем все ссылки — и смотрим, нет ли там документов, которые недоступны. И у себя тоже ссылаться. Требования по ИБ бывают очень мытные, надо консультироваться.

Требования активно меняются, перечень изменений в альбоме сообщений — до 800 страниц. И требования к интерфейсам тоже. Требования к интеграции и к сообщениям могут противоречить, и надо разбираться. И надо рассчитывать на необходимость постоянных доработок. Они получали все изменения от Банка, которому отправлял ЦБ. Но можно пропустить, что не отправят. У них были такие ситуации. Например, изменились требования по безопасности, и выяснили на тестирование. А там Kafka перестала удовлетворять, потребовался REST API.

Большое количество интеграций. Для пользовательского решения — минимум 4 вендоров: решение банка России, удостоверяющий центр Банка России, вендор API доступа к платформе и вендор для интеграции авторизации с госуслугам. Не все вендоры будут отвечать. Например, один из вендором предложил прочитать всю внутреннюю интеграцию и самим проработать интеграцию. И у них пока никакой интеграции с удостоверяющим центром нет, обещали к новому году. Важно: вопросы к ЦБ не стоит откладывать, потому что срок ответа не предсказуем: могут ответить завтра, а могут думать месяц. И все вопросы — надо дублировать. Когда они начали работать с несколькими банками — и они начали справшивать через разные банки. Появилось поле «Счет» без пояснение. Один ответ — для клиента заранее регистрируется номер счета цифровых рублей, и его надо откуда-то взять. А другой ответ — это любой счет клиента, на который возвращаются деньги, если что-то пошло не так. И дальше еще выясняли.

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

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

Елена Михайлова. Успешное внедрение BPM: Неожиданные сложности и эффективные решения

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

Взял Zeebe от Camunda. Движок два года назад встроили в CRM-платформу, которую делает компания. Но массово сначала не получилось: для аналитиков было слишком сложно, а разработчикам проще и привычнее написать метод. Их команде поставили задачу снизить порог входа, и они достигли успеха.

Чем снизили порог входа? Это в докладе не было, в конце Лена кратко рассказала, отвечая на вопросы, а я записал как услышал. Есть job worker, а есть коннекторы. Обычный способ работы — на job worker. У них есть фабрика базовые api, И есть коннектор Zeebe — что он умеет делать шаблоны. Например, есть сервис таск — и когда выбрал create task, то тебе сразу выдают методы, дают заполнить параметры и таким образом упрощают настройку. Еще упрощали настройку таймерных историй и другие распространенные случаи.

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

Какие проблемы?

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

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

Валерий Патрушев. Самое мощное оружие в галактике или автоматизация сиквенс диаграмм по-взрослому

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

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

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

Я это знаю по своему опыту: мы использовали для ведение кода на SQL препроцессор m4, и после разных экспериментов сильно ограничили его использование: только заголовки функций и пакетов, чтобы обеспечить синхронность заголовков и тела (это в Oracle), и чтобы автоматически порождать документацию. А сам код оставили на нативном языке, разрешив лишь локальные макросы, уместные там, где много кода повторяется, 2-3 общих для типовой обработки ошибок и логирования, чтобы можно было включать разные отладочные сборки. Иначе новым разработчиком было очень сложно погружаться.

Еще есть сложность с confluence. Если вы написали свою библиотеку, то чтобы ее включить — надо пройти админов. Но есть workaround? можно получить результат препроцессинга не в виде готовой диаграммы, а в виде описания после препроцессирования и его подложить в conluence, а исходный вариант туда же прицепить как заметку. У него есть библиотека, которая это автоматизирует.

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

Лев Немировский из ПСБ. Системный анализ для Highload: что действительно важно

Рассказ был основан на реальном кейсе, на котором произошел прокол: делали сервис для события, и совершенно не учли, что в 09:55, за 5 минут до старта, громадное количество пользователей придет и будет пытаться войти. И если производительности не хватит, то они создадут дополнительную нагрузку, кратно превышающие число пользователей. Потому что когда сайт не отвечает, пользователь что делает? Правильно, открывает еще одну вкладку и пробует там, и множить вкладки он может очень быстро. При этом проблема может быть не у вас внутри, а, например, с внешней капчей — там есть свои ограничения, если она стоит на входе.

Эффект известный, даже частные термины есть — эффект хабр-статьи или пиар-акции. И теперь они об этом знают. И понимают, что такие сценарии надо продумывать и включать. В разных вариантах. Не достаточно просто ставить обобщенное требование, такое как время отклика 500 мс для 95% запросов при нагрузке 1000 rps.

Но, к моему сожалению, этот кейс не был обобщен как продумывание разных сценариев, при которых сервису может стать плохо под нагрузкой. Вместо этого в докладе был рассказ именно про «правильный метод формирования требований для масштабирования», в который внесли одну поправку — на сценарии пиковых нагрузок. В том-то и дело, что никакого правильного метода не существует. Я слушал достаточно много докладов от разных компаний про работу с highload — применяемые методы очень разнообразны и грабли тоже. Тут как с ведением проектов: когда очередной проект по «правильной методике» не уложился в бюджеты и сроки, то верящие в метод люди проводят анализ и докручивают метод в конкретном месте. И в следующий раз стреляет в другом. Надо менять сам подход, agile-методы появились именно благодаря этому, было признано, что метод не дает гарантий. Так и тут: надо признать, что метод не дает гарантий, в любом случае что-то может пойти не так, и надо готовиться, чтобы увидеть проблему раньше, и иметь разные сценарии работы решений — да еще их тренировать. Частично это в докладе было, но без акцента. Примеров и деталей про организацию нагрузочного тестирования, тестирования устойчивости, резервных сценариев и плана действий при сбоях — не было.

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

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 11:47, 31 мая 2025 • нет комментариев