Срочно в номер! Мы все неправильно понимали, как работают методы HTTP!
Всегда ведь всем говорят, что REST строится вокруг методов HTTP, а они соответствуют операциям CRUD:
POST — это Create,
GET — Read,
PUT — Update,
DELETE — Delete.
Но не всё так просто. Есть документ с объяснением семантики HTTP — RFC 7231, 'HTTP/1.1 Semantics and Content', датируется 2014 годом, за авторством самого Роя Филдинга (и обновлённый в 2022 как RFC 9110)
Там всё написано, из первых уст, так сказать.
Понятнее всего с GET — это действительно запрос получения ресурса.
Создание ресурса — это PUT: 'The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.'
То есть PUT может и изменять ресурс, и создавать его. Главное — в PUT создается или изменяется ресурс по конкретному адресу (URI). Понятно, что это не сработает, если мы включаем в URI идентификатор, который выдает сервер (его и знать может только сервер). Но мы, например, можем положить через PUT оценку конкретным пользователем товара или статьи: тогда первый PUT создаст оценку, последующие её поменяют, но доступна она всегда будет по одному и тому же URI. В этом примере понятно, почему PUT небезопасный: кроме самой оценки конкретного пользователя ещё поменяется и общая оценка товара (и б-г знает что ещё — может быть, место в поисковой выдаче, а может этот товар попадет на главную, и т.п.).
DELETE — это не совсем удаление. Это скорее отключение ресурса — по этому URI он больше не будет доступен. Что там внутри сервера при этом произойдет — только его дело. Может быть, на самом деле всё удалится. Может быть, пометится как удаленный. Может быть, отправится в архив и появится по новому адресу (поэтому DELETE тоже небезопасная операция). В RFC сказано, что DELETE достаточно редкая операция, и может применяться к ресурсам, созданным при помощи PUT. Могут быть интересные истории, например с ресурсом, указывающим на "последнюю версию статьи". Если сказать ему DELETE — что должно произойти? Вся статья удалиться, или удалиться последняя версия, и на этом же URI должна восстановиться предыдущая версия?.. Возникает неоднозначность семантики.
И самое сложное — POST. Это вовсе не создание ресурса, как мы всегда думали. Это, вообще говоря, просто семантическая дыра: 'The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.'
То есть, как хотите, так и понимайте. Единственный смысл — мы хотим что-то сказать серверу, вот как. А дальше сервер уже будет решать, в соответствии с "собственной специфической семантикой ресурса". Это может быть:
— передача блока данных для обработки (не факт, что что-то тут создается!);
— создание нового ресурса, у которого ещё нет идентификатора и URI (обратите внимание, URI у ресурса появляется уже позже: мы обращаемся к одному адресу — к сервису, по сути, — чтобы создать ресурс по другому адресу);
— добавление данных к имеющемуся ресурсу (!!!)
Мы можем через POST создать один ресурс, несколько новых ресурсов, дополнить существующий ресурс, вообще ничего не создавать.
Кажется, самого Филдинга не очень заботило, строите ли вы своё API через CRUD, или нет. Его гораздо больше интересовало, чтобы ваше API было самоописательным и предлагало список действий, которые вы можете осуществить с его ресурсами.
И, конечно, в его диссертации вообще не упоминаются ни POST (там только GET и HEAD из методов упоминаются), ни CRUD.
В отдельном посте на эту темы он так и говорит: вся эта возня с методами просто не важна для обсуждения архитектурного стиля REST, главное — соблюдать единообразие и не делать получение данных через POST (а то кэширование и перезапросы работать не будут).
Так что POST — это операция со смыслом 'this action isn’t worth standardizing', "это действие не стоит стандартизации".
Как видно из поста Филдинга, в нулевые было распространено представление, что "настоящий" REST должен вообще обходиться без POST(!), видимо были сильны ассоциации с SOAP.
Всегда ведь всем говорят, что REST строится вокруг методов HTTP, а они соответствуют операциям CRUD:
POST — это Create,
GET — Read,
PUT — Update,
DELETE — Delete.
Но не всё так просто. Есть документ с объяснением семантики HTTP — RFC 7231, 'HTTP/1.1 Semantics and Content', датируется 2014 годом, за авторством самого Роя Филдинга (и обновлённый в 2022 как RFC 9110)
Там всё написано, из первых уст, так сказать.
Понятнее всего с GET — это действительно запрос получения ресурса.
Создание ресурса — это PUT: 'The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.'
То есть PUT может и изменять ресурс, и создавать его. Главное — в PUT создается или изменяется ресурс по конкретному адресу (URI). Понятно, что это не сработает, если мы включаем в URI идентификатор, который выдает сервер (его и знать может только сервер). Но мы, например, можем положить через PUT оценку конкретным пользователем товара или статьи: тогда первый PUT создаст оценку, последующие её поменяют, но доступна она всегда будет по одному и тому же URI. В этом примере понятно, почему PUT небезопасный: кроме самой оценки конкретного пользователя ещё поменяется и общая оценка товара (и б-г знает что ещё — может быть, место в поисковой выдаче, а может этот товар попадет на главную, и т.п.).
DELETE — это не совсем удаление. Это скорее отключение ресурса — по этому URI он больше не будет доступен. Что там внутри сервера при этом произойдет — только его дело. Может быть, на самом деле всё удалится. Может быть, пометится как удаленный. Может быть, отправится в архив и появится по новому адресу (поэтому DELETE тоже небезопасная операция). В RFC сказано, что DELETE достаточно редкая операция, и может применяться к ресурсам, созданным при помощи PUT. Могут быть интересные истории, например с ресурсом, указывающим на "последнюю версию статьи". Если сказать ему DELETE — что должно произойти? Вся статья удалиться, или удалиться последняя версия, и на этом же URI должна восстановиться предыдущая версия?.. Возникает неоднозначность семантики.
И самое сложное — POST. Это вовсе не создание ресурса, как мы всегда думали. Это, вообще говоря, просто семантическая дыра: 'The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.'
То есть, как хотите, так и понимайте. Единственный смысл — мы хотим что-то сказать серверу, вот как. А дальше сервер уже будет решать, в соответствии с "собственной специфической семантикой ресурса". Это может быть:
— передача блока данных для обработки (не факт, что что-то тут создается!);
— создание нового ресурса, у которого ещё нет идентификатора и URI (обратите внимание, URI у ресурса появляется уже позже: мы обращаемся к одному адресу — к сервису, по сути, — чтобы создать ресурс по другому адресу);
— добавление данных к имеющемуся ресурсу (!!!)
Мы можем через POST создать один ресурс, несколько новых ресурсов, дополнить существующий ресурс, вообще ничего не создавать.
Кажется, самого Филдинга не очень заботило, строите ли вы своё API через CRUD, или нет. Его гораздо больше интересовало, чтобы ваше API было самоописательным и предлагало список действий, которые вы можете осуществить с его ресурсами.
И, конечно, в его диссертации вообще не упоминаются ни POST (там только GET и HEAD из методов упоминаются), ни CRUD.
В отдельном посте на эту темы он так и говорит: вся эта возня с методами просто не важна для обсуждения архитектурного стиля REST, главное — соблюдать единообразие и не делать получение данных через POST (а то кэширование и перезапросы работать не будут).
Так что POST — это операция со смыслом 'this action isn’t worth standardizing', "это действие не стоит стандартизации".
Как видно из поста Филдинга, в нулевые было распространено представление, что "настоящий" REST должен вообще обходиться без POST(!), видимо были сильны ассоциации с SOAP.
1👍27❤7
А вот в 2014 в связи с CQRS обсуждался "REST без PUT" — ничего менять вообще нельзя, можно только постить новые версии ресурсов. (Там же, кстати, интересное рассуждение про CRUD и грануляцию ресурсов — мол, это создает слишком болтливые API и переносит бизнес-логику на клиентов).
В общем, надеюсь, мне удалось вас запутать, и при случае вы можете запутать вашего интервьюера (не знаю только, на пользу ли это вам пойдет).
Upd.: пока выглядит так, что если вы досконально знаете стандарты и активно пытаетесь им следовать — вы идете против мейнстрима и хотите странного.
В общем, надеюсь, мне удалось вас запутать, и при случае вы можете запутать вашего интервьюера (не знаю только, на пользу ли это вам пойдет).
Upd.: пока выглядит так, что если вы досконально знаете стандарты и активно пытаетесь им следовать — вы идете против мейнстрима и хотите странного.
😁34💯3
Вчера выпрыгнула на меня реклама очередного курса по системному анализу от конторы из четырех букв, я аж опешил от такого откровенного вранья.
Что, друзья-аналитики, влияют ваши решения на прибыль компаний и стратегические решения?
Это на тренингах тоже часто встречается: говоришь, опирайтесь на цели бизнеса. Не является целью создания системы создание системы. Цель всегда вне и выше системы (проверка: никакой системы нет, а цель сохраняется, переформулировать её не нужно).
Ну и люди сразу начинают писать про повышение прибыли, долю на рынке и прочие страшные вещи. Камон, где ваши артефакты, а где прибыль. На прибыль и продакт-то с трудом влияет, далеко не напрямую.
Я вот всем рассказываю про четыре уровня карты Нортона-Каплана, которая Balanced Scorecards. Снизу-вверх:
👉 обучение/ развитие/инновации,
👉 внутренние процессы,
👉 удовлетворенность и поведение клиентов,
👉 финансы.
Вы или ваши системы на каком уровне работают? Я вот делал системы для обучения и инноваций, это нижний уровень, от них вообще до финансов далеко (хотя некоторые умудрялись считать ROI даже, а некоторые наоборот — принципиально ничего не считали в деньгах).
В основном мы наверное занимаемся внутренними процессами. Какой-нибудь документооборот — как он влияет на финансовый результат или, прости господи, стратегию — пойди посчитай.
Если (если!) у вас система показателей в организации простроена, тогда можно и проследить влияние на финансы. Только оно будет, скорее всего, через несколько шагов. А так — смотрите на то, что поближе. Скорость процесса улучшить, число ручных проверок снизить, повысить контроль там где его не было, убрать/ускорить ручной ввод. Если на уровне продукта — повысить LT (а лучше LTV), DAU/WAU/MAU, повторные покупки, виральность, число шагов в конверсиях — короче, всё про поведение и удовлетворенность. А уж там и до финансов как-нибудь доберемся.
Впрочем, не знаю, может я от жизни отстал, и системные аналитики действительно стали на прибыль и стратегию влиять?
Что, друзья-аналитики, влияют ваши решения на прибыль компаний и стратегические решения?
Это на тренингах тоже часто встречается: говоришь, опирайтесь на цели бизнеса. Не является целью создания системы создание системы. Цель всегда вне и выше системы (проверка: никакой системы нет, а цель сохраняется, переформулировать её не нужно).
Ну и люди сразу начинают писать про повышение прибыли, долю на рынке и прочие страшные вещи. Камон, где ваши артефакты, а где прибыль. На прибыль и продакт-то с трудом влияет, далеко не напрямую.
Я вот всем рассказываю про четыре уровня карты Нортона-Каплана, которая Balanced Scorecards. Снизу-вверх:
Вы или ваши системы на каком уровне работают? Я вот делал системы для обучения и инноваций, это нижний уровень, от них вообще до финансов далеко (хотя некоторые умудрялись считать ROI даже, а некоторые наоборот — принципиально ничего не считали в деньгах).
В основном мы наверное занимаемся внутренними процессами. Какой-нибудь документооборот — как он влияет на финансовый результат или, прости господи, стратегию — пойди посчитай.
Если (если!) у вас система показателей в организации простроена, тогда можно и проследить влияние на финансы. Только оно будет, скорее всего, через несколько шагов. А так — смотрите на то, что поближе. Скорость процесса улучшить, число ручных проверок снизить, повысить контроль там где его не было, убрать/ускорить ручной ввод. Если на уровне продукта — повысить LT (а лучше LTV), DAU/WAU/MAU, повторные покупки, виральность, число шагов в конверсиях — короче, всё про поведение и удовлетворенность. А уж там и до финансов как-нибудь доберемся.
Впрочем, не знаю, может я от жизни отстал, и системные аналитики действительно стали на прибыль и стратегию влиять?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25💯9❤7👌3👏1
Продолжая тему про стратегию: лично мне не удавалось никак влиять на стратегию ни из роли аналитика, ни из роли программиста, ни из роли техлида. Вся стратегия только с C-level начинается.
Или из интересной роли советника. Это самая высокая роль, в которой ещё можно оставаться специалистом и индивидуальным контрибьютором, а не руководителем. Я говорю про советника директора, ну или одного из директоров (я, например, был советником директора по технологиям. В смысле, не советник по технологиям, а директор). Мистическая это должность, загадочная для всех. Чем он занимается — только сам директор и знает. Отчитывается тоже только перед своим директором. Вроде бы ничем формально не управляет, но статус высокий. Хотя может и порулить каким-нибудь временным проектом. В общем — чиновник по особым поручениям.
Вот тут можно поупражняться в стратегировании — ты их, зачастую, сам и пишешь или фасилитируешь встречи по их разработке.
Как туда попадают — не скажу, меня по карьерной лестнице так тащило (причем иногда эту должность под меня делали — подкиньте мысль начальству/HR).
Про стратегию на WAW был отличный доклад Бориса Вольфсона: в принципе, стратегия это набор трёх решений:
— где играем?
— как выигрываем? (за счет чего)
— что не делаем?
и как всё это связано с конкретными проектами.
Поэтому системному и даже бизнес-аналитику до этих вопросов далеко. Вот быть проводником стратегии аналитик может. Особенно последних двух вопросов.
Или из интересной роли советника. Это самая высокая роль, в которой ещё можно оставаться специалистом и индивидуальным контрибьютором, а не руководителем. Я говорю про советника директора, ну или одного из директоров (я, например, был советником директора по технологиям. В смысле, не советник по технологиям, а директор). Мистическая это должность, загадочная для всех. Чем он занимается — только сам директор и знает. Отчитывается тоже только перед своим директором. Вроде бы ничем формально не управляет, но статус высокий. Хотя может и порулить каким-нибудь временным проектом. В общем — чиновник по особым поручениям.
Вот тут можно поупражняться в стратегировании — ты их, зачастую, сам и пишешь или фасилитируешь встречи по их разработке.
Как туда попадают — не скажу, меня по карьерной лестнице так тащило (причем иногда эту должность под меня делали — подкиньте мысль начальству/HR).
Про стратегию на WAW был отличный доклад Бориса Вольфсона: в принципе, стратегия это набор трёх решений:
— где играем?
— как выигрываем? (за счет чего)
— что не делаем?
и как всё это связано с конкретными проектами.
Поэтому системному и даже бизнес-аналитику до этих вопросов далеко. Вот быть проводником стратегии аналитик может. Особенно последних двух вопросов.
lafest.ru
Борис Вольфсон. Ландшафт стратегий в большой компании
Вас интересуют, как гармонизировать работу между различными подразделениями и достигать стратегических целей в огромной компании? Борис Вольфсон в своём выступлении на Зимних Аналитических выходных 2024 года делится своим опытом и прибывает к ключевым решениям…
👍13❤🔥1👏1
Что вы представляете себе, когда слышите про схему организационной структуры? Наверняка — древовидную иерархическую диаграмму с прямоугольничками — отделами и должностями.
Но ещё лет 100 назад всё было не так очевидно.
Вот, например, организационная схема ТЕО — Театрального отдела Наркомпроса, составленная В.Э.Мейерхольдом, возглавлявшим этот отдел в 1920-1921 годах (с сентября по февраль, если быть точным).
В интернете её нет, я сфотографировал её в доме-музее Мейерхольда в Пензе, она там в уголочке скромно висит.
Ну красота же? Это вам не бездушные орг.чарты, это больше похоже на супрематизм Малевича (с которым Мейерхольд сотрудничал).
Подписи разобрать сложно, но справа вверху явно читается "ТЕО 1920-1921", "Отделов и секций". Дальше я немного теряюсь, может быть вы сможете лучше распознать. В центре зеленый треугольник — "Кино"? Под ним — "Те. Прос." и "Те. Обр.", то есть — театральное просвещение и образование? Справа в синем треугольнике — "Всеобуч"? (то есть, тут показаны ещё и смежные программы). Слева красный треугольник — ЦУТ, видимо "Центральное управление театрами"?
Среди мелкого текста можно разобрать "городской", "цирк", "школа", "массовых действий", "нац. меньшинств". ИИ где-то там видит ещё "режиссёрские курсы", "ТЕАТР", "Гостеатр", "Театр драмы", "Кукольный театр", "Мюзик-холл", "учреждения", "гос. труппы", "самодеятельность", "областные театры".
То есть это не только оргструктура, это ещё направления и области, которые контролирует и развивает ТЕО. Мейерхольд собирался радикально перестроить все театры (потому и был руководителем так недолго), и ему нужно было определить стратегию, так что это ещё и стратегический документ.
Как вам нравится такая визуализация? Использовали бы в своих проектах?
Но ещё лет 100 назад всё было не так очевидно.
Вот, например, организационная схема ТЕО — Театрального отдела Наркомпроса, составленная В.Э.Мейерхольдом, возглавлявшим этот отдел в 1920-1921 годах (с сентября по февраль, если быть точным).
В интернете её нет, я сфотографировал её в доме-музее Мейерхольда в Пензе, она там в уголочке скромно висит.
Ну красота же? Это вам не бездушные орг.чарты, это больше похоже на супрематизм Малевича (с которым Мейерхольд сотрудничал).
Подписи разобрать сложно, но справа вверху явно читается "ТЕО 1920-1921", "Отделов и секций". Дальше я немного теряюсь, может быть вы сможете лучше распознать. В центре зеленый треугольник — "Кино"? Под ним — "Те. Прос." и "Те. Обр.", то есть — театральное просвещение и образование? Справа в синем треугольнике — "Всеобуч"? (то есть, тут показаны ещё и смежные программы). Слева красный треугольник — ЦУТ, видимо "Центральное управление театрами"?
Среди мелкого текста можно разобрать "городской", "цирк", "школа", "массовых действий", "нац. меньшинств". ИИ где-то там видит ещё "режиссёрские курсы", "ТЕАТР", "Гостеатр", "Театр драмы", "Кукольный театр", "Мюзик-холл", "учреждения", "гос. труппы", "самодеятельность", "областные театры".
То есть это не только оргструктура, это ещё направления и области, которые контролирует и развивает ТЕО. Мейерхольд собирался радикально перестроить все театры (потому и был руководителем так недолго), и ему нужно было определить стратегию, так что это ещё и стратегический документ.
Как вам нравится такая визуализация? Использовали бы в своих проектах?
1🔥21🗿6⚡5❤3
McKinsey опубликовал карту принятия решений агентными ИИ. Точнее — какие решения можно им отдать и какую роль играет человек.
Получилась матрица, для разнообразия не 2x2, как обычно у консалтеров, а аж 3x3 — мир становится сложнее.
Ну хоть координат пока две:
— Риск от последствий неверного решения
— Сложность решения
Соответственно, риски могут быть трёх уровней:
— низкие (либо низка вероятность, либо почти нет урона)
— средние (потеряем много денег или репутацию)
— необратимые (может произойти что-то фатальное: гибель или ранения людей, разорение компаний, отзыв лицензий/запрет деятельности, падение рынков)
Сложность тоже делится на три уровня:
— низкая (простые повторяющиеся действия)
— средняя (есть некий паттерн, но в общем действия не совсем точно повторяются)
— высокая (ситуация сильно неоднозначная)
И дальше смотрим на пересечениях — какую роль играет ИИ, какую человек.
В правом верхнем — только решение человека. В левом нижнем — ИИ может действовать самостоятельно, без присмотра.
Дальше начинаются всякие интересные сочетания:
ИИ как исполнитель (принимает решения сам, человек мониторит)
ИИ как оператор (выполняет процесс, человек вовлекается в сложных случаях)
ИИ как ассистент (поддерживает, не принимает решения)
ИИ как коллаборатор (дает советы, человек валидирует)
В общем, тут нет сильно нового, я всё это видел лет 20 назад на фондовом рынке. ИИ тогда не очень был развит, но были алгоритмы и, прости господи, экспертные системы / системы поддержки принятия решений.
У нас были безрисковые роботы, про которых точно было известно, что они могут принести прибыль, но не могут сыграть в убыток (в основном за счет времени — если успеют, получат прибыль, если нет — ничего не получат, вот и всё. Риска нет.) Они просто запускались утром и отключались вечером, за ними особо и не следил никто, разве что для улучшения алгоритмов и скорости.
Были роботы с риском — они работали под пристальным наблюдением.
Были операции в миддле и бэке, проходящие автоматически — контроль рисков, формирование обязательств, проводок — человек за ними только следил, но в некоторых случаях брал управление на себя (или сама система передавала управления — что-то здесь я не понимаю, нужно вмешательство человека).
Была система, анализирующая и показывающая разные параметры сводного портфеля бумаг или валютной позиции — вот так, и вот так, и ещё в таком разрезе, эти данные подсветим, здесь подчеркнем, нужно обратить внимание, но финальное решение всегда за человеком. Или, например, калькулятор опционной стратегии — система посчитает, но решает трейдер всё равно.
Ну и были решения, которые вообще без всяких систем принимались, исключительно людьми.
А теперь всё то же не на рынке есть, а, например, в программировании или управлении продуктом. Ну и в анализе тоже будет.
Что уже сейчас можно отдать агентам?
Или иначе: где обычно находятся решения аналитика? Мне кажется (давайте поспорим!), что аналитик обычно работает в зоне низкого-среднего риска и средней-высокой сложности. С очень редкими попаданиями в зону высокого риска — туда аналитика не всегда пускают; точнее, там он выполняет как раз роль ИИ: makes recommendations, support humans. Это, кстати, и есть направление роста — хотите расти, идите туда, где ваши решения имеют больший риск.
Кстати, ИИ пока (пока!) не может удерживать под контролем долгосрочные дела — например, вести бухгалтерский баланс в течение года. Стратегические решения, от которых зависят будущие ситуации, пока плохо им всем даются. GPT o3, o4-mini и Gemini 2.5 Pro даже первый месяц не смогли корректно закрыть, Grok после 5-го месяца стал расходиться больше чем на 5%, а Claude Sonnet — после 8-го.
Получилась матрица, для разнообразия не 2x2, как обычно у консалтеров, а аж 3x3 — мир становится сложнее.
Ну хоть координат пока две:
— Риск от последствий неверного решения
— Сложность решения
Соответственно, риски могут быть трёх уровней:
— низкие (либо низка вероятность, либо почти нет урона)
— средние (потеряем много денег или репутацию)
— необратимые (может произойти что-то фатальное: гибель или ранения людей, разорение компаний, отзыв лицензий/запрет деятельности, падение рынков)
Сложность тоже делится на три уровня:
— низкая (простые повторяющиеся действия)
— средняя (есть некий паттерн, но в общем действия не совсем точно повторяются)
— высокая (ситуация сильно неоднозначная)
И дальше смотрим на пересечениях — какую роль играет ИИ, какую человек.
В правом верхнем — только решение человека. В левом нижнем — ИИ может действовать самостоятельно, без присмотра.
Дальше начинаются всякие интересные сочетания:
ИИ как исполнитель (принимает решения сам, человек мониторит)
ИИ как оператор (выполняет процесс, человек вовлекается в сложных случаях)
ИИ как ассистент (поддерживает, не принимает решения)
ИИ как коллаборатор (дает советы, человек валидирует)
В общем, тут нет сильно нового, я всё это видел лет 20 назад на фондовом рынке. ИИ тогда не очень был развит, но были алгоритмы и, прости господи, экспертные системы / системы поддержки принятия решений.
У нас были безрисковые роботы, про которых точно было известно, что они могут принести прибыль, но не могут сыграть в убыток (в основном за счет времени — если успеют, получат прибыль, если нет — ничего не получат, вот и всё. Риска нет.) Они просто запускались утром и отключались вечером, за ними особо и не следил никто, разве что для улучшения алгоритмов и скорости.
Были роботы с риском — они работали под пристальным наблюдением.
Были операции в миддле и бэке, проходящие автоматически — контроль рисков, формирование обязательств, проводок — человек за ними только следил, но в некоторых случаях брал управление на себя (или сама система передавала управления — что-то здесь я не понимаю, нужно вмешательство человека).
Была система, анализирующая и показывающая разные параметры сводного портфеля бумаг или валютной позиции — вот так, и вот так, и ещё в таком разрезе, эти данные подсветим, здесь подчеркнем, нужно обратить внимание, но финальное решение всегда за человеком. Или, например, калькулятор опционной стратегии — система посчитает, но решает трейдер всё равно.
Ну и были решения, которые вообще без всяких систем принимались, исключительно людьми.
А теперь всё то же не на рынке есть, а, например, в программировании или управлении продуктом. Ну и в анализе тоже будет.
Что уже сейчас можно отдать агентам?
Или иначе: где обычно находятся решения аналитика? Мне кажется (давайте поспорим!), что аналитик обычно работает в зоне низкого-среднего риска и средней-высокой сложности. С очень редкими попаданиями в зону высокого риска — туда аналитика не всегда пускают; точнее, там он выполняет как раз роль ИИ: makes recommendations, support humans. Это, кстати, и есть направление роста — хотите расти, идите туда, где ваши решения имеют больший риск.
Кстати, ИИ пока (пока!) не может удерживать под контролем долгосрочные дела — например, вести бухгалтерский баланс в течение года. Стратегические решения, от которых зависят будущие ситуации, пока плохо им всем даются. GPT o3, o4-mini и Gemini 2.5 Pro даже первый месяц не смогли корректно закрыть, Grok после 5-го месяца стал расходиться больше чем на 5%, а Claude Sonnet — после 8-го.
👍21❤5🔥2🤔2
Рассказывая про атрибуты качества, я раньше приводил в пример страницу из Википедии, их тут перечисленно 92 штуки.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
🔥45😁11❤4👍3👻2
Вот интересно, в одной дискуссии мнения разделились — правда ли, что все побежали срочно везде внедрять ИИ? Есть KPI, цели, метрики. Или как-то так, самотеком? Поэтому сейчас будет мини-опрос, как у вас (и где вы — в РФ или нет).
Как у вас в компании внедряется ИИ — активно и целенаправлено, или самотеком?
Anonymous Poll
47%
Активно внедряется (РФ)
6%
Активно внедряется (не РФ)
34%
Пущено на самотек (РФ)
5%
Пущено на самотек (не РФ)
7%
У нас ИИ вообще запрещен
❤2
Люблю, когда люди пишут и развивают свои каналы. Но иногда немного дополнительной мотивации не помешает. Systems.education объявляет конкурс на посты про системный и бизнес-анализ, проектирование систем. Я там буду в жюри. Пишите, почитаем!
❤3🔥2👍1
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
🏆 Конкурс авторских публикаций «Продолжи мысль» от Systems.Education
За последние годы сообщество авторов экспертных постов в Telegram серьёзно выросло. Мы предлагаем возможность ведущим профессиональных каналов заявить о себе. На конкурсе мы будем оценивать ваше умение не только писать чётко, понятно и по делу, но и рецензировать публикации коллег.
▫️ Участниками конкурса могут стать авторы, ведущие Telegram-каналы на темы, связанные с системным, бизнес-анализом, проектированием ИТ-систем и смежными дисциплинами.
Формат конкурса — Дистанционный. Участники будут размещать свои авторские публикации в собственных Telegram-каналах.
▫️ Зачем это вам:
— Заявите на большую аудиторию о своих знаниях, опыте и наработках
— Получите бесплатную нативную рекламу ваших блогов, если пройдёте в первый и второй туры
— Победители конкурса получат профессиональное развитие за счёт SE на свой выбор: оплата подписок на профессиональные ресурсы, продюсирование и методическая поддержка авторов, менторство и карьерные консультации от экспертов
▫️ Зачем это нам:
Мы стремимся развивать профессиональное сообщество системных и бизнес-аналитиков. Поэтому мы готовы поддерживать авторов качественного контента и распространять знания в области анализа и проектирования ИТ-систем.
⬆️ На карточках мы подробно рассказали о процессе подачи заявки, номинациях и этапах конкурса.
На лендинге вы найдете ссылку на регламент с методикой оценивания конкурсных работ и список жюри.
Подавайте заявку — и пусть мысль не просто продолжится, а станет вирусной
Контакт координатора для ответов на вопросы и подачи заявки на конкурс — @kosvetlanov
#продолжи_мысль_SE
За последние годы сообщество авторов экспертных постов в Telegram серьёзно выросло. Мы предлагаем возможность ведущим профессиональных каналов заявить о себе. На конкурсе мы будем оценивать ваше умение не только писать чётко, понятно и по делу, но и рецензировать публикации коллег.
▫️ Участниками конкурса могут стать авторы, ведущие Telegram-каналы на темы, связанные с системным, бизнес-анализом, проектированием ИТ-систем и смежными дисциплинами.
Формат конкурса — Дистанционный. Участники будут размещать свои авторские публикации в собственных Telegram-каналах.
▫️ Зачем это вам:
— Заявите на большую аудиторию о своих знаниях, опыте и наработках
— Получите бесплатную нативную рекламу ваших блогов, если пройдёте в первый и второй туры
— Победители конкурса получат профессиональное развитие за счёт SE на свой выбор: оплата подписок на профессиональные ресурсы, продюсирование и методическая поддержка авторов, менторство и карьерные консультации от экспертов
▫️ Зачем это нам:
Мы стремимся развивать профессиональное сообщество системных и бизнес-аналитиков. Поэтому мы готовы поддерживать авторов качественного контента и распространять знания в области анализа и проектирования ИТ-систем.
⬆️ На карточках мы подробно рассказали о процессе подачи заявки, номинациях и этапах конкурса.
На лендинге вы найдете ссылку на регламент с методикой оценивания конкурсных работ и список жюри.
Подавайте заявку — и пусть мысль не просто продолжится, а станет вирусной
⏰Прием заявок до 11.08 включительно
Контакт координатора для ответов на вопросы и подачи заявки на конкурс — @kosvetlanov
#продолжи_мысль_SE
👍8❤2🔥1
Пост на злобу дня: Аэрофлот упал, но быстро поднялся. В других отраслях тоже проблемы — то ли из-за атак, то ли по другим причинам.
Это всё, с одной стороны, про безопасность, а с другой — про непрерывность бизнеса. Обычно это считают подразделом безопасности — требования иметь планы BCP и DRP описаны в стандарте ISO 27001, в основном в виде сохранения защиты данных при авариях/чрезвычайных происшествий.
BCP — Business Continuity Plan: как мы собираемся работать, несмотря ни на что (атаки, аварии, стихийные бедствия, другие форс-мажоры).
DRP — Disaster Recovery Plan: как мы собираемся восстанавливаться после аварии.
Это очень клёвые документы, особенно если они разработаны по-честному, а не для галочки/чтобы пройти аудит. Это как аптечка в походе — обычно не нужна, но если нужна, то очень.
Близки к этому понятия RTO — Recovery Time Objective, целевое время восстановления, и RPO — Recovery Point Objective, целевая точка восстановления (а к какому, собственно, состоянию мы восстанавливаемся, что мы готовы потерять? далеко не факт, что ответ "ничего не готовы").
Я вам честно скажу — не знаю, как это в крупных компаниях организовано. Вроде интернет говорит, что есть какие-то отдельные BCM — Business Continuity Managers, менеджеры по непрерывности бизнеса. Не знаю, не видел.
В проектах, где я в разработке таких планов участвовал, всегда была рабочая группа из представителей бизнеса (операционного подразделения, клиентского, рисков), безопасности, ИТ и с обязательными участием бизнес- и системных аналитиков. Потому что бизнес выдает требования и оценивает последствия рисков, ИТ предлагает решения, а прокапыванием и проектированием деталей занимается аналитик. Ну а кто кроме БА знает, что в процессе может пойти не так и как его можно выполнить альтернативно?
Какие процессы наиболее критичны? Какая последовательность восстановления? Какие системы наиболее критичны для работы?
Есть документ, который даже в названии содержит слово "анализ": BIA — Business Impact Analysis.
Это вообще кайфовый документ для людей, склонных к упорядочиванию всего: вот у нас есть такой риск, что случится, если он реализуется? Что кто будет делать? Что кто не сможет сделать? Какие процессы остановятся/замедлятся? К чему это приведет? Что мы потеряем в деньгах и репутации, чем навредим людям, партнерам и обществу?
Упражнение в чем-то напоминает то, что дает Сергей Нужненко: Какие входы у вас есть? Какие выходы? Какие ресурсы? Как это всё управляется? Что будет, если потоки на них прервутся/замедлятся? Люди не смогут войти в здание, оборвется электричество, заболеют ключевые сотрудники, будут уничтожены данные / виртуальные сервера, прекратится доступ к Интернету или отдельным сервисам?
В конце концов, у армии США есть даже план по отражению угрозы нашествия зомби (CONPLAN 8888), а чем мы хуже?
В отличие от анализа рисков BIA (а также BCP и DRP) подразумевает ещё и необходимые ресурсы. Например, в одной организации мне гордо показывали серверную с собственным охлаждением, резервным питанием и выводом для подключения внешнего генератора. На мой вопрос, а заключен ли договор с поставщиками таких генераторов, ну или хотя бы есть ли их список под рукой, люди только удивленно хлопали глазами. Конечно, когда через год возник локальный пожар в щитке и серверная осталась без электричества, никакой внешний генератор быстро не приехал.
А в другой компании наоборот — не говоря о резервировании ИТ, был даже заключен договор на целый резервный офис с подготовленным оборудованием и периодически проводились учения по его развертыванию.
Это всё, с одной стороны, про безопасность, а с другой — про непрерывность бизнеса. Обычно это считают подразделом безопасности — требования иметь планы BCP и DRP описаны в стандарте ISO 27001, в основном в виде сохранения защиты данных при авариях/чрезвычайных происшествий.
BCP — Business Continuity Plan: как мы собираемся работать, несмотря ни на что (атаки, аварии, стихийные бедствия, другие форс-мажоры).
DRP — Disaster Recovery Plan: как мы собираемся восстанавливаться после аварии.
Это очень клёвые документы, особенно если они разработаны по-честному, а не для галочки/чтобы пройти аудит. Это как аптечка в походе — обычно не нужна, но если нужна, то очень.
Близки к этому понятия RTO — Recovery Time Objective, целевое время восстановления, и RPO — Recovery Point Objective, целевая точка восстановления (а к какому, собственно, состоянию мы восстанавливаемся, что мы готовы потерять? далеко не факт, что ответ "ничего не готовы").
Я вам честно скажу — не знаю, как это в крупных компаниях организовано. Вроде интернет говорит, что есть какие-то отдельные BCM — Business Continuity Managers, менеджеры по непрерывности бизнеса. Не знаю, не видел.
В проектах, где я в разработке таких планов участвовал, всегда была рабочая группа из представителей бизнеса (операционного подразделения, клиентского, рисков), безопасности, ИТ и с обязательными участием бизнес- и системных аналитиков. Потому что бизнес выдает требования и оценивает последствия рисков, ИТ предлагает решения, а прокапыванием и проектированием деталей занимается аналитик. Ну а кто кроме БА знает, что в процессе может пойти не так и как его можно выполнить альтернативно?
Какие процессы наиболее критичны? Какая последовательность восстановления? Какие системы наиболее критичны для работы?
Есть документ, который даже в названии содержит слово "анализ": BIA — Business Impact Analysis.
Это вообще кайфовый документ для людей, склонных к упорядочиванию всего: вот у нас есть такой риск, что случится, если он реализуется? Что кто будет делать? Что кто не сможет сделать? Какие процессы остановятся/замедлятся? К чему это приведет? Что мы потеряем в деньгах и репутации, чем навредим людям, партнерам и обществу?
Упражнение в чем-то напоминает то, что дает Сергей Нужненко: Какие входы у вас есть? Какие выходы? Какие ресурсы? Как это всё управляется? Что будет, если потоки на них прервутся/замедлятся? Люди не смогут войти в здание, оборвется электричество, заболеют ключевые сотрудники, будут уничтожены данные / виртуальные сервера, прекратится доступ к Интернету или отдельным сервисам?
В конце концов, у армии США есть даже план по отражению угрозы нашествия зомби (CONPLAN 8888), а чем мы хуже?
В отличие от анализа рисков BIA (а также BCP и DRP) подразумевает ещё и необходимые ресурсы. Например, в одной организации мне гордо показывали серверную с собственным охлаждением, резервным питанием и выводом для подключения внешнего генератора. На мой вопрос, а заключен ли договор с поставщиками таких генераторов, ну или хотя бы есть ли их список под рукой, люди только удивленно хлопали глазами. Конечно, когда через год возник локальный пожар в щитке и серверная осталась без электричества, никакой внешний генератор быстро не приехал.
А в другой компании наоборот — не говоря о резервировании ИТ, был даже заключен договор на целый резервный офис с подготовленным оборудованием и периодически проводились учения по его развертыванию.
❤13👍5🔥2
К чему я, собственно, это пишу. Слышу во многих обсуждениях сомнения в функциях системного/бизнес-аналитика. Мол, то ли всех заменит ИИ, то ли всех уволят из-за перехода на agile, то ли ещё что. Да и куда расти непонятно: то ли в архитекторы, то ли в продакты (рост ли это?), то ли в стратегию/CIO, то ли ещё куда. Вот один из вариантов — если вы любите операционку и кайфуете от налаживания процессов. Вариант, кстати, вполне реальный: у меня как-то раз именно в операционное подразделение сманили лучшего бизнес-аналитика — там задачи интереснее и рост понятнее.
❤14
Мы вместе с NextWay и Flow проводим независимое исследование рынка системных и бизнес-аналитиков. В виде опроса:
Как мы уже с вами выяснили, здесь собралась не совсем обычная аудитория — например, по уровню внедрения ИИ в своих организациях вы явно более продвинуты, чем другие аналитики. Поэтому ваши свидетельства очень важны.
Опрос займет у вас примерно 15 минут, а в результате мы будем с большой достоверностью знать — чем дышат аналитики, какие технологии и знания востребованы, что вообще происходит еа рынке.
Результаты везде опубликуем.
Ссылка на опрос
Как мы уже с вами выяснили, здесь собралась не совсем обычная аудитория — например, по уровню внедрения ИИ в своих организациях вы явно более продвинуты, чем другие аналитики. Поэтому ваши свидетельства очень важны.
Опрос займет у вас примерно 15 минут, а в результате мы будем с большой достоверностью знать — чем дышат аналитики, какие технологии и знания востребованы, что вообще происходит еа рынке.
Результаты везде опубликуем.
Ссылка на опрос
👍8
Участники тренинга рассказали про вопрос на собеседовании: как браузер узнает, в какую именно вкладку пришел ответ от сервера, если в двух вкладках открыта одна и та же страница. Гугловский ИИ, кстати, выдает отменную чушь — мол, если открыта одна и та же страница в двух вкладках, то они обновятся обе.
Вопрос достаточно простой (на каждое новое соединение открывается собственный сокет, то есть отличаться они будут локальным портом), так что даже начинаешь подозревать какой-то подвох. Ну, можно ещё рассказать про различие между HTTP/1.1 и HTTP/2 (в последнем будет удерживаться одно TCP-соединение, а запросы и ответы для разных вкладках будут передаваться в разных потоках).
Но, конечно, фантазия интервьюеров меня огорчает. Не могли что-нибудь интересное спросить. Если уж спрашивать какую-то абстрактную чушь, то пусть это будут действительно странные вопросы, а не чем отличается REST от SOAP и что происходит, когда вы набираете адрес в браузере (это в деталях описано вот тут , начиная с описания генерации скан-кода нажатой клавиши и опроса клавиатуры контроллером USB).
Я вот подумал и накидал десяток вопросов. Пользуйтесь, если вы любите такое. Заодно можем обсудить правильные ответы.
Итак, странные вопросы для собеседования:
1. В какой интеграции нет очередей: RabbitMQ, gRPC, Kafka?
2. Как устроена пагинация в GraphQL?
3. Есть ли в MCP HATEOAS?
4. Какой самый простой способ организации Service Discovery?
5. Что лучше с точки зрения безопасности — JSON или XML?
6. В каких версиях HTTP можно передавать потоки данных с сервера на клиент по инициативе сервера?
7. Что передается в методе PATCH по стандарту?
8. Каким методом HTTP нужно создавать ресурс на сервере?
9. Чем ограничивается число входящих сетевых подключений на сервере?
10. Какими функциями должна обладать система, чтобы её можно было считать полноценной шиной?
Вопрос достаточно простой (на каждое новое соединение открывается собственный сокет, то есть отличаться они будут локальным портом), так что даже начинаешь подозревать какой-то подвох. Ну, можно ещё рассказать про различие между HTTP/1.1 и HTTP/2 (в последнем будет удерживаться одно TCP-соединение, а запросы и ответы для разных вкладках будут передаваться в разных потоках).
Но, конечно, фантазия интервьюеров меня огорчает. Не могли что-нибудь интересное спросить. Если уж спрашивать какую-то абстрактную чушь, то пусть это будут действительно странные вопросы, а не чем отличается REST от SOAP и что происходит, когда вы набираете адрес в браузере (это в деталях описано вот тут , начиная с описания генерации скан-кода нажатой клавиши и опроса клавиатуры контроллером USB).
Я вот подумал и накидал десяток вопросов. Пользуйтесь, если вы любите такое. Заодно можем обсудить правильные ответы.
Итак, странные вопросы для собеседования:
1. В какой интеграции нет очередей: RabbitMQ, gRPC, Kafka?
2. Как устроена пагинация в GraphQL?
3. Есть ли в MCP HATEOAS?
4. Какой самый простой способ организации Service Discovery?
5. Что лучше с точки зрения безопасности — JSON или XML?
6. В каких версиях HTTP можно передавать потоки данных с сервера на клиент по инициативе сервера?
7. Что передается в методе PATCH по стандарту?
8. Каким методом HTTP нужно создавать ресурс на сервере?
9. Чем ограничивается число входящих сетевых подключений на сервере?
10. Какими функциями должна обладать система, чтобы её можно было считать полноценной шиной?
👍16😱10👎4💩3
Ооо, какая штука! Каталог паттернов работы с легаси-системами: https://legacy-modernization.io/
Вытащил из сообщества архитекторов Russian Association of Software Architects
Удушение, миграция, параллельная работа. В связи и импортозамещением (не всё ещё заместили?..) очень актуально.
Как обычно, многие паттерны — это просто здравый смысл, но хорошо, что они названы и собраны в одном месте.
Каталог разбит на 4 части:
— миграция с легаси-системами
— синхронизация данных
— организационные паттерны
+ не паттерны, а перечень типовых проблем и мотивов перехода со старых систем.
Паттерны интеграции:
— "душитель" (по-английски он фикус-душитель, Strangler Fig): откусываем от легаси-системы по одному юскейсу — ставим на входящем потоке роутер, который перенаправляет некоторые частные случаи в новую систему. Сначала единичные, потом всё больше и больше, потом все.
— "пузырь": развитие идеи anti-corruption level — внешние системы и пользователи работают с новой моделью (и функций, и операций), а он преобразует и сохраняет данные в легаси-системах. Постепенно он всё меньше и меньше зависит от легаси-систем, а потом они совсем отключаются — пузырь "лопнул". "Автономный пузырь" — изначально со своим хранилищем данных. "Обратный пузырь" — когда ставим его после легаси-системы, и отправляем в него запросы для обработки, то есть легаси как интерфейс, а в пузыре новая бизнес-логика с новой доменной моделью.
— можно прикрутить к легаси новое API или UI, или отлавливать и публиковать события из неё.
— дальше разные стратегии миграции: пишем в легаси, читаем из новой системы/читаем из легаси, пишем в новую систему. Или делим по сегментам пользователей (по странам, клиентам, юскейсам).
— параллельная эксплуатация. Любимое развлечение, однажды полгода этим занимались.
Паттерны синхронизации данных:
— CDC, чтобы гонять только изменения
— Sync and Backfill — когда у нас два отдельных процесса на синхронизацию новых данных (в реальном времени) и подгрузке исторических (асинхронно)
— Двойная запись (пишем одновременно в старую и новую систему)
— Общая БД
Обратите внимание: миграция требует практически тех же подходов, что и интеграция!
Организационные паттерны:
— AMET (Architecture Modernization Enabling Team) — вот это крутая идея! Временная команда, выделенная на фасилитацию перехода: помогает спроектировать новую архитектуру, не давать угасать импульсу, добавлять экспертизу там, где она нужна. Вот тут подробная статья про AMET https://livebook.manning.com/book/architecture-modernization/chapter-15, из книги Jean-Georges Perrin и Nick Tune 'Architecture Modernization: Socio-technical Alignment of Software, Strategy, and Structure' (на русском вроде её нет)
Добавлю от себя, что хорошо ещё иметь техническую команду для различных подпорок и строительных лесов: скриптов миграции, роутеров, синхронизаторов, контролеров расхождений с всякого такого добра. Его нужно писать много, и не всё из этого одноразовое — вам точно придётся запускать эти скрипты несколько раз, и обязательно предусмотрите детальный лог!
— Inner-Sourced Client Migration: команда со стороны сервиса берется за переписывание кода в клиентских системах (эффективно, но только для тех клиентов, кто готов пустить в свою кодовую базу). Да мы уже сами вам всё перепишем, только перейдите уже на новую версию!
— Dual Track — когда вы разделяете команду на две: одна занимается текущими доработками, другая миграцией.
Говорю же: нужно просто дать название какому-то приему, и уже паттерн. Всё, можно тренинги продавать.
Вытащил из сообщества архитекторов Russian Association of Software Architects
Удушение, миграция, параллельная работа. В связи и импортозамещением (не всё ещё заместили?..) очень актуально.
Как обычно, многие паттерны — это просто здравый смысл, но хорошо, что они названы и собраны в одном месте.
Каталог разбит на 4 части:
— миграция с легаси-системами
— синхронизация данных
— организационные паттерны
+ не паттерны, а перечень типовых проблем и мотивов перехода со старых систем.
Паттерны интеграции:
— "душитель" (по-английски он фикус-душитель, Strangler Fig): откусываем от легаси-системы по одному юскейсу — ставим на входящем потоке роутер, который перенаправляет некоторые частные случаи в новую систему. Сначала единичные, потом всё больше и больше, потом все.
— "пузырь": развитие идеи anti-corruption level — внешние системы и пользователи работают с новой моделью (и функций, и операций), а он преобразует и сохраняет данные в легаси-системах. Постепенно он всё меньше и меньше зависит от легаси-систем, а потом они совсем отключаются — пузырь "лопнул". "Автономный пузырь" — изначально со своим хранилищем данных. "Обратный пузырь" — когда ставим его после легаси-системы, и отправляем в него запросы для обработки, то есть легаси как интерфейс, а в пузыре новая бизнес-логика с новой доменной моделью.
— можно прикрутить к легаси новое API или UI, или отлавливать и публиковать события из неё.
— дальше разные стратегии миграции: пишем в легаси, читаем из новой системы/читаем из легаси, пишем в новую систему. Или делим по сегментам пользователей (по странам, клиентам, юскейсам).
— параллельная эксплуатация. Любимое развлечение, однажды полгода этим занимались.
Паттерны синхронизации данных:
— CDC, чтобы гонять только изменения
— Sync and Backfill — когда у нас два отдельных процесса на синхронизацию новых данных (в реальном времени) и подгрузке исторических (асинхронно)
— Двойная запись (пишем одновременно в старую и новую систему)
— Общая БД
Обратите внимание: миграция требует практически тех же подходов, что и интеграция!
Организационные паттерны:
— AMET (Architecture Modernization Enabling Team) — вот это крутая идея! Временная команда, выделенная на фасилитацию перехода: помогает спроектировать новую архитектуру, не давать угасать импульсу, добавлять экспертизу там, где она нужна. Вот тут подробная статья про AMET https://livebook.manning.com/book/architecture-modernization/chapter-15, из книги Jean-Georges Perrin и Nick Tune 'Architecture Modernization: Socio-technical Alignment of Software, Strategy, and Structure' (на русском вроде её нет)
Добавлю от себя, что хорошо ещё иметь техническую команду для различных подпорок и строительных лесов: скриптов миграции, роутеров, синхронизаторов, контролеров расхождений с всякого такого добра. Его нужно писать много, и не всё из этого одноразовое — вам точно придётся запускать эти скрипты несколько раз, и обязательно предусмотрите детальный лог!
— Inner-Sourced Client Migration: команда со стороны сервиса берется за переписывание кода в клиентских системах (эффективно, но только для тех клиентов, кто готов пустить в свою кодовую базу). Да мы уже сами вам всё перепишем, только перейдите уже на новую версию!
— Dual Track — когда вы разделяете команду на две: одна занимается текущими доработками, другая миграцией.
Говорю же: нужно просто дать название какому-то приему, и уже паттерн. Всё, можно тренинги продавать.
Legacy-Modernization.io
Welcome to legacy-modernization.io - resources to help you modernize effectively
🔥26❤11👍4