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

Дальше обычно выясняется, что всякое новое и экспериментальное люди не очень любят. Особенно когда речь идёт про свои деньги. И свои риски.

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

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

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

Но пока его там нет. А есть 20-30 «если», написанных на бумажке в столбик. Ну да, шанс ненулевой, говоря математически.

Но денег там нет. И спроса нет. И потребности нет. И клиента нет.
Есть влажные фантазии.

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

Создание спроса там, где его нет и не было — это пиздецки дорогое развлечение.

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

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

Основных вопроса как минимум два.
И я рекомендую себе их периодически задавать

• как живые люди описанную проблему/задачу решают прямо сейчас?
• где именно сейчас, в связи с этой проблемой, живёт платежеспособный спрос?

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

Пока нахаляву — ну сходите, рискните, дело ваше.

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

Вот только у вас их нет. А там, где они есть — стопудово и без вас тесно.

Проверочный маркер: если надо кому-то убедительно доказывать, какие вы крутые, нужные и инновационные — что-то идёт не так. Решение конкретной очевидной проблемы, и закрытие реальной потребности на вменяемых условиях, если никто никому в процессе не пиздит — это обычно shut up and take my money. Еще и в очередь выстроятся. Крутое решение — ну, продемонстрируй.

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

Говоря о рецептах: тесты, тесты, тесты.

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

Интереснее играться и вливать бюджеты в никому (по факту) не пригодившиеся фантазии. Первые 40 лет детства самые сложные.

Hope that helps.

Все еще не рекомендую брать скрам и прикручивать к себе «на изоленту», потому что SCRUM это цельная методология — в смысле неделимая, хотя и достаточно несложная. Добавлять — можно. Выкидывать части — нельзя, они несущие, их там и так немного.

Думаю, с этим моментом разберётесь, я уже несколько раз подробно об этом писал.

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

Цель продукта

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

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

Цели у каждого этапа

Они были, их просто нормально прописали. Теперь у продуктового беклога общая цель — это product goal, у беклога спринта — это sprint goal, у инкрементов/кусков работы это Definition of Done.

Все три — это именно артефакты. Они должны быть описаны, их можно посмотреть, почитать и потрогать. Соответственно, ожидание практического выхода, и обязательства в этой связи — то есть, коммитменты — также существуют именно в такой привязке (к PG, SG и DoD). Нельзя и неполезно коммититься на какие-то абстракции и фантазии: замучаетесь мерить.

Планирование спринта

Кроме вопросов «что делаем?» и «как делаем?» добавился третий вопрос «нахера делаем?», в смысле Why. Не в метафизическом смысле, а чего конкретно нам это дает из Product Goal и почему хотим сейчас именно это.

Why хорошая штука, которая позволяет нормально прописывать ADR (architecture decision records): что сделано, почему, как выбирали, и почему выбрали именно это.

Овнер и менеджер тоже часть команды разработки

Раньше было логическое отделение: вот типа люди от планирования, руководство, овнер и менеджер/мастер — а вон у нас рукопахари. Теперь нет, они все у нас Dev Team, иногда даже со смежными ролями. Все в одной лодке, ответственности у них общие.

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

Это раскрывает вопрос «совмещения ролей». Хотите — совмещайте. Лишь бы делалось в полном обьеме.

Овнер и с/мастер и все остальные т.к часть scrum team, «предельный» размер увеличен ST до 10 человек. Но это вообще пофиг, это ограничение всегда было рекомендательным и само-очевидным, много людей = больше бардак.

Сокращение обязательных частей

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

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

Само-управление вместо само-организации

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

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

Убрали привязки к циклу разработки

Разделение на проектирование, тестирование, сбор требований, системный блок итп теперь опциональное. Видимо потому что не везде было это применимо и в общем смысле избыточно.

Основная цель

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

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

Как соотносятся задачи в Product Backlog с основной целью — зона ответственности Product Owner.

Product теперь прописан более конкретно. Как механизм (который вы строите), который приносит заявленную ценность. You need to build an engine.

Из всего этого логически вытекает, что цель должна быть конкретной и измеримой. Конкретность определяется ценностью и набором изменений; а конкретнее по тексту, даже целевым состоянием: «a future state of the product which can serve as a target». Набор изменений от «сейчас» до «зашибись» собираются в product backlog.

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

• «захватить мир» — херовая цель, потому что вы нормально это не измерите (даже в моменте), а конкретики нет
• «захватить мир к октябрю» — не сильно лучше
• «получить вот тут показатель лучше конкурента» — уже что-то. Потому что измеримо, хотя и относительно
• «получить вот тут рост показателя на X» — измеримость появляется, можно сравнивать одно с другим
• «сделать вот такие и вот такие фичи» — конкретно, но не измеримо (потому что сделать можно по-разному)
• «сделать фичи по списку и получить вот такую целевую метрику» — конкретно, измеримо, но не факт что одно будет связано с другим
• «сделать AA чтобы получилось XX (достигаем вот этого), сделать BB чтобы YY (будет вот так)» — еще получше, появились связи, их проще дебажить и оценивать
• «сделать в продукте вот этот список, чтобы по нему последовательно получить вот такие улучшения, чтобы общие метрики стали вот такими» — уже близко к рабочему варианту, нормас (есть гипотеза, есть план, есть показатели)

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

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

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

Hope that helps.

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

Технологическая карта

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

С точки зрения процесса (1) — это разновидность flow diagram или, для простоты, тупо инструкция. Что у нас в процессе происходит, как именно это должно происходить, какие есть шаги, этапы и так далее. Зарубежная терминология так и оперирует общим термином process flow diagram, с дальнейшими уточнениями не особо парится.

С точки зрения ресурсов (2) интереснее. Для ТК принято четко формализовывать, что у нас является потребностью (для выполнения процесса), в количественном и качественном смысле; и что мы на выходе получаем, когда наш процесс будет выполнен, по любому из описанных вариантов.

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

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

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

С точки зрения процесса, методика ТК (то есть flow) дает нам описание процесса. Основное полезное качество — повторяемость. Соедини вот так ресурсы и исполнителя, получишь выход вот таком обьеме. Запусти два описанных процесса в параллель, получишь вдвое больше. Измени кратно количественные показатели — и, если процесс допускает, получишь кратно увеличение выхода (но тут есть нюансики). Сам процесс описан, и фундаментально не изменится.

С точки зрения ресурсов, методика ТК дает нам функцию. Как из одного получить другое. Взял 3 яйца, применил 20 минут человеко-времени и 1 нагретую сковороду, получил 200 граммов яичницы. С точки зрения процесса, мы имеем функцию process([resources...])=>result[]. А это уже математический аппарат. С этим можно далее работать, оптимизировать, скейлить, строить цепочки и играть во всё остальное процессное лего.

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

