Водоходъ (Рубрика #ForKids)

Решили прокатиться на кораблике в Нижнем Новгороде. Пришли вчера в кассы компании "Водоходъ" купить билеты, но их на вчера уже не было. Мы решил попробовать покататься сегодня и купили комфорт билеты на сайте Водоходъ. Пришли на посадку, но нам объяснили, что даже с билетами мы не покатаемся на кораблике. На сайте было указано, что для детей до 5 лет включительно билет нужен, но он бесплатный. Опции получить этот бесплатный билет на сайте не было и мы решили получить его в кассах. А в кассах нам сказали, что этот бесплатный билет для детей есть только в тарифе билетов стандарт, а в комфорт надо покупать билеты на всех (но на сайте этой инфы не было). Докупить билет мы не смогли - мест в комфорт не было. Сдать билеты на комфорт нормально тоже не получилось - в кассе сказали "где билет покупали, туда и идите", а на сайте Водохода предлагают заполнять документ и ножками приносить его в офис компании (или присылать письмом Почтой России). Классно, что у нас в Т-Банке есть возможность оспорить любую операцию, по которой не предоставили услугу.

Вывод: оплачивайте картами Т, чтобы иметь возможность оспорить оплату у таких "водоходов".

Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering)

Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем

- Введение и представление гостя
- Детство, образование и первые шаги в IT
- Работа в «Одноклассниках»: начало карьеры
- Инцидент в ОК и переосмысление надежности
- Переход к системной надежности
- Работа с Cassandra и автоматизация процессов
- Новые технологии и взаимодействие команд
- Миграция дата-центра: проект и организация
- Уход из «Одноклассников» 
- Первые шаги с Cassandra в новой роли
- Развитие Cassandra как сервиса в Т-Банке
- Проблемы архитектуры и декомпозиции кода
- Практические выводы и преимущества Cassandra
- Рекомендации инженерам по поводу развития и роста

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems

AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)

Записал расширенную версию доклада, который продолжает мое предыдущее "Интегрируем AI в процессы разработки в большой компании". Тогда я задал рамку и рассказал про то, как подходить к внедрению AI в крупной компании. А на этот раз я сделал фокус на переходе к агентским сценариям и обсудил следующие темы

- Введение и обсуждение темы доклада
- История ассистентов (GitHub Copilot, Cursor)
- Переход к агентам и почему они выглядят как революция
- Примеры агентов и инструменты (Claude Code от Anthropic, OpenAI Codex)
- Инфраструктура и протоколы (MCP, A2A)
- Экономические предпосылки агентского хайпа
- Примеры успешных кейсов от Google AlphaEvolve
- Будущее работы и уровни агентности в исследовании от Stanford
- Управление и регулирование агентов в исследовании от Google Deepmind
- Эволюция SDLC к агентскому Software Engineering 3.0
- Демо агентского режима внутри Т-Банка на примере игры "5 букв"
- Экосистема разработки и цели инженеров в исследовании "Measuring Developer Goals" от Google
- Внутренняя платформа разработки и Spirit и наш подход к AIфикации разработки
- Агентский режим и работа с данными внутри python notebook
- Агентский режим для обеспечения качества и создания тест-кейсов
- Агент для код-ревью
- Агент для поиска уязвимостей (safeliner)
- Измерение эффективности и фреймворки оценки
- Фреймворк для оценки ассистентов и агентов от платформы DX
- Результаты использования ассистентов/агентов в Т-Банке

Разбор и ссылки на все источники для изучения доступны в моем tg-канале
- https://t.me/book_cube/3925
- https://t.me/book_cube/3931

Выпуск подкаста доступен в Youtube, VK Video.

P.S.
Пройдите опрос, чтобы поучаствовать в нашем про влияние AI на разработку в России.

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[2/2] Designing Your Work Life (Дизайн работы мечты) (Рубрика #Career)

Продолжая рассказ про книгу дизайна работы мечты, можно показать как советы авторов разложить на 4 недели

1) Неделя 1 - Диагностика и рефрейм
- Начать вести энергодневник (5 дней). Отмечайте задачи, которые «заряжают/высасывают». Найдите 2‑3 быстрых улучшения (автоматизация, шаблоны, таймбоксы в расписании)
- Сделать рефрейминг топ‑боли. Например, "Слишком много митингов" можно превратить в задачу "за 2 недели сократить суммарно с 10ч до 6ч через 15‑мин стендапы и ассинк‑апдейты". Это и есть MAP (минимально осуществимая проблема), которую перед собой предлагают ставить авторы
- Разделите гравитацию и задачи. "Акции идут на рынке вниз" - это гравитация; а "у нас нет тестов" - это задача.

