Об DevOps и архитектуру

В целом, с LLM удобно и вести исследования различных предметных областей как таковых.К примеру, в процессе данной работы обнаружилось, что любой метод работы (компетенцию) можно разложить на:- Ядро метода (K), которое не меняется от проекта к проекту. Пример: «Разворачиваем Gitlab-CI в общем», «знание Ansible»- Контекстно-зависимые методы (S) — то же самое с репликацией, отказоустойчивостью и резервными копиями. Здесь можно много развивать в любую сторону — это по своей сути system analysis + system design. Написать пайплайн легко — берешь, читаешь туториал и пишешь. А вот вписать его в контекст проекта (количество команд, отзывчивость пайплайна, его надежность, комплаенс по секретам, мониторинг пайплайнов) — это уже совсем другое.- Внесервисные методы — заказчик часто не может качественно сформулировать запрос на услугу. Например, сколько ему времени хранить резервные копии, или сколько ему нужно диска под данные. Нужно ему в этом помочь, а может быть и убедить что нужно сделать так, а не иначе, т.е. транслировать потребности в требования.И все эти методы по своей природе разные — одно это знание инструмента, второе это насмотренность и знание архитектуры, третье это умение коммуницировать и выгружать из соседней команды чего они хотят на самом деле.По аналогии можно декомпозировать и другие объекты

Конкретно в одной из последних задач LLM мне помогает смоделировать операционную модель команды в проектной организации.А точнее как более эффективно интегрировать между собой:- Сервисы/услуги, предоставляемые проектной командой внутри проекта- Методы работы команды: ядро, контекстно-зависимые методы, внесервисные методы.- Состав команды- Грейды (в т.ч. разделение на «базу» и «точки роста» в рамках одного грейда), и назначение грейдов на методы работы- Предъявляемые артефакты работы для упрощения принятия решения промо/не промо- Трансформеры для того, чтобы люди двигались на следующий грейд (был человек грейда «джуниор», после участия в некоторой деятельности стал «миддл»).Все это естественно между собой густо перевязано связями, к примеру:- сервисы состоят из методов с одной стороны, и из людей с другой стороны- чтобы команда работала предсказуемо (т.е. реализовывала свои системы надежно, защищенно и т.д.) у ней должен быть достаточно определенный состав, а не производльный (не должно быть джунов без сеньора) и т.д. - сотрудник определенного грейда может выполнять какие-то методы работы, а другие методы еще пока не может- на собеседованиях мы проверяем наличие этих навыкови т.д. и т.п.В классическом моделировании при помощи условного archimate если мы меняем что-то в одном месте дальше нужно руками проходить по связям и смотреть что поменялось.Рисовать это в PowerPoint, еще хуже, т.к. в нем нет инструментов анализа.В случае работы с LLM при изменении вводных в одном месте все остальное автоматом пересчитывается (возможно нужно дать модели пинок, но это происходит).По сути у нас получается что-то типа пайплайна CI/CD для текстов, только на базе LLM, а не yaml.Гипотезы у меня сейчас следующие:- Насколько хорошо оцифрованная модель команды срисованная с реального мира будет работать и заведется ли вообще? Надеюсь узнаю за 1-2 месяца работы уже «в реальном мире» после того как ее доработаю.- Автоматический пересчет всех текстов когда я на вход подаю новые вводные: напр