• логистика(100 рублей денег, 1 час человека) = 10 яиц из магаза
• кухня(3 яйца, 20 минут человека, оборудование) = 200 гр яичницы
• выдача(200 гр яичницы, 5 минут человека, чистая тарелка) = 100 рублей в кассу
• клининг(тарелка, 5 минут человека) = чистая тарелка

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

• логистика (100р, 1:00) + (3*кухня (3я, 0:20)) + (3*выдача (200гр, 0:05, 1т)) + (3*клининг (1т, 0:05)) = [300 рублей, 1 лишнее яйцо]

или, сворачиваем:

• бизнес(100 рублей, (1:00+1:00+0:15+0:15 = 2:30 времени))
  = [300 рублей, 1 лишнее яйцо]

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

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

Количественные методы

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

Что тут у нас: во-первых, ограничения по flow и цепочке

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

Во-вторых, количественный скейл, с его возможностями и выявляемыми ограничениями

Этап логистики можно скейлить до какого-то предела, например за 1:00 час времени притащить не 1 коробку (10я) ресурса, а 10 коробок — за бОльшие деньги, но за тот же час. Тогда мультипликаторы (3*) дальше по цепочке теоретически можно увеличить тоже в 10 раз. А практически — исходя из располагаемого времени.

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

В-третьих, параллельность и возможности внутри получившегося flow (сложного, собранного нами из отдельных простых ТК)

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

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

Вот мы на выходе получили 300 рублей, а на входе было 100. Давайте мы из них возьмем еще 100 и запустим цепочку по кругу. Цепочка потребляет у нас 2:30 человеко-времени, значит за рабочий день 8 часов можно уложить ее 3 раза без параллельностей. Это даст нам при 3*100=300 рублей затрат итоговые 900 рублей в кассе. Если за оставшиеся 600 рублей у нас исполнитель (как ресурс времени) готов 1 день несложно поработать, значит наше ресурсное планирование вчерную сходится.

Производственные ограничения, включая неявные

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

Это новые constraints, в начальной задаче их не было, потому что нам было пофиг — а вот теперь появились.

Голдратт и балансировка

Вот теперь пора добавить чутка мат.статистики. У нас для каждой техкарты и процесса есть два типа ресурса по определению:

— показатели запаса, N единиц чего-то
— показатели потока, N единиц чего-то / на время

Затраченное время человека — это тоже показатель потока, единица работы / на время. Вы не сможете взять 0:20 минут одним куском, их надо потратить. Но вы можете их запасти в готовом продукте. Запасенное время и прочие показатели потока чаще всего создают добавленную стоимость, органически — потому что время можно потратить и запасти, но нельзя купить готовой кучкой.

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

Давайте я из цепочки чисто математически вытащу элемент «логистики» (З показатели запаса, П потока):

логистика(3, П)
= бизнес(З, П) — 3*кухня(З, П) — 3*выдача(3, П) — 3*клининг(П)

Но показатели потока, которые про время, нам придется сжечь в любом случае; время пройдет без нас. Значит, чтобы уравнение сошлось в ноль, «логистика» в левой части обязана точно так же нести всю разницу затрат потокового показателя. И то, что требуется для её процесса, и те побочные затраты, которые содержатся в «П» второй части уравнения.

логистика (3, П + побочные_затраты)

Сколько их? Зависит от гомогенности показателя (чьё там было время в показателях потока). Если показатель гомогенный, то мы украли у соседних процессов ровно тот же 1:00 час, пока они простаивали и ждали нашу логистику. Если они запараллелены все, то одну логистику ждали аж три показателя, каждый по часу — мы впустую сожгли 3:00 часа рабочего времени людей.

В правой части есть слагаемое «бизнес», т.к мы математически его перекинули; и да, бизнес как цепочка тоже стоял и ждал 1:00, мы потратили не 3:00, а 4:00. Сначала звучит немного нелогично, но вспомните про недополученную прибыль, которую за час вся цепочка могла бы принести. Прибыли нет, а время цепочки потрачено.

Стоимость этого несчастного часа «логистики», когда все всех ждали, будет составлять (100 р ее затрат + 1:00 ее времени + 4:00 потерь) = 100р + (600/8*5) = 475 рублей. Это я еще время линейное посчитал, из прикидки выше. Неплохо так, еще ничего не сделали, пользы не принесли, а затрат = почти на весь день выручки.

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

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

• барабан (drum): согласно потреблению З и П в каждом процессе и каждой ТК, нормализуем выход по времени. Сколько нам нужно тратить всего, что нам требуется, в идеальной картине мира и полной загрузке. Поскольку время общее, нормализованное, мы можем посчитать поток и время в пересчете на любой его кусок — например, на час, или на день. Появляется оптимальный ритм работы цепочки и производства (поэтому «барабан»), в котором производительность максимальна. А дальше соотв пытаемся к нему прийти и устремиться.
• буфер (buffer): для каждого процесса и каждой ТК у нас есть запас ресурса, который мы запасти можем. То есть, показатели запаса. Тогда затраты показателей потока, в первую очередь время, у нас ограничены только течением времени. Таким образом, в конкретном отдельном процессе будет совершаться работа, пока есть ресурсный запас. Это прикольная модель, потому что 1) мониторинг запаса дает значительную гибкость и 2) есть расширенные варианты, типа цветного буфера, когда можно размазать потребности по запасам по скорости расходования. Базовая оптимизация — достичь ресурсного оптимума запасов (с учетом их стоимости) по отношению к дельте времени отдельных процессов и/ли простоев.
• веревка (rope): метод обратной оптимизации по выходу и затраченному (планируемому) времени: из примера выше, если мы хотим получить 1 готовое блюдо в час X, то нам надо начать чесаться за 2:30 раньше и обеспечить всё необходимое к (T-2:30) или ранее. Если хотим 900 рублей в кассе за день, то все необходимые ресурсы должны быть доступны/свободны на начало дня в нужном обьеме. Начиная с «логистики», поскольку требование по выходу «тянет» за собой последовательно все нужные ресурсы и результаты, и придёт в нее, как в стартовый процесс. Поэтому «веревка» (иногда «канат»), за который мы тянем.

Где подвох

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

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

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

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

Например: у нас есть процесс разруливания херни. Он по определению исследовательский и нетиповой: сколько той херни бывает в жизни. Но мы вполне можем описать под-процесс оценки херни: потратить суммарный час времени вот этих ключевых специалистов, и на выходе получить документ, внутри impact map, оценка рисков и 2-3 плана обработки. Потратить еще час, и выбрать + расписать один из планов, которые берем в работу.

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

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

Поймем как мерить, как улучшать, и как заинтегрить улучшенное — так и сделаем. Пока не сделали, работаем по старому, пофиг что неоптимально, spice must flow, механизм простаивать не имеет права.

Пока нечего даже мерить, управление (и улучшение) будет идти по принципу «кто громче орёт», или вообще тупым перебором, а нам такое не надо.

Пока хватит. Hope that helps.

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

Я не могу палить детали проекта (NDA, как обычно), это live чужой зарубежный проект, но могу поделиться подходом. Как бы я это делал, и почему так.

