Transcription
Давай я представлюсь тогда ещё раз. Меня зовут Максим Вашинов. Я в айтишечке почти 20 годиков. Э, последние 3,2 года работаю в Испании в компании Ипам солuttion архитектором. До этого я был се в аутсорсе 7 лет. Вот. А затем решил, что хочу переехать в Испанию и всё жизнь поменялось.
В 2025 году, как известно, если ты не используешь AI, то то либо тебя скоро заменят, либо тебя скоро заменит искусственный интеллект, либо ничего не произойдёт. Мы так до конца не поняли в индустрии, но кажется, что одно или другое должно точно произойти.
Сейчас, а у нас будет два варианта взаимодействия. Первый вариант - это я просто показываю, как, э, я сейчас научился использовать AI для сугубо архитекторских задач. И вы просто смотрите, задаёте вопросы, и пока мы ждём ответы лэмки, мы можем общаться, и вы можете задавать вопросы, и мы их будем обсуждать. И вариант номер два, да, там ссылка правильная в Гугле сейчас. Это там вам нужна только веточка Copilot. Давайте я вам её сразу дам. Вот для того, чтобы делать вместе со мной, э, нужен докер, нужна де с cop, либо нужен какой-то другой редактор, который, э, вернее, какой-то агентский тул, который умеет вызывать любую вашу любимую lm. Вот первый вариант - это вы смотрите, второй вариант делаете со мной.
Э, давайте разберёмся сначала. Напишите, пожалуйста, в чатике, кто смотрит, а кто делает, потому что мне, а, это нужно для того, чтобы понимать, сколько нужно вас ждать, потому что если много людей хочет, э, хочет тоже делать, нужно делать чуть побольше паузу, чтобы люди успевали. Смотрю, делаю, смотрю, делаю, смотрю. Так, так, делаю, пытаются, смотрю, делаю. О'кей. Большинство смотрит, но есть те, кто делают.
Так, смотрите, я за то, чтобы, так как я сразу анонсировал, что это практический формат, я за то, чтобы как можно больше людей делало, поэтому мы будем ждать. Если кто-то сдаётся, то вы, пожалуйста, э напишите, что вы сдались и не успеваете, что вы переходите в режим смотрю. Тогда я просто чуть-чуть ускорюсь, чтобы ну чтобы не было скучно. Но по умолчанию я, конечно, за то, что делать.
И вот ещё есть такой документик. Я подумал, зачем нам презентации. Здесь задавали люди вопросы. Я постарался ответить на всё, что начал, на что можно ответить текстом. Здесь в комментариях уже есть ответы. Если я недостаточно хорошо ответил, то в процессе э в процессе мероприятия будем обсуждать. Есть парочка, на которые я не ответил, потому что сложновато на них ответить текстом. И сюда немножко буду добавлять ссылки, которые нам потребуются. И вот ряд слайдов я тоже сделал небольшой топ. Поехали.
Значит, курсор IDE, э, да, подойдёт. Единственное, что там немножко придётся, а, придётся немножко по-другому зывать пронты, а, потому что, я так, насколько понимаю, в курсоре этот тулинг ещё не поддерживается.
Как я дошёл, дошёл до жизни такой? Был у меня архитектурный вот шаблон, который мне нравился использовать. Вот этот вот, э, я его использую около 2 лет для всяких своих архитектурных делишек. Он состоит из трёх частей. Это диаграмма в формате C4, это документация в формате Arc 42 и это лок архитектурных решений в формате ADR Tools. Они все прекрасно интегрируются в одном туле, который называется Structurрайзеer. Это тул, который написал Саon Браун тоже для самого себя. Это автор аннотации C4. И, собственно, он написал как-то статью, что он видит минимальный комплект архитектуры современной вот такой, что это диаграмма в нотации SE4, сопровождающая документация в любом текстовом формате и, соответственно, налог архитектурных решений. Здесь на Гитхабе всё написано, как этим пользоваться. До недавнего времени никакой поддержки лмок здесь не было. И я элмками пользовался, когда мне нужно было что-нибудь там было получить какое-то sumри, э, э, коротенькая по, аэ, ну, на исследование, по которым по по теме, где я не очень был уверен или что-то или в качестве резиновой уточки спросить: "А вот что ты думаешь, дорогая, по этому поводу? Правт или не прав?" Это было не очень удобно, потому что приходилось заходить в окно чата GPT, туда что-то писать, потом докопировать обратно, потом опять зайти вчат GPT. И в какой-то момент, когда в GitHub Cileте появился агентский режим, я подумал: "О, клёво, значит, можно теперь не выходить из DE, проектировать архитектуру, также делать документацию и тот workflow, который у меня был в слмом, можно тоже его засунуть в Eть в браузер. Я решил, соответственно, интегрировать свои наработки по турингу в шаблон. И вот то, что у меня получилось, я сегодня хочу показать.
Я так понимаю, что вот эту картинку, наверное, видели не только лишь все. Поэтому прежде чем начать, давайте тоже спросим, потому что я иначе могу предполагать, что вы все это уже знаете, назвать какие-то термины, а вы их не знаете и, э, и может быть непонятно. Напишите, пожалуйста, в чатике из того, что вы здесь видите в плане ключевиков, ключевых слов, а в процентах там примерно какой процент этих ключевиков вам знаком? Ну там где ноль - это вообще какая-то дичь, которую никогда не видел. 100 - это понятно. Я всегда вот использую все эти слова знаю. 100% у нас есть. Великолепно. 99 40 50 10. Ну, довольно довольно разны результат 80, в общем, от 10 до 100. Давайте я тогда буду комментировать. А, то есть это м довольно такие устоявшиеся, в общем-то, штуки в индустрии, но не все их могут знать. Соответственно, я буду давать небольшие комментарии.
Э, что мы сегодня будем делать? Я, в общем, думал, как лучше, э, подойти к к этой задаче, сделать весело или сделать более подробно и останавливаться на деталях. Я решил, что надо делать весело. Поэтому мы возьмём вот эту задачу по проектированию аналитической платформы и попросим мм попросим лмки спроектировать всё за нас. То есть я буду вызывать протеtain, ll будет что-то писать. И большой дисклеймер, я не делаю это в работе. Я никогда не принимаю то, что мне говорит LM без без редактирования. И я никогда не даю такие промты, типа, дорогая М, пожалуйста, за меня всё спроектируйте. Обычно я пишу какой-то пром, где я не уверен и в промте написано много моих ассампшенов. Но так как если бы мы делали в таком формате, то было бы скучно и невесело, я решил именно для этого мероприятия поменять формат. И мы попросим LLM спроектировать всю эту систему.
Я не буду, а что лектор ничего не показывает. Вы не видите сейчас аналитическую платформу? ЛТо пишет: "Правильно ли я понимаю, что лектор ничего не показывает? Неправильно. Я шарю экран. А должно быть, да, должно быть видно. То есть я попрошу вот по этому брифу всё спроектировать лэмку, и мы посмотрим, насколько хороший результат получился, хороший или плохой. Соответственно, в работе делать так не надо. То есть поинт здесь какой, что можно ламки делегировать всякую рутину, но тот аутпут, который она даёт, надо всё-таки проверять и надо прикладывать голову. То есть copilot правильно называется. Copilot - это второй пилот. Это штука, которая, ну, вам помогает. Соответственно, не говорите тоже по том, что Максим вам сказал, что можно всё делегировать, всё будет хорошо. Нет, это хороший тул, который помогает, но не решает за вас. То, что я сейчас буду принимать, всё, что LLM мне скажет делать, нужно для того, чтобы а уложиться в полтора часа, б для того, чтобы это было как-то повеселее. И, соответственно, если тот результат, который LM нас полностью спроектирует без редактуры, если он нас устроит, то значит с редактурой это будет ещё лучше. То есть идея понятна, да? Сейчас мы берём эту задачу и целиком делаем полную архитектурную документацию и и диаграммы. То есть у нас на выходе получается SID Solution Architecture Document. То есть если этот термин не слышали, но, наверное, слышали термин дизайн документ, да? То есть когда какая-то фича делается, если это большая фича, то команда делает документ, описывает, как дизайн будет выглядеть, отправляет ревю кому-нибудь, если есть какой-то архитектурный комитет. турный комитет смотрит, говорит, получится, не получится. Если всех всё устраивает, то говорят, что да, о'кей, делаем так. Ну, и, соответственно, начинаем делать. Вот SID - это такая же штука, но не на фичу, а на целый solution.
Ну что, идея понятна, что мы будем делать. Напишите тогда, пожалуйста, что понятно или непонятно. А, да, тут может быть геолокация. Да, Андрей. Да, если кому-то удобно голосом, я за то, чтобы мы разговаривали, а не только один я вещал. Соответственно, просто, если у кого-то есть, вы поднимаете руку, размьючиваете и спрашиваете. А, сорвался только иконку нажал. Понятно. О'кей. Одному человеку понятно, Сергею понятно, всё, остальным непонятно. Если не понятно, что им непонятно, скажите, пожалуйста. Я буду смотреть, пока кто-нибудь не ответит. буду до вас докапываться. Понятно? Так, ну о'кей, хорошо.
Давайте, раз понятно, а успели все прочитать раздел requirement, давайте озвучу. То есть у нас есть аналитическая платформа, которая это система, которая, э, трекает ивенты с разных веб-сайтов, страницы, клики, э, просмотры страниц, нажатие на клики. Мы должны тоже трекать количество посетителей, количество уникальных посетителей. И мы должны иметь возможность посмотреть отчёты в разрезе по часам, дням, неделям, месяцам и так далее. Итим тегом и с точки зрения нефункци нефункциональных требований. Здесь вот у нас цели по качеству, но в общем-то это одно и то же. А нам надо уметь строить репорты и чарты за полторы секунды край. Система должна обрабатывать примерно 100 млрд событий в день. Допустимые допустима задержка в 50-100 минут для показа для показа статистики, и данные должны храниться для анализа условно вечно. Понятны ли требования? О'кей.
А как вы думаете, можете ли привести какие-то аналоги таких систем? Знаете ли вы аналогичные системы, может быть, пользовались Google Analytics? Отлично. Да, очень похоже. Только у Google Analytics будет больше, чем 100 млрд э-э событий. Довольно сильно больше. Ещё какие-нибудь системы знаете, которые похожи на эту систему? IV Pro. О'кей. Ещё варианты. Аметрика. О'кей. Да, аналитические системы. Никто не называет Яндексметрику тоже, но, в общем, Яндекс-метрика тоже такая же система в рунете, а, которая этим занимается.
Как бы вы подходили к проектированию системы, что надо сделать в первую очередь? Давайте, ребят, подключаемся. Я писал, что workшо, это значит, вы тоже работаете, а не только я. Что делаем? Сначала вам нужно пообщаться со стейкхолдерами. Так, о'кей. Стейкхолдеров нету больше. Они нам рассказали вот только это. Следующий шаг какой наш? Тогда нужно, чтобы они сгенерировали, чтобы она сгенерировала общение со стейкхолдерами. Потому что этой информации однозначно недостаточно, чтобы что-то сделать. Нужно контекст нарисовать. Контекст. О'кей. Я согласен, что с тем, что надо собрать больше требований. Давайте, чтобы просто здесь не останавливаться, попробуем всё-таки под эту задачу воспринять как задачу по систем-дизайну. То есть нет у нас эти з стейкхолдеров, и мы должны работать с теми ограничениями, которые есть. Обычно, если мы решаем задачку по систем-дизайну, то первый шаг - это действительно уточнить требования. Но здесь требований, в общем-то, достаточно для того, чтобы сделать в первом приближении, ну, нашу первую версию документа. А дальше нам нам надо сделать то, что называется back of the envelop calculations, чтобы понять, а где у нас проблематичные места, да, где у нас технические риски. И здесь начинается общение с ЛМ, то есть те, кто делают сейчас, давайте я открою новую новый TП. Здесь это Jet Brain Rider и DE, прошу прощения, идея подобная DE. То есть, если у вас идея, у вас должно выглядеть тоже примерно так же. Если у вас VS Code, тут тоже будет выглядеть похожим образом. Вам главное, что здесь выбрать? Агентный режим. И я буду использовать Clet 4. Она показала в тестах наибольше наилучшее сочетание между качеством надаваемого решения и тем временем, которое она думает. То есть у меня получилось, что GPT41 отвечал хуже, а GPT5 отвечал примерно так же на более многословно, тратил на это много времени, а с не с несколькими из шагов он не смог справиться. Вот. А, соответственно, что я делаю обычно я обычно считаю, а-а, считаю, сколько, а-а, ну, провожу back of the calculations и смотрю, где у меня риски. Здесь есть сейчас вот такая вот партянка из промтов, которые я уже подготовил. То есть, соответственно, те, кто тоже будут делать, а, на вот этой страничке с копайлота, вы можете зайти, сейчас скину ссылку. Вот сюда. И здесь список этих пронтов есть. Давайте я его добавляю в наш документ. Вот. Ну, возвращаюсь к вдшечку. Вот у нас первый промт называется вытащить необходимое значение для back of the calculation. Это у нас секция в адрке, потому что в архитектурной документации нет хорошего раздела для этого. Поэтому я решил, что мы можем использовать для этого архитектурный лок архитектурных решений. Я тайпаю здесь 100 вытащить номера. Нажимаю на поехали. И сейчас будет вызван Prompt из - папки GitHub Prompts. Вот этот вот. И вот там в промте уже написано, что нам нужно посмотреть на на секцию Introduction and goals. Вот, собственно, агент её нашёл. Надо посмотреть на quality requirements, которые пустые на данный момент, потому что, может быть, там что-то уже записали, и попробовать посчитать. Вот она у нас сейчас размышляет, что надо делать. Читает адры и всё остальное. В чате до этого были вопросы о том, какие промты написаны и так далее, и так далее. Давайте, пока она размышляет, а, не успели. То есть, если она будет долго размышлять, я буду переключаться и показывать, что там. Вот у нас сгенерировался первый первый ADR. Я захожу, смотрю, всё ли получилось, как я хотел. Заходим сюда. То есть первое вот у нас есть решение - это то, что мы вообще ведём в окрутурно решений. Второе решение - это выписать просто выписать просто те, э, те данные, которые нам кажется важны из брифа. 100 млн событий, да, важно. Время ответа репорта, да, важно. А ограничение на запрос, да, data injection, э, потенциальная задержка здесь, да. И дальше она вот додумалась, что ещё количество пользователей может быть важное, пиковый трафик, дальше количество ивентов для каждого визитора, соотношение, средняя средний размер ивента. Ну, в общем-то, меня это устраивает. Я, как обещал, я не буду сильно докапываться ламки, не буду редактировать, хотя в реальности я бы это делал. Я только попрошу ещё, давай ты сделай, пожалуйста, какие-нибудь reasonable assumptions. Assumptions about the TBD values. Я не хочу их сам вводить. Может быть, в реальности я бы их вёл сам, но здесь делегировано тоже LM. Пусть она сама заполнит. То есть вот эти вот штуки, пусть она тоже их придумает сама. Придумала. 3x для пиковых значений 10.000 конкурентных пользователей, наверное, маловато, но зависит от того, каких она имеет в виду. Если аналитики, то может это и правильно. Количество ивенто в сессию 2 кб Jonad. А вот это неправильно, скорее всего. Я думаю, что в аналитической системе это будет rightх heavy. [музыка] С это я всё-таки исправлю. и плюс LA. Всё-таки важная важная штука. Давайте я исправлю. Ну, потому что понятно, если у нас такое огромное количество ивентов, то здесь будет очень много записей, а при этом аналитики будут сравнительно мало делать запросов, но эти запросы будут тяжёлые. О'кей, меня в принципе устраивает, поэтому я готов двигаться дальше.
И здесь у нас есть развилка. Вообще, по идее, нужно, э, дальше сделать нормальные расчёты. И у меня здесь есть два пронта, которые могли бы это сделать. Первый пронт - это сгенерировать. Он здесь называется 110а. Аэ, посчитать back of the noop calculations и второе 110B переде конвертировать из CSV в MD. Я сразу скажу, что первый пронт, который из А, нормально не работает. То есть я пытался его дописать так, чтобы он нормально мог считать сам. Здесь плохие результаты. То есть он чего-то считает, но считает плохо. Даже когда я ему подключил MTP сервер с калькулятором, он много ошибается. Что Set, что GPT5, то есть я не получил хороших результатов, поэтому мы не будем пользоваться этим расчётом. И в принципе я этот шаг никому не не рекомендую. делегировать лмки. Вместо этого я сейчас возьму уже сделанные вычисления мною, добавлю их тоже в табличку. Вот ссылка с вычислениями. Я добавляю сюда, который делает вместе со мной. И здесь у меня уже всё посчитано. Что делаем дальше? Делаем дай мне, пожалуйста, это в виде CSV. сохранили. Ну, я выгрузил ещё свои расчёты по по размеру статистики в прошлый раз, когда тестировал. Я сейчас возьму только вообще расчёты, не буду даже статистику трогать. И что нам осталось? Нам осталось эти мои расчёты собственные, которые я предварительно сделал, добавить сюда. Добавляю. XT попал. Вот теперь попал. И пишу, давай мы пойдём по сценарию B, то есть с конвертации, с конвертации CSвишки. Добавляю эту CS-фишку, которую хочу сконвертировать в контекст, и говорю: "Сделай, пожалуйста, за меня". А очень не хочу я этой своей конверсией заниматься. Так, сдаюсь, смотрю. Так, ссылка на Google Doc. Давайте я ещё раз дам ссылку на Google Doc. Видимо, люди не получают апдейты, когда соединяются чуть позже. Вот ссылочка на Google Doc. Может подумать, какая БД или альтернативные решение будут хранить. Да, это тоже прямо хорошая очень мысль. Мы сейчас очень скоро до этого дойдём. Так, тот ли промт я вызвал? А давайте посмотрим. Сорян, я вызвал неправильный промт. Я вызвал промт с расчётами. И видите, вот он пошёл вызывать MCP сервер с калькулятором. Это будет долго всё происходить. Он посчитает неправильно. Я поэтому сейчас отменю. Я случайно прожал не тот промт. Вот. Да, давайте я ещё раз зайду и прожму правильный промт. Это B. Мне нужен CSV. Я его выбираю. Я нажал случайно на на тот пронт, который я вам сказал, что он нерабочий. Вот. Э, калькуляция у нас здесь. И конвертируем про пронты сбрасывали. Пронты все лежат вот здесь. И это сравнительно новая фича купайла, то, что можно все промты написать и потом их просто через слш вызывать. Собственно, я этой фичой пользуюсь, чтобы промты не писать. Если вы зайдёте, посмотрите, какие там промты написаны, вы поймёте, почему я их не хочу писать руками. Итак, смотрим, смогла она сконвертировать. Заходим и переходим в заново ВДРК. Смотрим, что она нам насчитала. Ну, насчитать она должна, в принципе, только то, что уже было в документе. Проверяем, всё ли правильно получилось. 16 209 1723, а, 162 2373. Да, правильно. Количество юзеров 100.000 146.000. Ну, давайте я даже скопирую так, чтобы проще было проверить. Тун-тун-тун-тун-тун. Всё правильно, ничего не придумала. А, и подсветку. Ну, видите, она немножко по-другому подсветила, потому что там у неё в инструкциях тоже написано. То есть она считает, что Ritterp здесь, ну, ничего страшного, зелёненький такой. Я думаю, что он всё-таки немножко страшный, несмотря на то, что здесь маленькие значения по по readрпису. Это тяжёлые аналитический запросы. Поэтому я всё-таки посчитал, что это что это жёлтая штука. Она посчитала, что зелёная, остальное а и да и количество данных тоже она считает, что это ничего страшного. Я думаю, что это страшное, но в целом не очень большая проблема, да? То есть это именно подсветка проблемных мест. Давайте я сделаю тоже одно исключение и подсвечу, что всё-таки, ну, типа хранить терабайты данных, но, по крайней мере, это жёлтенькая штука, на которую надо обращать внимание, потому что на одном сервере 16 ТБ мы хранить, наверное, не будем. То есть это предполагает кластеризацию, поэтому подсвечу вот так. Пока есть у кого-то возражения с теми расчётами, которые мы делаем, не с теми результатами, которые получаются, или всё у нас правильно выходит? Напишите в чатике, а я пока продолжу. Если вдруг кто-то думает, что фигню мы делаем.
Так, а следующий этап - это составление Utility 3, да? Utility 3 - это более полное описание тех вот qualitys, которые у нас есть а в ARC 42. раздел, он разделён на quality 3 и на quality scenarius. Это немножко многословно, но я буду придерживаться формата ars 2, поэтому сделаем ровно так, как 2 это хочет. То есть мы должны на основе того, что мы посчитали, на основе нашей цели по качеству написать более, а, более детально, какие у нас есть нефункциональные требования. И этим мы сейчас и займёмся. Мы говорим: "Знаешь что? Пожалуйста, requirements нам нужен, и я перейду. Скорее всего, она поймёт, какой файл нужен, но я обычно сам перехожу, ну, чтобы исключить всякие там тупники, которые у ламок бывают. Qual it requirements, поехали. То есть этот промт, он говорит следующее: посмотри на террорки, которые у нас есть. Посмотри на на бf, посмотри на quality и и сделай из этого qualityт в табличном формате и распиши сценарии в формате save Soft Engнинг института. Он имеет там определённый формат, э, он немножко душный. Если вам он не нравится, вы можете отредактировать пронты и написать тот формат utilти 3, который, э, который вам нужен. Так, Дмитрий спрашивает, где промты? Он есть. Всё есть в э в папке в, прошу прощения, в ветке, которая называется copilot. Давайте я ещё раз обращу внимание, что здесь вот у нас есть ссылочки. Вот у нас copilot, вот у нас есть ссылка на на аналитическую платформу. Да, всё там есть. Вот он сейчас думает, но надо quality requirements. Опять-таки, видите, я всё принимаю, да, особо даже не читаю, что он принял, и захожу потом смотреть, что получилось. Так, я немножко смотрю на чат. О'кей. Да, пронты, если вы вы склалонируете, зайдёте в Kinghub, вот пронты, вот они все лежат. Я их, собственно, через слэш и вызываю последовательно.
Получилась вот такая большая табличка. То есть он здесь ещё добавил, а он совместил данные, которые мы рассчитали на этапе back of the envelope calculations, quality goals, которые у нас были, как некоторые requirements, и сделал некоторые относительно того, что ещё может быть важным. То есть, например, он добавил здесь требования по secкity стопроцентный GDPR, CCPA compliance, например. Я думаю, что да, действительно надо, потому что мы собираем персональные данные. Дальше, что у нас должен быть? Ээ должна быть ролевая модель. Ээ добавил про Durability, про RPO, РТО как какие-то значения. Вообще довольно неплохие значения. А, кстати, посмотрел в нашу таблицу, э, за на 5 лет, увидел, что у нас там, э, какие у нас значения на горизонте 5 лет, сказал, что нам тут горизонтальное эскалирование нужно будет. В общем, меня устраивает. Вот эти сценарии - это то же самое, что мы видим в таблице, но расписанно в более подробном формате. Я обычно так не делаю сам. Я обычно совмещаю просто а крите, то есть я пользуюсь только таблицей, которая здесь, и может быть немножко больше пишу в критериях. То есть главное, чтобы они были измеримые. Но для примера, если есть те, кому очень важно писать сценарии именно в формате, как это предлагается в ARK 42, здесь проектировано именно так. Я опять-таки ничего не редактирую, я двигаюсь дальше.
То есть у нас есть quality goals, да? Э, соответственно, мы ровно двигаемся по вот этому рисунку. То есть вот наш quality и requirements. Вот наш utility 3, который мы построили. Они нам нужны будут здесь, чтобы дальше начать, собственно, проектировать архитектуру, пользуясь методом ADD3.0. Те, кто не знает, что это за метод, это просто, но для проектирования. Мы будем брать из этого из Quity 3 какие-то требования. Мы будем брать функциональные требования, ставить некоторую цель на итерацию, допустим, закрыть два или три или три требования из таблицы, проектировать часть системы и заходить на следующий виток итерации и повторять так, пока у нас не кончатся требования. После чего мы посмотрим, все ли требования у нас закрыты. Если все требования закрыты, значит, мы молодцы, архитектура у нас хорошая. Ну, там дальше можно будет подумать о том, насколько она эффективна по деньгам, но в целом с задачей мы справились. Если у нас требования какие-то не закрыты остались, значит, мы с задачей ещё не справились. Смотрим дальше.
То есть, э, если у нас что-то ещё есть, есть у нас ещё раздел про технические риски. Довольно часто его требуют формально запомнить, поэтому прожимаем прот на заполнение технических рисков тоже и смотрим, что у нас получится. Последности запуска промтов, да, имеет значение. Они не просто так пронумерованы. Здесь, э, смотрите, 100, 110, 120, 200 и так далее. Надо вызывать именно в порядке нумерации, потому что мы на каждом этапе, ну, во-первых, это логически так надо проектировать, то есть если вы не строите дом с крыши, правильно? А, а, во-вторых, на каждом следующем этапе мы частично пользуемся результатами, которые были созданы на предыдущем этапе. Соответственно, если вы начнёте там с пятого промта выполнять, то у вас не будет Коль 3, например, а без Кольс 3 вы не сможете приступить к проектированию, поэтому надо выполнять в порядке. Смотрим, что у нас написал по рискам. Переходим к рискам. О'кей. Реестр рисков, ID рисков. Те, э, те требования, которые связаны с этим риском. Описание самого риска, импаct, mitigation, триггеры, а, вероятность возникновения риска. Давайте выборочно
почитаем. А, риск про то, что мы не сможем это огромное количество ивентов в секунду вставлять. Риск согласен. Как будем митировать? Нам нужен какой-то стриминг и горизонтальное протеонирование. Асинхронный процесс. Согласен.
Аэ, так. Э система может развалиться на пиковых значениях. То есть взяли вот эти 1.16 ээ ивентов в секунду, умножили на три, действительно может развалиться. Как бы как будем справляться? Нужен какой-то автолин circuit breaker. А-а, так.
Да, в принципе, согласен. Дальше риск о том, что не сможем мы за полторы секунды ответить на тяжёлых запросах по агрегации. Это у нас тоже про перфоманс. Согласен. Как будем интигировать? Э- пригрегация, использования колоночного колоночной базы данных, кеширование запросов.
Слушайте, ну я согласен, в принципе, надо прочитать всё и посмотреть, но первые три мне показались разумными. Здесь, может быть, по ну какая-то редактура требуется, но в целом я всё оставлю и не буду дальше мучить ланку. Поеду дальше. Меня устраивает. Едем дальше.
Я пропускаю 220 coverage review. Сейчас он нам, прошу прощения, я не на то посмотрел. Да, это нам потом потребуется. Я ничего не пропускаю. Сорян. А мы, значит, закончили с требованиями. То есть вот эту часть мы выполнили и, собственно, переходим сейчас к самому проектированию. А давайте составим план вообще. То есть вот имеете требования, которые есть, нам нужен план итерации, что мы будем в итерации один проектировать, что будем в итерации два проектировать и в итерации три. Вот промт двухсотый D iteration plan. Он отвечает ровно за это.
Я снова возвращаюсь в наширки, говорю: "Слушай, я не умею проектировать, пожалуйста, давай сама составь план. Я пока чатик почитаю".
Так, откуда у меня структурайзер? Есть ли он в личном доступе и заполняется ли он вручную или автоматически? Структурайзер у меня от сайта Structurйer. То есть, если мы пойдём и на strctturizer.com, мы увидим, что есть такой инструмент. Тот, та версия структурайзеer, которую я использую, называется Structurйer Lite. Она лежит в докер контейнере и доступна по, я не помню, какая там лицензия, но, в общем, она примиссиive, да. Также у него есть вариант вот cloudдный есть вариант использовать его из Cli. Это пул, э, который сам для себя сделал Самон Браун, который, собственно, и придумал модель C4.
Смотрим, что нам LLM советует. А советует она проектировать следующим образом, что сначала в первую итерацию нам нужно Дайте открою это лучше браузере, так будет виднее. Так, что-то я не я А я не принял. Да, принимаем. Да, я не смогу это посмотреть в браузере. Это не ADR, поэтому я вот так просто открою, чтобы было виднее.
Какие у нас itтеation цели на итерации? Сначала, как мы будем, собственно, наши события писать в базу данных. Я считаю, отличная цель на первую итерацию. Полностью согласен. Можно с этого начинать. Я бы сам начинал бы либо с этого, либо с выбора базы данных для, ну, ну, потому что нам надо очень много. Есть два риска, что мы не справимся с нагрузкой по записи или что та база данных, которую мы выберем, она будет неоптимальна с точки чтения. Я думаю, что можно начинать либо с выбора базы данных, либо с механизма записи в эту базу данных, либо брать оба этих решения в первую отерацию. Поэтому, о'кей, меня устраивает.
Дальше itation 2, а кеширование и э производительность запросов. Я думаю, что на этом этапе нам придётся выбрать выбрать базу данных, потому что вот он здесь уже сказал, что у нас есть кандидаты в тактике, да, и пишет про колоночное хранилище. Поэтому, ну, вот, как я говорил, я бы начинал либо с первого, либо со второго, поэтому это последность меня устраивает.
Дальше High Vability Disaster Recovery. Ну да, почему нет? Э, дальше Pipeline, э, процессинга данных. Я бы, может, поменял местами, потому что как будто бы, ну, логичней, если мы поговорили про ставку данных и про базу данных, как будто бы пайeline процессинга данных он должен быть номер три, ээ, а потом думать про highability и дальше security and compliance, но это явно по рискам менее рискованная штука, поэтому, да, меня это устраивает. Единственное, давайте я небольшое изменение тоже внесу. Я, конечно, обещал ничего не менять, но чуть-чуть поменяем, просто последительно с местами.
И дальше идём и говорим: "Хорошо, нас, в принципе, это устраивает. Давай, дорогой друг, тогда заходим на первую итерацию. Вот я здесь запиню полон итерации, чтобы мне было поудобней". Э так запинил. берём итерацию и говорим: "Давай add iteration, это пром 210". И цель у нас вот такая вот, как ты и, собственно, предлагаешь. Ничего не будем в этом плане менять. План отерации у тебя есть в контексте. Мы сейчас на третьем адаре. Да, поехали.
Структура. Вот мы, собственно, Яна спрашивает, э, мы сейчас заполняем. То есть райер - это тул, который визуализирует три штуки. Первое - это, а, диаграммы в формате C4. Мы их скоро нарисуем. А они из кода генерируются из ДСля. Это, аэ, архитектурные решения, вот лок архитектурных решений. И это проектная документация либо в формате MD, либо в формате ASKIDOG. В данном случае это skскидок, потому что, э, потому что Arc 42, которую я выбрал, она идёт в формате asкидок, но вы можете заменить этот формат на другой.
Так, смотрим, она у нас сгенерировала. И посмотрим, что она у нас сгенерировала. Так, значит, контекст надо нам выбрать, э, стриминг-платформу. И выбираем мы и скавки Кинезиса, Пульсара, Google Папсаба и Ажур Иванхаба. Ну то есть он такой, в принципе, подумал: "Ты мне не сказал, используем ли мы Cloud Solutions или не используем. Поэтому я тут засунул, и Google Popsup, ижор." В принципе, если бы мы ему подсказали, какой у нас cloud целевой в констренте, например, указали, тогда бы мы немножко по-другому видели эту табличку. Он понял, что что, ну, если бы мы явно сказали, что протизируй э cloud natтив решения определённого облака, здесь мы не сказали, и он выбрал кавку, да? Почему? Потому что кавка имеет хорошую пропускную способность на запись. И дальше вот у нас подсвечено, что по всем тем, э, критериям, которые нам важны, как будто бы которые мы определяли на прочих шагах, Кавка себя хорошо ведёт. Кинезис он не выбрал, видимо, из-за эффективности по стоимости. А пульсар, давайте посмотрим, почему он не выбрал пульсар. Чёрт его знает, почему он не выбрал пульсар, он не объяснил. Давайте спросим [музыка] selectр интересно, он захочет редактировать или нет? Я надеюсь, что он просто скажет. Да, дорогой друг, отличный вопрос. Да, так очень хорошо. Вот пульсар. Почему кавка из экосистемы и более сложная архитектура? Но здесь он не не показал более сложную архитектуру, да, он просто из-за экосистемы, но вообще как бы здесь есть проблемка, да? То есть здесь бы надо было тогда жёлтеньком отметить. Ну давайте ему подскажем, если третья колонка с это справа. Третья колонка справа. Да-дада. А, operation complexity здесь есть. Да, слушай, я зря на него, да, поклёп, да? Ой, комплекс архитек. Дада. Да, всё правильно. Слушай, он просто здесь ушла таблица. Я, э, короче, не обратил внимания на вот эту штуку. Давайте здесь немножко остановимся. Вообще, как вам вот это вот это решение? Всё о'кей или вы бы решили по-другому? Напишите просто вот, ну, типа, кто не согласен, напишите, есть такие или А мы пока зайдём на второй раунд. Просто интересно, будут ли несогласные. А, Бакс, такой вопрос. А если вот, э-э, ну, это же получается как бы пайплайновая такая обработка, где ты шаг за шагом всё делаешь. А если вот вынести, например, какие-то параметры, вот, к примеру, там выбор архитектуры, там выбирает там чисто on premies там или ещё что-то, вот как в конфигурацию и биндить это кромтаб, можешь из рубря там ставить плейсхолдеры в тром и левелы ты настроил. Да, да, это у меня как раз туду. Мы, конечно, сейчас дойдём до конца, я покажу, что у меня в ту был, и там это будет, да. Но видишь, типа программисты одинаково должен как бы что-нибудь автоматизировать. О'кей. File settings, повесло. Дада. Да, всё. Так. А так я говорю: "О'кей, меня устраивает, поехали дальше. Давай следующий твой, э, твоё решение, которое ты хочешь принять, давай его примем. Я пока он думает, я не знаю, там кто-то уже посмотрел, например, промты выглядят примерно вот так. Здесь большие каждый промт - это довольно большая простыня. Так, сейчас минутку. Он думает? Да, думает. Всё хорошо. Это довольно большая простыня. Ага, Александр. Или тоже случайно? М. поднял руку. О'кей, будем считать случайным. Э смотрим, принимаем это решение и смотрим, что он решил. Я извиняюсь, меня теперь слышно? Да, слышно. Э, хотелось бы услышать, если можно, про именно формат промпток, почему они так написаны. То есть там какие-то теги есть, как будто бы, да, может быть, какие-то там переменные используются. И да, смотри, я чтобы точно успеть, я это буду говорить в конце. Если очень хочется посмотреть, то вот по ссылки здесь есть промт инжиниринг и как раз на что я опирался, когда делал эти промты. Угу. Спасибо.
Поехали э дальше. Да, я сорри, что быстро иду. Я просто засекал время, когда когда делал репетиции этой штуки, и она такая нагруженная по времени, но можем не успеть. Смотрим, что он говорит. Кликахаус надо выбирать аналитики. Но здесь читинг, конечно, у него понятно, что нейронные сетки там частотность кликхауса на запроса по аналитике, она очень большая. И, конечно, он выберет кликхаус. Но с другой-то стороны нам-то какая разница, как он к этому решению пришёл, если оно правильное. То есть А почему оно правильная? Да потому что мы знаем, что Яндексметрика сделана на Кликхаусе. И по секрету 100 млрд - это это данные с хайлоуда. 100 млрд ивентов в сутки - это данные с хайлоуда несколько лет назад, сколько настоящего трафика Яндексметрики. То есть мы можем сказать, что раз существует такая система, которая использует клиckхаус и для которой специально написали клиckхаус и она держит 100 млрд ивентов, ну будет у нас Кликхаус тоже держать 100 млрд ивентов, потому что, ну, а почему нет, если есть другая система с ровно такими же требованиями? И 100 млрд. Я выбрал как раз здесь цифру специально, чтобы мы могли убедиться в правильности этого решения. Давайте посмотрим, что он ещё рассмотрел. Apachд Druid тоже колоночное решение из того же класса. Amazon Red Shift тоже, а Big Query, соответственно, Big Query используется в Google Analytics тоже правильно, и Snowflake, а, в общем-то, тоже хороший кандидат, но это немножко более там, мм, скажем так, менее специализированное решение, да? То есть, если клик patch druid - это как раз колоночная база данных для realtime аналитики. Snowflake там часто в date анализе ещё используется, то есть он там много чего другого умеет, и он типа только облачный, соответственно, мм, ну, есть другие критерии, по которым нас SNFlake мог бы не устроить. В общем-то, говорит, кхаус надо использовать. Я готов согласиться, почему нет. Поэтому едем дальше. Это меня устраивает.
Турум-пурум-пурум. Берём и просим его спроектировать pipeline add itteration снова. То есть вот мы как раз крутимся в цикле нашего скрама архитектурного и движемся, пока наши все требования не будут учтены. как он приоритизирует стопцин. То есть, видимо, вопрос про о том, как находится как он выбирает столпти здесь и вот эта подкраска, как здесь используется. Если вы зайдёте в пронты и посмотрите, что там написано, сейчас я пока приму. Вот как раз про adderation. А нет, это ой, сорян. Вот здесь, то есть здесь я ему сказал, что я очень хочу, чтобы ты использовал рейтинг в виде эмоджи. Я задал ему, э, то, э, какой эмоджи соответствует чему. И дальше я ему сказал, что смотри, вот ещё я очень хочу, чтобы ты вставлял сюда релевантные требования в виде колонок. И вот тебе пример, что для выбора базы данных, например, вот выбор может выглядеть вот так. И что вот отвечай, пожалуйста, так. То есть я сначала, когда когда использовал нейронки, я просто задавал открытые промты, и он мне, к сожалению, отвечал в разном формате. Меня это не всегда устраивало. И дальше довольно много времени я убил на то, чтобы ээ написать такие пронты, которые выдавали бы довольно довольно прогнозируемый результат.
Вот здесь вот он решил, что надо использовать флинк. И иногда он хочет использовать флинк, иногда не хочет. Иногда он хочет использовать какастм для этого. Э, вообще это скорее всего неправильное решение, потому что если мы пойдём и сделаем вот такой запрос и каускавка, то он мог бы посмотреть. На самом деле здесь есть три рекомендованных решения. Click pipes, если это, если это cloud, click house connect syn, то есть это кавка connect и к нему подвязан S для кликхауса или кавка Table Engine. Кака нам сразу не подойдёт, потому что она скалируется только с инстансами кликхауса в кластере, а хотелось бы иметь возможность сколировать отдельно. Поэтому здесь выбор между клик Pipeson и CCK connectм либо кастонным слоем, который, в принципе, будет очень похож на кавка Connect. Соответственно, более правильное и стабильное решение здесь было бы всё-таки использовать использовать капка connectк, потому что он хоть как-то работает. А у Флинка коннектор ксу есть только не официально это комьюнити. Ну, соответственно, в продакш такое тащить, это такое себе, но я обещал с ним не спорить. Хочешь флинк? У Флинка просто тоже большой вес, потому что много про него пишут, поэтому он так решает. Я не буду с ним спорить. кто я такой, чтобы спорить с ЛМ, поэтому, ну, хочешь флинк, делай флинк, но я не согласен. Окей, хорошо, поехали дальше. Давай ещё раз. Нам осталось две итерации всего. Итерация add. Поехали. Провелабиabilль расскажи, пожалуйста. Ну да, флинка-то больше, чем коннектор. Я просто объяснил, почему. Ну, почему с линком будет больше геморрой на мой вкус? Но можем подискутировать на эту тему. Не, ну если там коннектор нужен, то там очевидно, что флинк не нужен. Flink - это всё-таки real time processing stateful. Там, если нужно просто Да, да, да, да. Но видишь, он падает просто в эту в эту вероятность, потому что типа вот флинкм же можно это сделать, как бы, но в Париж через Мамадыш очень неудобно, но можно. И я так понимаю, что он туда падает, потому что просто есть какие-то ключевики про стримпроцессинг у Флинка, и он туда заваливается. Короче, так вот это происходит, наверное. Где-то он сбился, короче, с А, слушай, То есть он, видимо, из-за того, что я переносил переносил план итерации, он, видишь, сбился в нумерации. У меня такого не было, когда я тестировал. Но, в общем-то, небольшая проблема. Я готов это руками по поправить. Давайте посмотрим, что он сказал про Multi. Значит, active active, Multiion, Active Passive, Hot Sty, call standby. Ну, ключевики правильные, да? То есть здесь надо, конечно, всё читать, что он там решил. Active passive with hot standby. Я не очень уверен насчёт этого, если честно. Здесь надо разбираться, что он имел в виду, особенно с учётом, что мы здесь уже клик засунули. как этот кластер будет выглядеть. Я думаю, что здесь он, ну, что-то начал воображать, и это тот этап, где нужно было бы подумать самому, больше его попромтить и ээ либо самому просто написать. Да, тоже, кстати, хороший вариант. Но мы здесь завязнем, если мы будем а если мы будем редактировать. И это не выглядит совсем уж плохо, да? Это выглядит так, как будто бы кто-то написал умных слов, не очень сильно понимая их значение, но разработчики так тоже делают. Поэтому давайте простим ЛМК это прегрешение тоже и просто позволим ей э- доделать всё, как она хотела. Кстати, да, Вагив правильно пишет про редко тестируемые установки. А естьation для этого у меня, но я ещё не успел сделать. Там довольно большая работа нужна, чтобы это исправить. Я в конце коснусь немного.
В общем, что-то он придумал про data Privaя, про GDPR и всё остальное. Мне кажется, вообще пофиг на GDPR в рамках нашего занятия. То есть, э, так-то не пофиг, конечно, и здорово, что он всё это написал, но я просто не хочу на этом останавливаться, потому что вот с точки зрения задач у нас голос даже не было ничего особенно про GDPR. Ну, это отдельная тема, которая понятно, что надо делать. Давайте просто пропустим и, ну, поверим, потому что опять-таки, ну, типа ключевики правильные, что там в деталях, не знаю, может, и неправильно. То есть у меня всё-таки цель показать, как мы от начала до конца пройдём. И я сразу сделал дисклеймер, что то, что я сейчас делаю, да, нельзя это выполнять дома. Выполнено профессионалами. Дома надо читать то, что ЛНКА предлагает, и думать своей головой. А пойдёмте вместо этого лучше в заново в Quality requirements и её спросим: "Дорогой друг, а всё ли мы учли, скажи, пожалуйста, в нашем, а, в наших ээ э в нашем, в наших решениях, а то может мы Ух ты! Ух ты! Интересно, зачем он создал вторую? Интересно. какой-то глюк. Так, и попросим его сделать нам матрицу по кавржу. Все ли решения у нас правильные? А все достаточное решение мы приняли для того, чтобы удовлетворить всё, что у нас здесь написано в нашем Cols 3. Говорит: "Сейчас посмотрю, прочитаю, что ты там в ВДР написал". Читает четвёртую, седьмую. В принципе, он прочитать всё, потому что я здесь принудительно все дры засунул в контекст на всякий случай. В принципе, в промте написано, что посмотри на CMD файлы в Адере. Чаще всего он смотрит, иногда отказывается он. Ну, соответственно, если не получилось сделать так, чтобы он сам посмотрел, самый простой способ докинуть ему в контекст руками, тогда у него получается.
Сколько операций потребовалось, чтобы выстроить все эти пронты? Ринат, видно, да, что хорошо слишком получается несколько. Да, не с первого раза. Не с первого. Где-то неделю я суммарно сидел, но не фултайм, а по вечерам. Точнее, не могу сказать, потому что ты не вёл таймреки такой. Меня было интересно доделать. Смотрим, да? То есть я его попросил проанализировать вообще свою работу. Мы нам, ну, как бы нормально вообще там, типа нам достаточно или мы что-то забыли. Двигаемся. Смотрим то, что здесь красном. Это нормально. Здесь будут вставлены диаграммы. Попозже их пока нету. Идём в quality requirements. Я его попросил здесь добавить отдельным пунктом TRability. Он добавил и говорит частично, да. А почему? Потому что потому что мы никакие из адеров не приняли. Поэтому он сказал, что в принципе дакрыли в эти требования. Ну вот, кроме последних, э, но частично, потому что эти все адары имеют статус пропост, мы их не приняли. И так, как я вам пообещал, что я буду минимально вмешиваться в то, что нам предлагает lм, и всячески следовать её желаниям, я всё принимаю без редактуры. Молодец. Давай. Всё мне очень нравится. Флинк твой нравится. Вообще всё нравится. Турке но, как говорится.
И заново идём в документы и попросим его ещё раз подумать, а всё ли у нас как бы о'кей с точки зрения каверджа. А так, кажется, правильно запускаем. Она пересматривает все адары сейчас. Ээ нашла, что у нас теперь, э, так или не нашла? Похоже, что не нашла. Или бы я не сохранил. Да, слушайте, это баг, кстати, скорее всего. А я знаю, почему так. Короче, когда закидываешь вот эту штуку в контекст, он её кеширует, поэтому он ничего нам не поменял. Ээ, чтобы сбросить ему кэш, просто перейдём в новый диалог, закинем ара заново в контекст и скажем: "Давай ещё раз посмотрим". Иногда мне прихо приходилось даже идея, к сожалению, перезагружать, потому что я не понимал, где происходит этот кэш. Возможно, это баги в купалте. Ну, опять-таки, наверное, это можно будет, наверное, это будет исправлено в будущих версиях. Сейчас он всё это перечитает. Пока если есть какие-то дополнительные вопросы, тоже вот можно или комментарии можно. Асис вот спрашивал, мы ему сказали, что выбрали. Нет, он сам решил выбрать кликаус. Вот. А сам разобрался. Ну, мы могли попросить его выбрать рукое, да, и тогда бы он дальше по-другому всё генерил, по идее. Да, тут очень важно, на самом деле, если ему добавлять ээ особенно в конец промта. И давайте я пока он, э, пока он думает, ещё покажу по поводу промтов. Тут один из самых важных, э, э, моментов - это преамбула. Тут здесь есть copilot instructions, то есть вот эта штука вставляется в промт самое первое, потом вставляются инструкции уровня уровня файлов. Здесь указано, каким файлом применять. Именя отдельные для дров, отдельные инструкции для документации, отдельная для а DSL отдельная. И вот здесь вот спрашивали, откуда теги появились. Задана задана семантика. То есть я ему сказал: "Знаешь, я буду использовать теги. У меня есть предефайн теги, у них есть вот такая семантика, а ещё есть глобальные теги, которые имеют больший вес. И если ты встречаешь теги с префиксом Global и то делай, пожалуйста, conflict resolution через то, чтобы принимать то, что в Global важнее. Ещё у меня есть плейсходеры, их надо заменять. А ещё у меня что только какой фигни у меня только нету. И всё это, пожалуйста, учитывай. Вот эта вся огромная партянка, партянка отправляется ему. Собственно, если ввести там тег, типа, что решение какое-нибудь уже принято, и сказать ему: "Это имеет самый важный приоритет, что бы ты не думал вообще, принимая такое решение и защищай его". Ну, собственно, вы знаете, что происходит соломо, когда его очень сильно попросить принять то решение, которое, э, которое хочется.
Вот когда я принял, смотрите, та же самая матрица, он посмотрел, сделал ссылки между адарами и и нашими между нашими требованиями, да, quality requirements и теми решениями, которые мы принимали. Показал, что, ты знаешь, да, всё вот принято. Единственное, почему-то он с вот этими решениями не разобрался про О1 и О2 и сказал, что нет у нас weк coverage, мы видим, что вот это у нас не принято. Давайте посмотрим, что такое было О1, О2. Я не помню. Это [музыка] ну не знаю. По идее, он должен был сказать, что вот есть у нас два сценария, которые которые не покрыты никак ничем. Видимо, он решил, что, знаете, мы даже не будем разбирать, потому что это фигня какая-то. Ну то есть здесь можно поправить, но опять-таки в основном справляется. То есть в основном он нормально смотрит и делает трассировку. Надо проверять, но в общем и целом получается у неё.
Так, с требованием мы закончили. То есть у нас теперь остались, ну, сладкое осталось, собственно, нарисовать диаграммы. Я закрываю документацию по этому и иду в модель. Э, сейчас есть только небольшая болванка. У меня вот такая аналитическая платформа, и в ней ничего. Вот всё, один квадратик. Естественно, нам этого недостаточно, мы хотим больше. Я говорю: "Давай мы нарисуем сначала диаграммы самого высокого уровня контекста". Это в сифорт контекст, то есть с высоты птичьего полёта. И Но стоп, извините, я забыл, забыл один важный момент. Сам же написал, блин, порядок вызова промтов и сам же забыл. Мы должны сначала, чтобы нам потом не лазать по всему нашему ару, сказать: "Пожалуйста, сделай мне summary." Всё, всё, что мы приняли в разделе, который называется Solution Strategy. А какой де бесплатно? Яна спрашивает. Я, насколько знаю, у CL есть бесплатная э бесплатный диition. У вас единственное на бесплатном эдиition не будет хороших моделей и на слабых моделях тоже быстро кончатся токены. Поэтому надо покупать копайт платный либо использовать что-то любой другой агентский тул. И нужна подписка, ну, как мне кажется, безлимитная, потому что все лимитные подписки, они очень быстро заканчиваются, токены выжираются, особенно при использовании таких жирных промтов.
Сейчас мы посмотрим, как он сделает самрим. И он должен её положить сюда вот solutionст, которая у нас пустая. Да, вот Ринат пишет, что говорят, даже полезно порой перезапускать чат. Это ровно то, что мы сделали. Вот здесь плюсик открывает новый чат. И я сбросил как раз контекст, чтобы он из кэша своего старые файлы убрал. Смотрим общий подход. Нам нужна распределённая ивент архитектура 1,6 млн пик на 347, да? Значит, GDPR колоночное решение All up for work for work cloud. Согласен. И дальше просто перечисляет, какие у нас есть дры и что мы там решили. Кавку решили решили, клик решили, решили. Кстати, вот в этот момент, в этот раз он что-то не стал думать о том, как холодное хранилище сделать. Не знаю, почему. В предыдущих тестах он, в принципе, думал об этом, что неплохо бы холодное хранилище тоже подумать и предлагал, а, опцию кликхауса, когда он читает с S3, просто чтобы можно было настроить в S3 э правила, по которым холодные данные бы уходили вообще бы в ледник, например, дешёвый. Э здесь он не стал об этом думать. Не знаю, почему, но так решил, хотя я делаю всё то же самое. Мм, ну в целом, ладно, это мы как архитектор должны сами тоже об этом подумать. Deploломент и операции. Автоматический security compliance. Ну, в принципе,
правильно. И ещё он вот какие у нас трейдофы сказал. Есть у нас комплекси против перформанса, значит, у нас будет сложная система, он выбрал. Ну, потому что нам нужна распределёнка, нам нужны кликсы, нам нужны кавки. Это сложные распределённые технологии. Всё-таки один из пасгресса было бы проще. Но он бы не справился. Consistency против availability мы выбрали consistency. Косты против capability мы выбрали открытое решение. Значит, ну, типа, косты оптимизировали privacy performance. Ну, что-то там, в общем, похоже на правду. Надо прочитать, отредактировать что-нибудь и оставить, а только наиболее важное. Но в целом, в целом правильно.
Вот теперь мы идём, собственно, проектировать диаграммы. Вот сейчас у нас есть один квадратик. А solution strateg нам как раз нужен, чтобы его добавить здесь в контекст и сказать: "Дорогой друг, пора рисовать контекст". А, да, то есть вся рисовашка — это вот этот DSL. Он довольно простой по синтаксису. Я думаю, что даже те, кто не знакомы, что не знакомы с синтаксисом, сейчас быстро поймут, как это всё выглядит. То есть, в принципе, здесь есть переменная, здесь есть равно элемент вот software system. Называется у нас Analytics platform. У него есть документы, у него есть адры. И вот он сейчас будет добавлять нам экторов и стрелочки. Это, соответственно, ну, собственно, стрелочки на диаграмме. Смотрим, что он у нас спроектировал. Есть у нас посетитель веб-сайта, есть у нас аналитик, есть у нас разработчик и есть у нас администратор. О'кей. Меня устраивает. Поехали.
И пойдём на технический уровень. И в сид называется уровень контейнера. Контейнер — это немножко более широкое понятие, чем докер только. То есть контейнер — это любая штука, которая может деплоиться отдельно, независимо от того, используете ли вы вы контейнеризацию в докер, кубернете, подman или что-то ещё. То есть любая штука, которая деплоится отдельно в терминах терминах си — это контейнер, потому что терминология была придумана до того, как докер захватил мир. И теперь мы можем даблкликнуть на этот квадратик и провалиться внутрь этого чёрного ящика и посмотреть, что у нас внутри. Вот у нас обводка. Здесь это был уровень контекста. Когда мы его раскрыли, мы увидели детали, что у нас посетитель и разработчик, они ходят в трекиing IDE. Здесь у нас JavaScript либо мобильный SDK, да? Здесь дальше у нас есть inention API, который он решил делать на NOD JS. Наверное, где-то в решениях там есть, либо он просто тоже по статистике в, ну, как бы уехал в NJS. Я не знаю, почему он решил Not JS, но если ему сказать просто в констрентах, что не надо на Notсеs, он не будет. Обычно язык программирования есть в контейтах. И вообще до этого он падал в GO, который здесь более применёнен. Сейчас вот упал Not JS. О'кей. Дальше мы это публикуем в Evве Broker. А у нас есть stream процессор. Это Flink он выбрал. Ну да, о'кей. Flink. Есть база данных Clickhous и есть Analytics Web UI, который он сделан на Реакте. Есть Qy API, есть privacy какой-то ещё, который за GDPR следит. Есть администратор, есть аналитик. Довольны ли вы той диаграммой и качеством принятых решения? Там Илья спрашивает, что лучше вязать по по цене и качеству. Я тоже отвечу на вопрос попозже. А если вот пишет крутяк, а остальные как? Спроектировали ли вы бы лучше за 1 час 12 минут и успели бы задокументировать все эти решения? Давайте так. Кто кто мог бы за час 12 сделать лучше? Так, о'кей.
Ээ, давайте я покажу ещё одну штуку. То есть, а соответственно, это верпай, которая была пустая. Ещё здесь есть ветка Analytics AI only, которую я использовал до этого. То есть я при подготовке к событию тоже аэ проделал вот этот workflow. Я сейчас просто покажу, а что получилось в прошлый раз. Так, сейчас смотрим. А что ты не переключился? Поехали. Ну почему ты не хочешь? Ui AI only. Sorry. AI only. А, ну понятно. О'кей, переключились. Сейчас он там подцепит. Вот здесь он, видите, принял больше решений. Э-э, у него в он в итеeration пне тоже, что не довольно похоже было. Были более нагруженные, да? То есть, видите, он выбрал типа High Volume data injection architecture. Блин, нет, мы это видим, по-моему, это зависший у меня в сейчас, сейчас, сейчас, сейчас, сейчас или прямо то же самое сделал. Че? Ладно, потом разберусь. Давайте я просто покажу, что он спроектировал до этого. Там будет довольно похоже, но немножечко не так. То есть, э-э, в этой итерации он решил, что всё-таки веб-сайты надо сделать, показать как отдельные системы, что имеет право на жизнь. Это даже более правильно. И здесь вебюзеер, он вот здесь находится. То есть веб-юзер ходит к сайту, сайт ходит к аналитической платформе. Это более правильно, мне кажется, а с точки зрения диаграммы. И дальше, если я провалюсь сюда, то есть он здесь тоже немножко использовал другие, а, другой color coding injection API. Здесь у нас REST API. Дальше у нас тоже eventбкер на Patch CA. Здесь есть Stream процессор, и в этот раз он выбрал Кавка Streams. Опять-таки, это не, ну, не совсем правильно, потому что здесь нету Кавкаконнекта. То есть надо либо и то, и другое использовать, либо либо что-то. Это это просто статистические решения. Здесь он вот как бы привирает. И здесь он ещё и спарк поставил сверху для очень сложного аналитического процессора. Мне кажется, для этого, типа, для чтобы было максимально стильно, модно, молодёжно, с микросервисами, без парка мы никуда не уйдём. А в остальном А вот он ещё решил QPI делать на грабкуэле. При вчём он консистентен? В том, что я и надо делать на реакте. Я ни разу не видел, чтобы он Я делал на чём-то другом. А, и Редис он ещё воткнул. Он сказал, что что-то, ну, как бы надо вот эти тяжёлые запросы ещё в редисе закешировать на всякий случай, потому что их будет не очень много, как будто бы, ихаус там типа лишнего дёргать. Дай-ка закишируем в редисе. Мне кажется, это всё дискуссионные моменты такие, которые не, ну, это такие решения, которые нельзя принимать без нормального тестирования в продакшене. Потому что, если посмотреть даже один из последних докладов Яндекса, как они ставили YDB, они очень хотели использовать жёсткие диски хддшные, потому что они у них простаивали. В общем, даже люди из Яндекса, но из команды Метрики, они из команды YDB узнали там про YDB много всего интересного то о том, как она работает и почему. И вот первые три их гипотезы о том, как вообще надо настроить, чтобы она работала с ХД, не заработали, просто потому что там были детали имплементации, про которые они никак не знали. Ну, соответственно, здесь кать нужен дис или нет без нагрузочного тестирования. Я думаю, что этот вопрос, ой, что ответ на этот вопрос давать, ну, я бы не стал, скажем так.
А у нас есть ещё 15 минут по плану и, э, соответственно, я успеваю ответить на вопросы. Давайте сначала начну студу, потому что на это ответить проще. Здесь уже кто-то спрашивал, что неплохо было бы прикрутить ещё какие-то ручки, конфиги и всё остальное. Да, то есть я об этом думаю, но э я пока один, кто работает с шаблоном. Если кому-то интересно мне помочь, welcome. Приходите, контрибьте, прикручивайте, я буду очень счастлив. Вот, потому что это это Open source, это под MIT лицензией, пока у него, у проекта есть один контрибьютор, будет больше, соответственно, будет больше возможностей. Второе, то, что я хочу прикрутить как можно быстрее — это MCP-сервер, который сможет читать нормально из Google Спречитов и Экселя. То есть сейчас у меня там стоит, мм, как это сказать э костыль, э, то, что мне надо выгружать в CSV, да? э-э потом экспортировать из CSV в MD. Это неудобно. Было бы гораздо удобнее сделать промт, дать ссылку на Google счишит и чтобы он оттуда забрал, потому что все эти вычисления делать в спрейчисте гораздо удобнее, чем делать в а в любом другом формате. Ну и, соответственно, Excel тоже нормальный вариант. С точки зрения того, что Excel создаёт zip архивы, можно использовать XMLный вариант Excе. Это называется Workbook. Его тоже можно хранить в репозитории. Более сложная штука — это добавить MCP-серверы для принятия решений. То есть сейчас он эти решения принимает статистически. Но, вообще-то, если я пойду в промты и, а, промты, вот тот промт, который который про вычисление back of the envelope всяких значений, то есть здесь у него чёрным по белому написано, что надо использовать MCP сервер. CP сервер калькулятор для для всех расчётов, чтобы он цифры статистически не угадывал. И вот этого достаточно. Он консистентно, если ему сказать, что обязательно используем CP сервер, он будет использовать, соответственно, на все вот эти вот штуки со сравнительными таблицами, какую базу данных выручить, какой inestion poin что ещё можно сделать так, чтобы он ходил к MCP серверу и спрашивал у него. Я даже сделал небольшой of concept. Это работает. Я на коллегике собрал MCP-сервер для который подсказывал бы, какую выбирать базу данных, но написал очень плохо, там буквально один и if какой-то сделал, на одном кейсе протестировал, соответственно, этот MCP сервер у меня выдавал фигню и проверял тоже на вот этом сценарии с аналитикой сказал: "А давай какую базу данных выберем". И там почему-то мой MCP сервер решил, что это базы данных и и начал предлагать из influx DB и там аналогичное решение. Меня удивило, что ЛНК его послушала, сказала: "Твой типа MCP сервер подсказывает вот это". Ну это фигня. Он сказал типа DB, но это работать не будет. Берём клик. Вот. А заставить можно, на самом деле. То есть это интересная тема, но здесь довольно много ресурсов нужно. Следующее — это оптимизация промтов, потому что сейчас мы, ну, нормально так выжигаем токены. Сейчас мы бы, ну, как бы плавно перейдём к теме промт инженеринга. И последнее. Я думаю, что у этого шаблона есть потенциал. Можно подключать кастомные реги для решений, которые принимаются в вашей компании. Здесь тоже есть проблема, что этот рэк надо сделать и ваш технические решения вашей компании их должно быть довольно много, и они должны быть довольно хорошо задокументированы, чтобы можно было этот трек сделать и подцепить его тоже к агенту, э, чтобы в том случае, когда он не уверен, он не придумывал, сходил, посмотрел ваши данные и, соответственно, уже на основе на основе ваших данных у него дальше размышления строились в другом направлении. Что касается оптимизации промтов, то есть вот спрашивали, в принципе, у Антропика и у GPT5 это написано явно. Используйте XML теги для создания структуры. И у GPT5 они тоже перешли на теги. В принципе, вроде как можно использовать и Markда для GPT тоже, но в примере используются именно теги. Вот здесь есть хороший раздел про метапромптинг. То есть, что после того, как вы всё сделали, вы можете спросить сами модели относительно качества ваших промтов. Эти промты прошли через три или четыре серии рефакторинга. И вот здесь, кому интересно, есть команда формат промт, которая тоже написана уже с тегами. Последние версии промтов я готовил через метапромтинг, то есть я брал предыдущие версии промтов, открывал их и говорил: "Отформатируй мне, пожалуйста, этот промт". Вот, допустим, первый в соответствии с форматом, который я указал здесь. Я это прошёл тогда по по всем промтам, исправил. И была последняя итерация, где я уже после метапромптинга сначала я отредактировал руками сам, потом прошёл метапромптингом и потом ещё третий раз прошёл всё и глазами проверил. Вот этот результат получился таким образом. И пока я это всё делал, я ещё шёл по этому workкфлоу заполнения каждого раздела. Выполнял промты в антропике и в чате GPT 4 и 5. Смотрел результаты, смотрел, что получается, удалял, начинал заново. редактировал, пока не получал правильный результат. И вот после того, как я эту итерацию повторил некоторое количество раз, получился тот результат, который получился. Вот это отвечая на вопрос про то, как всё это получилось.
О'кей. Проверяю тогда в Google Доке, что у нас было ещё по вопросам про продуктовую документацию. Прочн Давайте так. Остались какие-то вопросы здесь, где я не ответил текстом или ответил недостаточно. И там присутствуют те люди, которые задавали эти вопросы. Да, у меня был один вопрос. А вопрос, ну здесь этот мы фактически Greenfield проект рассматриваем, да? Вот у меня была задача примерно 2 месяца назад, она до сих пор, в общем-то, не решена. Хотел вот спросить, какой подход можно использовать? А у нас очень сложная система. У нас микросервисное приложение, которое фактически работает как распределённый монолит. К сожалению, да, много, но тем не менее у нас очень сложная система аутентификации, которая включает логин через разные системы. А, ну, например, ID — это обычное, потом пароль, пароль логин MFA вторая, и потом логины через THD party системы, которые, значит, мы тоже на них выдаём токен в нашей системе. А GT токен. А всё это делалось, скажем, 4 года назад на Do the Identity Server. Не знаю, Максим, этот знаешь ты эти да. Да, и у нас очень мно много кастомных аутентификаций. Это есть есть прямая аутентификация, то есть пользователь аутентифицируется по idнтити системе и потом подходитк какому-то APIю с токеном. Токен валидируется этот этот API ими DNET library для DNET client Library для аутентификации. И, соответственно, это запрашивает опять Identity Server, валидирует этот токен и даёт или не даёт доступ. Это самый простой случай. К сожалению, у нас есть ещё такой случай, как on off. То есть ладно, давай попробуем вопрос задать. То есть я понял, типа сложная тотификация. А вопрос какой? Вопрос такой, значит, это всё сидит в нескольких разных репозиториях и хотелось бы создать какую-то архитектуру, никто не знает, эту архитектура, этих людей уже нет. А, которая помогла бы понять, как вот из пяти-шести репозитория, где сидит вот этот сервер, а с помощью копайта экстракт сделать. Я я понял вопрос, да, напиши мне, пожалуйста, в личку в Телеке, потому что я лично не могу ответить на этот вопрос, но я знаю того, кто пытался подобную штуку сделать и вроде как довольно успешно. То есть типа Long Story Short, как будто бы взять весь этот код, попробовать слить в, ну, в одну папку. То есть типа папка называется вся система, и ты туда делаешь клоун всех своих репозиториев. И если 2 млн токенов хватает в контекст, попробовать загнать эту лмку, чтобы она выдала sumy. Но я что-то процентов на 80 думаю, что фигня получится и придётся, ну, придётся самому ещё разбираться. Единственное, что она может инсайты какие-то дать, потому что типа супербыстро, да? То есть она может там что-то найти, что подскажет, какие-то моменты. То есть за за человека она не, к сожалению, не сможет выполнить всю работу, но вот ээ какой-то первычный избор данных может сделать. Угу. Хорошо. Хорошо. А если что, тогда я напишу это в чат, который общий нашей нашего теле или какой-то другой. Да, ты можешь написать. Я просто потому что вот договорились, я к тебе в личку приду и м может я попробую познакомить тебя там с человеком, который это делал, и может у него получилось. Я просто точно не помню, получилось у него сделать или нет, и какой у него объём кода был. То есть здесь проблема может быть какая, что это не залезет в контекстное окно. Да, да, это правда. А если не залезеть в контекстное окно, надо делать рек. А делать рек — это для этой задачи как будто окиill. Угу. Наверное, да. Это очень дорого будет. Ну да, потому что, блин, проще посидеть просто попробовать разобраться, потому что трек делать долго, а какой будет результат, непонятно. И, ну, типа, есть вопросики по эффективности инвестиций. Спасибо.
Так, а вопрос ещё, что лучше вязать по цене и качеству? Ну вот я вот использую GHub Copilot. Ээ, ну, курсор мне не нравится, потому что мне не нравится Visual Studio Code. И он делает много неявных лишних, как мне кажется, для меня вещей, потому что есть у курсора есть системный промт свой, и там написаны такие же огромные простыни, он специализирован на кодинге. Я не пробовал, но у меня есть ощущение, что он может выдавать больше галлюцинации на вот таких архитектурных задачах, потому что у него будет свой системный промт, который надо будет выключать. Но это не основная причина для меня. Основная причина в том, что мне идея подобное де нравится больше, чем-код. Ну, естественно, если меня перестанет устраивать купай, мне придётся разобраться либо с курсором, либо с клодкодом, либо с чем-то ещё. Wнсрf я бы не использовал, потому что у него были там же финансовые проблемы, его как будто бы купили. Но это не то, что это не то, что он плохой, это я просто вижу риски некоторые у этого продукта. То есть как будто бы как будто бы его победил курсор и вкладываться в технологию, это моё мнение, я могу быть вообще на 100% не прав, вкладываться в технологию, которая как будто бы проигрывает, и потом переходить на другое де. А, ну вот я сам не хочу. То есть у меня была типа простая логика. Я использую всегда идеи подобные де и я хочу использовать то, что может с ними интегрироваться. Пока нет очень очень типа везкой причины использовать что-то другое. Я пока вот эту очень вескую причину не нашёл.
Ну что, кажется, я на всё ответил. И вот явно правильно, да, это говорит, что надо всё это перепроверять в реальной жизни. Вот такие не как не повторять это вот эти штуки дома, потому что LLM вам может наврать. То есть это в первую очередь оптимизатор вашей рутины, которая вот ээ м особенно если вам надо писать много документации, потому что, например, в компании бюрократические э бюрократические процессы это очень сильно помогает. Ещё она может что-то подсказать, о чём вы не знаете. У меня такое много раз было, когда она подсказывала технологии, а я их просто не видел. Они оказывались релевантные. То есть я переходил, смотрел, так вот это подсказывает, это что-то как бы фигня. И ты дальше спрашиваешь: "Что ты подсказал? Это же фигня, вроде". Такой: "Ну да, наверное, фигня". А бывает, что смотришь, вроде подходит и говоришь: "А ты подсказал почему?" И он отвечает уверенно, что вообще как-то здесь подходит. Ну то есть типа если ещё поговорить там в чатике дополнительно, ну у меня получается понять, где он врёт. Надеюсь, надеюсь, что у меня получается понять, где он врёт, а где не очень. Э и третье, иногда просто, ну, что-то забываешь, что что-то есть. Она раз тебе подсказывает, и в голове так бах, блин, а я не подумал про эту штуку. Действительно же просто в голову не пришло. Ээ я к этому отношусь как к такому очень ээ эрудированному, но не очень сообразительному помощнику. Предлагаю всем также относиться. А тем, кому понравилось, поставьте, пожалуйста, звёздочки на гифтхайбе, кто не поставил. Те, кто хочется контрибютить, приходите, контрибюте. Вот у меня весь туду лист того, что я хочу ещё дальше развивать. Это всё, что я хотел сегодня показать.