2) Неделя 2 - Мини‑эксперименты (bias to action)
- Составьте job backlog: выпишите 10 гипотез, что сделает работу лучше/ценнее; выберите 1 с максимальным эффектом
- Раскатите прототип, например, поставьте добавьте no‑meeting block 2×90 мин в своем расписании, или внедрение pre‑commit hooks с прогоном проверок. Только надо определить метрику успеха заранее.
- Проведите несколько инфо‑интервью. Это могут быть 30‑мин разговоры с людьми из интересных команд/ролей. Просите рассказать истории, а не спрашивайте "есть ли вакансии". Зафиксируйте навыки/артефакты, которые реально ценят.

3) Неделя 3 - Remodel/Relocate
- Составьте 1‑пейджер для изменения в своей работе. Что вы убираете/делегируете, что берёте взамен, выгода для команды, риски, план проверки через 2 недели.
- Попробуйте shadow‑ротацию. Попроситесь на 1–2 технических шэдоу‑слота в соседнюю команду (обзор инцидентов, демо). Это безопасный "relocate‑прототип".

4) Неделя 4 - углубление анализа
- Проведите ARC‑скан. Оцените работу по шкале 1–5: автономия/связность/компетентность и проанализируйте, удовлетворены ли эти потребности в его текущей работе, и как можно улучшить ситуацию.
- Оцените как вы хотели бы выглядеть баланс денег, смысла и саморазвития в работе. В долгосрочной перспективе карьеру нельзя измерять одним показателем (например, только зарплатой)
- Внедрите WIP‑лимиты. Не более 2 параллельных задач; остальное в очередь.
- Практикуйте ритуалы роста. Еженедельный короткий пост‑анализ без обвинений: что попробовать иначе в следующем спринте.

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

#Career #Software #Design

