БЕЗБТ Истории аналитика


Kanal geosi va tili: ko‘rsatilmagan, ko‘rsatilmagan
Toifa: ko‘rsatilmagan


Финтех | Системный/Бизнес-анализ | Личный опыт
— Чистая практика без воды: кейсы, ошибки и лайфхаки.
— Реальные истории вместо теории. Мои провалы и победы — ваш skill-up.
Подписывайся, если хочешь знать, «как оно на самом деле».

Bog‘liq kanallar

Kanal geosi va tili
ko‘rsatilmagan, ko‘rsatilmagan
Toifa
ko‘rsatilmagan
Statistika
Postlar filtri


База знаний.zip
1.5Mb
Как и обещал, выкладываю свою Базу Знаний БА/СА еще и в формате .md файлов, удобнее всего смотреть через Obsidian.

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

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

• как в посте выше - пайплайны по дописыванию и ревью статей для Obsidian у меня уже работают и их вполне можно использовать независимо от проекта. Есть статья, нужно дополнительное исследование - есть инструмент. Дорабатывать тут можно только движок для исследований
• а вот с выкладкой на сайт http://basahub.ru сложнее, сейчас уже есть отдельно написанный проектик, который прямо по моему vault в Obsidian пересобирает контент для сайта, остается только опубликовать. НО если появится другой тип контента, новые фичи и так далее - его также придется дорабатывать

И вот, чем хочется заняться в первую очередь:

1) доработать раздел с BPMN, сейчас там схемы в mermaid, а я хочу прямо в Obsidian вставлять xml-схемы из Camunda, чтобы были полноценные примеры.

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

3) добавить теги в каждую статью и реализовать поиск на сайте по тегам

4) поэкспериментировать с ИИ-ассистентом, чтобы ему можно было позадавать вопросы по статье, но это явно потребует большей мощности - на будущее кароч)

@nobrstories #базазнаний




Да уж, мои перерывы меня самого немного пугают, но что уж тут поделаешь.
Сложа руки я не сидел, не переживайте!

Итак, помните, я когда то анонсировал какое-то "нечто" в Obsidian вот тут?
Да-да, задержался немного, не пару недель это у меня заняло, но все-же, вашему вниманию - сайт, где я собрал кучу материалов для Бизнес и Системных аналитиков - http://www.basahub.ru

Вся информация взята из моего локального Obsidian, и ее накопилось довольно много.
130+ статей, все в открытом доступе, надеюсь, что помаленьку буду эту идею развивать дальше, потому что как только буду находить новые материалы - они будут добавляться в мой Obsidian, а оттуда прямиком на сайт!

@nobrstories #базазнаний




Итак, я ж говорил, что в канале буду писать и про факапы в том числе, так что вот вам прекрасный пример проеба 6 часов.
Цель была простой: хотел поставить себе локальный вариант Claude Code, затестить на одной задачке как раз, которая мне нужна не для работы и рассказать об этом здесь, может еще конфигурацией поделиться.
На поверхности и реализация выглядела несложной:
- ставим Claude Code
- ставим Ollama и скачиваем qwen3.5:4b и qwen3.5:9b
- ставим mcp для подключения к Ollama
- отучиваем Claude ходить в интернет - добавляем в конфиги Claude Code localhost, где живет Ollama, благодаря mcp-серверу
- скачиваем и ставим глобально пачку базовых mcp-серверов (для obsidian, для чтения/записи файловой системы, для серфа в интернете)
- добавляем эти mcp-сервера в конфигу для Claude Code
- профит.

В реальности все стало ломаться буквально с третьего шага:
1️⃣ чтобы Claude перестал просить авторизацию, сначала я создал файл с параметрами в корне claude, но он их проигнорировал, так что это решилось быстро - через environmentVariables, достаточно заменить путь к Antropic на localhost, на котором живет Ollama (по факту Claude думает, что обращается к Opus, а идет к нам локально в LLM)
2️⃣ со скачиванием LLM никаких проблем не возникло, разве что первый запуск всегда небыстрый, даже небольших моделей
3️⃣ в этот момент я подумал, что хорошо бы добавить еще и подключение к облачному DeepSeek (дешево ведь), и нашел, как сделать удобный переключатель, но для этого пришлось удалить mcp-сервер ollama и написать отдельный скрипт для прокси, который будет перенаправлять вызовы либо на одну из 2-х локальных моделей, либо в облачный DeepSeek.
4️⃣ безо всяких других инструментов на этом этапе все завелось прекрасно, но, когда я начал подключать mcp-сервера для работы с файлами и Obsidian - все пошло по пизде...
5️⃣ сначала я не мог добавить в глобальные параметры мои mcp-сервера (он их просто не видел), затем, когда я их добавил в корневой папке claude в параметры инициализации - он их хотя бы нашел и поднял
6️⃣ потом выяснилось, что формат, в котором принимает запрос Ollama, отличается от того формата, который выплевывает из себя Claude (да-да, об этом вам с рилсах не скажут, пидоры). Самый простой пример на картинке, но он явно не единственный.
7️⃣ окей, я явно в прокси исправил эту ошибку и по идее запросы стали уходить, но ответы не распознавались. Как выяснилось - по той же самой причине несовпадения форматов. К тому же расхождения форматов даже усугубились: параметр thinking, reasoning effort, tools - все это надо дорабатывать в моем прокси, чтобы просто совместить Ollama с Claude Code.

