Телеграм канал «Клуб CDO»

Последние сбои в AWS, которые на прошлой неделе затронули крупнейшие сервисы, снова подняли старую дискуссию — что лучше: собственная инфраструктура или облако. Такие обсуждения в целом уже обыденность в нашей жизни и я бы оставил их без внимания, но после вчерашнего сбоя в Azure удержаться уже не смог. Лично наша команда никак не пострадала. Мы столкнулись с небольшими сложностями из-за зависимых внешних сервисов, что добавило нагрузки на команду сопровождения, но ядро торговой системы продолжало работать без сбоев. Сам сбой Azure мы, по сути, заметили только из новостей. Мы давно придерживаемся гибридного подхода. При проектировании архитектуры тщательно распределяли компоненты между собственными серверами и облаком, чтобы объединить преимущества и нивелировать слабые стороны. В результате выработали для себя несколько принципов. Первое — все бизнес-критичные задачи должны быть внутри. Речь о тех процессах, без которых нарушается нормальное обслуживание клиентов и выполнение ключевых операций. Главная сложность — правильно определить границы критичности. На первый взгляд кажется, что это почти весь бизнес, но на самом деле важно чётко понимать, за что вы отвечаете перед клиентом, что входит в ваш SLA и какие функции клиент ожидает от продукта. Если часть этих функций вынесена в облако, это тоже должно быть отражено в SLA, ведь сбой стороннего сервиса неминуемо скажется и на клиенте. Второе — задачи с высокой утилизацией процессора выгоднее держать on-prem. Если у вас есть процессы, которые нагружают CPU круглосуточно, покупка собственных серверов быстро окупается. Мы пересчитывали это много раз, и пока факт остаётся фактом: постоянные высоконагруженные вычисления в облаке обходятся дороже. Я вот про “безопасность” я тут наоборот, не пишу. Для уровня middle и small-enterprise бизнеса я считаю что поддержка собственной функции контроля периметра обходится даже выше, чем использование AWS/Azure - там защита из коробки лучше. А защита “каких-то данных” на серверах и в БД является вообще не самым приоритетной точкой. Вектор атаки в 80% случаев нацелен на людей - пароли, доступы, почта, социальная инженерия и тд. Облако подходит для гибкости. Оно идеально, когда нужно быстро или временно нарастить мощности, увеличить объём данных или развернуть дополнительный стенд. В краткосрочной перспективе это удобно и экономично. И не надо забывать про DR. За последние два года я дважды сталкивался с полной недоступностью дата-центров AWS — в Токио и в США. Поэтому резервная инфраструктура в другом DC обязательна, и как раз здесь облако отлично работает: его можно быстро включить и восстановить работу критичных сервисов. В такой системе координат мы мы распределяем задачи между своим железом и облаком.

Мы редко "говорим" о базовых вещах в работе с данными. Вот, например, давайте вспомним про модели структуры данных в классическом хранилище? Никто эту задачу не отменял, мы как и раньше каждый день занимаемся развитием классических реляционных структур и укладываем в них данные для аналитики. И есть ряд "классических" подходов к разработке таких структур: • Dimensional modeling (звёздная/снежинка): факт + измерения, денормализация ради скорости и простоты BI; хорошо для Gold‑слоя в медальонной архитектуре. • Data Vault (Hubs/Links/Satellites): ориентация на интеграцию, историзацию, аудит и гибкость схем; оптимален для Silver‑слоя, далее трансформируется в витрины. • One Big Table (OBT): максимально денормализованная «широкая» таблица для критически быстрых дашбордов/ML‑фич, жертвуя гибкостью. • Кубы/материализованные представления: предрасчёт агрегатов и кеширование для ускорения сложных разрезов. и тд Вот интересная статья которая показывает, что спор «что лучше — Data Vault или dimensional modeling» бессмысленен: эти подходы решают разные задачи на разных этапах. Автор предлагает практический шаблон в рамках medallion architecture: в слое Silver использовать Data Vault для гибкой интеграции, историзации и аудита, а в слое Gold — звёздные схемы для быстрого, понятного анализа и стабильной семантики бизнес‑метрик. Интересно тут то, что подробно разбираются реальные компромиссы — гибкость vs производительность, техники мостинга Silver→Gold (PIT/Bridge, управление суррогатными ключами, SCD Type 2, инкрементальные загрузки), а также организационные практики: метаданные‑драйв, CI/CD, разделение команд и роль семантического слоя. Это даёт применимый чертёж масштабируемой, аудируемой и быстрой платформы без «серебряных пуль». https://www.dataengineeringweekly.com/p/revisiting-medallion-architecture-760