Первое: команда

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

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

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

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

В какую часть системы (и команды) потребуется для начала заглянуть поглубже и найти понимание с людьми — Саша М, привет! — чтобы лучше понимать логику и контексты. Что от кого можно ожидать, а что, напротив, нам не светит?

Что надо получить: ключевые акторы, зоны ответственности, важные и ключевые куски экспертизы. Записная книжка со списком, кто что знает и куда ходить (куда все ходят) в сложных случаях.

Потому что нам туда придется ходить. Зачем додумывать недостающее, если (для начала) можно просто пойти и спросить.

Второе: структура системы

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

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

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

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

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

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

Что надо получить: карта системы, или хотя бы «рисунок карты» (ц). Неидеальную, но уже стартовую модель взаимосвязей. С огрызками знаний и их источников, в тех местах где они есть. Чтобы потом дополнять недостающее и синхронизировать с реальностью (и прояснять мутные моменты, там-то всё важное и выяснится).

Третье: метрики и наблюдаемость

Как конкретно в любой момент мы узнаём (или должны узнать), что наша система работает нормально, и всё с ней хорошо?

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

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

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

Что надо получить: по-хорошему инструментарий для оценки работоспособности — когда/если пойдем ломать, будем это делать не вслепую. В плохом случае ничего этого нет но, для старта, мы уже будем знать, «где конкретно этого нет» и значит надо прикрутить/сделать/заполучить. В совсем плохом варианте мы все равно получим список узких мест и бутылочных горлышек, которые ни фига не наблюдаемые, но объективно важны — потому что там болит. А это уже весьма дофига для старта.

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

Hope that helps.

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

upd: TxG не общепринятая аббревиатура, это просто я себе так пометил статью чтобы потом по проекту найти.

Британский регулятор (ICO) который выступает как орган для GDPR UK, уже какое-то время назад (2019) ввел механизм регистрации. Реестр реестров, ага.
Там есть fee, в смысле деньги, которые надо этому самому ICO ежегодно заплатить.

— Размер взносиков от 5000 руб до 376 000 руб (от 52 до 3763 в фунтах), в год.
— Штрафы соизмеримые, до 400 000 руб (до 4000 в фунтах). Не запредельно, но все равно неприятно.

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

Кого касается

Тех, кто зарегистрирован как компания в UK.

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

И вот тогда будет касаться точно.

Где описано

Нормальным языком вот тут https://ico.org.uk/for-organisations/data-protection-fee/faqs-data-protection-fee-payment-and-online-registration/

Юридическим языком вот тут https://www.legislation.gov.uk/uksi/2018/480/contents/made и вот тут (изначальный документ) https://www.legislation.gov.uk/uksi/2018/480/made/data.pdf.

Ценник с 2019 года поменялся в сторону увеличения.

За что платим

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

Детский сад, короче.
С вас чисто хотят денег, потому что могут по закону.

Кто должен платить

Если коротко — все, кто обрабатывает информацию о физиках (включая своих же клиентов) любым электронным образом.

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

Про видеозапись у них какой-то больной вопрос, подробнее тут https://ico.org.uk/for-organisations/advice-for-small-organisations/cctv-and-dashcams/dashcams-and-uk-gdpr-what-small-businesses-need-to-know/

Сколько платим

На вебсайтике можно протыкать опрос https://ico.org.uk/for-organisations/data-protection-fee/data-protection-fee-self-assessment/

• Всякая мелкота обычно попадает в категорию за 52…78 фунтов (tier 1). Мелкота это если у вас оборот за год меньше 632000 фунтов или меньше 10 сотрудников. Для всяких представительств и локальных branches вроде бы нормально, вряд ли у вас вся контора зарегана в UK-юрисдикции (а если да, то зачем?)
• Если условия выше не выполняются, хоть одно, тогда tier 2 и точно не менее 78 фунтов, но есть мелким шрифтом условия по характеру данных и их обработки. Для всякой медицины, юридической практики, кредитного скоринга и финансовых организаций — будет больше. Общие условия для tier 2 — до 36 млн фунтов годового оборота и до 250 сотрудников
• Все кто крупнее и в это не попал — tier 3, 3763 фунта в год.

Юридические и финансовые услуги (которые tier 2) где-то там прописаны. Коротко, legal or financial services = accountancy and auditing, consultancy, credit referencing, debt administration, insurance, or mortgage broking.

Если несколько офисов и представительств: считается по тому, кто там из них data controller (то есть принимает решения об обработке данных), и сколько их. Обьединять несколько в один платеж, если они части одной конторы — точно можно. Разделять на несколько мелких, чтобы заплатить с каждого минималку — сложнее, но иногда тоже можно, надо им писать и показывать какие-то документы, которые определяют взаимодействие мелко-контор. Сам не подскажу, не пробовал.

Если вы зачем-то public authority, то тоже правила другие. Это про госконторы, организации здравоохранения, полицию и армию, различные советы и организации, регуляторка, общественный транспорт, fire and rescue, образовательные организации (включая частные). Скорее всего это не про вас, если что, юристы должны быть в курсе.

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

То есть если коротко, за просранные обязательства (за истекший год) надо будет заплатить в двойном размере — сам тариф + похожий на него штраф. Но заранее не узнаешь.

Перед штрафом вам шлют Notice of Intent, и на реакцию дается 2 недели.

Кому можно не платить

Есть список исключений. Но обычная нормальная коммерческая компания туда ни фига не попадает, даже если там один человек и продажа спичек через интернет. Хотя для таких fee будет минимальный (52 фунта = 5000 руб), регистрироваться и платить все равно придется.

Если у вас некоммерческая организация (то есть, конкретно nonprofit по устанавливающим документам), то список правил такой:

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

Оговорка про благотворительность тоже есть, специфика соединенного королевства, но надо быть в charity-реестрах.

Разводы и скам

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

Все письма, которые нормальные настоящие, должны исходить от ico.org.uk. Вся оплата — тоже, только на их вебсайте https://ico.org.uk/for-organisations/data-protection-fee/register/

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

Что еще

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

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

Hope that helps.

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

О чем это всё

Партизанские конференции и Лес. Интересный социальный (в основном, образовательный) проект инициативной группы, который вырос вокруг отраслевых конференций Рунета. И вокруг сообщества людей, которые так или иначе на тех конференциях (и в онлайне), естественно, пересекались. Основная цель — прикнести в тусовочку больше движухи; найти, выработать и проработать новые, перспективные форматы взаимодействий; притащить разнообразные игровые и проектные механики; побороться с тупняком и just for fun, конечно.

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

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

Форматы

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

Формат «междусобойчика и саморефлексии» для встреч и конференций — не новый. По сути, именно это происходит на любом большом мероприятии в рамках афтерпати, итоговых пьянок; внутри организаторской/мастерской группы, а также в сети. Где формируется отдельный слой обсуждений, мнений, рефлексии и длинный хвост выводов, последствий и смыслов.