Да, тут можно было бы вернуться к обычному mcp-серверу Ollama, он то наверняка из коробки умеет все это обрабатывать, но мне хотелось самому переключать-выбирать модели локально, либо выбирать облачный DeepSeek, а это только ручками.

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

Так что сегодня вместо этого попробую сделать аналогичный процесс с помощью Hermes, а не Claude Code - плюс в том, что на apple m2pro он будет значительно быстрее, поскольку поддерживает MLX.
В любом случае - я пока что экспериментирую и пытаюсь найти удобный для себя вариант, не замыкаясь на готовые облачные решения (а то мало ли что).

@nobrstories #LLM


Вот такую имбулю готовлю для всех желающих, надеюсь закончить проверку всех источников в ближайшие пару недель)
@nobrstories #базазнаний


11.01 Эмбеддинги и векторизация.md
23.8Kb
Пара-пам, всем привет, я вернулся!
Хочу сказать, что я решил-таки взяться за фундаментальную подготовку здоровенной базы знаний для бизнес и системных аналитиков.
С одной стороны без воды, а с другой - прям собрать все-все-все, что знаю сам и структурировать.
Пропадал я преимущественно потому, что уже закончил драфт на 120+ статей и сейчас занимаюсь редактурой и выверкой всего этого добра.

Но сейчас не об этом😕
Пока дополнительно изучал дополнительные материалы и яростно пиратил книги - наткнулся на статью о перспективах разработки от 25 года (нужен впн).

И мне прям до рези в пятой точке захотелось вставить свои 5 копеек. Сначала о чем статья:
1️⃣ тезис статьи в том, что ИИ - это только инструмент, который только усиливает команду, а не замещает ее.
Успокаивает, правда?
2️⃣ тезис о том, что требуется сосредоточиться на systems design и качестве кода, то есть - НЕЛЬЗЯ терять экспертизу в том, чтобы знать, КАК ваш продукт работает
3️⃣ тезис в том, что экстемально повышается важность deliver as fast as possible, и уточняется, что команде НУЖНО давать определенную свободу, чтобы можно было совершать ошибки и работать быстрыми итерациями.

А теперь позвольте дополнить:
1️⃣ что БА, что СА никак нельзя оставаться в виде проводников бизнес-требований. Если ваши требования содержат только бизнес-логику - у меня для вас плохие новости, описывать надо, как система работает, хотя бы потому, что это позволит лучше и понимать, и пробовать проектировать архитектуру, а не просто "пересказывать бизнес-путь".
2️⃣ плюс в том, что все фундаментальные пробелы в знаниях подтягиваются, а практика доступна и на рабочем месте, если есть возможность влезть под капот вашего продукта.
3️⃣ минус в том, что исключительно деградантское управление какое-то время будет считать, что ИИ должна заменять сотрудников, а не усиливать, но господь им в помощь - на рынке нет ни единого успешного примера таких замен, обсираются практически все и нанимают народ обратно.
В первую очередь это вызвано упорным нежеланием понять, что ИИ - не панацея, если менеджер/управленец идиот.
4️⃣ и вот самое сладенькое - чтобы создавать крутой продукт, требуется адаптироваться, меняться, это правда.
Но многие забывают добавлять, что при этом надо не бояться ошибиться, а значит это нужно РАЗРЕШИТЬ.

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

Поэтому сосредотачиваемся на подтягивании своих знаний и не ссым, кожаные мешки будут нужны в любом случае.
А во вложении бонус - я ж обещал рассказать про эмбеддинги?
Вот вам пример одной из статей моей будущей глобальной базы знаний!
P.S. само собой будет целый блок про ИИ.
P.P.S. статья в markdown, скачайте себе obsidian, попробуйте уже наконец кайфовый инструмент.

@nobrstories #LLM #баттхерт


ну и вот как я сегодня себя чувствовал на презентации...
#ворованыемемы @nobrstories


