fa
Feedback
Блог Сергея Баранова об ИТ-стратегии, архитектуре и организационном развитии

Блог Сергея Баранова об ИТ-стратегии, архитектуре и организационном развитии

رفتن به کانال در Telegram

Меня зовут Сергей, пишу о технологиях, социо-технической архитектуре и организационном развитии

نمایش بیشتر
4 079
مشترکین
+124 ساعت
-47 روز
+2330 روز
جذب مشترکین
سپتامبر '26
سپتامبر '26
+4
در 2 کانال‌ها
اوت '26
+68
در 3 کانال‌ها
Get PRO
ژوئیه '26
+63
در 3 کانال‌ها
Get PRO
ژوئن '26
+16
در 1 کانال‌ها
Get PRO
مه '26
+22
در 2 کانال‌ها
Get PRO
آوریل '26
+66
در 7 کانال‌ها
Get PRO
مارس '26
+80
در 4 کانال‌ها
Get PRO
فوریه '26
+59
در 4 کانال‌ها
Get PRO
ژانویه '26
+129
در 4 کانال‌ها
Get PRO
دسامبر '25
+78
در 3 کانال‌ها
Get PRO
نوامبر '25
+103
در 2 کانال‌ها
Get PRO
اکتبر '250
در 0 کانال‌ها
Get PRO
سپتامبر '250
در 0 کانال‌ها
Get PRO
اوت '250
در 1 کانال‌ها
Get PRO
ژوئیه '250
در 0 کانال‌ها
Get PRO
ژوئن '250
در 0 کانال‌ها
Get PRO
مه '250
در 0 کانال‌ها
Get PRO
آوریل '250
در 0 کانال‌ها
Get PRO
مارس '250
در 0 کانال‌ها
Get PRO
فوریه '250
در 0 کانال‌ها
Get PRO
ژانویه '25
+19
در 0 کانال‌ها
Get PRO
دسامبر '24
+38
در 0 کانال‌ها
Get PRO
نوامبر '24
+74
در 1 کانال‌ها
Get PRO
اکتبر '24
+123
در 1 کانال‌ها
Get PRO
سپتامبر '24
+149
در 0 کانال‌ها
Get PRO
اوت '24
+114
در 0 کانال‌ها
Get PRO
ژوئیه '24
+84
در 0 کانال‌ها
Get PRO
ژوئن '24
+85
در 0 کانال‌ها
Get PRO
مه '24
+96
در 1 کانال‌ها
Get PRO
آوریل '24
+146
در 1 کانال‌ها
Get PRO
مارس '24
+128
در 0 کانال‌ها
Get PRO
فوریه '24
+141
در 1 کانال‌ها
Get PRO
ژانویه '24
+188
در 1 کانال‌ها
Get PRO
دسامبر '23
+225
در 4 کانال‌ها
Get PRO
نوامبر '23
+103
در 3 کانال‌ها
Get PRO
اکتبر '23
+81
در 1 کانال‌ها
Get PRO
سپتامبر '23
+87
در 0 کانال‌ها
Get PRO
اوت '23
+131
در 0 کانال‌ها
Get PRO
ژوئیه '23
+132
در 0 کانال‌ها
Get PRO
ژوئن '23
+96
در 0 کانال‌ها
Get PRO
مه '23
+132
در 0 کانال‌ها
Get PRO
آوریل '23
+80
در 0 کانال‌ها
Get PRO
مارس '23
+49
در 0 کانال‌ها
Get PRO
فوریه '23
+39
در 0 کانال‌ها
Get PRO
ژانویه '23
+109
در 0 کانال‌ها
Get PRO
دسامبر '22
+68
در 0 کانال‌ها
Get PRO
نوامبر '22
+111
در 0 کانال‌ها
Get PRO
اکتبر '22
+130
در 0 کانال‌ها
Get PRO
سپتامبر '22
+72
در 0 کانال‌ها
Get PRO
اوت '22
+139
در 0 کانال‌ها
Get PRO
ژوئیه '22
+108
در 0 کانال‌ها
Get PRO
ژوئن '22
+42
در 0 کانال‌ها
Get PRO
مه '22
+62
در 0 کانال‌ها
Get PRO
آوریل '22
+91
در 0 کانال‌ها
Get PRO
مارس '22
+108
در 0 کانال‌ها
Get PRO
فوریه '22
+93
در 0 کانال‌ها
Get PRO
ژانویه '22
+63
در 0 کانال‌ها
Get PRO
دسامبر '21
+63
در 0 کانال‌ها
Get PRO
نوامبر '21
+42
در 0 کانال‌ها
Get PRO
اکتبر '21
+56
در 0 کانال‌ها
Get PRO
سپتامبر '21
+42
در 0 کانال‌ها
Get PRO
اوت '21
+44
در 0 کانال‌ها
Get PRO
ژوئیه '21
+76
در 0 کانال‌ها
Get PRO
ژوئن '21
+32
در 0 کانال‌ها
Get PRO
مه '21
+26
در 0 کانال‌ها
Get PRO
آوریل '21
+84
در 0 کانال‌ها
Get PRO
مارس '21
+44
در 0 کانال‌ها
Get PRO
فوریه '21
+117
در 0 کانال‌ها
Get PRO
ژانویه '21
+92
در 0 کانال‌ها
Get PRO
دسامبر '20
+852
در 0 کانال‌ها
تاریخ
رشد مشترکین
اشارات
کانال‌ها
05 سپتامبر+1
04 سپتامبر+3
03 سپتامبر0
02 سپتامبر0
01 سپتامبر0
پست‌های کانال
«Цитадель» Антуан де Сент-Экзюпери Эта книга - наставления мудрого правителя своему сыну о том, как управлять царством. Но на
«Цитадель» Антуан де Сент-Экзюпери Эта книга - наставления мудрого правителя своему сыну о том, как управлять царством. Но написана она так, что после каждой страницы еще можно целый день размышлять об изложенном. Я уверен почти на 100%, что после ее прочтения никто не сможет смотреть на мир вокруг себя как раньше, что-то глубинное точно откроется. Вообще, это не художественное произведение в классическом понимании. Это сборник притч, размышлений, объединенных фигурой рассказчика в лице правителя. Сам по себе образ цитадели символизирует акт творения и формирования внутреннего мира человека. Сложно подобрать слова для описания этой книги, столь она многогранна. Вот взять притчу о корабле. Суть в том, что правитель строил свое царство как корабль, – крепил, оснащал и «теперь он плывет в потоке времени, ставшем ему попытным ветром». Но тут же предостерегает от опасной иллюзии. Люди, обжившись на корабле, перестают замечать все вокруг. Они начинают думать, что «море создано для корабля»… а дальше тема раскрывается еще глубже, – что враг (сопротивление, ограничение) – это то же самое, что море для корабля. Море грозит поглотить судно, и корабль вечно сопротивляется ему, но именно это сопротивление веками формирует его корпус, делая обтекаемым и изящным. Это же буквально диалектика в чистом виде. Спустя годы на многое в книге смотришь с позиции логики, но сама книга ровно от этого пытается предостеречь. Например, рассуждение о том, что дом невозможно осознать логикой: «Дом для людей! Рассудку ли тебя строить? И способен ли кто-нибудь выстроить тебя как цепочку логических заключений? Ты – реальность, но ты – нереальность тоже. Ты есть, и тебя нет. Сущность твоя – разнородность, и для того, чтобы ты появился, нужно тебя сотворить. Тот, кто, желая понять сущность дома, разбирает его, видит кирпичи, черепицу, но не находит ни тишины, ни уюта, ни прохлады, которым служили кирпичные стены и черепичная крыша. Кирпичи, черепица – чему способны они научить, если распался замысел зодчего, который объединил их воедино? Камень нуждается в сердце и душе человека.» Тут и системное мышление и постулаты лидерства и эмерджентные свойства, можно дать множество характеристик, но стоит ли оно того? Безусловно, это ни в коем случае не обесценивание, а скорее о том, что формальные правила, формальные методы, формальное мышление, привычное и повторяющееся день за днем - это рамка, граница, за которую не так просто выйти и не удивительно, что в нашем ментально перегруженном, до предела усокрившемся мире появляются в том числе книги, вроде «Думай в других в форматах», в которых даются методики как выходить за рамки собственных ментальных границ или практики «осознанности и замедления», вроде когда ты идешь привычным путем на работу, но начинаешь сознательно обращать внимание на все вокруг и эта дорога как-будто становится для тебя новой, хотя ты ходил по ней уже тысячи раз. #Книги