Самый простой и понятный вариант, когда обмен мнениями и смыслами встроен в сам формат в тех же процессах — это баркемп (или барконф), т.н «барная конференция». Любой участник имеет право на вклад и мнение, обсуждения происходящего происходят тут же, программа и активности возникают в процессе, композиция происходящего происходит прямо на лету.

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

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

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

Без кавычек, потому что задача team building как раз формирует более тесное взаимодействие, доверие, взаимопонимание.

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

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

Интересно, полезно, весело. А минусы будут? Надо брать.
Что было в части практической.

Хронология (2007-2009)

• 2005-2007: сама идея, обсуждения в ЖЖ. Место старта — профильные айтишные, рекламные и маркетинговые сообщества в ЖЖ, та же адвёртка-два-ноль,
• 2007: появляется Фидик (friendfeed), куда далее перекочевал с идеями значительный пласт аудитории — потому что формат ЖЖ уже тогда всех надоел
• 2007 блок онлайновых дискуссий по игро-моделированию и игротехнике

Важная публикация в Коммерсанте 2008 (о, живая ссылка!) про то, что вообще происходит.

Дальше сами конференции — эпоха Леса

• 2007 Гугло-конф
• 2008 айКонф
• 2008 КИБ
• 2008 SocialExp
• 2008 iCamp
• 2008 iСМИ
• 2009 ОК2009 (КИБоРИФ, РИФоКИБ)
• 2009 iCamp

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

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

• 2011 Стартап-школа
• 2011 БФП Лето (проекты «школы Потанина» выступили основным драйвером в этот период)
• 2011 Otus, Educamp, ЛША (тут я не следил)
• 2012 БФП Зима
• 2012 БФП Лето

Материалы: где почитать и куда копать

— почивший сайт Леса, partyconf, про который сейчас помнит вебархив
— вики-хоронилище Метавера, которое сейчас живое (пока живое)
— сайты отраслевых конференций, тоже вебархив
— архив Фидика, но там вы без бутылки не разберетесь; формат фидика очень «рваный», а контексты считай утеряны

А вот пересечение (от Дениса Бескова) с Олегом Буниным и про Product Camp, как идею, со своей хронологией 2007-2011: Как в России появился первый Product Camp

Конкретно про Метавер (мета-университет)

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

— хронологический блок
— лесное
— потанинское
— блок концепций

Разберётесь. Конкретно про Метавер, из того, что я помню: на этапе 2009+ контента стало много, идей стало много, внутрянка мастерской и игротехнической работы пошла в отдельных направлениях, отдельных мастерских группах. Встал вопрос авторства, на который до этого всем ранее было плюс-минус пофиг. Материалы Метавера под открытой GNU Public, но это не значит, что все материалы открытые. Появился и NDA, и сегментация по направлениям. Поэтому тут я ссылаюсь только на открытое.

Важно: помещение существующих материалов в банк [Метавера] осуществляется только с согласия всех владельцев этих материалов.

Базовые идеи

Сохраненный оригинал. Дальше уже в моем переложении.

Кооперация

Всё происходящее = командная работа, как базовая идея. Просто прийти почиллить и поглазеть — сложно, и ломает формат. Зато тем, кто внутри командного взаимодействия, вот тем точно хорошо и клёво. Здесь же отрастает «Contribute or GTFO», как контраст с «пассажирами» основной площадки конференции. Пришел — вносишь вклад, помогаешь другим, выбираешь себе роль, отыгрываешь.

Термин contribute or gtfo принес (кажется) Урбан, по аналогии с «tits or gtfo». Подробнее есть у Кости:

Ну, это честно. Хотя и непросто.

Мана

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

Несложно заметить, что всё это про психологию, про эмоции, и про Чиксентмихаевский «поток». Acceptable.

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

Про ману, экологию и проблематику можно почитать тут

Обучение

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

То есть, помимо учебно-образовательного слоя самой отраслевой конференции (о чем она там была), есть слой мета-образовательный «как мы это делаем, и зачем мы это делаем». Удачное берём, осмысливаем и тиражируем; неудачное отбрасываем. Повторить.

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

Конференция живого действия

И в концепции, и формате, в основе лежит активность. Участвуй, создавай, обсуждай, предлагай, критикуй, помогай, делись, радуйся, рассказывай, показывай, дай попробовать. Если не получается — притворись, что получается, включи фантазию, снимись с ручника. Fake it till you make it. Правил нет, судей в общем-то тоже нет, а фейерверк кроме тебя никто не зажжет.

Нас всех заколебали трепачи. Нам самим надоело «просто трепаться». Нам не нравится заниматься «мета-деятельностью». Нам нравится действовать. Лес — это практика малых дел.

Сюда же про «темп» и скорость движухи.

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

Диалог и люди

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

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

Leave your trace

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

Если говорить про взаимодействия, фан и совместный опыт — точно дофига.

Фоточки (пока их не забыл интернет)
— от Тио (гуглоконф 08, Судак 08, лесное 08, КИБ 08, iСМИ 08, iCamp 09, OK2009)
— от Джинджер (OK2009, ВВЦ 09, iCamp 09, Лосево, лесное)
— от Яны (выборка)

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

Видео вот кое-что OK2009 достано из архива Митрича (Женя Калинин):
Синий Диван, Расшарь свое туду, TEDx Россия, Атлас Будущего, Игра в артефакты, Тобе и Али, Дедушко…

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

Я даже убрал про «Порно 2.0», хотя у Митрича есть :)

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

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

Урбана поставил первым, потому что вон он там в вики Метавера месяц назад ковырялся судя по логам, значит живой :)

Своих фоточек с Тио тоже не нашел, надо в холодные бекапы лезть, но если ты это читаешь — привет тебе ;)

Игрища

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

• обмен бейджами (отрефлексировать ролевые модели, поменяться ролями, построить диалог с нуля)
• игра в будущее (форсайтинг, форкастинг)
• проектирование продуктов (идеальный продукт, абсурдный продукт)
• спринт-конференции (5 min, печа-куча), блиц-доклады
• игра в мемы (построение коммуникации, синтез диалога вокруг поставленной задачи)
• сад граблей (прогнозирование-проектирование, обкатка подходов)
• игра в переходы (это видоизмененные «метаморфозы»)
• тематические зоны (гладильня, рыдальня, говорильня, газон итп)
• лесная книга (вирусное «собери мысль из надписей и людей»)

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

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

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

Сложности

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

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

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

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

++ забавное от Митрича принесли: главное впечатление от КИБа — многообразие форматов (КИБ 2008)

Контейнеризация

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