refsq2025.pdf
159.5Kb
Фух, сегодня поучаствовал в конференции https://systemanalyst.life/systemconf#program, остался под очень приятным впечатлением и от организации, и от других спикеров.
Основная тема всей конференции - использование ИИ для системного аналитика и я прям счастлив, что эту тему педалируют и развивают.
Очень круто, что люди спрашивают конкретные вещи - как работать с конфиденциальными данными, на какие open-source модели можно обратить внимание и так далее.
И я понимаю, что все это можно прям к себе в контент-план записывать и помаленьку рассказывать.
Но начать бы я хотел с другого вопроса - о роли системного аналитика (да и вообще многих других ролей) в процессе повсеместного внедрения ИИ.
Многих это беспокоит и я могу понять почему, но, чтобы не быть голословным - я нашел некоторое исследование, которое действительно позволит чуть снизить градус беспокойства.
Статью прикладываю во вложении, а пока расскажу, в чем суть.

Авторы исследовали возможности трассировки связи между требованиями к разрабатываемым продуктам. По сути, они изучали, может ли LLM помочь в том, чтобы из разрозненной документации по продукту собрать более-менее вменяемую документацию.
Для этого использовали несколько подходов: и RAG, и Chain-of-Thought, и сравнивали использование open-source моделей и проприетарного ChatGPT.
Чтобы не утруждать теоретическими выкладками и методиками оценки (я туда немного погрузился, вам оно не нужно), перейду сразу к обнадеживающим выводам:

1️⃣ open-source модели сопоставимы с проприетарными - это ОЧЕНЬ важный момент, о котором я уже говорил. LLM это только движок, по настоящему мощным инструмент делает вся сторонняя обвязка: mcp-серверы (как руки для LLM), механики сжатия/вытеснения контекста, долговременная память и ее архитектура (графы, векторные БД), организация поиска и так далее (рано или поздно расскажу обо всем). Именно эта обвязка и создает "магию" сильного ИИ, хотя с тем же успехом вы и сами можете скачать open-source модель на 4-9 млрд параметров и навайбкодить себе несколько нужных именно вам mcp-серверов и организовать память. И ничуть не потеряете в качестве, может только в скорости.

2️⃣ RAG+LLM - действительно мощный инструмент, который показал свою эффективность. Но от себя добавлю - он станет полезным только в случае, если вы аккуратно подготовите данные для использования LLM.
Просто сделать векторную БД, оцифровать ваши доки в векторы и положить туда - недостаточно. Требуется подготовить иерархию, связи, очистку данных и продумать хотя бы поверхностно механику поиска.

3️⃣ максимальное значение эффективности применения LLM пока что достигает около 45% (фактически это гармоническое среднее между precision и recall, но нахрена вам это). А это подводит к главному выводу:
Ключевая роль человека в процессе разработки остается прежней. Меняется только подход - не создание, а оценка работы ИИ и корректировка.

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

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

Всем, особенно новоприбывшим - огромное спасибо за то, что обратили внимание🩷
@nobrstories #LLM


Прошел месяц и тут, как ни в чем не бывало, сначала хотел вернуться к теме инвалидации кэша в Redis, но потом решил, что лучше написать что-то поинтереснее (по крайней мере, на мой взгляд).
Пока я готовил материалы к докладу по ИИ, наткнулся на интересную статью по использованию LLM для анализа бизнес-требований.
Если супер-кратко, то в 25 году исследователи решили проверить, насколько поможет при запросе в LLM некоторое количество качественных референсов.
Для начала дополнительный термин в копилку:
🔹in-context learning - это процесс обучения модели прямо в контексте запроса.

Простой пример in-context learning:
"Ты - эксперт в бизнес-анализе. Определи, является ли требование неоднозначным.
Вот примеры:"

Далее примеры в виде пар "Требование" и "Метка" (однозначное/неоднозначное).
И в конце целевой текст, который требуется проверить.

То есть суть здесь в том, чтобы прямо в запросе дополнительно передавать какое-либо количество эталонных примеров.
Вывод статьи: чем больше примеров в запросе, тем лучше, но в тестах значительный отрыв продемонстрировал именно пример с 10 эталонными примерами.

Эти выводы, на самом деле, мне стали интересны (и могут заинтересовать вас) сразу по нескольким причинам:

1️⃣ когда я настраивал свою систему AI-агентов, которые разбирают обращения пользователей, я использовал поиск по старым, уже разобранным обращениям и закидывал в контекст 3-4 примера ранее разобранных обращений.
Так вот - можно смело пихать 10 и болше и проверять результаты. Хотя я и не думал это тестировать.