«95% компаний не получают отдачи от инвестиций в GenAI» Это – ключевой тезис недавнего отчета MIT. Первая реакция ожидаема: «GenAI не приносит пользы». Но затем последовала взвешенная оценка: отчет говорит не о бесполезности технологий. Проблема не в моделях, а в процессах и подходах к внедрению. MIT изучили более 300 корпоративных кейсов и выявили четкий разрыв – высокий adoption (распространенность использования), но низкий disruption (преобразующий эффект): ⚪️80% компаний уже экспериментируют с GenAI. ⚪️40% – активно внедряют. ⚪️Но лишь в 5% случаев кастомные корпоративные решения уходят в производство. В чем причины? ▶️Сложность интеграции в негибкие корпоративные процессы. ▶️Неспособность моделей запоминать контекст и учиться. ▶️«Теневое» применение ИИ: сотрудники неофициально используют личные аккаунты ChatGPT и Claude, но компания не видит улучшения финансовой отчетности. Главный барьер – learning gap (разрыв в обучаемости). LLM кажутся простыми, но их внедрение требует перестройки самих бизнес-процессов. А что делают успешные 5%?  ☑️ Не работают в одиночку. Партнерства с внешними вендорами успешны в 67% случаев, а внутренние разработки дают результат лишь в трети. ☑️ Децентрализуют внедрение. Решения инициируют линейные менеджеры и продвинутые пользователи, а не централизованные ИИ-лаборатории. ☑️ Делают ставку на интеграцию. Фокус – на постепенной эволюции и встраивании систем в бизнес-потоки, а не на эффектных демо. Отчет показал: «95% нулевого ROI» – не приговор GenAI, а отражение состояния корпоративных процессов. Мы видим не провал технологий, а огромный разрыв между хайпом и зрелостью внедрения ИИ. #Tech_Inside

Дайджест статей Модель данных для успешного бизнеса: от простоты к компромиссам Статья рассказывает о том, как выбор и развитие модели данных влияет на эффективность бизнеса, от простых решений до необходимости компромиссов при росте системы. https://habr.com/ru/companies/neoflex/articles/959066/ BI в цепочке создания ценности: где аналитика даёт максимальный эффект? Статья рассказывает о том, как бизнес-аналитика (BI) может приносить наибольшую пользу на различных этапах цепочки создания ценности предприятия. https://habr.com/ru/companies/modusbi/articles/959374/ ML в продакшене: почему аналитикам и бэкенду сложно договориться Статья объясняет, почему между аналитиками и разработчиками часто возникают сложности при внедрении моделей машинного обучения в продакшн, и предлагает способы устранения этих барьеров. https://habr.com/ru/companies/oleg-bunin/articles/955850/ Вертикальное шардирование базы данных: проблемы, решения, практические рекомендации Статья рассматривает особенности вертикального шардирования баз данных, типичные проблемы этого подхода и предлагает практические рекомендации по их решению. https://habr.com/ru/articles/959748/ ETL & ELT. От перестановки «слагаемых» результат меняется Статья объясняет различия между подходами ETL и ELT в обработке данных, а также показывает, как выбор подхода влияет на архитектуру и эффективность систем хранения и анализа данных. https://habr.com/ru/articles/960254/ Engineering Reliability With Delta Expectations Статья рассказывает о том, как обеспечить надежность данных с помощью Delta Expectations — механизма проверки качества данных во время их записи. https://dzone.com/articles/delta-expectations-write-time-data-quality Building an AI Agent That Debugs Production Incidents Статья описывает процесс разработки ИИ-агента, способного автоматически обнаруживать, анализировать и устранять инциденты в продуктивной среде программного обеспечения. https://medium.com/@anil.k.nayak8/building-an-ai-agent-that-debugs-production-incidents-e594ac4494ed Data Quality Statistics & Insights From Monitoring +11 Million Tables Статья представляет статистику и ключевые выводы по качеству данных, полученные в результате мониторинга более 11 миллионов таблиц в различных организациях. https://medium.com/data-science-collective/data-quality-statistics-insights-from-monitoring-11-million-tables-94227350d2fa Post-Training Generative Recommenders with Advantage-Weighted Supervised Finetuning Статья описывает новый подход улучшения генеративных рекомендательных систем после обучения с помощью взвешенной по преимуществу техники дообучения с учителем, что позволяет повысить их точность и эффективность. https://netflixtechblog.com/post-training-generative-recommenders-with-advantage-weighted-supervised-finetuning-61a538d717a9 What I Learned Migrating a Legacy Data Stack Into a Modern Lakehouse Architecture Статья описывает опыт автора по переходу от устаревшей системы хранения данных к современной архитектуре Lakehouse, включая трудности, решения и полученные уроки. https://medium.com/towards-data-engineering/what-i-learned-migrating-a-legacy-data-stack-into-a-modern-lakehouse-architecture-c5cac173aeea How RecSys & LLMs Will Converge: Architecture of Hybrid RecoAgents Статья описывает, как рекомендательные системы (RecSys) и большие языковые модели (LLMs) могут быть объединены в гибридные RecoAgents для более точных и персонализированных рекомендаций. https://medium.com/criteo-engineering/how-recsys-llms-will-converge-architecture-of-hybrid-recoagents-03bf3da7d493