• Есть ряд оффлайновых и предсказуемых площадок-хостов. У них есть место, локация, люди, инфраструктура. Там что-то происходит, с заранее заданными форматами. Сетка мероприятий кратко- и средне-срочная. Время и место жестко заданы, контент и agenda подбираются по вкусу, исходя из возможностей.
• Есть сама движуха, которая онлайновая, в смысле виртуальная. Она существует в информационном поле. У нее есть люди, идеи, контент и повестка дня. Краткосрочных оффлайновых событий нет (потому что для них достаточно онлайна, вы в одном чатике/фидике сидите). Зато есть потребность в чем-то существенном, на средне- и долгосрочном горизонте. Постоянной площадки нет, оффлайна нет. Время и место, следовательно, никак не заданы (их надо подбирать и искать), зато контент и agenda примерно понятны и формализуемы в конкретный момент времени.

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

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

• оффлайновая площадка получает себе аудиторию, темы, движ и закрывает потребность в контенте, проходимости, чеке итп
• онлайновая движуха получает себе площадку (из числа доступных на выбор) в календаре, по мере необходимости и аппетитов, на подходящих «прямо сейчас» условиях и не заводит свой бар

Где кепку бросил, там сегодня дом.

Про этику развесисто читать тут

А чего я?

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

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

Хотя, конечно, на нескольких мероприятиях был и поучаствовал.

Поучаствовал мало, contribute or gtfo я не вывез.

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

Но авторство все еще туда. Лесом в Лес.

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

Спасибо что были вместе.

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

Что произошло. Помимо технических ограничений любого характера, которые мы уже видели ранее, регулятор рынка через ФАС выпустил актуальное разъяснение, что ведомство (ФАС) собирается расценивать размещение рекламы в Tlg (медийной площадке) как нарушение закона «о рекламе» ч. 10.7 ст. 5. Со штрафами с рекламодателей. Задним числом, за прошедший год.

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

С такими танцами никакой рекламодатель не пойдет легально размещаться, рискуя попасть на штрафы (до 500 000 руб).

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

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

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

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

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

Раньше, кстати, это еще и 3% налогов с рекламы в бюджет давало.

Дальше оплата налом, криптой, серыми схемами, чем угодно — но только не официальными каналами, где их видит РКН-ФАС-ФНС.

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

Вопрос «какой мудак это придумал?» я тоже оставлю за скобками, это не суть важно пока что.

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

Выводить такие взаимодействия в «белую зону» обратно под регуляцию обычно пиздецки сложно и дорого. Не спасают не только штрафы, но даже массовые расстрелы (кроме шуток, есть пример Китая). Если регуляция и закон УЖЕ не работают, то они могут быть произвольной жесткости, сложности, хоть кары небесные; они УЖЕ не работают.

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

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

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

Лучше все-таки хреновая регуляция, чем ее полное отсутствие.
Но тут как: кинжал хорош для того, у кого он есть.

Это работает в любой регуляции мульти-акторной системы (где много игроков и поиск равновесия). Равновесие все равно найдется. Только регулятора там уже не будет.

Вот такой вам пример.
С мессенджером разберемся, а вот с некомпетенцией на местах уже хз.

Такие дела.

О, куски интервью на морду Газеты/Сбера попали. Местами без контекста, но зато вместе с Клименко и Поповым (+Дуровым и Песковым), ебать компания конечно подобралась
https://www.gazeta.ru/tech/22636879/blokirovka-telegram.shtml

Ща будет база базишная, на уровне институтских курсов.
Но я упоминал ранее, а тут снова под руку вспомнили. Значит, надо.

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

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

Это ОЧЕНЬ тупое упрощение, есличо, я точно в курсе.
Но если вы хотя бы его понимаете, далее разбираться и всё усложнить, с пользой себе — не проблема.

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

Соответственно и цели в этих двух вариантах тоже разные

• мы привлекаем новую аудиторию, чтобы скомпенсировать эрозию и получить количественно плюс (в любых приятных показателях).
  Эрозия -15%, привлекли +20%, в выигрыше 5%.
• мы удерживаем старую аудиторию, чтобы уменьшить показатель эрозии, меньше терять (аналогично в любых приятных показателях).
  Эрозия -15%, снизили до 10%, в выигрыше 5%.

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

Стратегия с «новыми» и захватом рынка ориентируется на acquisition-цепочку. Вот та самая AIDA, внимание-интерес-желание-действие. Воронки, каналы, грелки, связки. Конверсия обычно или в пользователя, или в деньги. Привлекать новых проще в той части, где о вас еще не знают, где есть возможность откусить себе кусочек аудитории — например, пачкой чуть более таргетированных офферов, чем у конкурента.

Стратегия со «старыми» и удержанием ориентируется на retention-фазу. Вам не нужно никого привлекать, вам нужно наглядно убедить, что с вами всё еще зашибись. Работаем с Retention-Conviction-Satisfaction. Конверсия обычно идет либо в допродажи, либо в увеличение LTV (подписки, апгрейды), либо хотя бы в активное ядро аудитории, как вы его там меряете (да, CCU). Взаимодействовать со старыми проще в том смысле, что а) вы про них уже много чего знаете, б) с ними есть коммуникация, в) кредит доверия и г) они уже хотя бы раз дали вам денег, например. И надо, чтобы продолжали.

Это совершенно разные аудитории, цели, соответственно приемы, таргеты и механики.

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

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

Считайте, что вы просто покормили маркетинг и слили бюджеты.

Разделение, почему я про него пишу, обычно наглядное и тупое как угол дома.

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

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

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

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

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

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

Вот такой вам инструментик-рецепт. Хотя бы на подумать.

Hope that helps.

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

Справедливо. Я бы смотрел, где вы получите больше пользы и импакта

Обратите внимание на циферки сверху.
Можно привлечь +20% и получить +5% суммы. Можно снизить эрозию на 5% и получить, типа, тот же выигрыш.

• если нам дешевле привлекать +20% и сразу их конвертить — не вопрос, делайте так. Особенно, если там маячит живой конверт, и возможность окучить какой-то важный кусочек рынка.
• если нам дешевле сохранять +5%, например на уже насыщенном рынке, то скорее всего это будет дешевле. У вас инструментов больше, и аудитория вот она, за ней не надо бегать и лить воронки.

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

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

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

Рынков где можно пойти и тупо нарубить себе +20% юзербазы, не ввалив камазы бабла, и не продать при этом чьи-то органы — их не так много. Мало их. Но это если в людях мерить. Если в деньгах, то бывает всяко-разное (например, есть вкусная ниша, или нету, но оба варианта одинаково хреновые), но и эрозии «в деньгах» не взятые мной с потолка -15%, а поменьше. Короче, depends.

Статья про CDN и content policy немного подогрела обсуждение (кстати, спасибо). И да, я о JWT высказываюсь не совсем в оптимистическом ключе.

У него, как у подхода и метода, есть плюсы — иначе бы он не появился, но есть и минусы, и минусы неприятные. Это не просто «Витя старый хейтер и опять ворчит». Вот давайте по ним, по минусам и деталям, пробежимся.

JWT, json web token