2️⃣ нам далеко не всегда нужны RAG-платформы и полноценное понимание контекста для решения нашей задачи. То есть процесс дообучения моделей, создания сложной базы знаний, проектирование гибридного поиска по внешней памяти - это конечно круто и очень полезно, но это долго, муторно и все-равно создает проблему "экспертного лжеца".
Ведь если просто скормить LLM вашу документацию, то, при галлюцинациях - она станет ОЧЕНЬ эффективно вам врать со ссылками, что будет действительно порой сложно проверить.
Поэтому для каких-то задач действительно стоит использовать LLM как чистый лист и обучать прямо в запросе.

3️⃣ исходя из предыдущего - нам пока что все-равно не следует избавляться от человека в ходе работы LLM, цена ошибки все-таки высока. НО, всегда надо держать в голове, что, переусложняя процесс обучения и работы LLM - результаты ее работы становится все сложнее проверять.

@nobrstories #LLM


Рекомендации для ИТ-резюме 2026.md
12.4Kb
За последнее время я реально устал от чатов с вакансиями, анализами резюме, собеседований и так далее. Скорее эмоционально устал, чем физически, но все-же - рынок труда для IT сейчас в трудном положении, если не в пиздецовом.
Сложновато не вкатываться в фатализм при этом, но я постараюсь.
Да, проблемы есть, да до рекрутеров достучаться сложно, да, приходится колдовать над резюме, чтобы тебя заметил не просто человек, но пропустила ATS. Лично меня даже бесит то, что фактически нужно из кожи вон лезть, чтобы продемонстрировать как ты героически работал кучу лет, хотя может быть и геройство было не всегда, скажем честно.
А рынку все-равно, чем больше соискателей, тем они хитрее, лучше приспосабливаются и лучше "продают" свои навыки.
Соответственно приходится не отставать и работать над конкурентными улучшениями.
Так к чему это я?
Поскольку нас тут немного, я решил собрать вообще все рекомендации, которые я наскреб по куче чатов/форумов, в один промпт для ИИ и делюсь этим)
На самом деле тут прям самая актуалочка на 2026 год, чтобы на HH можно было после кучи откликов хотя бы пробиться к людям.
Нет, я не спиздил, честно собирал сам
Можете просто прочитать и примерить на себя, а можете запихнуть в ChatGpt вместе со своим резюме и получить нужные исправления.
Короче говоря - пользуйтесь на здоровье.
P.S. может и не для IT-сферы тож пригодится.
@nobrstories #резюме

352 0 28 3 12

Стратегии кэширования.

Все-таки решил вынести в отдельный пост просто потому, что это касается не только Redis.
Так, базово у нас 2 блока - как можно ЧИТАТЬ кэш и как можно ПИСАТЬ кэш.

📖 Как читаем из кэша?
1️⃣ cache aside - здесь приложение само сначала идет в кэш, если там нет того, что нужно, идет в БД, получает данные и САМО приложение записывает в кэш.
2️⃣ read through - приложение заходит ТОЛЬКО в кэш, и уже сама система кэширования, если не нашла нужного значения, идет в БД, забирает данные, прихранивает у себя и отдает дальше приложению

✏️Как пишем в кэш?
1️⃣ write around - самый простой вариант - приложение всегда пишет данные в БД, при этом не трогая кэш вообще. Соответственно, когда потребуются данные - сразу возникает ситуация из cache aside.
🟢плюсы:
- не записываем ненужный мусор в кэш
- просто реализуемо (ну а хули, если мы все время только в БД и пишем, а в кэш заливаем только при чтении)
- полезно, когда у вас загруженный на запись сервис (не просто high-load!)
🔴минусы:
- первоначальное чтение дольше, логично? сходили в кэш, нихуячего получили, сходили в БД, получили, записали, отдали пользователю
- старые данные в кэше. Вот это уже больно, в этой стратегии не подразумевается, что мы будем обновлять значения в кэше пока оно не протухет. Соответственно, когда, например в кэше будет лежать старый статус заказа, а в БД уже обновленный, пользователь увидит его только, когда Redis выкинет его у себя и приложение его снова запишет. И да, долго, исходя из первого минуса.

2️⃣ write back - приложение сплошным потоком пишет все в кэш, а Redis асинхронно с другой стороны аккуратно прихранивает все это в БД.
🟢плюсы:
- ну это быстро, все данные всегда пишутся не на жесткий диск, а в оперативную память. перформанс, так сказать, на все бабки, учитывая стоимость DRAM сейчас
- сжатие данных - тут не совсем очевидно, но если мы перезаписываем одно и то же событие И нам нахер не нужна история (например полная история координат курьера), то фактически у нас будет один сегмент оперативной памяти, в котором будут всегда актуальные данные и пачка срезов, возникших при репликации в БД
🔴минусы:
- риск потери данных - если у нас накроется Redis или сервер с ним, то все, что было обновлено в оперативке после последней крайней записи в БД - потеряется
- сложнее в реализации, тут без комментариев, нужно очень постараться, чтобы реализовать логику write back только там, где это нужно и не обосраться

