Из каких ролей переходят в аналитики? Мы не знаем. Самый популярный ответ — другое (36%). На втором месте — первая работа в ИТ (21%). На третьем — другая роль в ИТ (не разработчик, не QA, не из поддержки и не тех.пис) — 19%.

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

Стажеров-системных аналитиков не бывает (1%)

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

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

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

Соответственно, все хотят прокачать навыки в system design, solution architecture и проектировании интеграций.

Если это правда — что, нужно срочно делать образовательные продукты для аналитиков по архитектуре и system design?

Я привез на Flow обновленную карту интеграций.

Обновлений много:

* Изменена структура: добавлены колонки "Семантика взаимодействия", "Стандарты", "Гарантии доставки"
* Добавлена семантика для REST: ресурсный стиль (REST уровня 2) и гипермедиа стиль (HATEOAS, REST уровня 3)
* Добавлены JSON:API, HAL, JSON-LD
* SOAP включен в асинхронные методы
* Добавлен WS-RM для SOAP — протокол гарантированной доставки
* Добавлены подходы к целостности транзакций: ACID и BASE
* Добавлено описание паттернов API Gateway и ESB
* Добавлено описание ETL-процесса
* Добавлена CAP-теорема
* Добавлено описание семантик гарантированной доставки
* Раздел "Особенности" объединен с разделом "Когда использовать"
* Исправлены опечатки

А самое главное — я, кажется, придумал шаблон для описания любой технологии интеграции!

Какие вопросы мы должны задать, когда смотрим на технологию?
1. Что это? Протокол, язык, набор принципов, конкретный продукт?
2. Какой верхнеуровневый паттерн? (по Грегору Хопу: файловый обмен, общая БД, удаленный вызов, сообщения)
3. Режим взаимодействия — синхронный или асинхронный? (скорость против пропускной способности)
4. Семантика запроса / интеграционный стиль: RPC, Query, ресурсный (REST 2 lvl — ресурсы и методы HTTP), гипермедиа (REST 3 lvl, HATEOAS), стриминг, публикация/подписка — в общем, как мы смотрим на интеграцию?
5. Протокол: опираемся на HTTP или используем что-то низкоуровневое? Если HTTP — то используем ли строку запроса и хедеры? То есть, получится ли подключить кэширование, маршрутизацию и все эти готовые штуки?
6. Формат сериализации: текстовый или бинарный? Есть ли схема? Обязательна ли она? Насколько строгая типизация? Есть ли сложные структуры: вложенные объекты, массивы, maps, множества?
7. Есть ли возможность определять и передавать кастомные ошибки?
8. Есть ли встроенные средства гарантированной доставки, и какие семантики поддерживаются?
9. Что с безопасностью? Шифрование, аутентификация, контроль прав.
10. Скорость сериализации / десериализации, размер сообщений
11. Есть ли инструменты преобразования данных?
12. Есть ли язык определения интерфейсов / спецификаций?
13. Статус стандартизации / распространенность / надежность / поддержка в разных языках и фреймворках
14. Какие особенные фишки есть у технологии?
15. С какими проблемами мы столкнемся?

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

Ссылка на актуальную версию карты: https://disk.yandex.ru/i/k69r0Qr39_1P-w

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

Через эту рамку я попробовал несколько технологий разложить:

JSON-RPC: протокол
Паттерн: удаленный вызов
Режим взаимодействия: синхронный
Семантика запроса: RPC
Протокол: не зависит от протокола. Существующие реализации: HTTP, WebSockets, TCP
Формат: текстовый, JSON, свой формат вызовов и ответов. Схемы нет.
Ошибки: встроенные + кастомные (код+описание)
Инструменты преобразования данных: встроенных нет
Безопасность: встроенная в HTTP (SSL)
Семантика доставки: at-most-once
Язык спецификаций: OpenRPC (необязательный; есть генерация кода)
Фишки: легковесный, пакетные запросы
Проблемы: затруднен роутинг, кэширование, мониторинг, передача бинарных данных
Кейсы применения: взаимодействие ИИ-агентов с системами и сервисами (MCP), крипта, отправка команд.