Что такое JWT: это подписанный кусок контента. Внутри него есть три куска данных, по стандарту. В одном из них, в поле payload, лежит ваш набор данных. У набора данных (payload) есть набор «стандартных полей», но вы можете туда напихать свои, с произвольными ключами.

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

По узнаваемым «ey» и трем точкам итоговая структура запросто распознаётся «на глаз». Ну и читается чем попало, доступных библиотек сотни.

• Если вам нужно шифровать токены, чтобы не читалось кем попало, гуглить JWE, Json Web Encryption. Там пять полей вместо трех, тоже через точку, header определяет дальнейшее содержимое и его тип. Нам он тут пока не нужен, дальше разговор про простой, plain.

Содержимое, payload

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

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

— sub: кому выдан. Subject это актор/принципал, которому лично выдан токен: чаще всего это либо лично пользователь (и его ID), или конкретная внешняя система (если актором выступает она, для server to server взаимодействий). Иногда и то, и другое.

— aud: система, для использования которой предназначался токен. Если Audience задан, то он обязан ставиться/проверяться, и при выдаче токена, и при использовании. Если не задан, то такой токен выдан «кому попало», на предъявителя.

— exp: до какого времени (unix timestamp) токен считается валидным. Всё что позже — отбрасывается, тк считается протухшим.

— nbf: с какого времени токен валидный (unix timestamp). Обратное предыдущему, до какого времени токен использовать еще нельзя. Это полезно, когда в обороте есть несколько токенов, старый еще-рабочий, и новый еще-не-начавшийся.

— iat: когда выписан этот конкретный

— jti: идентификатор именно этого токена. Полезно при ведении базы активных токенов и при проверках (пере-проверках).

— kid: какой ключ использовался для генерации подписи этого токена и, следовательно, как получателю проверять его подпись (и чем).

— alg: что за механизм подписи использовался. Вы удивитесь, но это важно, и об этом поле часто забывают (ниже расскажу).

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

Подпись, signature

Подпись никак не защищает данные от их читаемости. В 99% случаев вы столкнетесь с открытыми токенами, хотя формально есть варианты им payload зашифровать. Но это и не требуется.

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

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

— RS256, RS384, RS512 варианты асимметричной подписи с RSASSA-PKCS-v1_5
— ES256, ES384, ES512 варианты асимметричной подписи на ECDSA, на эллиптических кривых

Для зануд, есть и другие:

— PS256, PS384, PS512 варианты RSASSA-PSS в варианте probablistic (MGF1), подпись будет каждый раз разная, но все еще валидная (иногда это важно)

— EdDSA (одно значение alg) и явное указание используемой э/кривой в поле crv. Возможные на практике значения = [Ed25519, Ed448]. Если вам нужна действительно промышленная криптография, нормальный вариант, потому что нет ряда изъянов из других вариантов, и все еще достаточно быстрый.

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

Целевая система получает токен, смотрит что там за ключ использовался, есть ли у нее открытая часть, и проверяет подпись. Если открытого ключа KID нет, значит надо пойти (безопасным образом) к источнику, и забрать открытую часть, провести проверку. Это мы уже на минималочках реализуем public key infrastructure.

Нахера это всё?

Что здесь хорошо, то есть плюсы:

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

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

— внутрь токена в payload можно безопасным образом вшить результат каких-то «тяжелых» проверок: список ролей, возможностей, ключевых открытых данных юзера (user ID, screen name), внутренние идентификаторы. Подтвержденным, секурным образом. Если конечно их вообще можно передавать открытым текстом (помним, токен читается)

— куча готовых механизмов, типовых и проверенных, которые скорее всего доступны на целевых системах. Для популярного софта, библиотек, реализаций. Третьи системы чаще всего не будут гореть желанием реализовывать под ваши задачи какой-то лютый кастом. А сама идея реализовывать industrial grade криптографические защиты руками обычно несёт много граблей by design, лучше взять готовые механизмы.

Плюсы значительные, механизм неплохой.
Но есть и минусы.

Давайте сразу 2.5 простых, статических минуса тут обозначу:

— объем. JWT это примерно полкило данных. На каждый запрос везде у вас начинает летать +0.5Кб, что может быть на высоконагруженных системах неприятно, хотя и не смертельно. (0.5кБ х 10000 rq/sec x 86400 сек) = 412 Гб трафика в сутки просто ради того, чтобы токены гонять. Хотя, если бы вы их не гоняли, еще неизвестно, существовал бы способ лучше.

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

— ограничение размера. Впихнуть в JWT более 2 Кб обычно не удается, потому что растет объем передачи, и стандартные заголовки http и прочих транспортных протоколов уже начинают упираться в ограничения

Чаще всего это неизбежное зло, но тем не менее.

Далее проблемы интереснее.
Структурные, логические.

Проблема раз: украденный токен

Токен в такой схеме отчуждаемый. Мы его сгенерили на системе-источнике, куда-то выдали, в широкий мир кому-то там. Дальше он = вещь самостоятельная и автономная. Система-приемник ему верит; основным плюсом является то, что для проверок «никуда бегать не надо», как следствие — никто к источнику истины уже и не придет, пока токен не стухнет.

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

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

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

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

Проблема два: обновление токенов, refresh

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

Можно конечно просто ничего не делать. Но. Система-приемник поняла, что токен ей не оч, юзера шлет нафиг. Юзер сам идет в систему-источник, проходит там заново все проверки. И это очень сильно рвёт цепочку взаимодействий, это «авторизация истухла посреди чего-то там», in a middle of something.

Поэтому часто прикручивают другой механизм: механизм рефрешей.

• Один вариант, когда система-приемник может сама сходить, за юзера, в источник, и передать какой-то ключик, который позволит получить обновленный JWT, без необходимости фоллбека на «полный замес».
• Второй вариант, когда ключика refresh нет у системы-приемника, но есть где-то там у юзера, и общий механизм от лица юзера забирает этот ключик, чтобы JWT с его помощью обновить, и продолжить работу.

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

Как решать: операции с перевыпуском JWT, как по рефрешам так и по любому другому поводу, должны быть обвешаны проверками, логами, мониторингом и (желательно) не меньшим фингерпринтингом, как описано в «проблеме 1». Не меньшим, а возможно даже большим.

• Знаю реализации, например, когда рефреш выдает токен с заведомо меньшими правами (хочешь нормальный, используй полную схему).
• Знаю реализации, где используется «цепочка рефрешей», когда нельзя использовать один рефреш более одного раза, и таким образом ситуация «спёрли» уже явно у кого-то не сработает, и вызовет вопросы.
• Знаю реализации, когда использование рефрешей ограничено не только per user, но еще и для целевой системы (одна система не может дергать рефреш одному юзеру чаще чем X).

Еще рефреш не должен «жить вечно», иначе мы получаем бесконечный источник валидных токенов. Рефрешнулся, получил JWT, получил новый рефреш, снова рефрешнулся… кстати, как вы собираетесь это проверять?

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

Проблема три: отзыв токена per user