На этой неделе прошла конференция Blockchain London — одно из крупнейших событий в области цифровых финансов и технологий. Хотя технических докладов было немного (а точнее, не было совсем), мероприятие получилось насыщенным — акценты были сделаны на финансах, регулировании, платежах и будущем цифровых валют. Особенно запомнились выступления: • CEO Udacity, который рассказал об эволюции автопилотов и обучении систем ИИ на реальных данных; • дискуссия о новых вызовах кибербезопасности в эпоху квантовых технологий — квантовые вычисления уже выходят за пределы лабораторий и начинают менять ландшафт защиты данных; • серия панелей о будущем платежей, стейблкоинов и цифровых активов в международных расчетах. Главный вывод, который можно сделать после конференции: Крипта — это не только про доверие, это про снижение транзакционных издержек. Если раньше я говорил, что фундаментальным критерием эффективности экономики является коэффициент эффективности труда, то теперь добавлю ещё один — стоимость транзакции. Чем ниже цена транзакции, тем больше экономических процессов становится возможным, тем выше их скорость и эффективность. Если ИИ — это про эффективность труда, то крипта — про стоимость транзакции. И вместе они формируют контуры новой, более рациональной экономики будущего.

Почему ИИ-агенты (пока) не заменят ваших сотрудников Про ИИ-агентов говорят все. Но что происходит, когда демоверсию пытаются внедрить в реальный бизнес? Ниже – инсайты от инженера-создателя более десятка таких систем (спойлер: суровая инженерная правда прозаичнее маркетинговых обещаний). • Наслоение ошибок. Допустим, каждый шаг агента точен на 95%. Но если шагов 20, общая надежность падает до 36%. Улучшение промптов не поможет. Нужно разбивать длинные цепочки действий на короткие шаги с верификацией человеком и возможностью отката. • Высокая стоимость работы с контекстом.  ИИ-ассистенты при каждом новом запросе перечитывают всю историю диалога. Объем передаваемых данных растет – а с ним и стоимость. После нескольких десятков сообщений это становится экономически невыгодно. • Сложность создания инструментов для ИИ. Такие инструменты должны давать короткие и четкие ответы, а не перегружать ИИ-агента длинными текстами. Но даже если сам инструмент написан идеально, ему приходится работать со старыми корпоративными системами: тут и ограничения, и задержки, и риски сбоев. Итог: Не стоит гнаться за полной автономией ИИ-агента. Лучше воспринимать его как мощного ассистента с четкими границами: ИИ генерирует идеи и код, человек – проверяет и контролирует выполнение. Такой подход приносит реальную пользу уже сейчас. Больше деталей – в статье по ссылке #Tech_Inside

VTORNIK.Вечер #3 28 октября, с 19:00 до 21:00 мы приглашаем на третье мероприятие в серии. Оно пройдет офлайн и будет посвящено тому, как подходить к внедрению AI в корпорациях. В этот раз вас ждет следующая программа: 1. Дорожная карта ИИ: от быстрых побед к экосистеме и новым возможностям Спикер: Иван Дашкевич, Владелец ИИ-интегратора Octobrain и Главный архитектор Finam Flow – мультиагентного корпоративного ИИ компании Finam. Совладелец, главный архитектор и ключевой разработчик Lia Chat — системного решения для автоматизации первой и второй линии поддержки. 2. AI-First Трансформация. Почему главный барьер — не технологии, а мышление лидеров Спикер: Денис Реймер, Основатель и CEO Reymer Digital. В прошлом: - Вице-президент ГК ЛАНИТ (LANIT-BPM, CleverDATA, DTG) - Директор по продуктам B2B и инновациям, ЭР-Телеком Холдинг - Член совета директоров банков и технологических компаний Executive MBA, IoD Certified Director. Место проведения: Офис наших партнеров — компании «Virtu Systems». м. Кропоткинская / м. Полянка, Берсеневская наб., 6, стр. 2, Москва, 3-й этаж. Мероприятие бесплатное. Регистрация обязательна. Количество мест ограничено. Будем рады всех видеть!