❓В идеале используется в контроллерах ССД, RAID контроллерах серверов, где есть Battery Backup Units, то бишь резервное питание, которое позволит выполнить последнее сохранение, дла высокопроизводительных БД, для управления сессиями. Короче говоря везде - где ОЧЕНЬ важна скорость сохранения данных без потери производительности приложения, которое эту память использует.
3️⃣ write through - приложение пишет данные и в кэш, и в БД. Тут на картинке в БД пишет само приложение для кэша, но это необязательно, писать может и источник самостоятельно в оба конца.
🟢плюсы:
- всегда свежие данные и в кэше, и в БД
- все сохранено, ничего не теряется
- все данные читаются очень быстро, потому что потребители всегда найдут их в кэше
🔴минусы:
- долгая запись, с этим нужно смириться, поскольку пока мы все не запишем, мы не пойдем дальше.
- большая нагрузка на сеть, так как постоянно требуется записывать и обновлять записи и в кэше, и в БД
❓По применению - финансовые транзакции, да и в целом все, что критично не потерять в процессе обработки. При этом важно понимать, что даже в случае критичных данных может быть кэш вам нахер и не упал. Мне лично нравится всего один аргумент - если вы уверены, что ЧИТАТЬ эту ахуенно важную запись (которую сложно найти, легко проебать, и невозможно забыть, ахах, не удержался, простите) будут чаще, чем ПИСАТЬ, то стоит рассмотреть вариант write-through кэша.

@nobrstories #cache


Удивительно наблюдать, как понемногу смешиваются специализации в IT - еще года полтора назад никто и не подумал бы спрашивать на собеседованиях чуть глубже про технические знания, к примеру про NoSql и Redis в частности, а теперь вообще легко. Впрочем, а почему бы и нет, мы должны быть любознательны, причем и в техническую, и бизнесовую часть.
Поэтому в этот раз можно немного ликбеза по тому, что же такое Redis?

1️⃣ это хранилище данных NoSQL, которое хранится не на жестком диске, а в оперативке (in-memory), пока все просто. Оперативка дороже, но зато запись в нее во много раз быстрее, чем на диск, так что из плюсов - быстродействие, из минусов - отказоустойчивость

2️⃣ формат данных - это не просто ключ-значение, как обычно отвечают. Есть несколько типов:

- строка (string) - фактически это любой массив байт, где может быть текст, число, сериализованный JSON, бинарный код картинки и так далее. Сериализация - есичо, это преобразование того, что мы видим на экране в то, что лежит в памяти компудахтера, то есть мы видим текст, а в памяти лежит длинная строчка байт.
- хэш (hash) - это коллекция пар "поле-значение" для одного ключа. Ладно, на примере - допустим у нас есть пользователь, у него есть отображаемое имя и email, вот эти два "поля" можно сохранить в привязке к 1 ключу в базе, это сэкономит память
- список (list) - фактически связный список строк под одним ключом. Redis позволяет очень быстро вставлять и выкидывать сообщения с обоих концов списка. Самый частый пример - список последних/частых запросов, искать по нему не нужно (это медленно), а вот просто по FIFO добавлять и выкидывать нужно быстро.
- множество и упорядоченное множество (set/sorted set) - если в хэше у нас "поле-значение", то тут просто массив значений под одним ключом. Разница между обычным множеством и упорядоченным тупо в том, что во втором случае для каждого значения из массива есть еще и число score. Например массив игроков и их очков.

3️⃣ базовые команды - это инструкции, как в SQL, но, заточенные под типы данных выше
- SET/GET - очень просто, задаем значение для строки и получаем его
- HSET/HGET - догадаетесь по первой букве? да, задаем значение для хэша и получаем его же
- LPUSH/RPUSH/LPOP/RPOP - добавляем (RUSH) слева (L) или справа (R), либо выкидываем (POP) таким же образом
- SADD/SMEMBERS - добавить множество, получить все элементы
- ZADD/ZRANGE - добавить упорядоченное множество, получить множество, отсортированное по возрастанию score
Чуть больше про команды вот тут - https://habr.com/ru/articles/485672/

4️⃣ Pub/Sub - эти две функции фактически превращают Redis в брокер сообщений.
Фактически у нас есть некий издатель, канал и множество подписчиков, НО отправка сообщений похожа на семантику at most once в kafka. Аналогия с "выстрелил и забыл" здесь очень подходящая.