Ситуация: юзер получил JWT, пошел с ним в систему-приемник.
Система его приняла.

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

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

Можно предусмотреть на системе-приемнике выборочные проверки раз в rand (1, X), или проверки раз в квант времени. Токен живет сутки, но раз в 5 минут per user мы все равно будем переспрашивать источник, всё ли там норм вот конкретно с ним. Если на системе-приемнике есть кеш валидных JWT (а чаще всего он есть, так проще), то вот как раз по протуханию локального хеша мы а) перепроверяем криптографию подписи и б) переспрашиваем источник о статусе и об отзыве токена.

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

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

Можно без него, если у вас JWT живут 1-5 минут, может и пофиг.
А может и не пофиг, лишние 5 минут жизни уже заведомо скомпрометированного токена и учетки — вполне позволяют успеть «наворотить дел».

Проблема 4: отзыв токенов в принципе

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

• Если мы вдруг хотим перестать доверять юзеру, уже рассмотрели выше. Но у него может быть NN токенов, все валидные, а злоумышленник мог еще каких-то даже наполучать.
• Возможно, мы хотим перестать доверять авторизации не per user, а per audience, сделать невалидными все токены, которые выдавались на какую-то внешнюю конкретную систему. Audience конкретный, юзеров может быть произвольное количество.
• Возможно, у нас тупо спёрли ключ подписи. Или мы нашли проблему в базовом механизме авторизации у себя, на системе-источнике. Следовательно, всем юзерам с каким-то признаком, и их токенам, мы больше доверять не можем; а в сторонних системах должны оперативно перестать это делать.

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

Но сразу минус: это ни фига не гранулярно. Поменялся ключ — всю юзербазу разлогинило и выкинуло. Где-то это оправданная мера, где-то не очень.

Для более точного контроля можно использовать KID. Для конкретного токена указано, чем его проверять. Если у системы-приемника нет нужного открытого ключа, надо сходить секурно на master.host/keys/KID и забрать там нужный — а затем проверить. В принципе, вариант. Но вам еще надо указывать не только то, какие ключи бывают валидными, но и явно те, которые стали невалидными, иначе система-приемник будет иметь у себя закешированные, включая старый, и вы ничего так не достигнете.

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

Можно не писать timestamp, а просто взять какое-то инкрементное возрастающее значение, знать его на системе-источнике per user, и писать внутрь токена. Технически почти ничем не отличается; всё, что получено системой-приемником со значением X, автоматически делает (для нее) невалидным всё полученное/получаемое ранее/позднее, что меньше X.

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

И то и другое = алярма и повод идти смотреть.

Проблема 5: кривая реализация

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

Варианты реализации «на хешах» (HS) просто использовать не надо (а надо не забыть отключить). Переключить ALG на хеши и поймать коллизию не то чтоб сильно невозможно, RS-подпись тоже подписывает хеш, чтоб попроще было, а коллизия на двух хешах ловится. Короче, ненужное отключаем.

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

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

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

Выданные JWT и рефреши к ним, в системе-источнике, придется и хранить и логировать. Чтобы понимать, что у вас на периметре происходит, чего там за сессии у юзера, куда он ходил, где у него актуальные права итп. Мониторингом этого всего обвешать, тк если у вас у юзера вдруг вместо 1 JWT стала 1000, значит кого-то хакнули, или хотя бы на полпути.

В общем, проверять придется много.

Блок про сравнение пока не знаю, хочу дописать сюда или нет.

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

• полностью stateless jwt = размеры, сложности с обновлением (неуправляемый кеш)
• stateful jwt = все равно ходить в какие-то другие системы, перепроверять данные
• механизм отзыва надо придумывать
• механизмы обновлений надо придумывать, а типовые (refresh) имеют слабости
• все равно должен использоваться совместно с чем-то еще

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

Пока что так,
Hope that helps.

Медиа-хайп вокруг популярного печально известного мессенджера в очередной раз пополнился дыркой, или «дыркой»: хранение и отдача медийки реализована по ссылкам, которые доступны снаружи из открытой сети.

Ссылка выглядит так: i.oneme.ru/i?&fn=ресайз&r=композитный_хеш

Результат — ну, например, вот такой:
https://i.oneme.ru/i?&fn=w_1440&r=BTEFHNxXjmuR0N2Fir9SuMMRpSFWLfO_ieehECYcyBCPMsJPkexaioi5pUNQOIf47xc
Эта ссылка доступна прямо сейчас, безо всякой авторизации, всему интернету.

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

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

Так ли это? Нет, не так. Вот эту картинку я же как-то узнал, а?
Она точно не моя, мне ее никто не слал, у меня даже того мессенджера нет.

Проблема общая в том, что любая ссылка в интернете = штука открытая. Интернет так работает.

То есть, она уже не только «не секретная» — она уже совсем-совсем не секретная. И ее можно не подбирать, достаточно взять из логов готовую, работающую.

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

Чтобы оценить масштабы бедствия:
https://web.archive.org/web/*/https://i.oneme.ru/i*

Берите любую.

Не только Махом единым. Такая же, или аналогичная по сути своей схема исторически используется в офигеть каком множестве систем. Чисто так сложилось, просто по инерции. И регулярно оказывается, что открытые всему интернету ссылки — они, вы не поверите, открытые всему интернету. Причем неограниченное время.

Секретная ссылка с секретным алгоритмом хеша, энтропией, итд итп — перестает быть секретной, и становится security by obscurity, когда у злоумышленника уже есть эта ссылка готовая. Ее не надо генерить, вот она, бери. Никаких проблем.

Техническая проблема под этим всем следующая: edge CDN network.

Сервис не раздает картинки «сам». Объёмы медиа-контента обычно внушительные, он валяется где-то там кучей — и есть отдельная инфра, задача которой просто отдавать контент, не затрагивая логику приложения. То есть — CDN и его хосты, content delivery network.

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

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

Но это только первая часть проблемы.

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

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

Сотне тупых раздающих CDN-машин категорически насрать, что там за контент, откуда он взялся, и кому там чего можно. Что-то внутри себя они могут, но по очень небольшому списку (потому что все еще должны быть быстрыми, большими и тупыми). Ходить куда-то к вам в инфру и проверять права доступа — вся эта сетка не будет, при любом раскладе.

Еще важно отметить в этой связи, что и бегать синхронизироваться (= «что там обновилось») с вашим медиа-источником удаленная CDN-сеть размером с Акамай может, но не обязана — ввиду ее размеров. Первичный запрос — да, будет к вам, будет cache on read, CDN заберет исходник, к себе сложит. Если вы его там у себя поменяли, изменили, что-то еще танцевали — ей пахеру.

Даже удалять точечно контент там никто не будет, его дешевле хранить «условно вечно», чем бегать синхронизировать состояние каждого кусочка в отдельности. То есть, нюдсы, попавшие на CDN, останутся там навечно — мечта безопасника, практически. Есть полиси по времени жизни кусочков, но с ограничениями.