Apache Thrift: язык описания данных и интерфейсов (IDL) + фреймворк кодогенерации
Паттерн: удаленный вызов
Режим взаимодействия: синхронный, асинхронный
Семантика запроса: RPC
Протокол: TCP-сокеты, файл, память, IPC-сокеты, HTTP
Формат: бинарный, компактный, JSON.
Схема: обязательна. Строгая типизация. Сложные структуры.
Ошибки: специальный тип exception
Инструменты преобразования данных: нет
Безопасность: TLS, SASL
Семантика доставки: at-most-once
Язык спецификаций: Thrift (обязателен, генерация кода обязательна)
Фишки: вариативность форматов сериализации и транспортных протоколов
Проблемы: плохая документация, поддерживаемые функции различаются в разных языках.
Кейсы применения: Взаимодействие с разнотипными фронтами; сериализация данных без использования транспортных функций, в т.ч. в Kafka.

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

(Upd.: В комментах есть в формате PDF, а то, говорят, в PPTX красивые шрифты побились :( )

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

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

Я вот, например, в разговоре с Дмитрием Таболичем сформулировал важное понимание про роль архитектора. Обсуждали мы доклад Дениса Бескова про пошаговый алгоритм проектирования архитектуры систем. Ну или system design. Денис его перед конференцией показывал в чате архитекторов (RASA Chat) и у себя в канале.

И вот среди архитекторов в чате разгорелось обсуждение, суть которого свелась к следующему (пересказываю своими словами):

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

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

Но если научиться быть архитектором невозможно, то откуда тогда берутся архитекторы? И вот тут я словил инсайт: дело в том, что архитекторами просто становятся. Невозможно научиться, нужно стать им. Просто в какой-то момент ты понимаешь — да, я архитектор. Появляется такое внутреннее неоспоримое убеждение. После этого, конечно, тебе уже не нужны никакие подпорки в виде алгоритмов, стандартов или чего-то там, они даже смешны. Ведь ты — архитектор [Гарри], и всё, что ты делаешь — дело архитектора. И никто другой тебе не может сказать, что ты — не он. Да кто ты такой, чтобы мне говорить, кто я такой? Сам ты не архитектор. Косвенным признаком можно считать, когда архитекторы тебя признают в тусовке своим. Как лебедя из сказки Андерсена. Думаешь — пусть они меня заклюют, эти прекрасные птицы, ан нет, не клюют — прислушиваются даже и кивают.

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

Это не про насмотренность, опыт или экспертность в программировании. Это про уверенность. У аналитиков, правда, с этим большие проблемы — видели в опросе, 54% испытывают синдром самозванца часто или всегда. Обращали внимание, как люди говорят о своей профессии? "Ну, я работаю кем-то вроде системного аналитика..."

Ни один программист не скажет, что работает "кем-то вроде фронтендера", у них всё чётко. И архитектор не будет сомневаться. Так что нужно качать не столько знания, сколько уверенность в себе и самоопределение.

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

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

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

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

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

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

А можем ещё сильнее заострить, и задать вопрос — когда требуется принятие решений? Мне кажется, принимать решение нужно, когда есть конфликт.

То есть, мы можем посмотреть через рамку конфликта. Ещё точнее — конфликта, связанного с техническими и функциональными свойствами системы.

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

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

Технический долг возникает как раз из-за компромиссов и избегания решения конфликтов. ТРИЗ дает советы, как решить конфликт (противоречие) с улучшением всех аспектов и удовлетворением всех сторон.

Гипотеза: архитектор в принципе нужен там, где есть много конфликтов (в технических системах) и их нужно решать.

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

На днях мне попалась книга Патрика Ленсиони "5 пороков команды", и второй по счету порок — страх конфликтов (до него — отсутствие доверия, а за ним — безответственность, нетребовательность, безразличие к результатам. Ленсиони рисует пирамидку, и говорит, что один порок тянет за собой следующий).

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

И если кажется, что его нет, то нужно поискать. По-английски он даже использует фразу conflict mining — добыча конфликтов.

И это задача лидера — искать их, вытаскивать и обострять, не давать закапывать.

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

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

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

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

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

У меня с этим всегда были проблемы. Самая моя долгоживущая система долго вообще никак не называлась. Ей уже полгода пользовались, а названия не было. Пользователи её называли "считалка". Ну, такое. В итоге назвали её АСК: Автоматизированная система казначейства. Причем он оказался мужчиной: "Опять это вас АСК не работает!"

А другую систему, для маржинальной торговли, тоже долго не называли, потом так и прижилось - Margin Trading.

Ещё в одной системе были десятки сервисов с трехбуквенными аббревиатурами: PLP, PLE, XLE, LMS, LRS, FMS и т.д. Своим всё понятно, человек со стороны не разберется.

Кому-то это легко дается легко — мой младший ребенок отлично придумывает названия: смастерил что-то из лего, и говорит — это Шушик! Смотришь — ну точно, вылитый Шушик, по-другому и не назовешь.

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

В одной компании версии систем называли именами озер: Байкал, Селигер, Сенеж. Стойкая ассоциация с чем-то военным.

В другой компании — очень российской! — версии были по номерам, но сама система называлась почему-то по имени города в Калифорнии - Аламеда.

В иностранном ПО любят кроме номеров версиям давать ещё и кодовые имена. У ОС Android это были разные сласти: мармелад, нуга, пирог, орео. У Microsoft - названия городов. У Apple - то примечательные места, то города, то кошки, то сорта яблок.

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

Самые креативные названия версий у Ubuntu, есть даже целая страница: https://wiki.ubuntu.com/DevelopmentCodeNames, там у них всякие "Бдительные Бородавочники" и "Сметливые Селезни" (прилагательное + животное на одну букву).

У Intel кодовые имена процессоров назывались по горам, рекам, озерам и городам вокруг мест, где расположены фабрики по производству. До сих пор помню фотку в офисе Бабаяна: "Команда Эльбруса покорила МакКинли" (гора на Аляске, кодовое имя одной из версий процессора Itanium).

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

Я пытался найти какие-то исследования о воздействии именований релизов... на что-нибудь. Но не нашел. Попадаются только статьи про автоматическую генерацию описаний — release notes. Так что мы не знаем — приносит ли кодовое именование пользу, или это просто приятное развлечение.

А как у вас принято именовать релизы? Номера, кодовые имена, какие-то правила их присвоения?

Какие вы знаете методы приоритизации? Например, функций продукта или пользовательских историй?

MoSCoW, RICE, модель Кано, value/effort, buy a feature, USM, Weighted Shortest Job First, что ещё бывает?

В целом, это, конечно, многофакторный анализ — то, чему учат на предмете "Системный анализ" в институтах. Чтобы не учитывать много факторов — их схлопывают до 2-4.

Но мне, честно говоря, и этого всегда было много и как-то сложно. Хочется чего-то более легковесного.

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

Вопрос — как перейти от попарного сравнению к упорядоченному списку. И такой метод есть — это рейтинговая система Эло (Elo rating system), которую используют в шахматах для оценки силы игроков.

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

Почему-то не вижу статей про применение рейтингов Эло для приоритизации, зато есть инструмент, куда можно забить свой бэклог и прогнать приоритизацию https://elo.bytes.zone/ (кстати, там можно всё, что угодно, сравнивать, не только элементы бэклога).

Я попробовал один список загнать, с которым мы группой часа два работали и чуть не переругались — получился ровно тот же результат, причем минут за 5-7.

Попробуйте, очень интересно, что у вас получится?

Я уже писал про митап Pimon 2025, посвященный ESB — очень классный, это фактически специализированная конференция про шины.

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

Интеграционные платформы: Панацея или лишний слой?», Антон Копылов, «Аксеникс» видео | презентация

«ESB в России: тренды и перспективы. Результаты исследования», Александр Жиляев, Size Marketing видео | презентация

«Российские платформы ESB: критерии выбора, практическое применение», Сергей Скирдин, «Белый Код» видео | презентация

«Применение нейросети для трансформации сообщений в FESB», Олег Рубцов и Франклин Банкуе, «Неолант Тенакс» видео | презентация

«Integration Gears: новый модуль Monitoring Center», Антон Курудинов, «ЛАБ СП» видео | презентация

«Прототип инструмента для миграции с SAP PO на Integration Gears», Денис Бекишев, «ЛАБ СП» видео | презентация

«JSON-first integration flows», Марат Бареев, BeringPro видео | презентация

«Репликация в «Нормализаторе», Леонид Шумский и Александр Грищенко, «Т1» видео | презентация

«Подсистема интеграции для 1С:Предприятия», Андрей Соколов и Сергей Сулимов, «Корус Консалтинг» видео | презентация

Ну или все видео в одном плейлисте: https://youtube.com/playlist?list=PLHiGNvm26VdMoauuMRoSOxQV7tkq-7iie

Надеюсь, в следующем году мероприятие будет ещё масштабнее!

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

Вот что мне показалось любопытным:

Во-первых, в РФ вендоров ESB больше 40 штук! Это само по себе удивительно, потому что в Википедии всего 28 во всем мире перечислено, а на Capterra и того меньше — 19 (но там, как обычно, мусор какой-то).

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

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

Во-вторых, и это, на мой взгляд, недостаток — у нас нет эталонного набора функций для ESB. Этот термин вообще зыбкий — то ли корпоративная шина, то ли интеграционный фреймворк, то ли движок бизнес-процессов, то ли брокер сообщений — все по-разному называют. Как в анекдоте: почему иногда говорят "Будапешт", а иногда — "Бухарест"?..

Тут бы хотелось какую-то классификацию, ну или профили — как сборки типовых функций. Сергей, насколько я понял, выделяет следующие:
1. Набор типов коннекторов и возможности их конфигурации. Тут нужно раскрывать, что там внутри: правила, форматы, фильтры, протоколы.
2. Функции и возможности преобразования данных
3. Настройка маршрутизации и, как расширение, целых сценариев и бизнес-процессов
4. Проверки корректности данных и контрактов
5. Мониторинг и траблшутинг — тоже в широком смысле, от логов до механизмов гарантированной доставки и очередей ошибок
6. В принципе наличие очередей, их виды и назначение

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

Надеюсь, такая работа ведется (и готов участвовать, кстати).

То же касается и НФТ: выцеплены отдельные характеристики, но хочется систематизации.

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


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

С другой стороны, если анализировать продуктовую сторону такого обзора, возникают некоторые сомнения — кому и в какой момент он нужен? Шину выбирают не так часто, а меняют и того реже. И если так, то обзор должен стоить довольно дорого, и быть довольно детальным, с результатами пилотов и экспериментов, с рассмотрением типовых кейсов (это, кстати, раскрыто у Сергея в серии постов — некоторые решения он пилотировал). На западных рынках есть такой тип компаний: технологический брокер, или консультант по выбору ПО. Который только советует и выбирает, но не ведет сам проект внедрения (этим занимаются интеграторы). Интересно, есть ли у нас похожие сервисы, и готовы компании платить за такую услугу?

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

Вот и сейчас — смотрю на отчет по сбою амазоновского US-EAST-1, который уронил чуть ли не все сервисы (люди урок в Duolingo пройти не могли! Стрики свои многомесячные потеряли!)

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

Темы интеграций, на самом деле. Но аналитики редко туда заглядывают. А тут ещё точка возникновения сбоя — план DNS, это в 99.9% случаев за пределами внимания аналитика.

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

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

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

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

Я на тренинге упоминаю о статистических проверках данных: не просто вам пришло что-то, и ок, а проверьте — то, что пришло, оно вообще похоже на то, что вы ожидали? Возможно, обычно вам записей приходит около 10000, а тут пришло 100 — это нормально, или ошибка? Обычно суммы в договорах распределяются нормально, а тут вдруг 70% одинаковые — это нормально? Время выполнения домашних заданий у студентов тоже как-то распределено, а тут мы получили все с одним временем загрузки — подозрительно? Наш процесс собирается удалить все IP-адреса — правильно ли это? И так далее. Думать о таких вещах заранее — верх душноты. С другой стороны, достаточно один раз потерять все записи за день из-за сбоя в интеграционном слое — и будешь вставлять такие проверки на автомате.

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

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

Ну что, аналитики, настало ваше время! Самый модный способ разработки программ с помощью ИИ сейчас — SDD, spec-driven development. Человек пишет требования и спецификации, ИИ пишет по ним код. Программисты не нужны.

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

Идея похожа на подход "documentation first", знакомый нам по API. Как конкретно код написан — уже не очень важно, пока он соответствует спецификациям. И меняется в ходе проекта в первую очередь спецификация, она становится ключевым артефактом. А как все смеялись над российским подходом с обязательными аналитиками и постановками на каждом проекте!

Инструменты SDD уже выкатил GitHub: Spec Kit, есть отдельные проекты — Tessl.io и Kiro. Недавно на сайте Мартина Фаулера вышла обзорная статья, кратко перескажу её здесь.

Три основные идеи SDD:

1. Spec-first: сначала пишется (ну или генерируется) спецификация. Код генерируется только по этой спецификации.
2. Spec-anchored: спецификация сохраняется надолго. Если в дальнейшем понадобятся изменения — меняется спецификация, а не код. Изменения в коде следуют за изменениями в спецификации.
3. Spec-as-source: спецификация — главный артефакт, и только над ней работает человек. К коду человек не прикасается.

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

Работает примерно так:

Kiro предлагает цепочку Requirements → Design → Tasks (Требования → Проект → Задачи).
Требования записываются в виде юзер-сторей с критериями приемки в формате BDD-сценариев (Дано... Когда... Тогда...).
Проект представляет собой описание устройства будущей системы:
Архитектура:
Компоненты архитектуры
Потоки данных
Компоненты и интерфейсы
Модели данных и т.д.

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

У Spec Kit всё примерно так же, но перед требованиями есть ещё общий документ "Constitution" (Конституция), это что-то вроде системного промпта, где перечислены главные правила, вроде "Никакого кода без заранее написанных юнит-тестов" и "Обязательная модульность: каждая фича реализуется как отдельно стоящая библиотека".

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

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

Теперь о проблемах. В статье есть и описание попыток что-то сделать в логике SDD, и основной вывод — непонятно, для какого кейса применим этот подход. В туториалах, если они есть, показано создание небольшого проекта с нуля (greenfield). Но именно что небольших. При попытке исправить небольшой баг в существующем проекте (brownfield) быстро выяснилось, что нужно написать 4 разных юзер-стори и проверить 16 приемочных сценариев. Причем в одном из случаев ИИ неплохо разобрался с кодовой базой, но когда дошло дело до самостоятельного написания — принялся дублировать уже существующие классы...

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

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

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

Приходите! За кого будете болеть?

Чем изучение учителей может помочь аналитикам?

Я люблю перетаскивать методы из одной отрасли в другую. Такой трансфер технологий и методик. А то каждый варится внутри своей индустрии, и не знает, что там у других. И появляются почти идентичные методики — например, в образовании никто не знает про PDCA или HADI-циклы, у них там ADDIE — Analize, Design, Develop, Implement, Evaluate. В авиации очень развита методика использования чеклистов. В медицине — интересные находки в области обратной связи (например,"шит-сэндвич" плохо работает, лучше работает Ask-Tell-Ask). В промышленности есть стандарты по интеграции. И т.д.

Интересно это изучать и переносить работающие практики.

Вот, например, модель интеграции технологий в образовательный процесс, TPACK. Идея в том, что для эффективного использования технологий нужно не просто хорошо знать технологические инструменты (Technology Knowledge, TK), но и педагогические практики (Pedagogical Knowledge, PK) и свой предмет (Content Knowledge, CK). И их пересечения: TPK — как подкреплять педагогические практики технологиями, TCK — как технологии помогают именно в этом предмете, и PCK — какие педагогические практики используются для этого предмета. Ну и TPACK — как всё это собирается вместе. В последнее время эту модель расширяют знаниями про ИИ: AI-TPACK.

И вот тут, кажется, можно рассмотреть такую же картинку для аналитиков, применительно к AI. Получается очень похоже:
🤖 технологические знания (PlantUML, C4, SQL, Swagger, RegExp'ы, Промпт-инжиниринг) — TK,
📚 знания методов анализа (методы сбора требований, контекстный анализ, моделирование потоков данных, моделирование данных, методики проверки полноты, методики разработки и оценки НФТ, пользовательских интерфейсов, интеграций) — System Analysis Knowledge, SAK,
🎁 знание предметной области — Domain Knowledge, DK.

Сокращение c красивым именем, правда, не придумывается — TDSAK? SADTK? TEDSAK? DAISAK?

Но про пересечения (особенно в контексте ИИ) можно продуктивно подумать:
TSAK — какие методы системного анализа можно поддержать какими технологиями и [ИИ-]инструментами?
TDK — какие технологии обычно применяются для описания этого домена? Что про них знает ИИ?
DSAK — какие методы анализа применимы в этом домене? Что чаще используется?

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

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

Но несколько небезынтересных идей удалось сформулировать.

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

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

Если очень нужно работать с внешней командой, а хочется продуктовый подход — есть способ организации работ "Retainer", вот про него в изложении Алексея Кулакова: https://speakerdeck.com/kulakov/razrabotka-produkta-vs-autstaf-vs-autsors

Ещё есть Agile Contracts: "Money for Nothing and Your Change for free" https://www.scruminc.com/agile-2008-money-for-nothing-2/

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

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

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

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

Обычно я скорее испытываю чувство "блин, вы меня опять поимели, но уж ладно, я готов с этим смириться". Мастерство владельца продукта — дотянуть денежный поток с клиентов до максимума, не потеряв при этом клиентов на каком-то разумном сроке. Срок, на самом деле, зависит от бизнес-модели. Если у вас на входе достаточно большой поток клиентов, то каждого конкретного вы можете хоть дурить — этот отвалился, другой придёт, неважно. Ваша цель — однократная покупка. Это модель продавцов на АлиЭкспресс. Но обычно все борются за LTV — время жизни в продукте и денежный поток за время жизни. Например, допродажами — когда ты уже оплатил подписку, но вот за этот сериал нужно заплатить отдельно. И вот максимизация этого потока достигается состоянием клиента "ненавижу вас, но всё равно плачу". Какой уж тут win-win.

А самые крутые продукты, самые массовые, действуют ещё тоньше. Они играют на подкармливании смертных грехов:
🧐 гордыня,
🤩 алчность,
🤬 гнев,
🤑 зависть,
😍 похоть,
😋 чревоугодие,
🥱 лень.

Все доставки, AI-помощники, уберы, сервисы уборки, готовой еды, такси, умные дома, подборки музыки — это лень.

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

Любая платформа с комментариями и реакциями эксплуатирует гнев. В Интернете кто-то не прав! Этот коммент сосет! Снимите ваше белое пальто! Да начнется срач!

На алчности живут свалки контента и маркетплейсы. Доступ к миллиону фильмов, видео, книг и музыкальных треков! Всего за 299 р. в месяц. Только сегодня, со скидкой до конца дня. Цена снижена, купи три — получи один бесплатно, у нас черная пятница и киберпонедельник. Сюда же все кэшбеки, розыгрыши, и прочая геймификация. За каждую покупку вам выдадут NFT-игрушку, собери всю коллекцию!

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

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

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

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

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

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

Так что главный фреймворк по построению продуктов — SDD, Sins Driven Development. И приоритизировать фичи нужно по вкладу в пестование какого-нибудь греха.

А если так не делать — то и продукт "не выстрелит", или экономика не сойдется. Такой вот win-win.

Забытое искусство конструирования URL. Нашел классную статью про URL'ы: https://alfy.blog/2025/10/31/your-url-is-your-state.html

Главная идея: URL'ы — это состояния. Похоже на REST, да? Всё крутится вокруг состояний приложения, и каждый URL представляет некоторое состояние. Это относится и к API, а к web-приложениям — в особенности.

При этом URL — это такая пограничная тема между бэкендом и фронтендом. Кто за них отвечает? Кто их проектирует? Или как они вообще появляются? Иногда — аналитик (для API). Для приложения — непонятно, кто.

Современные фронтендеры часто вообще не понимают, о чем речь. Типичное проявление: вы устанавливаете фильтр на таблицу или список, потом переходите к конкретному экземпляру, потом возвращаетесь обратно — и все фильтры сброшены. Ну конечно, а где их сохранить? В cookie? В localStorage/sessionStorage? В внутрибраузерной indexedDB? Так много вариантов и очень сложно в реализации. Вот бы был простой способ сохранить это состояние без всяких баз.

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

Основной элемент URL для этого — query parameters, параметры запроса(строка после ?). И такой недооцененный элемент URL, как фрагмент (строка после #).

Эти части URL можно использовать очень творчески, например, в GitHub добавление фрагмента #L108-L136 будет означать "показать исходник, выделив в нем строки 108-136".

А вот как записываются в URL координаты в Google Maps: @22.443842,-74.220744,19z

Состояние чего мы можем хранить в URL? Какие данные о состоянии приложения?
— Поисковый запрос
— Фильтры
— Пагинация
— Сортировка
— Модель просмотра (таблица / список / карточки)
— Период дат/времени
— Диапазон строк или ещё чего-то счетного (в отличие от пагинации, здесь имеется в виду подсвечивание на странице)
— Координаты или область просмотра для больших графических представлений (карты, доски)
— Выбранные опции, выделенные элементы, активные вкладки, раскрытые/закрытые элементы в древовидных структурах
— Параметры конфигурации интерфейса, например — язык или тема (темная/светлая)
— Фича-флаги, варианты A/B-тестов

Какие типовые подходы есть к кодированию информации в query:
Значения параметров через & : ?debug=true&analytics=false или даже без значения: ?mobile (самого наличия флага уже достаточно)
Множественные значения:
?languages=javanoscript+typenoscript+python или
?languages=javanoscript,typenoscript,python
Массивы: ?ids[0]=42&ids[1]=73 (php поддерживает парсинг такого автоматически)
Структурированные данные:
?filters=status:active,owner:me,priority:high или даже JSON в форме base-64:
?config=eyJyaWNrIjoicm9sbCJ9== (но это уже не очень хорошо, URL перестал быть человекочитаемым)

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

В общем, проблема проектирования URL получается на стыке:
Product/UX: Как будет понятно и удобно пользователям?
Frontend team: Как удобнее писать клиентов?
Backend team: Как наиболее эффективно парсить и распознавать URL'ы?
DevOps: Как настроить кэширование и маршрутизацию?
SEO/Marketing/Product: Ради чего мы всё это делаем и как измерить эффект?

И кто всё это сведет воедино? Понятно, это западная статья, у них нет системных аналитиков, но мы-то знаем...