Так, база есть, в следующем посту распишу про стратегии кэширования, время жизни записей и инвалидацию, а то уже места не хватает)
@nobrstories #Redis


Итак, вернемся к основной теме канала - моей работе как системного, мать его, аналитика.
Так вот, у нас уже давно зреет инициатива о подходе API first, и в этом подходе не всегда все очень гладко.
Сам API first подход хорош - аналитик готовит swagger-схему проектируемых эндпойнтов сервиса и отдает разработчикам в составе задачи на доработку. Что может пойти не так?
В swagger у нас есть и описание состава запроса, и состав ответа, и перечень кодов ошибок со структурой ответов, НО помимо этого мы еще проектируем состав DTO.
Помните, когда я разбирал Фаулера, я рассказывал, что DTO - это фактически структура данных, которая описывает структуру объектов в коде МЕЖДУ фронтом (слоем представления) и базой данных какого-либо сервиса (слой хранения).
И вот тут кроется проблема:
1) допустим, что сервис уже существует, есть интеграции, есть уже какие-то описанные разработчиком DTO
2) когда вы проектируете новый API, сами, либо через LLM (особенно если так), вы можете насоздавать кучу DTO, которые попросту не вписываются в то, как это видит разработчик в своем транспортном слое.
Как с этим бороться?
Ну, во-первых, нужно учитывать имеющиеся DTO, где их взять? Логично, что в репозитории сервиса, то бишь нужно либо залезать в код, либо брать автособранный swagger из реального сервиса и аккуратно добавлять туда новое, переиспользуя те объекты, которые уже есть.
А во-вторых, нужно пообщаться с разработчиком по вашему новому API, чтобы понять, нормально ли вы запроектировали структуру объектов.
Либо, уже после того, как разработчик сделает сам сервис, взять итоговый swagger из кода и сравнить со своим API first и поправить его, потому что иначе что?
Правильно - ваша библиотека API от аналитиков будет только "витриной" запросов и ответов и ей можно будет если не подтереться, но опираться только на описание входа и выхода.
Это тоже нормально, но со временем, когда вы будете добавлять все новые API - ваша структура данных станет сильно отличаться от реальности и будет вызывать только баттхерт от разработчиков, вместо того, чтобы реально помогать в работе.

@nobrstories #REST #APIFirst


set_your_own_VPN.md
14.6Kb
Сам файл, почему то в один пост с картинкой телега не выкладывает, если будут вопросы - буду рад ответить)


Всем привет!😁
Вот я снова и пропал, регулярно что-либо делать - это и правда не так просто как кажется.
Во всяком случае у меня накопилось немного материалов, поэтому начну излагать.
Начнем с того, что на прошлой неделе арендовал VPS-сервер и поднял свой VPN и прокси для телеграма, потому что разные сервисы в последнее время то отваливаются, то работают нестабильно.
Плюс все-таки свой, хоть и арендованный сервер - уже чутка безопаснее, нежели дешевые vpn, не говоря уже о бесплатных.

Ну и, поскольку я потратил на это некоторое время, собрал некоторое количество ошибок, решил поделиться итоговой инструкцией суперподробно, прям по шагам:
- подготовка и первое подключение к VPS-серверу
- установка панели управления на свой сервер
- настройка личного VPN
- оптимизация сети
- установка MTProto для телеги
- установка SOCKS5 для телеги

Само собой, аренда сервера - удовольствие чуть более дорогое, но вам хватит мощности 1 CPU + 2GB RAM + 20GB NVME, чтобы все прекрасно работало и это будет стоить около 450-500 рублей в месяц, в зависимости от оператора.
Операторов есть дохрена (adminvps, aeza, 4VPS - гуглится элементарно), платить можно спокойно по СБП, а сервера лучше всего брать в той стране, где пинг поменьше, это чаще всего прямо у провайдера на главной странице написано.
Скриншон взят с AdminVPS, но не буду рекламировать - в последнюю неделю у них перебои с выдачей серверов.

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

А в моей инструкции вы все сделаете своими ручками один раз и будете радоваться.
P.S. файл формата .md, при желании вы можете скормить его любой ИИ и она ЕЩЕ больше разжует каждый шаг, хотя я постарался сделать так, что больше вообще ничего не потребуется)
@nobrstories #vpn