Как продакты, аналитики и дизайнеры создают ценность через мышление (Рубрика #ProductManagement)

Интересное выступление Кирилла Николаева, моего коллеги, директор по аналитике в Т-Банке. Кирилл разбирает, что на самом деле стоит за jobs to be done (JTBD) и почему не всегда цель продукта - "снять трение": иногда продукт должен намеренно заставлять пользователя подумать, если это повышает качество решения и снижает риски.

Если выделять ключевые идеи, то в разрезе ролей они выглядят так
- Product manager задает рамку смысла: он формулирует «работу» (JTBD) и желаемое изменение поведения, а не список фич. Цель - ценность, а не “проще любой ценой”.
- Аналитик переводит гипотезу в проверяемые критерии, выбирает метрики качества решения (не только CTR): ошибки, возвраты, LTV‑эффекты, время принятия решения.
- Дизайнер (когнитивный интерфейс): проектирует правильное трение - подсказки, подтверждения, микро‑обучение - там, где «подумать» критично (финансы, безопасность, ответственность).

Почему не всегда надо упрощать - упрощая без разбора, легко ускорить неверные решения. Добавленное «осмысленное усилие» иногда повышает доверие, снижает ошибки и улучшает долгосрочные метрики.

Что это значит для инженеров/техлидов:
- Инфраструктура экспериментов: feature‑flags, канареечные релизы, дешёвая постановка A/B системы, единая схема событий.
- Телеметрия качества решения: события «я понял/подтвердил риски», отмены, возвраты, ошибочные действия, dwell/time‑to‑decide.
- Доступ к объяснимости: журнал «критических точек мышления» (какие подсказки/правила сработали) для дебага и аудита.
- Ритуалы: единый JTBD‑бриф на 1 страницу; общий план экспериментов; еженедельный «decision review» по качественным и количественным сигналам.

Антипаттерны:
- "Оптимизация на клики": растит метрики, но ухудшает решения.
- "Простота ради простоты": убивает безопасность/ответственность там, где пользователю нужно разобраться.
- Feature-driven без JTBD: лечим симптомы, а не работу пользователя.

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

#Software #Metrics #ProductManagement #Software #Design

Vite: The Documentary (Рубрика #Frontend)

На прошлой неделе вышел документальный фильм про Vite или как один побочный проект Эвана Ю (автора Vue.js) за несколько лет изменил весь фронтенд. Начать стоит с того, а почему Vite так важен. Он появился в ответ на то, что Webpack стал слишком медленным и громоздким. В этот момент Эван Ю, автор Vue.js пытался улушить DevEx инженеров, что писали на Vue и он попробовал радикально другой подход: запускать dev-сервер без бандлинга, отдавая модули прямо в браузер через ESModules. Так появился Vite - инструмент, который:
- Стартует почти мгновенно;
- Обновляет код без перезагрузки страницы (hot module replacement, HMR);
- Компилирует зависимости через esbuild и Rollup, обеспечивая скорость на уровне Rust-решений.

В начале фильма звучит фраза «если вы пишете на современном JS-фреймворке, вы, скорее всего, используете Vite» и это уже не преувеличение. На нем работают Vue, SvelteKit, Nuxt, Astro, Remix, Qwik, Laravel, Shopify Hydrogen и десятки других фреймворков. Авторы фильма рассказывают про таймлайн развития технологии, который выглядит примерно так
- 2020 - Первая версия как dev-сервер для Vue.
- 2021 - Vite 2.0 — мультифреймворк, переход SvelteKit и Laravel.
- 2022 - Экосистема взрывается: ViteConf, Vitest, интеграции с Nuxt 3 и Astro.
- 2023 - Remix и RedwoodJS переходят на Vite; анонс Rust-бандлера Rolldown.
- 2024 - Основана компания VoidZero; Vite 6.0, 17 млн скачиваний в неделю.
- 2025 - Премьера фильма и планы на Rust-реализацию всего стека.

Ключевые факторы DevEx, за которые инженеры полюбили Vite
- Скорость: дев-сервер стартует за секунды, HMR - почти мгновенный.
- Простота: минимальная конфигурация и плагинная архитектура.
- Расширяемость: единая база для React, Vue, Svelte, Qwik и др.
- Интеграции: тестирование (Vitest), Storybook, E2E (Cypress, Playwright), Laravel, Rails.
- Сообщество: 850+ контрибьюторов, десятки компаний (Google, Shopify, Cloudflare, NASA, OpenAI).

Но Vite не стоит на месте и окмпания VoidZero уже пишет на Rust собственные инструменты:
- Rolldown - замена Rollup внутри Vite;
- Oxc - быстрый парсер и линтер;
- Есть планы на «Vite +» - единый стек для сборки, тестирования и форматирования.
- Есть движение в сторону AI - на ViteConf 2025 уже обсуждали агентов, помогающих создавать приложения на Vite.

Фильм получился не только про технологию, но и про сообщество: как инженерный «побочный проект» стал точкой объединения фронтенда.

Раньше я уже рассказывал про другие документальные фильмы из этой же серии и могу рекомендовать их любителям технологий и историй про их создание и развитие.
- Kubernetes Documentary
- eBPF Documentary
- Inside Envoy
- GraphQL: The Documentary
- Node.js Documentary
- Python: The Documentary
- Ruby on Rails: The Documentary
- React.js: The Documentary
- Angular: The Documentary

#Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment

Review of Book "AI Engineering" #3 - Chapter 3 & 4: Evaluation Methodology и Evaluate AI Systems(Рубрика #AI)

Вышла третья серия подкаста с разбором крутой книги "AI Engineering", которая дает представление об оценке как самих foundation models, так и приложений на их основе. Книгу разбирает Александр Поломодов, технический директор Т-Банка, а также Евгений Сергеев, engineering director в Flo. Собственно, в этой серии мы обсудили две главы: "Chapter 3: Evaluation Methodology" и "Chapter 4: Evaluate AI Systems". Ну а если раскладывать по темам, то они представлены ниже

- Введение и тема выпуска
- Почему оценка ИИ‑приложений сложна; рост важности валидации
- Валидация в пайплайнах и сложности доменов
- Ограничения бенчмарков и переход к продуктовой валидации
- Риски неконтролируемой генерации
- Теория информации: энтропия как база метрик
- Кросс‑энтропия и KL‑дивергенция для оценки моделей
- Перплексия и влияние контекста на уверенность модели
- Функциональная корректность vs нефункциональные требования
- От лексической к семантической близости; эмбеддинги
- Паттерны валидации и AI as a judge
- Попарные сравнения и ранжирование моделей; транзитивность и голосования
- Каркас системы: критерии → выбор моделей → сборка пайплайнов
- Факт‑чек и референс‑чек; доверенные источники; человеческий бейзлайн
- Дизайн пайплайна: независимые тесты, гайдлайны, разметка; финальные выводы

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов
1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации.
2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers).
3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов.

Как это примерно работало
- Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов.
- Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации.
- Архитектура обработки выглядела примерно так
-- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation.
-- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут.
- Отдельно были сделаны оптимизации
-- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик.
-- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок.
-- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout.

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

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data