2
Рубрика #Книги Я всегда любил и по-прежнему люблю читать, часто даю отсылки к самым разным книгам в беседах. У меня с самого детства была большая библиотека и, хотя в детсве мы жили не сказать, что богато, единственное, наверное, в чем мне никогда не отказывали – это покупка книг. У меня была (и сейчас на месте) вся коллекция энциклопедий от Аванты, все книги Черепашек Ниндзя и детского детектива Черный Котенок, огромное количество произведений о мифах Древней Греции, много книг по математике и бесконечное количество художественной литературы. Затем, когда появился первый ПК, 386, появились книги по использованию ПК и… ассемблеру =) Потому что на 386 писать на чем-то еще было весьма затруднительно. Затем появился Intel Pentium 166 и появились книги по VC 6.0, Java (Java Cookbook и подобные), Perl, параллельным вычислениям и появился Танненбаум =), это был кажется 10-11 класс. В универе было много книг со всех концов света, – и фантастика (те же принцы Амбера, Гиперион), какие-то совсем трэш-романы, прикладные книги по теории игр (я занимался разработкой игр), по геометрии (в том числе трехмерных, помню свой первый 3dfx) и по экономике (мы тогда столько всего разрабатывали, открывали и закрывали, писали бизнес-планы, чем только не торговали через фидошку, чинили материнки и видеокарты). А затем был период новых книг и повторного чтения старых книг, вроде Достоевского. Книг стало очень много, а выбрать все сложнее, появились сервисы с кратким содержанием вроде SmartReading, которые до сих пор выручает, если хочется именно ознакомиться и понять, стоит ли игра свеч. Сейчас уже собралась новая библиотека и она процентов на 80 - профессиональная, однако все самые значимые для себя книги я стараюсь покупать в бумаге, чтобы у них было свое место и чтобы они напоминали о себе и о идеях в них заложенных. А какие-то напоминают, сколько еще того, «что и не снилось нашим мудрецам».
369
3
Тот самый слон из притчи и твое архитектурное решение
Тот самый слон из притчи и твое архитектурное решение
595
4
NFR – это требование к чему именно? Наверняка у всех вас в том или ином виде описаны атрибуты качества, такие как безопасност
NFR – это требование к чему именно? Наверняка у всех вас в том или ином виде описаны атрибуты качества, такие как безопасность, производительность, масштабируемость. На первый взгляд все в порядке: они указаны и даже заданы количественно или качественно. Однако при детальном рассмотрении часто выясняется, что совершенно непонятно, к какому объекту относится требование. Требование производительности – к чему конкретно? К продукту? К отдельному модулю? К сервису? К данным? К конкретному пользовательскому сценарию? К каким проблемам это может привести? ▪️Компания берет на себя обязательства, которые невозможно проверить и защитить перед клиентом или регулятором: не зафиксировано, к какому именно объекту относятся эти обязательства ▪️Архитектурный артефакт невозможно однозначно спроектировать и протестировать, если NFR сформулированы без привязки к нему ▪️Требования нельзя проверить на полноту и согласованность между командами, поскольку отсутствует воспроизводимая практика определения объектов и границ NFR Что разберем на вебинаре? Одна из обязательных частей сценария атрибуты качества – объект, к которому относится требование. На вебинаре обсудим два вопроса: ▪️Какими бывают объекты NFR? ▪️Как определить границы этих объектов? Вебинар проведет Сергей Баранов. 🗓 8 сентября, 17:00 МСК 🔗 Подключение: https://scrumtrek.ktalk.ru/sccu2uneqagt Регистрация не требуется – добавляйте событие в календарь, чтобы не забыть 🙂
1 170
5
Диалог с агентом как разбор классической архитектурной дилеммы У нас ScrumTrek практически все разрабатывается агентами. Бывало всякое. Поделюсь историей, которая произошла буквально сегодня. Банальная фича - отображать нумерацию элементов или нет, если отсутствует заголовок первого уровня, а второго - на месте. Детали не важны - показывать числа или нет в зависимости от условия. Мои первые размышления: ну это же логично, нет текста - нет номера. Ставлю задачу. А он мне – бро, а давай мож чекбокс сделаем, вдруг кому-то надо. Ну ты, думаю, умеешь смуту навести. Ладно, может и правда кому-то надо. А он не унимается – таких 70 блоков по всем страницам и 60 подпадают под твои критерии, у них убираем (снимаем чекбокс)? Я уже напрягся, – ты вроде не живой, чтобы живого Заказчика доводить вопросами, взял и сделал как сказали (sarcasm!). Но ведь правда – есть разные продукты, у них свои владельцы, есть разные ЦА под разные продукты, у них свой опыт, свои вкусы. Вопсчем, я породил техдолг 🙂 Cказал «добавляем чекбокс, везде оставляем как есть сейчас». А мораль этой истории лежит в нескольких плоскостях сразу: 1. Очень мелкое изменение может повлиять на непропорционально большое число людей (контекстов использования – это, например, – продукты, владельцы, сегменты пользователей, публичные материалы, экспортируемые документы, скриншоты, инструкции) 2. Очень мелкое изменение может иметь лавинообразный эффект на атрибуты качества, в неявных местах (объемы данных, скорость обработки, …). В ATAM такие параметры или архитектурные решения называются sensitivity points. А теперь, наверное, самое важное. Как завещал Кент Бек, вдохновленный выступлением Энрико Занинотто на конференции XP 2002, изменения бывают обратимыми и не обратимыми: ▪️Обратимые – это изменения стилей, локальная верстка, скрытые за фича-флагами эксперименты. Здесь агенты дают колоссальное преимущество в скорости проверки гипотез. ▪️Необратимые – изменение финансовых данных, утечки персональных данных, слом публичных API или падение репутации, то есть изменения, которые уже вышли во внешний мир. Такие решения нужно оценивать заранее настолько тщательно, насколько это практически возможно (need to be evaluated up front to the degree possible). Порожденный мной в истории выше техдолг с точки зрения кода отдается за 10 минут. Но только в случае, если изменение было обратимым, потому что в противном случае техдолг отдать получится, но репутацию реверснуть нельзя, придется нарабатывать заново. Но и это еще не все. Архитекторы работают во многом с будущим. И вот такие мелкие изменения запросто могут без должного анализа возыметь отложенный негативный эффект на атрибуты качества - заложенная уязвимость, рост объемов данных, поедающих бюджет на хранение и производительность, аналитические запросы, кладущие раз в месяц прод базу на лопатки. Что делать? До принятия решения о реализации: • Классификация решений по обратимости. Именно так обычно никто не классифицирует (или я не видел), обычно это продуктовый и технический анализ влияния (impact analysis) и последствий, этого обычно хватает • Конечно, ADR, куда без него • Сценарии атрибутов качества и анализ точек чувствительности (sensitivity points) Структурные методы: • Ограниченные контексты и явно закрепленное владение за ними (больная тема вообще всех) • Контракты интеграции • Архитектурные фитнес-функции, термин не сказать что сильно прижился, если проще – автоматизированные проверки архитектурных инвариантов в CI/CD Поставка и эксплуатация: • Progressive Delivery (сюда входят и фиче-флаги и канареечные релизы и dark launch). По своей сути – это попытка перевести изменения из необратимых в обратимые • Наблюдаемость и опережающие индикаторы атрибутов качества (одна из причин, зачем нужны формальные описания сценариев атрибутов качества) • Реестр техдолга с бюджетом погашения (иначе он будет просто пополняемым списком и не более) Полезное из этого канала в тему поста: ▪️Архитектура и методология ▪️Про DDD и понимание предметной области ▪️Экономические последствия архитектурных решений (youtube) + презентация
664
6
Переписывать ли легаси? Один из вопросов из зала на конференции звучал примерно так: «стоит ли сразу и полностью переписывать легаси?» Часто легаси воспринимается как мусор, помойка. Но при этом в легаси живут тонны накопленного неявного знания, например: ▪️Обходные пути в реализации редких сценариев ▪️Исторически сложившиеся ограничения ▪️Древние договоренности ▪️Порой совершенно неочевидные интеграции ▪️Точечные решения на основе поведения пользователей ▪️Ошибки, которые когда-то были исправлены, возможно без обратного внесения в документацию, просто было «по пути» Без восстановления знания о легаси в худшем случае все неявное знание может быть утеряно. Суть в том, что проектируя идеальное решение в текущем представлении можно потерять то, что сделало решение немного уродливым, но рабочим и успешным. Однако разве не является как раз рабочее и успешное решение идеальным? Нет. Работающее и успешное решение – идеально относительно требований сегодняшнего дня, а система живет во времени. У нее есть и другое измерение качества – стоимость будущих изменений. Если каждая новая фича стоит три месяца и один инцидент, если единственный человек, понимающий модуль тарификации, уволился в позапрошлом году, если под этим всем лежит рантайм без обновлений безопасности, то… решение работает, но уже не успешно, просто счет приходит с задержкой, но приходит. Отвечая на вопрос в заголовке, «все и сразу» переписывать не стоит почти никогда. Постепенное вытеснение (strangler fig) дает ценность частями и сохраняет возможность остановиться на полпути (что, однако, будет стоить поддержки двух систем одновременно), если приоритеты изменились. «Все и сразу» выплачивает все в конце, при этом старая система продолжает жить и обрастать фичами, и переписывание пытается нагнать это развитие, сюда же момент переключения – это единственная точка, где вся накопленная неопределенность реализуется одновременно. «Все и сразу» применимо в достаточно ограниченном спектре ситуаций: платформа умерла (вендор ушел) и постепенная миграция по этой причине физически не может быть осуществлена. ▪️Система достаточно мала, чтобы написать ее заново было дешевле, чем провести детальный анализ ▪️Предметная область кардинально изменилась, и старое поведение более не актуально в принципе Как же восстанавливать неявное знание? ▪️Исследование предметной области (DDD, Event Storming, …) ▪️Анализ истории изменений в связке с задачами в таск-трекере ▪️Анализ задач в таск-трекере в исторической перспективе, включая комментарии ▪️Анализ логов и трафика ▪️Анализ артефактов эксплуатации ▪️Анализ данных в прод базе ▪️Тесты, фиксирующие поведение AS IS ▪️Анализ требований и внешних спецификаций (законы, приказы, ..) ▪️Интервью саппорта ▪️Shadowing (прогон реального трафика через обе системы со сравнением ответов) И в заключении еще один важный момент. Не все выявленное знание все еще истинно. После восстановления важно посмотреть на полученную картину критически и отбросить то, что уже не актуально как в части бизнес-процессов, так и в части технической реализации, иначе есть риск в новую систему перенести за компанию и внушительную часть технического долга.
1 014
7
Фронты (каналы), бэкенды и BFF Сегодня на JVM Day познакомились с Маликом Сафиевым (🙌) и одну из затронутых тем хотелось бы вынести сюда. Итак, у вас есть фронт, бэк и между ними BFF, который переводит предметку бэка в предметку фронта (или не переводит). Вопросов два: 1. Должен ли форнт использовать предметку бэка? 2. Если не должен и на BFF есть ACL, то кто владеет BFF? Под фронтом будем понимать один и более каналов, вроде мобилки, виджетов, чего угодно. Зафиксируем несколько тезисов: 1. Фронт должен быть на языке той предметной области, в которой живут потребители фронта 2. Модель предметной области фронта и бэка может не совпадать Нам потребуется два паттерна DDD: 1. Conformist (когда один контекст использует модель другого контекста по тем или иным причинам) 2. ACL, когда один контекст защищает свою модель от модели другого Таким образом: - если предметка фронта и бэка совпадает (например, внутренний бэкофис, условная бухгалтерия, когда бэк автоматизирует бухгалтерию и с фронтом работают бухгалтеры), то это чистый Conformist - если предметка отличается (например, сложные налоговые расчеты в бэке сотвсякими сторно и другими страшными терминами, а фронт - обычные люди, которым нужно циферку налога увидеть, да уведомление подать и все это на обычном бытовом языке), то нужен ACL, он может быть на BFF и если это так, то этим BFF+ACL владеет фронт, так как BFF жестко связан с конкретным пользовательским опытом и именно фронт защищает свою предметку - на фронте может быть много моделей (вкладка для маркетолога, вкладка для сейла, вкладка для менеджера), тогда несколько ACL, каждым владеет команда соответствующего контекста, лучше, конечно, вести отдельные BFF в таком случае, но тогда архитектура усложняется и это важно учитывать Как мы видим, у фронта появляется потребность в бэк-компетенциях, так что использование BFF (и ACL на нем) это не только архитектурное, но и организационное решение. При этом сквозной функциональностью BFF, вроде безопасности или отказоустойчивости владеет платформенная команда.
1 035
8
Фронты (каналы), бэкенды и BFF Итак, у вас есть фронт, бэк и между ними BFF, который переводит предметку бэка в предметку фронта (или не переводит). Вопросов два: 1. Должен ли форнт использовать предметку бэка? 2. Если не должен и на BFF есть ACL, то кто владеет BFF? Под фронтом будем понимать один и более каналов, вроде мобилки, виджетов, чего угодно. Зафиксируем несколько тезисов: 1. Фронт должен быть на языке той предметной области, в которой живут потребители фронта 2. Модель предметной области фронта и бэка может не совпадать Нам потребуется два паттерна DDD: 1. Conformist (когда один контекст использует модель другого контекста по тем или иным причинам) 2. ACL, когда один контекст защищает свою модель от модели другого Таким образом: - если предметка фронта и бэка совпадает (например, внутренний бэкофис, условная бухгалтерия, когда бэк автоматизирует бухгалтерию и с фронтом работают бухгалтеры), то это чистый Conformist - если предметка отличается (например, сложные налоговые расчеты в бэке сотвсякими сторно и другими страшными терминами, а фронт - обычные люди, которым нужно циферку налога увидеть, да уведомление подать и все это на обычном бытовом языке), то нужен ACL, он может быть на BFF и если это так, то этим BFF+ACL владеет фронт, так как BFF жестко связан с конкретным пользовательским опытом и именно фронт защищает свою предметку - на фронте может быть много моделей (вкладка для маркетолога, вкладка для сейла, вкладка для менеджера), тогда несколько ACL, каждым владеет команда соответствующего контекста, лучше, конечно, вести отдельные BFF в таком случае или подключать к нему ACL как отдельные внешние библиотеки Как мы видим, у фронта появляется потребность в бэк-компетенциях, так что использование BFF (и ACL на нем) это не только архитектурное, но и организационное решение. При этом сквозной функциональностью BFF, вроде безопасности или отказоустойчивости владеет платформенная команда.
1
9
Есть кто тут сегодня из канала? Можем встретиться, познакомиться.
455
10
Поговорим о знании Существует модель описания знания, включающая в себя три основных компонента: - декларативное знание (что?) - процедурное знание (как?) - условное знание (когда и почему?) Декларативное знание - это факты и утверждения, процедурное - правила действий. Декларативное - предпосылка для процедурного. При этом в зависимости от обретаемого знания конкретные типы могут быть разного объема, где-то больше декларативного (теоретическая наука), где-то процедурного (езда на велосипеде). При этом знание неотделимо от контекста и деятельности, в которой оно применяется. Подумайте о кешировании и про: - разработку самого комплнента кэша (разработчик) - выбор класса и конкретной реализации (архитектор) - настройка и мониторинг (SRE) Таким образом, часть знания не существует в голове отдельно от практики, в которой она проявляется. Помимо этого, в знании есть условные понятия, качественно меняющие понимание все области. Вспомним снова про кеширование, с точки зрения архитектуры примером будет переход от «настроить идеально инструмент кеширования» к «пойти на компромисс между целостностью и скоростью». Исходя из вышесказанного, декларативное знание предшествует процедурному, однако затем они развиваются синхронно в процессе обучения, но не обязательно синхронно. Согласно модели Дрейфуса (на является универсальной, но применяется в образовании), на ранней стадии доминирует декларативное знание в виде явных, контекстно-независимых фактов, на поздних - все более интуитивным. Это, в частности объясняет, почему нельзя научиться проектированию архитектуры за короткое время, - принятие решений почти всегда контекстно-зависимое. Универсальная модель обучения, таким образом: - декларативные знания - обучение, чтение, наблюдение - процедурные - повторяемая практика - условный - накопление опыта в разных ситуациях Важно отметить, что механизмы получения знания - не взаимозаменяемы. Если вы идете на конференцию, например, ArchDays, - вы получаете декларативное знание, отберите для себя выступления, которые могут быть вам полезны, заранее подумайте, как сможете применить и после выступления спрашивайте спикеров именно о том, как применить, какие действия выполнять, обменяйтесь контактами, спрашивайте по мере продвижения, либо исследуйте более глубоко тему самостоятельно. Так вы получите максимальный эффект. В организационном контексте подумайте следующем: - достаточно ли у сотрудников декларативного знания, чтобы качественно выполнять процедуры (процессы) - достаточно ли у сотрудников декларативного знания, чтобы реализовать в коде требуемые процедуры (фичи) - существуют ли процедуры, развивающие то, что декларируется (мы инновационны.. но есть ли процедуры это развивающие, обучающие?) - мы - гибкие, но заложены ли циклы обратной связи с последующими изменениями на основе этих циклов? - …. Для архитектора: - декларативное - курсы, книги, доклады, документация - процедурное - реальное проектирование систем - условное - разбор компромиссов, работа с разными контекстами
2 059
11
Немного диалектики по мотивам обсуждения с @emacsway_log Пару «владелец продукта - архитектор» можно рассмотреть как управляемое противоречие. Эти роли держат баланс, - владелец продукта отвечает за ценность здесь и сейчас, архитектор - за техническую устойчивость в долгую. Одно без другого не работает, - фичи без архитектуры превращаются в техдолг и тормозят поставку, а архитектура без фич не дает бизнес-ценности сама по себе. Это противоречие нельзя «решить» раз и навсегда, его можно только удерживать в равновесии. Для этого баланс закрепляют в процессах. Пока процессы работают, напряжение остается продуктивным. Стоит балансу сместиться и получаем либо неуправляемый техдолг, либо «архитектуру ради архитектуры».
975
12
Гипотеза родилась без оснований, выросла без метрик и умерла в презентации. Вечная память.
1 433
13
Очень хорошее интервью Натальи Касперской Кратко тезисы: ▪️Важно отделять бюрократию от технологического развития. Технологии развивались исторически снизу вверх, творчески, управлять бюрократически такими людьми – делать хуже (см книгу «Как пасти котов»). ▪️Регулирование само по себе может быть хорошим. Импортозамещение – правильное регулирование в условиях, когда любую технологию в условиях санкций могут отключить. В направлении ИБ практически вся задача решена. Операционные системы – базовый уровень. Базы данные – есть несколько. Есть пробелы в инженерных и узких областях. ▪️При этом повсеместное внедрение ИИ (как KPI) – не самый лучший вид регулирования (пример из прошлого – blockchain). Нельзя очаровываться технологиями, у технологий есть ограничения. Инженеры знают ограничения, но тех, кто понимает как работает технология – мало. Гуманитарии в основном не понимают ограничений, но представлены в информационном поле шире. ▪️Мы не знаем, как новые технологии подействуют на детей. Технологии развиваются быстро. Что отмечают ученые – сокращение у детей памяти, сокращение визуальных представлений (воображения), ухудшение зрения. ▪️Растет ли производительность? Освобождается ли время? Возможно. И на что мы тратим это время 🙂 Вы не тренируете мозг – мозг становится слабым. Как примеры – сможете ли без навигатора добраться до места, сможете ли сложить в уме большие числа. ▪️Агенты заменяют рутину, но супер-бухгалтера, супер-юриста они не заменят, нужно именно мышление. Сокращать человека или нет – это конкретное решение конкретных людей в конкретной организации, ИИ тут не при чем. ▪️Государство должно ограничить использование ИИ в социальной сфере для недопущения дискриминации. Но нужен баланс. В Европе самый жесткий закон на эту тему, но у них и не было своих ИИ-разработок и они законом ограничивают доступ американских технологий, отслеживающих социальную жизнь людей ▪️Дипфейк - реальная проблема. Особенно вокруг людей, у которых было много видео при жизни ▪️В видеохостиннге многое упирается в мощности. Может стоило в условиях небольшого рынка сделать государственный хостинг и дать к нему доступ разным игрокам рынка, чтобы они развивали собственные коммерческие продукты. Идет распыление ресурсов, вместо того, чтобы сделать 3 хороших, делаем 60 средних. Происходит дублирование функционала. Проблема большого числа операционных систем – тем, кто на них работает приходится портировать приложения под все, это высокие дополнительные затраты. С одной стороны - вроде не хватает людей, с другой стороны – распыление ресурсов. Позиция минцифры – рынок должен порешать сам, это хорошая позиция, но может дать сбой в условиях давления времени и геополитической напряженности. ▪️Чем мощнее технология – тем выше риски ИБ ▪️По уровню развития ИИ Россия – примерно на третьем месте в мире с большим разрывом между нами и следующим сверху ▪️Важно развивать критическое мышление, – огромные объемы данные не выдерживают никакой критики От себя, несколько прикладных выводов в части архитеткуры решений: 1. Минимизируйте число целевых платформ и закладывайте слой абстракции (portability), фрагментация отечественных решений может сделать портирование явной скрытой стоимостью 2. Проектируйте под заменяемость каждой внешней зависимости, – «рынок порешает» означает, что именно то, что используется у вас рынок может отвергнуть и система перестанет существовать, потребуется срочная замена 3. Чем мощнее технология, тем выше риски ИБ, – security by design – must have 4. Закладывайте валидацию и происхождение данных и контента (видимо не только в технологии, но и в процессы) https://www.youtube.com/watch?v=-3tbUsmizUc
1 664
14
А как подключиться к веб-версии Макса? Я захожу, просит одноразовый пароль, ввожу, мне говорит, что нельзя зайти, нужно в приложение, приложения у меня нет, сканирую второй QR код, на телефоне переводит просто на пустую страницу http://mobileid.megafon.ru/si-init?client_id=… И ничего не происходит, просто пустая страница. Контактов поддержки нигде не нашел.
1 565
15
Будни программного комитета Archdays :)
2 087
16
Я вот чего не понимаю, про ИИ же кучу всего можно интересного рассказать. Вот на вскидку только с инфраструктурным уклоном - Архитектура оркестрации агентов от LandGraph до Temporal. Или вот более теоретическая-академическая архитектура self improval system. Ну на худой конец архитектура пайплайнов для предотвращения утечек данных и балансировки запросов к разным провайдерам для урезания костов - если хочется больше девопсятины и кибербеза. Чо все упарываются в беклоги, рефакторинги и спеки?... 🙁
2 001
17
В архитектурных этюдах новый кейс о наболевшем: https://t.me/archicases/9786/9787
1 969
18
Про фейл с моделью Чего сегодня рассказали, делюсь с разрешения 🙂 В общем, небольшой региональный банк, выдает кредиты, они в конце прошлого/начале этого года решили попробовать пропилотировать использование LLM модели для оценки заемшиков. В целом как пилот и затевалось, но мало ли, думали что может что-то из этого выйдет. Взяли подрядчика, подрядчик решил пойти по пути файнтьюна как я понял, не понял зачем, но ок. Дообучили на исторических данных, на всем корпусе данных что было, на приемке на синтентических данных показало 90-95% точности. В целом круто, конечно. В прод выводить не стали, страшно, но каждую заявку стали отдельно отправлять в модельку и потом сравнивать модель и какое решение система/аналитик приняли. В общем, точность у них упала до 60-70%, начали разбираться почему, разобраться - отдельный челлендж, непонятно же почему такие решения, а модель попробуй допроси. И на самом деле они там до сих пор не уверены в своих выводах, но основной вывод был такой, что дообучали на всех заявках, а заявки поступали и решения принимались в разные периоды времени - были и кризисы и рост и разный кредитный портфель по объему и риску, то есть куча факторов, которые влияли на скоринг не только с учетом риск-профиля заявителя, но и кредитных аппетитов и рисков банка (к слову вот этот контекст восстановить полностью так и не удалось, получается нужно вычислить «дифференциал» в каждой точке принятия решений по кредиту, ну или на каком-то отрезке, в течение которого условия были стабильными, до изменений, а кто эти изменения фиксирует, попробуй выясни, что там поменялось). А поделиться я захотел, потому что сам все время указывают на потребность в качественных данных и качественном представлении этих данных для того, чтобы модели могли нормально работать, но вот этот кейс завел меня в тупик. Получается, что мало самих данных, нужны и условия в которых эти данные были сформированы, а как это получить - большой вопрос. У меня только два варианта как можно решить такую проблемы: • Сегментация данных по периодам стабильности (как написал в тексте выше), однако надо их как-то определить и определить точки перехода • Версионирование самих политик, без них как сегментировать не совсем понятно, в целом стоит видимо фиксировать под контролем версий все изменения в рамках принятых решений, чтобы собрать полный актуальный контекст в точке времени и в прошлом • Дополнять внешним контекстом (макроконтекстом) по отношению к компании, который имел влияние на принятие решения В Event Storming есть такая связка, что данные – это следствие решений, а не описание реальности само по себе. Получается, что модель, обученная только на данных, теряет причины, которые эти следствия сформировали, а это и есть та база, которая нужна модели, чтобы мы могли ее подпустить к принятию решений. Кстати, пока писал, подумал, что конкретно в решениям по кредитам это может быть решено (может кто-то так и делает), если вместе с заявкой, данными и решением сразу же сохранять в условном json весь тот контекст (условия), которыми руководствовались при принятии решения, хотя опять же, далеко не все доступно, макроситуация недоступна например. Ну и проблема не нова, в безопасности уже много лет система просто блокирует переводы, доступы, а почему - даже сам банк порой не знает и иногда не может узнать, но то безопасноть, совсем другое дело - операционные бизнес-процессы.
2 150
19
29 августа поделюсь наблюдениями про типовое и не типовое в архитектуре. Основная идея в том, что мы много чего себе можем по
29 августа поделюсь наблюдениями про типовое и не типовое в архитектуре. Основная идея в том, что мы много чего себе можем понапридумывать, вообразив, что некая задача суперважная, суперсложная и вот нужно ее прям кропотливо спроектировать и никто такого раньше не делал, мы уникальные. А оказывается, что в индустрии для таких задач есть типовые решения и нетипового там по факту с гулькин нос. Или решаем мы суперсложную архитектурную задачу, а если разложить систему на косточки, оказывается, что ничего сложного там и нет и снова задача вполне себе типовая. Будет легкий и непринужденный доклад с примерами и мыслями для медитации над своими системами после :) https://meetup.tbank.ru/conference/jvm-day/
2 660
20
Вышел Qwen 3.8 https://qwen.ai/blog?id=qwen3.8 • 2.4T parameters (95B active), with open weights releasing next week • comprehensive improvements across coding, work, research, and long-horizon tasks • end-to-end and dependable delivery of complex tasks
1 849