Капец я лошара. Сказал, что буду выкладывать что-то по чуть-чуть каждый день и вот уже месяц молчу.
Мда, доверия мне нет, поэтому начинаю исправляться.
Ключевые проблемы:
1) все мои знания поверхностны и надерганы из разных источников
2) мой опыт и насмотренность в качестве системного аналитика наоборот мне мешают рассказывать что-то интересное, потому что мне кажется, что это не очень интересно и душно - вот такой вот парадокс...
3) дисциплина хромает - как только я задумываюсь о том, как развивать себя/направление работы/блога/интересов, мое внимание распыляется и я не могу заставить себя работать в одном направлении
Что ж, весьма логично, что никакой энтузиазм в долгую не работает, поэтому буду восполнять свои пробелы.
Раз объективно сейчас направление AI не только популярно, но и востребовано - начинаем этому учиться.
Сделал mindmap-карту обучения и начал ей следовать, о чем и буду писать далее)
Буду рад, если вы будете проходить этот путь со мной😃
Пойду освежать линейную алгебру в чертогах памяти...
@nobrstories


День 4.
Сложновато заставлять себя писать каждый день, что ж ты будешь делать.
Зато сегодня нашел что-то полезное - есть такой канал в тг/бусти/ютубе "Осознанная меркантильность", существует уже давно и вызывает много противоречивых отзывов, но мы здесь не за этим.
О чем это - базово про работу в IT, найм и обучение в этой сфере. Круто то, что даже при безоценочном суждении там много полезного, вот, например одно из свежих видео про найм в IT - https://youtu.be/J9zNT0xgRpc
Есть несколько полезных тезисов для тех, кто сейчас ищет или вообще в целом думает о поиске работы:
1️⃣ ключевой агрегатор, как ни крути - HH, тут других вариантов нет, здесь я полностью согласен.
Но хотел бы дополнить автора, потому что по факту крутые вакансии, а-ля менеджмент, а то и топ-менеджмент, не присутствуют на агрегаторах в принципе, можно даже не ждать.
Так что здесь, если вы упираетесь в определенный потолок, нетворкинг - единственный вариант.
2️⃣ рынок 2026 действительно смещен в сторону работодателя, но с этим можно работать.
От себя могу добавить одно - в 2025 году было много волн сокращений из бигтеха, при этом до нового года активный найм не случился (тогда как обычно с сентября обычно рекрутинг бодрый).
При этом сейчас в начале года появляется много вакансий, что нехило намекает на то, что бигтех сознательно почистил свои ряды, чтобы заново собрать всех в новом году подешевле, имхо.
3️⃣ HH, мягко скажем, поступают некрасиво - закрыли API для соискателей, при этом автоматизацию для работодателей накрутили так, что до живого человека дойти очень сложно.
4️⃣ накручивать/скручивать опыт - спорный вопрос, мне кажется, что это личный вопрос каждого, но важно понимать, что резюме смотрит довольно тупой фильтр, если указано 2 года 10 месяцев, а в вакансии 3 года минимум, рейтинг для этой вакансии в любом случае снизится.
5️⃣ фильтр для работодателя тупой еще и потому, что ищет совпадения преимущественно по тому, что вы указали в блоке "Навыки", поэтому не поленитесь и посмотрите, что указано в вакансиях и копипастите себе, даже если это тупо (да-да, если в вакансии хотят навык с канбан или git, укажите их, даже если это тупо база)
6️⃣ делать несколько резюме - прекрасная практика, это позволяет экспериментировать, создавая разные варианты под разные вакансии. НО они привязаны к одному аккаунту, а это значит, что рекрутер увидит и историю изменений, и все остальные ваши опусы, и хз, как он на это отреагирует.
Поэтому пока что рабочий вариант - сделать А/Б тесты на старой учетке, затем зарегаться заново под новым номером и уже на нем завести свой финальный вариант и жестко пойти в найм)
7️⃣ из своего опыта скажу, что сами собеседования на позицию СА слабо изменились за последние несколько лет, записей собесов куча на youtube, можно подчерпнуть для себя много нового
8️⃣ еще от себя лично добавлю, что никогда не доверяйте рейтингам работодателей, это такая хуйня из-под коня, что даже объяснять глупо, насколько они нарисованы коричневым пальцем.
9️⃣ плашка "подтвержденные навыки" в резюме указывается даже если вы прошли всего один тест, так что не теряйте времени, заскакивайте в самый легкий и, если понравилось, можете еще что-то пройти
🔟 насчет самого резюме, поскольку опять же, его читает ИИ, не забудьте добавлять ключевые слова улучшил/исправил/снизил и сколько-нибудь %. На самом деле вы даже не соврете, вы же работали в команде, и, скорее всего, в любом случае за время вашей работы какие-либо показатели точно улучшились. Вам то может и пофигу, вы головы от проекта не поднимали, а вот ИИ прочтет и это повлияет на скоринг вашего резюме.
1️⃣1️⃣ сопроводительное письмо можно составить хорошо один раз, индивидуальные письма для каждого отклика дают не очень много конверсии, но факт его наличия - да.
1️⃣2️⃣ linkedin все еще важный канал, так что обновите и постарайтесь там хотя бы регулярно немного активничать. То же касается и HH - активность на сайте тоже немного повышает скоринг резюме.
Фух, это прям самое полезное, за остальным можно в источник)
#найм @nobrstories