Об вайбкодинг текстовПримерно с октября я довольно плотно занимаюсь работой с текстом при помощи LLM + FPF.Сперва Google AI Studio (бесплатный, хорош для быстрого старта), теперь ChatGPT Plus.Из недавних открытий (и мне почему-то не встречались статьи про это) — работа с текстом не через WebUI, а через IDE+coding agent.Проблематика следующая:Примерно от 1-2 страниц текста, у тебя в нем появляется заметное количество взаимозависимых объектов.Когда какой-то меняется, их неплохо бы обновлять и «пересчитывать» — примерно как в случае с Openspec, Spec-Kit, которые описаны выше.А если текст структурирован, доработок много, то в чате начинаешь быстро теряться, забывать скопипастить какие-то строки, соглашения, терять диффы и т.д.Иными словами, поболтать с моделью в UI легко и приятно, но непродуктивно если что-то нужно получить на выходе — выгребать ценное из гор слопа сложно и муторно.Но когда разговариваешь с LLM в IDE, агент сам фиксирует и типизирует все объекты, фиксирует принятые решения и вообще ведет подробный лог изменения документов.Скорее всего на старте разговора нужно настроить AGENTS.md и структуру репозитория, но если опыт с этим есть проблем с настройкой не должно быть.Вот пример моей настройки: https://github.com/timurb/fpf-workbench.Для использования клонируем+копируем репозиторий, открываем в любой IDE с подключенным агентом, подробно описываем свою ситуацию и просим сохранить как вводные данные. Дальше просим дать такие или иные ответы, или сделать корректировки, и они появляются прямо на диске.В следующем посте о том, что я собираю с помощью LLM.

Как я написал в прошлом посте, меня как и во многих других вещах, в контексте LLM интересует в первую очередь методологический аспект: как работать с ними эффективно?При этом я намеренно не задаю определение слова «эффективно», чтобы можно было применять этот подход в разных контекстах.В этот раз я не буду писать долго и много, и просто порекомендую посмотреть на https://github.com/Fission-AI/OpenSpec/Это одновременно метод и инструмент для построения coding workflow вида «планируем фичу -> проектируем архитектуру -> пишем тесты -> пишем код». На базе него эту эффективность собрать кажется достаточно несложно независимо от того что вы понимаете под «эффективностью»:- если вам дела нет до документации можно ее оставить только как опору для агентов- если вам техническая документации нужна, здесь уже есть готовый каркас на базе которого можно строить и не выдумывать его самому- каркас довольно легковесный, при этом его можно дорабатывать (например корректировать какая именно документация вам нужна)(уточнение: я пока не могу сказать насколько он сочетается с полностью автономными coding agents)Похожие инструменты/подходы, но менее удобные для старта по тем или иным причинам:- https://promptdriven.ai/ — кажется, один из первых подходов «спеки -> доки», который так и не выстрелил, да и помер. Смотреть на него не рекомендую.- https://github.com/github/spec-kit — более детальный по сравнению с OpenSpec и кажется более тяжеловесный подход от Microsoft - https://github.com/bmad-code-org/BMAD-METHOD — на мой взгляд чрезмерно формализованный- Plan & Act — самый простой, но и наименее мощный из всехКак и с изучением всего нового, рекомендую взять какой-то подход и сделать на базе него десяток итераций (реализовать десяток решений любого размера начиная от простейшего скрипта).Мои первые опыты генерировали гигантское количество документации которая не нужна, но теперь я понимаю что именно из нее нужно.Следующая итерация видимо будет обкатка этих подходов в коллективном контексте

С этими LLM одни проблемы — количество идей увеличилось в несколько раз. Когда их воплощать то?Вторая проблема (связанная с первой), о которой мало говорят — как и многие современные технологии LLM вторгаются в стандартный культурно-обусловленный дофаминовый цикл. Если раньше в процессе работы над проблемой радость от решения проблем была размазана на длительность работы, то теперь за час разговора можно получить подробный план решения, и пачку тикетов в персональную (или не обязательно персональную) тикетницу на довольно рутинную реализацию.У меня получилась такая эвристика: «если после разговора с LLM ты не почуствовал себя дураком, или не ушел из разговора с вооот такенным списком задач — ты поговорил зря» — знай эти задачи как-то приоритезируй и разгребай. Но в разгребании радости гораздо меньше чем собственно в поиске решения. Навык «разбивать большую задачу на много маленьких, каждая из которых приносит пользу» становится еще более актуальным чем во времена пост-ватерфола: сейчас становится супер легко попасть в ловушку over-engeneering, причем сразу на множестве уровней одновременно: уровне описания проблемы, уровне описания концепции решения, уровне постановки задач, уровне проработки архитектуры решения, уровне определения и проработки границ между компонентами, уровне определения качества этих компонентов. Чуть промахнулся — получил тонны нейрослопа, который еще не сразу заметишь.На уровне реализации все наоборот, хорошо — написал задание, модель тебе написала ответ. Но попутно тут же наплодила долга на всех перечисленных уровнях (и нескольких не перечисленных).А если делать интероп LLM с человеком — чтобы по-очередно могли писать код и люди и LLM получается все еще более интересно, но об этом в другой раз.Что любопытно, практики Devops описанные отцами-основателнями и далее превратившиеся в DX, Evolutionary Architecture, и частично Platform Engineering на концептуально-методическом уровне вполне неплохо помогут справиться с возросшей сложностью.У тебя вне

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