** Удобный лайфхак, кстати, у медиа-сервиса VK: если запросить свой собственный архив данных, вам отдадут ссылки на ваши же давно удаленные фоточки, и исходники, реально на CDN присутствующие. Можно слить бекапчик, ностальгии ради.

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

Первый путь — чисто на источниках-урлах-хешах (но не так, как у Макса, а посложнее)

Второй путь — на подписывании, и проверке content policy, когда CDN заранее имеет локально проверяемые правила для каждого юзера, юзер сам ему их приносит.

Путь дешманский

Чисто на источниках = означает, что кешированного контента по ссылкам, на CDN, должно стать меньше, и он оттуда должен удаляться совсем. Актуальный — перезапрашиваться заново, с вашего медиа-источника. Если ваш источник такого контента не отдал (уже не отдал), «вечная ссылка с нюдсами» работать уже перестанет, у нее источника нет.

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

Если CDN совсем-совсем тупой, и не умеет в удаление никаким образом (так бывает) — можно динамически пересоздавать всю сеть, скриптами. Убивать ноды в CDN целиком, выводить из роутинга насовсем, пересоздавать новые. Да, они будут пустые, будет прогрев кеша и нагрузка на ваш источник — но зато сразу по актуальному состоянию.

Реализовывать правила per-user таким образом практически невозможно. Потому что CDN все еще отдает контент по ссылке в любом случае, ссылка утекла — здрасти. Всё, чего вы добьетесь, что можете ограничить доступ к источнику на своей стороне — и, например, проверять глобально права доступа хотя бы раз в день/неделю/месяц. Это все еще может быть удобно для глобальных настроек приватности. Ну и для GDPR, вы же помните, что юзерский контент хранить вечно нельзя.

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

Важная оговорка: текст написан в марте 2026, рано или поздно они переобуются, переделают. Текст останется, в назидание потомкам.

Борьба с энтропией

Отдельно напомню, что саму ссылочку тоже надо не иметь возможности злонамеренно подобрать. То есть, я вон смотрю на структуру хеша в ссылке Макса, и вижу там 3 конкретных блока. Значит, чисто теоретически, они а) заменяемые б) подбирабельные. Если вы строите любой хеш по предсказуемым, детерминированным данным — например, id юзера — то смысла в таком хеше ровно ноль, он подбирается. То же самое по двум, трем, четырем параметрам: если они детерминированные, вопрос времени.

Если в хеше «соль», рандомная вставка, но статическая — тоже не оч хорошо, особенно если прям перебором видно, где она живет и на что влияет.

Поэтому генерация ссылки, если уж вы делаете решение только на них (с очисткой кешей), должна иметь time-bound параметр. Или несколько. Например, сегодняшний день из даты, по UTC. Таким образом, закешированная ссылка, которую сгенерили позавчера, уже ничего не отдаст ни с CDN (где ее удалили очисткой кеша), ни с медиа-источника (где проверка хеша не пройдет). Авторизованный юзер может запросить и получить новую валидную, посторонний неавторизованный васян из интернетов — не может.

Ну и логичная оговорка, что вам по дефолту надо будет генерить 2 копии сразу, «за сегодня и за вчера», чтобы на переходе суток через полночь у вас весь контент не офигевал. Тут понятно.

Чем более variable источник хеша/ссылки/подписи, тем сложнее его ломать, и тем вам спокойнее спать. Детерминированных хешей не должно быть, «вечных» не-устаревающих не должно быть.

Чем плох злонамеренный подбор, не ограниченный по времени.

Вариант 1: представьте, что вы заведомо знаете, что на картинке по ссылке с заданным хешом (который вы пока не знаете), описано что-то очень вам злонамеренно нужное. Например, ключ от кошелька где деньги лежат. Таким образом, вы можете целенаправленно атаковать перебором ровно один урл, с доступной вам скоростью. Ваши 86 млн вариантов в день — вполне себе скорость. Даже если вы потратите месяц на подбор, результат перекроет затраты. А «месяц» или более — ничем не ограничены, если ссылки вечные, и целевая система даже не узнает о хаке.

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

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

Путь правильный

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

Но что есть:

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

Куки и свойства браузера. Как правило, ноды CDN торчат в сеть самостоятельно, значит на них можно навесить доменный роутинг (cdn1.yoursite, cdn2.yoursite итп). Это означает, что при обращении юзера на cdn1.yoursite — на CDN — браузер получит всё то, что было ему отдано в cookie для домена *.yoursite.

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

Опа, у нас появляется механизм для разделения юзеров.

Но это вяло и уныло.

Может, вообще запишем в куку права целиком?

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

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

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

Развиваем идею дальше.

А что если мы совместим идею врЕменного хеша, как выше, с идеей подписывания правил доступа односторонним ключом?

Это мы уже придумали content policy, как у больших.

Мы можем в родительской системе написать правила прям явно: {файл, срок_доступа, юзер/роль}, и подписать асимметричной криптографией, положить подпись рядышком. Эта инфа сама по себе не секретная, как и ее подпись — просто пихаем их прямо в ссылку.
Вторым шагом мы в cookie для CDN, уже конкретному юзеру и его браузеру, пишем, что это вот такой-то {юзер/роль}, и тоже рядом генерим и кладем подпись.

Таким образом, задача проверки сводится к чему:
— взять правила из ссылки, проверить подпись, взять юзера из cookie-заголовка, проверить подпись, и сравнить одно с другим. И с календарным временем.

И вот это уже офигенный механизм, который может много-много чего.

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

Проверка асимметричной криптографии тоже штука не самая дешевая, но все-таки лучше (для коммерческой конторы) когда к тебе не бегают юзера со своим креативом, а когда ты сам родил предсказуемый механизм и сказал «во, пользуйтесь». Лишь бы ключ для проверки подписи под ногами на CDN валялся — и то, только открытый, потому что закрытый где-то там у автора контента в его системе живёт, он нам нафиг не нужен. Секурно.

Из последнего варианта с content policy уже можно накурить-накрутить себе что-то свое, произвольной развесистости.

Занудно скажу, что подписанные cookie про юзера из данного примера, которые полетят на CDN и заставят работать механизм проверки content policy, тоже различными способами воруются. Браузером, расширениями, mitm, проксёй, трояном итд итп.

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

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

WAF

Несложно заметить, что на том же принципе и механизме реализуется и web application firewall практически любого характера.

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

Пользуйтесь, известные костыли — понятные костыли.

Hope that helps.

UPD, добавлено позже: я намеренно не писал о куче готовых реализаций на площадках — потому что я хз, что вы там у себя в инфре используете — но окей, вот например как «дешманский путь» на урлах и подписях реализован

• в амазоне https://docs.aws.amazon.com/cli/latest/reference/s3/presign.html#examples
• в minio (presigned url) https://docs.min.io/enterprise/aistor-object-store/reference/cli/mc-share/mc-share-download/