День 3.
Да-да, для меня еще четверг)
Вот вроде и работал сегодня, а вроде и сложно найти, о чем поделиться.
Читал замечательную статью о том, в чем может ИИ помогать системному аналитику.
Там и SQL-генерация, и диаграммы можно нарисовать, и код прочитать, и бизнес-задачу спроектировать, но все поверхностно и как будто совсем не то.
Без погружения в контекст.
При этом у меня есть коллега, который чуть ли не документацию по целому сервису заделал при помощи single-shot промпта, просто очень хорошо, подробно, длинно написанного.
И вот я сейчас пока даже не знаю как к этому относиться.
С одной стороны я вижу, что подготовка супер-длинных промптов по каждой задаче как будто тратит почти столько же времени, что и самостоятельная разработка требований.
А с другой, это видимо во мне говорит лень, потому что по сути - это реально следующий виток работы аналитика, потому что только в этом случае мы сможем в принципе справляться с возрастающей нагрузкой.
Единственный хороший вывод, который я для себя сделал и может он кому то пригодится:
1) Нашли мелкую задачу, которую можно сделать автоматом, потратьте время и автоматизируйте ее - похуй, через хорошо один раз написанный промпт, либо через самописную программу.
2) Если дело касается промптов - складывайте их потом в кучку, чтобы объединять цепочки заданий.
Да-да, это занудство, но весь вот этот ваш опыт и наработки начинаются прям с мелочей, которые банально нужно хотя бы начать сохранять.
Завтрашние вы скажете себе спасибо даже за то, что вам не нужно лишний раз писать в чат про "твоя роль - системный аналитик..." а сделаете копипаст.
#нудятина @nobrstories


День прошел, число сменилось - нихуя не изменилось.
День 2.
Сегодня мало что смог сделать по работе, кроме тестирования ИИ для аналитики, поэтому у меня есть, что рассказать.
В продолжение вчерашней темы про IDP и прочую ересь для работы с LLM я понял, что упустил важный инструмент - MCP-сервер.
Это протокол, который сделан для интеграции ИИ с внешними источниками, если проще - руки для ИИ.
С его помощью LLM может выполнять запросы к API, обращаться к локальным документам и выполнять фактически какие-либо действия - менять файлы, вносить какие-либо изменения, куда дадите доступ.

Казалось бы, а зачем тогда вообще RAG/IDP/индексирование/векторизация и прочее?
А вот и нет, даже если дать хорошей LLM доступ ко всей информации вашей компании доступ через MCP - при любой необходимости ей придется перебирать все данные, пока она не найдет нужное.
То есть да, само собой, в случае с deepseek это понятно - он выполняет через search базовое гугление, парсинг подходящих статей и вот тебе контекст.
Но нам то такое не подходит - в confluence особо не погуглишь, поиск там довольно тупой, соответственно, нужен хороший "движок поиска", который поможет найти хотя бы в какую сторону копать.

Что умеет MCP-сервер? Вообще стоит разделить возможности на 3 категории:
1) инструменты (tools)
- поиск в интернете
- парсинг веб-страниц
- создание отчетов
- различные нишевые инструменты - погода, курсы конвертаций, переводчик и так далее
2) ресурсы (resources)
- база знаний
- внешние API
- доступ к файлам
- доступ к БД
3) промпты (prompts)
- шаблоны промптов для агентов
- пошаговые промпты для планирования
- промпты для уточнения
- сценарии выбора нужных инструментов

На самом деле с документацией можно ознакомиться тут - https://modelcontextprotocol.io/docs/develop/build-server

А тепень вернемся к тому, что просто сам по себе MCP-сервер - мощная штука, но для полноценной работы только его мало:
1) для огромной документации нужен отдельный поиск RAG+IDP, иначе MCP придется перебирать информацию - это долго и дорого по ресурсам
2) точность ответов RAG+IDP точно будет выше, поскольку через MCP будет найдено все подряд и, либо оно не влезет в контекст модели, либо будет менее релевантно и добавлять много информационного шума
Тем не менее - MCP критично важен, если нам нужна не просто думающая LLM, но и с возможностями дотянуться до чего-то самостоятельно.
#LLM #MCP @nobrstories

20 ta oxirgi post ko‘rsatilgan.