Интересный взгляд от Github на Platform Engineering в эпоху AI:https://githubnext.com/projects/continuous-ai/«Классические» платформы всегда event-driven, они предоставляют сервис в ответ на некий API-запрос, будь то вызов REST API или push в репозиторий.С появлением понятия «агент» платформа может выполнять некоторую активность постоянно — переход от вызовов API к постоянному сервису. Робот-пылесос убирающий квартиру постоянно, а не только по запросу.Промежуточным шагом к этому были операторы и шедулеры — условный cert-manager не просто выписывает тебе сертификат LetsEncrypt, а поддерживает его в актуальном состоянии.Auto-scaling group или HPA не просто масштабирует нагрузки, а поддерживает оптимальное количество мощностей для них.И то и другое — это по сути классическая работа operations. Написание автоматизации и ее конфигурирование — классическая работа разработки.Если рассматривать результат работы agentic AI как некую активность над вверенным ему ресурсами (или шире — объектами), платформенную инженерию можно осмыслить по новому.Не доставка товаров курьером по кнопке, а непрерывная доставка JIT.Не сканирование кода на уязвимости по созданию PR, а непрерывное сканирование и их устранение. Раньше мы рассматривали dependabot и vulnerabot как ботов. Кажется теперь можно рассматривать их как first class citizen в платформах

Страница команды Github по продуктовым исследованиям (во многом на базе LLM).В разных стадиях — от «набросок на салфетке» до «работающий продукт»https://githubnext.com/

The Kubernetes design is based on choreography, but can incorporate orchestration benefits.Пояснительная бригада: choreography и orchestration это два подхода композиции микросервисов (паттерна saga).В случае orchestration есть отдельный микросервис, который оркестрирует процесс, проходящий через несколько микросервисов.В случае choreography микросервисы обмениваются событиями напрямую.Так вот, операторы в Kubernetes в общем случае работают в соответствии с подходом Choreography, а не Orchestration как мы могли бы подумать.Что с этим делать? Ничего, просто забавное наблюдение 😃

Святослав Котусев небезызвестный в кругах Enterprise Architecture своими исследованиями EA, выпустил новую версию своего легковесного фреймворка по Enterprise Architecture:https://eaonapage.com/4 больших одностраничных карты вместо 1.5 тыс страниц TOGAF (в прошлой версии было 2 одностраничника):Из изменений:- Добавилась модель зрелости EA- Добавились полтора десятка вариантов функциональной оргструктуры архитектуры (в зависимости от размера и типа организации), в т.ч. небольшой бенчмарк по количеству архитекторов в организации- Расширилась карта практик EA (добавились связи с артефактами ЕА, появились примеры, карта стала более практической)- Уточнены формулировке на карте артефактовРекомендую как минимум полистать всем, кто так или иначе сталкивается со следующими темами или интересуется ими:- Lifecycle объектов уровня солюшена и масштабнее- Опермодель архитектурной функции и взаимодействие между отделами и проектами- Виды архитектурной документации (обоснования, governance, портфолио и архрепозитории)